Coolify + Cloudflare too many redirects? Fix the loop

A Coolify application behind Cloudflare can be healthy and reachable while the browser reports ERR_TOO_MANY_REDIRECTS. The container is not necessarily crashing. More often, two layers disagree about the request’s scheme or canonical hostname and keep sending the client back to a URL it has already visited.

The fastest safe fix is not to clear cookies, disable HTTPS, or stack another redirect. Record the actual Location sequence, identify which hop changes, and then remove one conflicting rule. In the common Cloudflare–Coolify–Traefik–application chain, the loop usually comes from Flexible TLS against an HTTPS-enforcing origin, conflicting hostname rules, or an application that ignores the original HTTPS scheme forwarded by its trusted proxy.

A redirect is an HTTP response with evidence: status, host, scheme, path and Location. Capture that evidence before changing Cloudflare, Coolify or application settings.

First, prove the redirect sequence

Use a header-only request without following redirects, then a bounded trace that prints each hop. A browser’s final error hides the useful middle:

curl --silent --show-error --dump-header - \
  --output /dev/null https://app.example.com/

curl --silent --show-error --location \
  --max-redirs 10 --output /dev/null \
  --write-out '%{url_effective} %{http_code}\n' \
  https://app.example.com/

For a readable hop-by-hop trace, repeat the first command against each returned Location, or use curl --verbose in a private terminal. Do not publish cookies, authorization headers, origin addresses or full diagnostic dumps. Test a public unauthenticated path such as /health separately so login middleware does not confuse the result.

1. Use end-to-end TLS, not Flexible mode

Cloudflare documents the classic loop precisely: in Flexible mode, the browser-to-Cloudflare connection can use HTTPS, but Cloudflare contacts the origin over HTTP. If Coolify or the application redirects that HTTP request to HTTPS, the browser requests HTTPS again, Cloudflare sends HTTP to the origin again, and the cycle repeats.

For a normal public Coolify app with a valid origin certificate, set the Cloudflare zone to Full (strict). That keeps both legs encrypted and validates the certificate presented by the origin. Before changing the mode, make sure the exact application hostname exists in Coolify and the origin can serve a valid certificate for it. If Full (strict) produces error 526, repair the certificate rather than falling back to Flexible; the Cloudflare 526 and Coolify certificate guide covers that sequence.

Cloudflare also warns about the inverse conflict: with Full or Full (strict), a rule that redirects origin HTTPS back to HTTP will loop. Remove the HTTPS-to-HTTP rule. The completed state should have one direction—HTTP to HTTPS—not rules pushing both ways.

2. Inventory every redirect owner

A request may be redirected by Cloudflare before it reaches the VPS, by Coolify’s generated Traefik configuration, by nginx or another web server, or by framework middleware. Write down every active rule before editing one:

• Cloudflare Always Use HTTPS, Redirect Rules, Bulk Redirects and Workers;
• Coolify domain entries, including their scheme, apex and www forms;
• Traefik redirect middlewares or entry-point redirects;
• nginx, Caddy or Apache redirects in the deployed source;
• application settings such as a base URL, canonical host, force-SSL middleware or authentication callback URL.

There can be more than one HTTP-to-HTTPS redirect without a loop if every layer agrees, but duplication makes diagnosis harder and can produce needless hops. Prefer one clear owner for each policy: edge or proxy for scheme enforcement, and one deliberate layer for canonical-host redirects.

3. Make apex and www point one way

A common hostname loop looks like this: Cloudflare redirects www.example.com to example.com, while the application redirects the apex back to www. Pick one canonical host, then align every rule with it.

In Coolify, include every hostname that must reach the application long enough to return its redirect. Merely creating a DNS record does not create a matching Traefik router. Then configure one permanent redirect from the alternate host to the canonical host, preserving the path and query string. Update canonical tags, Open Graph URLs, RSS and the sitemap to use that same host.

# Intended result; use your chosen canonical host
http://www.example.com/path  → https://example.com/path
https://www.example.com/path → https://example.com/path
http://example.com/path      → https://example.com/path
https://example.com/path     → 200 application response

Do not redirect a hostname away before Coolify can route it. An unmatched host may hit a default router, hiding the actual rule behind a 404 or certificate error.

4. Check the original scheme at the application

Traefik normally terminates public TLS and forwards HTTP to the application container over a private Docker network. That internal HTTP hop is expected. It also forwards the original request context, commonly through X-Forwarded-Proto: https.

If the framework ignores that trusted proxy information, force-HTTPS middleware sees the internal hop as HTTP and redirects to the same public HTTPS URL. The next request follows the same route and receives the same redirect. This often appears as an HTTPS URL redirecting to itself.

Use the framework’s supported trusted-proxy configuration so it accepts forwarding information from the actual proxy boundary and derives the public scheme correctly. Do not blindly trust forwarded headers from every source: if clients can reach the application directly, arbitrary headers can spoof scheme or client identity. Keep the app private behind Coolify’s proxy and scope trust to the deployment’s supported proxy path.

Useful application evidence is a temporary, access-controlled diagnostic log containing the derived scheme, host and path—not cookies or complete request headers. Remove verbose request logging after the fault is understood.

5. Separate edge behaviour from origin behaviour

If it is safe within your architecture, compare the normal proxied request with a controlled origin test that preserves the real hostname and TLS SNI. Keep the origin destination private:

# Public Cloudflare path
curl --silent --show-error --head https://app.example.com/

# Controlled origin path; run privately and substitute the real destination
curl --silent --show-error --head \
  --resolve app.example.com:443:ORIGIN_ADDRESS \
  https://app.example.com/

• Public loops, origin does not: inspect Cloudflare TLS mode, Redirect Rules, Workers and edge hostname policy.
• Both loop identically: inspect Coolify domain redirects, Traefik, web-server rules and application middleware.
• Origin TLS validation fails: solve certificate issuance or hostname routing before drawing redirect conclusions.
• Origin is intentionally tunnel-only: do not expose or invent a direct route just for this test; inspect tunnel and origin logs instead.

Temporarily switching a production record to DNS-only is not a harmless diagnostic step: it can expose the origin and bypass edge controls. Use direct testing only when the origin is designed to accept it and the rollback path is known.

6. Do not let cached permanent redirects mislead you

Browsers and CDNs can retain 301 or 308 responses after the rule is fixed. Test with curl first because it gives a clean request and visible headers. Then purge only the affected Cloudflare URL if the old redirect was cached, and retest in a fresh browser context.

Cookie clearing is relevant only when the loop depends on session state. It cannot repair a deterministic scheme or hostname conflict visible to a cookie-free curl request. Likewise, disabling HSTS does not fix servers that contradict each other; HSTS simply makes the browser choose HTTPS before the request.

7. Verify the fix without hiding a new fault

After changing the smallest responsible setting, deploy or restart only if that layer requires it. Then verify all entry URLs and one unique page:

curl --silent --show-error --location \
  --max-redirs 5 --output /dev/null \
  --write-out '%{url_effective} %{http_code} %{num_redirects}\n' \
  http://app.example.com/

curl --fail --silent --show-error \
  https://app.example.com/expected-path | \
  grep -F 'EXPECTED UNIQUE HEADING'

The desired result is a short, finite chain to the canonical HTTPS URL and expected content. Also check /health, login or callback routes if used, an asset, and a nonexistent path. HTTP 200 alone is weak evidence because a stale cache or single-page fallback can serve the wrong page successfully.

Safe repair order

1. Capture the first response and every Location value.
2. Classify the loop as scheme, hostname, path or session related.
3. Confirm the exact domain is attached to the intended Coolify app.
4. Use Cloudflare Full (strict) when the Coolify origin has a valid matching certificate.
5. Remove any origin rule that redirects HTTPS back to HTTP.
6. Align apex and www rules toward one canonical host.
7. Ensure the application derives HTTPS through the trusted proxy path.
8. Remove duplicate or contradictory edge, proxy and application rules.
9. Retest without cookies or cached redirects.
10. Prove a finite redirect chain and unique content on the final URL.

Authoritative references: Cloudflare’s ERR_TOO_MANY_REDIRECTS guide documents Flexible-versus-origin HTTPS loops, Full-mode HTTPS-to-HTTP loops, edge settings and conflicting redirect rules. Its Flexible mode documentation explicitly warns against using Flexible when the origin forces HTTPS. Coolify’s domain documentation explains how domain schemes and redirect options generate proxy configuration. Traefik’s RedirectScheme reference explains scheme redirects and the importance of forwarded headers when another proxy is in front.