421 Through a Proxy? Check Target Identity and Connection Reuse

An HTTPS request through a residential proxy returns 421 Misdirected Request. Replacing proxy credentials or repeatedly rotating exits may miss the actual boundary: the target server can reject a request whose authority does not fit the connection context.

This guide proposes a bounded diagnostic plan for owned or explicitly authorized endpoints. It separates proxy setup, target response and connection reuse. It does not report executed tests, guarantee a particular client's behavior or claim every 421 has the same cause.

1. Confirm that the response really is 421

Retain the status line, sanitized response headers, final target URL and the client's stage trace. Distinguish an HTTP response from a TLS verification failure, a failed proxy CONNECT or a local exception. A tool's final error label may hide an earlier response.

MDN describes 421 as a request reaching a server unable to serve the requested scheme and authority. Its example includes connection reuse across hostnames. That is a diagnostic lead, not proof that your incident involves cross-host reuse.

RFC 9110 distinguishes an origin or origin-side gateway's 421 from forward-proxy behavior: a proxy must not generate 421. Therefore, a 421 seen while using a proxy is not automatically a proxy-authentication error. If a component appears to synthesize it, identify that component and its role rather than assuming standards-compliant behavior.

2. Draw the actual connection boundary

Record the proxy endpoint, target scheme/host/port, requested path and client HTTP/TLS configuration separately. With a tunneled HTTPS flow, distinguish connection to the proxy, CONNECT target, TLS session to the destination and the HTTP request sent inside it. Other connection modes need their own documented trace.

Use client diagnostics and owned server logs to record the requested authority, observed TLS server name where available, negotiated HTTP version and a connection identifier or reliable new/reused indication. Mark unobservable fields as unknown. Do not infer target TLS context from the proxy gateway hostname.

Keep the canonical hostname in the URL and retain certificate and hostname validation. Do not replace the target with an IP and merely overwrite Host, or disable TLS checks to obtain a 200. Those changes alter the identity test and can conceal the original mismatch.

3. Run a fresh-connection comparison

1. Choose one harmless GET fixture with a known body marker on an owned or authorized target.
2. Run it with the normal client pool, preserving the exact target URL and proxy settings. Record the observed connection context and response.
3. Use the client's documented way to establish a new target-specific connection, such as an isolated client instance with no existing pool.
4. Verify from trace evidence that a new connection was actually created. Changing a request header alone is not proof.
5. Repeat the same GET once within a fixed deadline and request budget, checking both status and expected body marker.

Fresh success after pooled failure supports a connection-context hypothesis; it does not prove the proxy altered the request or establish a permanent fix. A fresh connection can also reach a different edge or observe changed server state. Retain route and server evidence before attributing the difference.

4. Test cross-host reuse only when it is in scope

If the real client may reuse connections across multiple authorized hostnames, create an owned two-host fixture and record the host sequence. Compare each host on its own fresh connection with the observed pooled sequence. Do not assume a shared address or certificate guarantees the server accepts both hosts on one connection.

Only call this a cross-host reuse test if the trace demonstrates reuse; otherwise mark that condition untested. A client may choose separate connections. Do not manufacture a success by manually mixing an unrelated TLS name and authority on a production site.

When fresh connections also return 421, inspect the target's virtual-host, edge and origin routing configuration with its owner. An authorized baseline route can provide another observation, but differences in DNS or selected edge must be recorded. One successful baseline request does not isolate a single cause.

5. Keep retries distinct from unknown submissions

RFC 9110 permits retrying a received 421 over a different connection even for a non-idempotent method. That permission concerns an actual 421 response; it does not turn a timeout with an unknown submission outcome into a known rejection.

This diagnostic uses a harmless GET so that the connection comparison does not create business side effects. For a real POST, distinguish a confirmed 421 from a lost response, and follow the destination's documented recovery and receipt rules. Never generalize a single 421 into unlimited automatic retries.

After identifying a correction, repeat the affected fixture under the intended pool settings. A fresh-connection workaround can change latency and resource use, so measure those tradeoffs separately before rolling it out broadly. Do not claim a throughput improvement or universal HTTP-version fix from this test.

6. Prepare a compact evidence matrix

• Normal pool, single host: status, body marker and connection context are captured.
• Fresh target connection: exact URL and verification remain unchanged; new connection is demonstrated.
• Owned two-host sequence where applicable: reuse is observed or explicitly marked untested.
• Fresh connection still fails: preserve target routing evidence instead of repeatedly changing credentials.
• HTTP version changed as a separate experiment: record the actual negotiation, not just the requested option.
• Unknown transport outcome: use the appropriate readback workflow rather than treating it as a confirmed 421.

These cases are proposed, not executed measurements. Record case ID, client version, proxy mode, target authority, route label, connection evidence, HTTP version, status and first differing observation. Redact proxy secrets, authorization headers and signed query values.

The 98IP dynamic residential IP page helps identify the product used for authorized route checks. Confirm current connection methods and account options through the API configuration page. These pages do not define the target's virtual-host policy or guarantee cross-origin connection reuse.

FAQ and completion checklist

Is 421 the same as proxy authentication failure? No. Preserve the response stage and identify the responding role before choosing a remedy.

Does fresh success justify disabling TLS verification? No. The identity checks must remain intact for a meaningful comparison.

• The actual 421 and response boundary are captured.
• Proxy endpoint and target identity are recorded separately.
• New versus reused connections are observed rather than assumed.
• Certificate and hostname verification remain enabled.
• Retries are bounded and unknown submissions use readback.
• Only authorized fixtures are used, with no unsupported performance or compatibility claims.