How to Fix 421 Misdirected Request

Table of Contents

A 421 Misdirected Request is an HTTP status code which is an client error response occur when your request sent to server not able to replicate matching/required response since the server is not the authorized one/target source. There are more into the issue that stems from in order to resolve the issue.

Let’s go through detail information on this and help you resolve the issue.

What Is a “421 Misdirected Request” Error?

A “421 Misdirected Request” error is an HTTP error message commonly seen on websites served by Apache or similar web servers, especially when SSL and multiple domains are configured. The error typically appears with the code HTTP 421 and

Description for 421 Error

The client needs a new connection for this request as the requested host name
does not match the Server Name Indication (SNI) in use for this connection.

When you load the website, it will send a request of the url with a header to the server and the server receives the request but it will reply with 421 error indicating that there is some issue with combination of scheme (like HTTP/HTTPS) and authority (host/domain) specified in the request URL which is typically common when hosted in shared hosting server.

Common 421 Misdirected Request Error Message:

1. Terminal/curl

Example message text – HTTP/1.1 421 Misdirected Request

Server: nginx/1.18.0 or Apache/2.4.54 (Unix)

Content-Type: application/json (nginix) or text/html (apache)

Connection: close

Source – Raw server response

2. Browser

Example message text – 421 Misdirected Request (sometimes with additional message below)

Source – Server or user-visible error text

3. Log message (Apache error log)

Example message text – AH02032: Hostname default

Source – Apache domain log (Plesk-specific cases)

4. Proxy-related note

Example message text – Error triggered after proxy setups (nginx -> Apache) without proper passing of SNI

Source – Common in Plesk/nginx proxy environments

What Triggers a 421 Misdirected Request Error?

1. HTTP/2 multiplexing allows clients to reuse a single TCP connection to send requests for multiple domains (virtual hosts), which can sometimes route a request to the wrong backend server or service.

2. If multiple domains share the same IP address or SSL certificate and the server sends the wrong SSL/TLS certificate during the TLS handshake with SNI, the certificate may not match the requested hostname, causes the webserver to refuse the request, believing isn’t routed to correctly match SNI with the respective domain.

3. Web server misconfigure with reverse proxy, load balancer setting which incorrectly route a request to backend which doesn’t handle it.

4. If domain dns is wrongly pointed/configured to server or resolve to wrong server.

5. CDN or proxy service incorrectly forward request when server can’t match or provide result for the request.

6. Browsers or applications caching old connection details

7. The server isn’t set up to correctly match SNI with the respective domain.

8. Any service or platform where an SSL-protected site sits behind a proxy (like Nginx or Cloudflare) can be affected

Actions that could trigger the Error:

1. During website loading, especially right after SSL certificate installation or website migration.

2. When accessing services over HTTPS on shared hosting.

3. API endpoints or services behind a load balancer or reverse proxy.

4. Multi-domain configurations on web servers (Apache, Nginx, LiteSpeed).

5. Redirects between different domains or subdomains that share IP addresses but have distinct certificates or TLS requirements

6. Navigating between multiple subdomains or domains hosted on the same server with different SSL/TLS configurations or certificates.

7. When browsers aggressively reuse HTTP/2 connections for multiple hosts without opening a new one per domain as required by the server’s TLS/SNI setup.

Which Websites or Services Will Be Affected?

1. Website hosted on Plesk that use Nginx as reverse proxy when Apache process request from nginx

2. When website running or using EA-Nginx or other proxies such as Cloudflare

3. Recent Apache update (version 2.4.58-1ubuntu8.6), Apache now has stricter security rules. It demands to know the exact hostname of the site it’s serving via a technology called SNI (Server Name Indication). Because Nginx wasn’t forwarding this specific piece of information, Apache rejects the connection, resulting in the “421” error.

4. Shared hosting environments with multiple domains on the same server or IP using multi-domain certificates

5. Clients who perform redirects across different hostnames/domains on the same connection can trigger this error intermittently

6. Sites migrating domains or switching hosting providers

How to differentiate if client or server issue:

1. If error occurs consistently for a given request regardless of client, it’s almost always a server-side misconfiguration.

2. If error occurs sporadically or clears on retry/refresh, it could relate to client connection reuse and HTTP/2 handling, but generally still points to server limitations in handling those cases.

How to Fix 421 Misdirected Request:

Before making any changes to fix the issue, take a backup of your server configuration and data.

Basic Level Resolution:

1. DNS and Network Configuration:

Verify that your domain’s public DNS records point to the correct IP address of your hosting server. Once confirmed, use tools like nslookup to check DNS resolution and traceroute (or tracert) to verify the network path your requests take to reach the server. If you suspect cached DNS data, flush your local DNS cache to force fresh resolution.

2. Fix Redirects

When a client loads a site and receives a redirect to a different domain, the browser must open a new connection for the redirected domain. If it incorrectly reuses the connection established for the original domain when requesting the redirected site, the server will respond with a 421 Misdirected Request error because the reused connection is not valid for the new domain.

Ensure that clients open a new TCP/TLS connection for the redirected domain by detecting changes in hostname and protocol during redirects. On the server side, configure separate SSL certificates for each domain or properly set up multi-domain certificates with correct SNI handling.

3. Test with Different Client and Browsers:

Different browsers maintain their own cache and cookies and may manage server connections (like HTTP keep-alive) differently. If a problem occurs when using a browser that reuses connections aggressively but does not occur when using tools like Postman or curl that typically open new connections, it suggests the issue may be client-side (related to connection reuse or session management).
However, if the problem persists across multiple different browsers, it likely indicates a server-side issue.

Intermediate Level Resolution:

1. Check SSL/TLS and SNI configuration

Instead of multi domain or wildcard ssl certificate that use single certificate for multiple domains, use separate SSL certificate for each domain or subdomain.

So if nginx forward to apache as a reverse proxy will pass SNI header correctly to server.

2. Load balance or CDN Configuration

When using a load balancer or CDN, make sure it forwards the correct hostname (SNI) during the SSL handshake so the backend server receives the right domain and routes the request properly, preventing errors like 421.

2. Disable HTTP/2 connection Reuse

HTTP/2 allows multiple request to be simultaneously processed over a single connection for improved performance. If there is any misconfiguration on the virtual host or block, then the actual request to the domain could be sent to another domain which use the same ip or might be reject with error 421. Disabling HTTP/2 connection reuse helps avoid misconfiguration-related errors and security leaks.

Advanced/Rare Resolution

1. Server Virtual Host Configuration

When a domain is hosted and an SSL certificate is installed, a virtual host is configured for the domain on the server, either manually or automatically. If the virtual hosts are misconfigured, the server may reject or misroute requests for domains it is not properly set up to serve. In shared hosting, ensure each website has its own virtual host block and that unrelated domains are not combined in the same block, to prevent routing errors and maintain security.

2. Configure Correct Reverse Proxy

If nginx proxied to apache updated version, add directives to forward the host and SNI which allows backend servers to validate the hostname requested and server respective certificate.

For example, in Nginx:

proxy_ssl_server_name on;
proxy_set_header Host $host;

If these headers were not forwarded, it will not provide correct ssl certificate and content.

3. Update Server Software and Patches

Keep your web servers (Apache, Nginx), proxies, and underlying SSL/TLS libraries updated. Some 421 problems result from software bugs or stricter security updates, as seen in Apache 2.4.58+ changes impacting SNI handling.

4. Downgrade Version:

A recent upgrade from ea-apache24 to version 2.4.64 by Cloudlinux has resulted in 421 misdirected requests when combined with NGINX or any other as reverse proxies. Since this is still a work-in-progress, you can do as follow,