Proxy Redirect Loops: Trace Location Headers, Scheme Changes, and Session State
A proxy redirect loop is a repeating chain of HTTP 301, 302, 303, 307, or 308 responses in which the client never reaches a stable final page. Before changing the proxy exit, turn off automatic redirect following for one controlled request and record every response status and Location value. Keep the target URL, client, proxy endpoint, test time, and session state fixed.
The first useful question is not whether the proxy is good or bad. It is which two states keep disagreeing: HTTP versus HTTPS, one hostname versus another, one region versus another, signed-in versus signed-out, cached versus fresh, or local DNS versus proxy-side DNS. The repeated transition identifies the layer to test.
Classify the repeating redirect pair
| Repeating pattern | Likely disagreement | Evidence to capture first |
|---|---|---|
| HTTP to HTTPS, then HTTPS to HTTP | Scheme detection or forwarded headers | Status, Location, request scheme, and proxy headers |
| www to apex, then apex to www | Canonical host rules | Host header and each absolute Location value |
| Country path A to B, then B to A | Region, language, or geolocation policy | Exit region, cookies, headers, and final DNS address |
| Login to callback, then callback to login | Session or callback state | Cookie scope, callback host, and redirect parameters |
| Only one client loops | Cache, HSTS, service worker, or client policy | Fresh-client comparison and response headers |
| Only the proxied path loops | Proxy headers, exit region, DNS, or upstream edge | Direct-versus-proxy chain comparison |
1. Capture the chain without following it automatically
Send a low-risk request with redirects disabled. For each hop, record the requested URL, response status, exact Location header, response host, protocol, timestamp, and whether the next URL is absolute or relative. Stop after a small fixed number of hops, such as ten. A browser error page alone hides the transition that matters.
A pass is one intentional redirect followed by a stable success response. A fail is a repeated URL pair or repeating sequence. An ambiguous result is a chain that changes on each run; capture the varying hop and check region, cache, and session inputs before drawing a conclusion.
2. Check scheme and port interpretation
A common loop occurs when the public request is HTTPS but an upstream application believes it received HTTP. The application redirects to HTTPS, while another proxy or routing rule rewrites the request back to HTTP. Compare the external URL, upstream scheme, target port, and any approved forwarded-protocol header used by the deployment.
Do not add arbitrary forwarding headers from an untrusted client. Confirm the expected proxy boundary and header policy with the application owner. Also verify that the configured proxy scheme is supported by the client using the protocol mismatch checks; an HTTP proxy URL, HTTPS proxy transport, and SOCKS5 endpoint are not interchangeable in every library.
3. Compare host and canonical URL rules
Write down the host for every hop. Look for changes between an apex domain and www, between alternate subdomains, or between a public hostname and an internal hostname. Two independent canonicalization rules can each consider the other host incorrect and send the client back.
Test the intended canonical host directly through the same proxy endpoint. A pass ends on one documented hostname. A fail alternates between hosts. Stop and escalate if a redirect leads to an unrelated domain, an unexpected login host, or a destination outside the approved application boundary.
4. Separate regional routing from application routing
A proxy exit can change the region signal seen by an upstream service. The site may redirect to a country or language path while a stored preference, application setting, or another edge layer redirects back. Record the exit country, requested path, language header, existing preference state, and each regional Location value.
Use the proxy region drift checklist when the redirect begins after login or after an exit change. Keep the test region fixed. Rotating exits during diagnosis changes the input and can make a deterministic policy conflict look random.
5. Test session state without copying credentials
Authentication flows may loop when the login host sets state for one domain, the callback returns to another, or the application cannot validate the expected session. Compare a signed-out low-risk request with an approved test session. Record cookie names and scope metadata without exposing values, along with callback host, status, and Location sequence.
Do not import or reuse another user’s cookies. If a clean signed-out request passes but an approved test session loops, follow the session continuity checklist and inspect domain, path, secure flag, same-site policy, expiry, callback state, and whether the exit changed during the flow.
6. Rule out cache, HSTS, and service-worker differences
A cached redirect can preserve an old host or path after server rules change. HSTS is not an HTTP redirect, but it can upgrade a request before the first visible response and distort a scheme comparison. A service worker can also modify navigation behavior for one browser profile while a command-line client remains unaffected.
Compare the chain in a fresh approved client with no prior site state, then inspect cache-control headers and browser network records. Do not clear production user state as the first step. If the fresh client passes, isolate the affected cache or client policy and retest one change at a time.
7. Compare local and proxy-side DNS results
Direct and proxied requests may resolve the same hostname through different DNS systems, address families, or edge regions. Record local A and AAAA answers, the connected address family, proxy-side resolution mode when supported, and the response host. A stale or regionally inconsistent edge can apply a different canonical rule.
For SOCKS5 paths, use the SOCKS5 DNS resolution guide to distinguish local resolution from remote resolution. Do not treat forcing IPv4 or changing DNS as a permanent fix until a controlled comparison proves that the redirect chain changes with that single variable.
8. Run a direct-versus-proxy comparison
Use the same device, client version, target URL, request headers, and time window. Run one direct request and one request through a fixed proxy endpoint with redirect following disabled. Compare every status and Location value, plus the final connected address and response timing.
If both paths loop identically, focus on application, canonical host, or session policy. If only the proxied path loops, investigate exit region, forwarding boundaries, DNS, and the upstream edge selected by that route. If neither result repeats, preserve the evidence and repeat later rather than declaring a repair without a reproducible failure.
9. Apply pass, fail, ambiguous, and stop conditions
| Outcome | Evidence | Next action |
|---|---|---|
| Pass | The chain reaches the documented final host and stable success response | Restore redirect following and resume gradually |
| Fail: deterministic loop | The same two or more URLs repeat with fixed inputs | Repair the conflicting scheme, host, region, or session rule |
| Fail: proxy-only loop | Direct passes while the fixed proxied path repeats | Inspect proxy boundary, exit region, DNS, and selected edge |
| Ambiguous | The sequence changes between identical attempts | Capture variance in time, DNS, cache, and session inputs |
| Stop | The chain leaves the approved domain set or exposes an unknown login destination | Isolate the route and escalate before sending credentials |
10. Retest one repair in a controlled lane
Choose the smallest repair supported by the evidence: one canonical host rule, one trusted forwarded-scheme setting, one regional preference, one callback configuration, or one DNS path. Retest one target through one fixed endpoint. Do not rotate the exit, change the client, and clear state in the same attempt.
Resume only when repeated tests reach the intended final URL with the expected scheme, host, region, and session outcome. When selecting proxy service options, prefer configurations that make protocol, region, session behavior, and endpoint history observable so the same comparison can be repeated.
11. Keep a compact redirect-loop record
- Initial URL, method, client version, and test time
- Proxy protocol, endpoint, exit region, and authentication result
- Each status code and exact Location value
- Host, scheme, port, and connected address for each hop
- Local or proxy-side DNS mode and address family
- Signed-out or approved test-session state
- Direct-path and proxied-path comparison
- Repair attempted, retest result, and stop decision
Store the sequence in a proxy error log template. A complete chain lets application, network, and proxy owners see the same evidence without reducing the incident to a generic browser message or repeatedly replacing exits.
Conclusion: find the disagreeing state
Proxy redirect loops become manageable once every hop is visible. Disable automatic following for a controlled request, identify the repeating pair, and compare scheme, host, region, cache, session, DNS, and direct-versus-proxy evidence. The loop usually reflects two components enforcing incompatible views of the same request.
Keep the inputs fixed, change one verified setting, and retest until the chain reaches a documented final state. Stop when the redirect leaves the approved domain boundary or the evidence cannot explain where credentials would be sent.