Cloudflare Tunnel · Reverse Proxy · Help

Cloudflare Tunnel: ERR_TOO_MANY_REDIRECTS

Trace Location headers and the origin scheme when an application enters a redirect loop through the tunnel.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

A redirect loop requires identifying which service produces the first incorrect redirect. Record the Location chain and correlate it with origin and proxy logs. Then inspect the actual origin protocol, hostname and trusted handling of forwarded information. A working LAN request with a different name or protocol does not prove correct tunnel configuration; the reported version comparison does not establish a general cause.

Source basis: Q1 · Q2 · Q3

Applies to
Covers applications behind Cloudflare Tunnel and additional reverse proxies. The report names cloudflared 2026.8.0 and TrueNAS chart 2.0.16 without confirming a specific cause.
How to verify the result
A fresh browser session reaches the intended canonical host, login and subsequent navigation work without looping, and the recorded redirect chain follows the intended flow.
Your first check

Which component produces the first repeated redirect?

Record status and Location for a harmless request, then compare equivalent host and scheme conditions at the origin. A simple LAN request may be a different test.

The browser reports ERR_TOO_MANY_REDIRECTS. Other routes work, the connector is connected, and the application opens on the LAN. A report involving cloudflared 2026.8.0 describes repeated redirects to the same URL. A version comparison was significant in that report, but a definitive root cause was not established. Q1

The LAN request may not be equivalent

An internal HTTP address, public HTTPS hostname and different Host header can lead the application to make different decisions. Successful LAN access therefore does not automatically clear the origin of involvement. A healthy tunnel status also verifies only part of the path. Q2

Trace the loop deliberately

  1. Capture the first redirect. Use browser network tools or an HTTP client with bounded redirect following. Record request URL, response status and Location, without sharing cookies or access tokens. Repetition of the exact URL is different from alternation between two hostnames.
  2. Locate the producer in logs. Correlate time and path across tunnel, proxy and application logs. An identifying response header alone may be misleading; a matching logged response provides stronger evidence about where the redirect originated.
  3. Inspect the service URL. Check whether the tunnel contacts an HTTP listener that always redirects to HTTPS. Use the intended origin scheme with correct certificate verification. Arbitrarily reducing TLS protection does not resolve contradictory redirect logic.
  4. Compare host and proxy information. Check the application's public base URL and expected forwarded headers. Trust those headers only from the intended proxies. A header supplied by any external client must not become a blanket source of trusted connection information.
  5. Test the version separately. If the problem began after an update, use a limited test instance under equivalent routing conditions. Do not change TLS mode and application configuration at the same time as the connector version.

Verify more than the first response

After a bounded correction, confirm that normal sign-in and a harmless subsequent page work. Check the canonical hostname and the behaviour of a new session. If the origin uses a different hostname, the documented HTTP and TLS identity parameters may be relevant. Q3

For handoff, prepare a short sanitised redirect chain, service URL, connector version, recent changes and matching log entries. Clear cookies only when a specific session comparison justifies doing so; it will not repair a server that continually redirects a request to itself. Preserve the previous configuration so that each comparison remains understandable.

Frequently asked questions

Do I need to disable HTTPS?

No. First identify which component is processing inconsistent scheme or hostname information.

Does successful LAN access prove a Cloudflare fault?

Not without equivalent host, scheme and proxy conditions. The two requests can trigger different application behaviour.

Describe your case

Support with this issue

We can investigate the redirect chain, origin destination and trusted proxy headers.

Describe your case →Related service: Data & improvements

Sources