421 Error | Fast Fixes For Misdirected Requests

You’ll see this when traffic lands on the right IP, then asks for the wrong “virtual host.” The server refuses because the name it saw during TLS handshaking doesn’t line up with the name inside the HTTP request. It can feel random since a refresh might load, but the mismatch is still there.

You’ll get the meaning in plain terms, the common triggers, a checklist by stack, plus tests that confirm the fix.

What The 421 Status Means In Plain Terms

Servers host many sites on one IP. They sort requests by host name. On HTTPS, that host name can show up twice. One copy is the TLS SNI value sent at the start of the handshake. The other is the HTTP Host header sent with the request.

When those two names don’t match, the server can’t safely decide which site should answer. With HTTP/2, it can show up more because browsers reuse a single connection for multiple host names when certificates and settings allow it. If the server can’t map the request’s host to the active TLS context, it responds with status 421, also called “Misdirected Request.”

If the site loads on refresh, suspect a name mismatch tied to connection reuse, not a broken app.

Why 421 Shows Up On Real Sites

A 421 is rarely “a WordPress problem.” It’s usually a routing detail in front of the app. The app can be healthy while the edge can’t decide which host should answer.

Shared IP With Multiple HTTPS Sites

When multiple domains share one IP, SNI is the traffic cop. If a client connects without sending SNI, or sends the wrong name, the server falls back to a default certificate and vhost. Then the HTTP request arrives with a different Host header. That mismatch can trigger 421.

Reverse Proxy Or Load Balancer Name Drift

Some proxies pass the Host header fine, yet connect to the origin with an empty or different SNI value. If the origin uses SNI to choose the right certificate or vhost, it can reject requests where the Host header says one thing and SNI says another.

HTTP/2 Connection Reuse Across Host Names

Browsers try to be efficient. If two host names share a certificate and point to the same IP, the browser may reuse an existing HTTP/2 connection for the next host.

Web Server Updates That Tighten Checks

Some updates tightened validation around SNI and Host matching. It can expose proxy configs that “worked by accident.” If your 421 started right after an update, suspect stricter validation rather than a sudden app failure.

Common Cause	Where To Check	Fast Fix
Wrong SNI sent to origin	Proxy TLS upstream settings	Send SNI that matches the served host
CDN origin host mismatch	CDN origin host header setting	Match origin host to the cert on the origin
Missing default SSL vhost	Apache/Nginx default site	Set a safe default vhost and cert
HTTP/2 coalescing surprises	Browser + cert SAN list	Split certs or adjust HTTP/2 use

Fixing 421 Error On Shared IP And Reverse Proxies

If you only change one thing, align the name used during TLS to the origin with the host name you want the origin to serve. In practice, that means aligning SNI and Host.

Confirm The Mismatched Names

Pull the exact error text from the browser, the CDN, and the origin logs. Many servers spell it out, like “requested host name does not match the SNI in use.” That line is your north star.

• Check The Requested URL — Confirm the host in the URL bar, plus any redirect targets. A stray www or staging subdomain can flip the Host header.
• Check The Origin Certificate — Verify the cert includes the host you serve, including the www or non-www form you redirect to.
• Check DNS Records — Confirm A and AAAA records point where you think they do, not to an old IP.

Fix SNI Forwarding In Proxy Setups

Many stacks terminate TLS at the edge, then re-encrypt to the origin. If that second leg uses HTTPS, you must send SNI.

• Enable Upstream SNI — In Nginx, use proxy_ssl_server_name on. Set proxy_ssl_name to the origin host when proxying to HTTPS.
• Pass A Clean Host Header — Keep the original Host header, or set it to the origin host your vhost expects. Don’t let it drift between domains.
• Verify With One Host — Route one domain through the proxy, confirm it loads, then add the next domain.

CDNs Like Cloudflare

With a CDN in front, you can get a 421 when the CDN connects to the origin using one host name while the HTTP request asks for another. This can happen after moving origins, changing SSL modes, or setting a custom origin host header.

• Match The Origin Host Header — Set the CDN to use the same origin host that exists on your origin certificate and vhost.
• Use Strict Validation Carefully — If the CDN checks the origin cert name, the host used for TLS must match that cert.
• Check Redirect Chains — A redirect between www and apex can expose host mismatch on the first request.

After proxy changes, you don’t need a full cache purge. A private window forces new connections and is a reality check.

Fix Checklist For Common Stacks

Different stacks fail in different places. Use the checklist that matches your setup. If you run a hosting panel, also check its updates, since panels may ship patches after upstream web server changes.

Nginx In Front Of Apache

This combo triggers 421 when Nginx proxies to Apache over HTTPS while Apache expects SNI. If Nginx doesn’t send SNI, Apache picks a default host, then rejects the request once it sees a different Host header.

1. Turn On Upstream SNI — Enable SNI on the Nginx proxy connection and set the upstream name to the host you serve.
2. Keep Names Consistent — Pass Host as the requested domain, unless your origin vhost expects a different internal name.
3. Set A Default SSL Site — Configure a default SSL vhost so no-SNI traffic lands somewhere predictable.
4. Reload Both Services — Reload Nginx and Apache so new connections pick up the new settings.

Apache With Many TLS Virtual Hosts

Apache can emit 421 when the negotiated SNI doesn’t match the Host header. It shows up more on HTTP/2, especially when multiple sites share an IP.

1. Validate ServerName Entries — Ensure each domain has a matching ServerName and needed ServerAlias values.
2. Confirm One Safe Default — Make sure the first loaded SSL vhost is a safe catch-all.
3. Run A Targeted HTTP/2 Test — Disable HTTP/2 for one vhost, test, then re-enable once SNI and Host are aligned.

Control Panels And Managed Hosts

If the issue started right after a web server update, your panel may already have a fixed build. Some users saw 421 after Apache patches that tightened SNI checks.

1. Install Recommended Updates — Apply the panel’s web server and proxy packages that mention 421 or SNI fixes.
2. Remove Temporary Pins — If you pinned Apache to avoid the error, unpin once the fixed build is available.
3. Rebuild Vhost Config — Use the panel’s rebuild tool to regenerate vhost files after updates.

WordPress Behind A CDN

WordPress usually isn’t the trigger, but redirects can make the mismatch visible. A plugin that forces HTTPS or rewrites host names can push traffic toward a name the origin doesn’t serve.

1. Confirm WordPress Site URLs — Ensure WordPress URL and Site URL match the canonical host you want.
2. Pause Host-Rewrite Rules — Disable redirect plugins and rules, test, then re-enable once host handling is clean.
3. Align CDN Host Settings — Ensure the CDN connects to the origin host your certificate includes.

If you still see 421 after those checks, look for split DNS or an extra AAAA record. One record pointing to an older origin can create a “some users only” pattern that’s hard to spot.

Preventing 421 From Coming Back

Once the site loads, spend a few minutes on guardrails. Most repeat incidents come from new domains, new certs, or a proxy change that drops SNI on the origin leg.

Make One Canonical Host And Stick With It

Pick one canonical host, then redirect everything to it. Keep the origin vhost, the origin certificate, and the CDN’s origin host header aligned to that choice.

• Standardize Redirects — Use one redirect chain, not a pile of layered rules.
• Include Both Common Versions — If you accept www and non-www, include both on the cert and vhost.

Be Careful With Multi-Domain Certificates

Multi-domain certificates can encourage browsers to reuse connections across host names. If your setup can’t safely answer those hosts on one connection, split certificates by site or disable HTTP/2 on the hosts that collide.

• Separate Unrelated Sites — Use different certificates or different IPs for sites that don’t need to share.
• Watch Wildcards — Wildcards can pull in names you didn’t plan to co-host.

Log Enough To Spot A Repeat

When 421 comes back, speed matters. Add logging that tells you which name the client asked for and which name the server selected.

• Log Host And SNI — Include the requested host, the server name, and the upstream name in logs where possible.
• Alert On 421 Spikes — A short burst can point to a proxy deployment or a DNS change.

Quick Tests To Prove The Fix Worked

You don’t need fancy tools. You just need fresh connections and a clean pass over your host variants.

1. Use A Private Window — This avoids connection reuse from your main session.
2. Load The Canonical Host — Visit the exact host you want people to land on, then click a few internal links.
3. Test Redirect Variants — Try www and non-www, plus http to https, and confirm each ends at the same host.
4. Check Another Network — A hotspot can reveal stale DNS paths.
5. Scan Origin Logs — Confirm no new 421 entries appear during your test window.

One last sanity check can help when you’re unsure where the mismatch lives. Run a direct HTTPS request to the origin that sets the host name for TLS and the Host header to the same value. If that works, the origin is ready, and the remaining work sits in the CDN or proxy settings.

If you see a 421 error again after a change, go straight to names first. SNI, Host headers, and cert names are the usual suspects.