Summary After updating the cloudflared TrueNAS SCALE community app, one specific hostname routed through Cloudflare Tunnel started failing with ERR_TOO_MANY_REDIRECTS, while a second hostname on the same tunnel kept working normally, and the backend app itself worked fine when accessed directly on the LAN. Rolling the cloudflared app back to the previous version immediately fixed the issue with no other configuration changes.
Symptom Visiting the affected hostname (e.g. https://app.example.com/) resulted in ERR_TOO_MANY_REDIRECTS in the browser. The second hostname on the same tunnel (https://other-app.example.com/) continued to work correctly the entire time — ruling out a full tunnel outage. The origin app worked perfectly when accessed directly on the LAN (http://:/...), both before and during the incident — ruling out an app-level bug. In DevTools → Network, the request chain showed dozens of 301 Moved Permanently responses to the same path (e.g. /web/), where the response Location header was byte-for-byte identical to the request URL — i.e. the server (or tunnel) was redirecting the request to itself, indefinitely. This happened consistently whether the initial request was made over plain HTTP or HTTPS (confirmed by manually typing https:// explicitly in a fresh Incognito window with cache disabled — the loop was identical, ruling out any browser/HSTS/cache artifact). Content-Length: 0 on the redirect responses, and Cloudflare's X-Response-Time-Ms header showed sub-millisecond values, though this alone was not conclusive about whether the response originated at the edge or was passed through from origin.
To Reproduce Steps to reproduce the behavior:
Run cloudflared as a TrueNAS SCALE app (remotely-managed tunnel, Public Hostname configured via Zero Trust dashboard) with chart version 2.0.16 / App Version v2026.8.0.
Route a hostname to a plain-HTTP origin service (http://:).
Access the hostname from a browser (e.g. https://app.example.com/web/).
Observe ERR_TOO_MANY_REDIRECTS — the origin/tunnel responds with 301 redirects where the Location header is identical to the requested URL, looping indefinitely.
If it's an issue with Cloudflare Tunnel: 4. Tunnel ID: Omitted — happy to provide privately if needed for triage. 5. cloudflared config: Remotely-managed tunnel, ingress configured via the Zero Trust dashboard "Published application" UI:
Hostname: app.example.com → Service: http://: (BROKEN after 2.0.16)
Hostname: other-app.example.com → Service: http://: (worked fine throughout) Both hostnames are on the same tunnel, same LAN host, same "plain HTTP origin" pattern. cloudflared version: 2.0.16 (broken) — issue resolved by rolling back to 2.0.14.
Expected behavior The request should reach the origin service normally, as it did before updating cloudflared, and as it still does for a second hostname on the same tunnel.
Environment and versions
TrueNAS SCALE 25.04 (Fangtooth)
cloudflared installed as a TrueNAS SCALE community catalog app
Broken: App Version v2026.8.0, chart version 2.0.16
Working (after rollback): chart version 2.0.14
Remotely-managed tunnel (configured via Zero Trust dashboard, not a local config.yml)
Logs and errors Origin-side logs (backend app) show a clean, successful startup on every request cycle — no exceptions, no errors — ruling out an origin crash or app-level redirect bug.
Browser-side (Chrome DevTools → Network, cache disabled, fresh Incognito session), a representative request/response pair from the loop:
Request: GET https://app.example.com/web/ :scheme: https
Response: 301 Moved Permanently Location: https://app.example.com/web/ <-- identical to the request URL Content-Length: 0 Server: cloudflare
This exact request/response pair repeats indefinitely until the browser aborts with ERR_TOO_MANY_REDIRECTS. Confirmed identical behavior with an explicit https:// request from a clean Incognito window (no cache/HSTS involved).
Additional context Before filing, ruled out every layer except cloudflared itself:
Origin app's own HTTPS-redirect setting: disabled, not the cause.
No Cloudflare Page Rules, Redirect Rules (Single/Bulk), Workers Routes, Snippets, or WAF Custom Rules configured for the affected hostname.
DNS record for the affected hostname: correct CNAME to .cfargotunnel.com, proxied.
A second hostname on the identical tunnel, pointed at a different plain-HTTP origin on the same LAN host, was unaffected the entire time.
Given all of the above, cloudflared chart version 2.0.16 (App Version v2026.8.0) is the only remaining variable, and rolling back to chart 2.0.14 fixed it immediately with zero other changes. Happy to provide further diagnostic detail (HAR export, header dumps, tunnel ID privately) if useful.
Summary After updating the cloudflared TrueNAS SCALE community app, one specific hostname routed through Cloudflare Tunnel started failing with ERR_TOO_MANY_REDIRECTS, while a second hostname on the same tunnel kept working normally, and the backend app itself worked fine when accessed directly on the LAN. Rolling the cloudflared app back to the previous version immediately fixed the issue with no other configuration changes.
Symptom Visiting the affected hostname (e.g. https://app.example.com/) resulted in ERR_TOO_MANY_REDIRECTS in the browser. The second hostname on the same tunnel (https://other-app.example.com/) continued to work correctly the entire time — ruling out a full tunnel outage. The origin app worked perfectly when accessed directly on the LAN (http://:/...), both before and during the incident — ruling out an app-level bug. In DevTools → Network, the request chain showed dozens of 301 Moved Permanently responses to the same path (e.g. /web/), where the response Location header was byte-for-byte identical to the request URL — i.e. the server (or tunnel) was redirecting the request to itself, indefinitely. This happened consistently whether the initial request was made over plain HTTP or HTTPS (confirmed by manually typing https:// explicitly in a fresh Incognito window with cache disabled — the loop was identical, ruling out any browser/HSTS/cache artifact). Content-Length: 0 on the redirect responses, and Cloudflare's X-Response-Time-Ms header showed sub-millisecond values, though this alone was not conclusive about whether the response originated at the edge or was passed through from origin.
To Reproduce Steps to reproduce the behavior:
Run cloudflared as a TrueNAS SCALE app (remotely-managed tunnel, Public Hostname configured via Zero Trust dashboard) with chart version 2.0.16 / App Version v2026.8.0.
Route a hostname to a plain-HTTP origin service (http://:).
Access the hostname from a browser (e.g. https://app.example.com/web/).
Observe ERR_TOO_MANY_REDIRECTS — the origin/tunnel responds with 301 redirects where the Location header is identical to the requested URL, looping indefinitely.
If it's an issue with Cloudflare Tunnel: 4. Tunnel ID: Omitted — happy to provide privately if needed for triage. 5. cloudflared config: Remotely-managed tunnel, ingress configured via the Zero Trust dashboard "Published application" UI:
Hostname: app.example.com → Service: http://: (BROKEN after 2.0.16)
Hostname: other-app.example.com → Service: http://: (worked fine throughout) Both hostnames are on the same tunnel, same LAN host, same "plain HTTP origin" pattern. cloudflared version: 2.0.16 (broken) — issue resolved by rolling back to 2.0.14.
Expected behavior The request should reach the origin service normally, as it did before updating cloudflared, and as it still does for a second hostname on the same tunnel.
Environment and versions
TrueNAS SCALE 25.04 (Fangtooth)
cloudflared installed as a TrueNAS SCALE community catalog app
Broken: App Version v2026.8.0, chart version 2.0.16
Working (after rollback): chart version 2.0.14
Remotely-managed tunnel (configured via Zero Trust dashboard, not a local config.yml)
Logs and errors Origin-side logs (backend app) show a clean, successful startup on every request cycle — no exceptions, no errors — ruling out an origin crash or app-level redirect bug.
Browser-side (Chrome DevTools → Network, cache disabled, fresh Incognito session), a representative request/response pair from the loop:
Request: GET https://app.example.com/web/ :scheme: https
Response: 301 Moved Permanently Location: https://app.example.com/web/ <-- identical to the request URL Content-Length: 0 Server: cloudflare
This exact request/response pair repeats indefinitely until the browser aborts with ERR_TOO_MANY_REDIRECTS. Confirmed identical behavior with an explicit https:// request from a clean Incognito window (no cache/HSTS involved).
Additional context Before filing, ruled out every layer except cloudflared itself:
Origin app's own HTTPS-redirect setting: disabled, not the cause.
No Cloudflare Page Rules, Redirect Rules (Single/Bulk), Workers Routes, Snippets, or WAF Custom Rules configured for the affected hostname.
DNS record for the affected hostname: correct CNAME to .cfargotunnel.com, proxied.
A second hostname on the identical tunnel, pointed at a different plain-HTTP origin on the same LAN host, was unaffected the entire time.
Given all of the above, cloudflared chart version 2.0.16 (App Version v2026.8.0) is the only remaining variable, and rolling back to chart 2.0.14 fixed it immediately with zero other changes. Happy to provide further diagnostic detail (HAR export, header dumps, tunnel ID privately) if useful.