t4mer@notebook

// problem · 18 june 2026 · 1 min

HTTP 421 Misdirected Request caused by an incorrect Host header

A 421 that looked like Nginx until the outbound Host header showed up.

Time wasted: 2 hours

Problem

An outbound API call from Laravel returned 421 Misdirected Request. The same URL worked in Postman.

Environment

Laravel HTTP client / Guzzle Nginx HTTPS

Symptoms

HTTP 421 from the client. Application logs sometimes quiet depending on whether the request left Laravel at all. curl/Postman succeeded. Restarting PHP-FPM did nothing.

Expected

A normal JSON response from the provider.

Investigation

Checked Laravel routes and APP_URL first (wrong layer). Compared nginx server blocks. Then dumped the raw outbound request from Guzzle.

Things I tried

Restarted PHP-FPM. Blamed a deploy. Compared staging nginx. Recreated the call in Tinker with “the same” URL. None of that changed the Host header I had set manually.

Root cause

A manually supplied Host header that did not match the URL’s host - and/or HTTP/2 connection reuse across names when TLS was involved. 421 is about authority and connection, not about JSON.

Solution

Stopped setting Host by hand. Let the client derive it from the URL. For the TLS/vhost variant, aligned certificates and server names and stopped assuming HTTP/2 reuse is always safe.

Why it worked

Proxies and origin servers decide which vhost or certificate applies using the connection and the Host/authority. If those disagree, 421 is a legitimate refusal.

Lesson

When HTTP behaves strangely, inspect the actual request before blaming the framework. 421 is trying to tell you about authority.

Found something wrong?

These notes can be incomplete, or wrong in a different environment. Suggest a correction on GitHub or email me at me@t4mer.net.

// related