An HTTPS redirect loop means two or more layers disagree about the request scheme. A browser may show only repeated https:// URLs, but the redirect can originate in NGINX, a load balancer, an ingress controller, a CDN, a tunnel, or the application itself. The reliable fix is to trace every hop, identify where TLS terminates, and make exactly one trusted layer own the HTTP-to-HTTPS decision.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The most common case is a proxy that accepts HTTPS from the visitor but forwards HTTP to NGINX. NGINX then believes the request is insecure and redirects it to HTTPS; the proxy sends the redirected request back over HTTP, producing the same response forever. Cloudflare documents the equivalent loop when Flexible mode talks HTTP to an origin that forces HTTPS.
As an Amazon Associate I earn from qualifying purchases.
What an HTTPS redirect loop looks like
Browsers usually report ERR_TOO_MANY_REDIRECTS after following a limited number of redirects. The visible address can remain unchanged, or it can alternate between http:// and https://. A redirect is not limited to status 301: NGINX, ingress controllers, applications, and proxies can emit 301, 302, 307, or 308 responses.
The important clue is the Location header. If every response points to the same URL, one layer is repeatedly applying the same policy. If the scheme alternates, one layer is forcing HTTPS while another is sending traffic back to HTTP. A loop can also involve a hostname change, a port change, or a tunnel service URL that keeps re-requesting the same HTTP origin.
#1 Best Overall
| Status | How it can participate in a loop |
|---|---|
| 301 | Permanent redirect commonly used for HTTP-to-HTTPS rules. |
| 302 | Temporary redirect that can still repeat indefinitely. |
| 307 | Temporary redirect that preserves the request method. |
| 308 | Permanent redirect that preserves the request method. |
The core rule: trace every hop
The browser’s URL does not identify the component that sent a redirect. Start at the client and follow the request through the CDN or load balancer, ingress, NGINX, tunnel, and application. At each hop, establish three facts:
- Did this component receive HTTP or HTTPS?
- Did it forward HTTP or HTTPS to the next component?
- Did it generate a
Locationheader or simply pass one through?
Only one layer should normally enforce the public HTTP-to-HTTPS policy. Other layers must recognize an already-secure request instead of redirecting it again. If TLS terminates before NGINX, the scheme has to be conveyed through a trusted header such as X-Forwarded-Proto; otherwise NGINX sees the proxy’s internal HTTP connection rather than the visitor’s HTTPS connection.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Step 1: Capture the redirect chain
Run these commands from a machine that can reach the public hostname:
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null -L --max-redirs 5 https://example.com/The first command shows the initial response without following it. The second follows redirects but stops after five, which is enough to expose a repeated chain without allowing a runaway request. Record the status code and complete Location value from every response.
How to read the output
- Repeated identical
Locationheaders indicate that the same apparent transition is being requested repeatedly. - Alternating
http://andhttps://locations indicates disagreement between layers. - A change in hostname or port suggests a canonical-host rule, tunnel route, or proxy rewrite rather than a simple TLS redirect.
- A response that has no
Locationheader but still fails may be a certificate, connection, or application error instead of a redirect loop.
Cloudflare’s 2026 troubleshooting guidance specifically recommends looking for repeated Location headers and the 301, 302, 307, and 308 statuses. Save the headers before changing configuration; they provide a baseline for confirming the fix.
Step 2: Test NGINX directly with the production host name
From the proxy, tunnel, or load-balancer host, bypass the public edge and test the HTTP listener with the same host name used in production:
Free tools Windows power users keep installed
One-click scans. No signup required.
curl -sS -D - -o /dev/null -H 'Host: example.com' http://127.0.0.1:80/If this returns an HTTPS Location, the origin is deliberately redirecting HTTP. That is correct when a visitor reaches NGINX directly over HTTP, but it is unsafe when an upstream service is configured to send every request to the origin over HTTP. In that topology, the upstream will repeatedly trigger the origin’s redirect.
Rank #2
Also test the HTTPS listener locally when it is available:
curl -sS -D - -o /dev/null --resolve example.com:443:127.0.0.1 https://example.com/A successful HTTPS response without a new HTTPS redirect proves that NGINX can serve the secure request locally. If the local HTTPS request redirects, inspect the server and location blocks selected by the host name and URI.
Step 3: Determine where TLS terminates
Draw the actual path before editing a redirect rule. The correct configuration differs fundamentally between direct NGINX termination and upstream termination.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →| Topology | What NGINX receives | Correct redirect decision |
|---|---|---|
| TLS terminates at NGINX | HTTP on port 80 and HTTPS on port 443 | Redirect the port-80 server to HTTPS; serve the application from the port-443 server. |
| TLS terminates at a load balancer, CDN, or ingress | Often plain HTTP from the trusted upstream, even for a visitor’s HTTPS request | Use the upstream’s trusted forwarded scheme; do not apply an unconditional redirect to every request arriving from that proxy. |
| Cloudflare Flexible | HTTP from Cloudflare to the origin | Do not force HTTPS at the origin; use Full or Full (strict) with a valid origin certificate, or enforce HTTPS only at the edge. |
| Cloudflare Tunnel with an HTTP service URL | HTTP from the tunnel to the origin | Use an HTTPS service URL when the origin serves HTTPS or redirects HTTP to HTTPS. |
When NGINX terminates TLS
Use separate listeners: a port-80 server that returns a single HTTPS redirect, and a port-443 server that contains the certificate and application proxying. The secure server must not redirect its own HTTPS requests back to HTTPS.
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
# certificate directives and application proxying go here
}This pattern is appropriate only when the client really connects to NGINX over port 80 or 443. It is not appropriate when a trusted proxy terminates TLS and forwards all traffic to NGINX over HTTP.
When a trusted proxy terminates TLS
The proxy must overwrite, rather than merely append, X-Forwarded-Proto and restrict access to the NGINX listener so an arbitrary client cannot forge that header. NGINX Ingress documents a redirect-to-https behavior that evaluates http_x_forwarded_proto. Prefer that controller feature when it is available instead of duplicating the logic in an ad-hoc server block.
A topology-specific NGINX pattern is:
# Use only when the trusted proxy overwrites X-Forwarded-Proto
if ($http_x_forwarded_proto = "http") {
return 301 https://$host$request_uri;
}This rule redirects only requests that the trusted proxy explicitly identified as HTTP. Do not add an unconditional HTTPS redirect to a server block that already receives HTTPS traffic from the proxy. If the proxy sends X-Forwarded-Proto: https, NGINX should serve the request without another redirect.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Step 4: Fix Cloudflare SSL/TLS mode
Cloudflare Flexible mode encrypts the browser-to-Cloudflare connection but sends unencrypted HTTP from Cloudflare to the origin. If the origin responds to that HTTP request with an HTTPS redirect, Cloudflare sends the redirected request back to the origin over HTTP again. The edge and origin repeat the same transition.
Cloudflare’s documented remedies are:
- Change the zone’s SSL/TLS Encryption Mode to Full or Full (strict), and install a valid certificate at the origin.
- Alternatively, remove the origin’s HTTPS redirect and enforce HTTPS at the edge, so the origin receives the scheme it is configured to serve.
Full and Full (strict) are not interchangeable from a certificate perspective. Full encrypts the edge-to-origin connection; Full (strict) also requires the origin certificate to be valid for the host name. Choose the mode your certificate and origin configuration can actually support.
Check both dashboard and origin rules
Review Cloudflare’s edge settings for Always Use HTTPS and redirect rules, then inspect NGINX and the application. A dashboard rule whose target begins with http can send an otherwise secure request back to HTTP. Remove conflicting rules or make the targets consistently HTTPS. Do not assume that disabling one visible rule removes an application-level redirect.
Step 5: Correct a Cloudflare Tunnel route
A tunnel’s Service URL determines how the tunnel connects to the origin. If the origin serves HTTPS or responds to HTTP with an HTTPS Location, an HTTP Service URL will re-trigger that redirect on every request.
Recommended Free Tools
Point the route to an HTTPS endpoint such as:
https://localhost:443Use the appropriate HTTPS address for your deployment, set the origin server name to the name covered by the certificate, and keep certificate verification enabled when the certificate is publicly trusted. The origin name matters because TLS certificate selection uses SNI; connecting by an unrelated name can produce a certificate mismatch even after the redirect chain is fixed.
Cloudflare states that when an origin returns an HTTPS Location, you must use an HTTPS Service URL or change the origin redirect policy. An HTTP Service URL sends every request to the origin over HTTP and can repeat the redirect indefinitely.
Step 6: Validate certificate hostname and SNI
A certificate-name mismatch can look like a tunnel or routing failure after the redirect is corrected. Test the certificate directly:
openssl s_client -connect 127.0.0.1:443
-servername example.com -verify_hostname example.com
-verify_return_error </dev/nullConfirm that the certificate covers example.com, that the server presented the expected certificate for the supplied SNI name, and that the verify return code is 0 (ok). If verification fails, correct the certificate chain, hostname, or SNI configuration before debugging application redirects.
Step 7: Audit every redirect owner
Search all layers, not just the first NGINX file you find. A redirect can be generated in a server block, a location block, an error handler, an ingress annotation, or application middleware.
- NGINX
returndirectives, especially 301, 302, 307, and 308 responses. - NGINX
rewritedirectives and regular expressions that alter the scheme, host, or port. error_pagedirectives that point to an HTTP URL or an internal redirect with different scheme assumptions.- Ingress annotations such as
ssl-redirectandredirect-to-https. - Cloudflare Always Use HTTPS and dashboard redirect rules.
- HSTS and framework canonical-URL settings.
- Application code that constructs absolute HTTP URLs from an untrusted or missing forwarded scheme.
NGINX documentation notes that both return and error_page can generate browser redirects, so inspect server and location contexts together. An application may also issue a redirect after NGINX has correctly proxied the request; the response headers will reveal that ownership.
Common loop patterns and their fixes
Flexible mode plus an origin HTTPS redirect
Symptom: The public URL is HTTPS, but the origin sees HTTP and returns an HTTPS Location on every request.
Fix: Use Full or Full (strict) with a valid origin certificate, or remove the origin redirect and enforce HTTPS at the edge. Do not leave Flexible in place while the origin insists on HTTPS.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsLoad balancer terminates TLS, NGINX does not trust the forwarded scheme
Symptom: HTTPS requests from visitors arrive at NGINX over an internal HTTP connection. NGINX redirects them, even though the visitor is already using HTTPS.
Fix: Configure the load balancer to overwrite X-Forwarded-Proto, restrict direct access to NGINX, and make the ingress or NGINX rule evaluate that trusted value. Remove any rule that redirects every request regardless of the header.
HTTP Tunnel Service URL to an HTTPS origin
Symptom: The tunnel connects over HTTP, receives an HTTPS Location, and reconnects over HTTP repeatedly.
Fix: Change the Service URL to the origin’s HTTPS endpoint, set the correct origin server name, and verify the certificate with SNI.
Two legitimate HTTPS policies overlap
Symptom: NGINX, an ingress controller, and the CDN each have an HTTPS redirect enabled. One layer may construct a different host, port, or path, creating a cycle.
Fix: Select one owner for the public redirect. Configure the other layers to preserve and trust the already-secure scheme, then retest from each network boundary.
Application canonical URL disagrees with the proxy
Symptom: NGINX returns a normal upstream response, but the application sends a redirect to HTTP because it cannot determine the original scheme.
Fix: Configure the framework’s trusted proxy settings and canonical URL to use the verified forwarded scheme. Do not accept arbitrary client-supplied forwarding headers.
Use a single-owner decision framework
Before changing a directive, answer these questions in order:
- Where does public TLS terminate: NGINX, a load balancer, a CDN, an ingress controller, or a tunnel?
- Does the origin itself serve HTTPS on the endpoint used by that upstream?
- Which component is intended to own the HTTP-to-HTTPS redirect?
- Does the upstream overwrite a forwarded scheme header and limit network access to trusted sources?
- Does the certificate match the host name and SNI value used for the origin connection?
- Are Cloudflare mode, tunnel Service URL, ingress annotations, NGINX directives, and application settings consistent with those answers?
The answers should describe one unbroken policy: an HTTP request is redirected once, and an HTTPS request is served without another scheme transition.
Verify the fix from every boundary
After changing configuration, repeat the public and direct-origin tests. Reload NGINX only after validating the configuration syntax with your normal deployment procedure, then test:
- The public HTTPS URL with
curl -sS -D - -o /dev/null. - The public URL with
-L --max-redirs 5to ensure the chain terminates. - The origin’s HTTP listener with the production
Hostheader. - The origin’s HTTPS listener with the expected host name and SNI.
- The CDN, ingress, or tunnel path independently, if those components can be tested from their own hosts.
A successful result has either one intentional HTTP-to-HTTPS redirect followed by a final 200-level response, or a direct 200-level HTTPS response when the edge already performs the redirect. There should be no repeated Location header and no alternating scheme.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Preventing the loop from returning
- Document where TLS terminates and which component owns redirects.
- Keep the trusted proxy’s forwarded-scheme behavior explicit and tested.
- Limit origin access so clients cannot forge
X-Forwarded-Proto. - Include redirect-chain checks in deployment and certificate-renewal validation.
- Review CDN, ingress, NGINX, and application changes together; a harmless-looking redirect toggle can create a cycle at another layer.
- When adding a tunnel or changing its origin URL, verify whether the origin expects HTTP or HTTPS before deploying the route.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
