iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
An Nginx HTTPS redirect loop occurs when two network layers disagree about whether the request is HTTP or HTTPS. The browser may show an HTTPS URL, while Nginx, a load balancer, CDN, tunnel, or application still evaluates the connection as HTTP and redirects again. Stop the loop by tracing every hop, identifying where TLS terminates, trusting a correctly overwritten X-Forwarded-Proto value when necessary, and leaving the HTTP-to-HTTPS redirect to one layer.
The most common case is Cloudflare Flexible mode in front of an origin that redirects HTTP to HTTPS. Cloudflare connects to the origin over HTTP, the origin returns an HTTPS redirect, and Cloudflare repeats the HTTP request. Switch the zone to Full or Full (strict) with a valid origin certificate, or remove the origin redirect and enforce HTTPS at the edge.
Recommended Free Tools
What an HTTPS redirect loop actually means
A redirect is an HTTP response such as 301, 302, 307, or 308 containing a Location header. The client requests that location, receives another redirect, and repeats until the browser reports ERR_TOO_MANY_REDIRECTS.
The visible browser address does not prove which component generated the response. A request can pass through a browser, DNS provider, CDN, load balancer, ingress controller, tunnel, Nginx, and an application. Any of those layers can issue a redirect. A loop results when one layer sends the request to HTTPS while another sends it back to HTTP, or when a proxy repeatedly presents an HTTP request to an origin that insists on HTTPS.
#1 Best Overall
Typical chains include:
- Cloudflare Flexible connects to the origin with HTTP; the origin redirects to HTTPS; Cloudflare again connects with HTTP.
- A TLS-terminating load balancer forwards plain HTTP to Nginx, while Nginx checks the local connection instead of the trusted forwarded scheme and redirects an already-HTTPS visitor.
- A Cloudflare Tunnel uses an HTTP Service URL even though the origin returns an HTTPS
Locationheader. - An ingress annotation, Nginx
returnrule, and application canonical-URL setting all attempt to enforce HTTPS with conflicting assumptions.
The repair is not to keep adding redirects. It is to establish one authoritative HTTPS policy and make every downstream layer understand the scheme that the trusted proxy observed.
Find which layer is redirecting
Start with headers rather than browser error messages. The following commands show the first response without following it, then follow at most five redirects so a loop cannot run indefinitely:
Free tools Windows power users keep installed
One-click scans. No signup required.
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null -L --max-redirs 5 https://example.com/Record the status code and every Location value. A repeated identical location indicates that the same transition is being issued repeatedly. Alternating locations such as http://example.com/ and https://example.com/ indicate that different layers disagree about the scheme. Cloudflare’s 2026 diagnostics specifically use repeated Location headers and the 301, 302, 307, and 308 status codes as loop clues.
Read the result as a chain
- HTTPS response with an HTTPS Location: a component is redirecting an already-HTTPS request. Check forwarded-scheme handling, duplicate redirect rules, and application canonical URLs.
- HTTPS response with an HTTP Location: a proxy or application is downgrading the request. Inspect canonical-host settings, rewrite rules, and dashboard redirects.
- First response from the public hostname differs from the direct origin: the edge, load balancer, ingress, or tunnel is involved.
- The chain ends in a certificate error after the redirect is corrected: validate the certificate name and SNI separately; certificate problems can resemble routing failures.
Test Nginx without the proxy
From the proxy or tunnel host, send the production host name to the local HTTP listener:
curl -sS -D - -o /dev/null -H "Host: example.com" http://127.0.0.1:80/If this returns an HTTPS Location, any intermediary configured with an HTTP origin or Service URL will trigger that redirect on every request. Use the origin’s HTTPS listener instead, or change the origin policy so the intermediary’s chosen scheme is accepted.
Rank #2
Repeat the test against the HTTPS listener when it is available. A direct HTTPS response establishes what Nginx does when reached over TLS; it does not by itself prove that the public proxy is forwarding the correct scheme.
Identify where TLS terminates
Draw the actual path before changing configuration. The correct redirect test depends on the component that first decrypts TLS.
| Topology | What Nginx receives | Where HTTPS should be enforced | Critical check |
|---|---|---|---|
| TLS terminates at Nginx | HTTP on port 80 and HTTPS on port 443 | Nginx port 80 can redirect to HTTPS; Nginx serves the application on 443 | The 443 server has a certificate matching the requested host |
| TLS terminates at a load balancer, CDN, or ingress | Often plain HTTP, even for an HTTPS visitor | The trusted proxy or ingress should enforce the policy, or Nginx must use the forwarded scheme | The proxy overwrites X-Forwarded-Proto and only the proxy can reach the origin |
| Cloudflare Flexible | HTTP from Cloudflare to the origin | Cloudflare edge, with no origin HTTPS redirect | Flexible cannot be combined with an origin that forces HTTPS |
| Cloudflare Full or Full (strict) | HTTPS from Cloudflare to the origin | Cloudflare or the origin, but not conflicting layers | The origin certificate is valid for the hostname in Full (strict) |
| Cloudflare Tunnel | The protocol selected by the Tunnel Service URL | The Service URL must match the origin’s protocol | An HTTPS origin or HTTPS redirect requires an HTTPS Service URL |
When TLS terminates at Nginx
Use a dedicated HTTP server block that performs one redirect, and a separate HTTPS server block that serves or proxies the application. A minimal pattern is:
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
# ssl_certificate and ssl_certificate_key belong here.
# proxy_pass or the application handler belongs here.
}The example assumes visitors reach Nginx directly and that the 443 certificate covers example.com. Do not copy this unconditional port-80 redirect into a server block that receives already-decrypted HTTPS traffic from a load balancer; that topology requires forwarded-scheme logic instead.
When TLS terminates before Nginx
A load balancer, CDN, or ingress should set and overwrite X-Forwarded-Proto to the scheme used by the visitor. Nginx can then redirect only requests whose trusted forwarded value is http:
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute# Use only when a trusted proxy overwrites X-Forwarded-Proto
if ($http_x_forwarded_proto = "http") {
return 301 https://$host$request_uri;
}This is a topology-specific pattern, not a license to trust arbitrary client headers. A visitor can send an X-Forwarded-Proto header directly unless the network prevents that. Restrict origin access to the trusted proxy and configure that proxy to overwrite the header rather than preserve a client-supplied value.
Where an ingress controller provides a documented HTTPS redirect feature, prefer it over duplicating the logic in every Nginx server block. F5 NGINX Ingress documents redirect-to-https; its decision evaluates http_x_forwarded_proto. Confirm that the ingress actually receives the proxy’s value and that another layer is not issuing a second redirect.
Fix Cloudflare SSL/TLS mode
Why Flexible loops
Cloudflare Flexible encrypts the browser-to-Cloudflare connection but uses unencrypted HTTP from Cloudflare to the origin. An origin that forces HTTP-to-HTTPS therefore returns an HTTPS redirect to a request that Cloudflare will make over HTTP again. The same request transition repeats until the browser stops following it.
Use Full or Full (strict) for an HTTPS origin
In Cloudflare’s dashboard, open the zone’s SSL/TLS settings and select Full or Full (strict) when the origin serves HTTPS. Full (strict) requires a valid origin certificate for the requested hostname. With either mode, Cloudflare can connect to the origin over HTTPS, so an origin HTTPS redirect no longer conflicts with the edge-to-origin protocol.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsCloudflare’s documented remedy is to remove HTTPS redirects from the origin or raise the SSL/TLS Encryption Mode to Full or higher with an origin certificate. Choose one owner for the redirect rather than keeping independent rules at both layers.
Check dashboard redirect rules
Review Cloudflare’s Always Use HTTPS setting and redirect rules alongside the origin configuration. A dashboard rule whose target begins with http can create a downgrade even when Nginx is correctly serving HTTPS. Remove or correct that target, then test the public hostname again with the header-tracing commands.
Correct a Cloudflare Tunnel route
A Tunnel Service URL determines how the tunnel connects to the origin. If the origin serves HTTPS or returns an HTTPS Location header for HTTP requests, set the Service URL to an HTTPS endpoint such as:
https://localhost:443Use the appropriate local address and port for your installation. Set the origin server name to the hostname covered by the certificate and keep certificate verification enabled when the certificate is publicly trusted. This supplies the expected SNI and prevents the tunnel from repeatedly sending HTTP to an origin that insists on HTTPS.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
If you intentionally want an HTTP Service URL, the origin must stop redirecting that route to HTTPS. Otherwise, an HTTP Service URL sends every request over HTTP and can repeat the redirect indefinitely.
Validate the certificate and SNI after the loop is gone
Redirect troubleshooting and certificate validation are separate checks. Test the local HTTPS listener with the hostname supplied as SNI:
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 and that the verification result is 0 (ok). A certificate-name mismatch can appear as a tunnel or routing fault even after the redirect policy is correct. If the certificate is for a different name, fix the certificate or the origin server name rather than adding another redirect.
Audit every possible redirect owner
Search the complete request path, not only the Nginx file you edited. Inspect server and location contexts together because a rule inherited from a broader context can affect a seemingly unrelated endpoint.
- Nginx: search for
return 301,return 302,rewrite, anderror_page. Nginx’sreturnanderror_pagedirectives can generate browser redirects. - Ingress: check
ssl-redirect,redirect-to-https, and any controller-specific annotations. Verify which forwarded header the controller evaluates. - CDN or edge: inspect Always Use HTTPS and redirect rules, including targets that begin with
http. - Application: review framework canonical-URL, force-SSL, trusted-proxy, and host-normalization settings. An application that believes every request is HTTP can redirect even when Nginx is correct.
- Browser policy: review HSTS while testing. HSTS upgrades browser requests locally, so test with
curlor another client to observe the server’s actual responses.
Remove duplicate policies or make their ownership explicit. For example, an edge can redirect public HTTP to HTTPS while Nginx accepts the already-HTTPS forwarded scheme without issuing another redirect; alternatively, Nginx can own the policy when the edge passes the request through transparently.
Use the symptom to choose the next test
The same HTTPS URL repeats
Run the first curl command without -L and inspect the response’s Server, Via, or other identifying headers when present. Then compare it with the direct-origin test. If the origin is clean but the public hostname repeats, inspect the CDN, load balancer, ingress, or application trust settings. If both repeat, remove the duplicate redirect at the origin first.
The URL alternates between HTTP and HTTPS
Find the response that changes the scheme in its Location header. An HTTPS-to-HTTP transition commonly comes from an application canonical URL, a dashboard redirect, or a rewrite that does not understand the forwarded scheme. Correct that owner rather than adding another HTTPS redirect.
The public site loops but the origin works
This points to the proxy-to-origin protocol or forwarded header. Confirm whether TLS terminates at the proxy, whether the proxy overwrites X-Forwarded-Proto, and whether Nginx is reachable directly by untrusted clients. For Cloudflare, verify the SSL/TLS mode and, for a Tunnel, the Service URL.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →The site works directly but fails through a tunnel
Compare the tunnel’s Service URL with the origin listener. An HTTPS origin or an origin that returns an HTTPS redirect requires an HTTPS Service URL. Then validate the origin server name and certificate with openssl s_client.
The loop stops but a certificate error appears
Do not reintroduce HTTP to bypass the error. Check certificate hostname coverage, SNI, trust-chain validation, and the proxy’s origin verification mode. Full (strict) and a verified tunnel require the certificate to be valid for the configured hostname.
Quick Recap
A reliable repair sequence
- Capture the public response with
curl -sS -D - -o /dev/nulland follow no more than five redirects. - List every
Locationand classify each hop as HTTP or HTTPS. - Test the origin over HTTP with the production
Hostheader. - Identify the TLS termination point and document what protocol Nginx receives.
- Choose one redirect owner: Nginx, the ingress or load balancer, the CDN edge, or the application.
- If a proxy terminates TLS, make it overwrite
X-Forwarded-Proto; configure Nginx or the ingress to trust that value only from the proxy. - If Cloudflare is Flexible, either remove the origin HTTPS redirect or change to Full or Full (strict) and install a valid origin certificate.
- If Cloudflare Tunnel is involved, use an HTTPS Service URL for an HTTPS origin or an origin that redirects to HTTPS.
- Audit Nginx directives, ingress annotations, edge rules, HSTS, and application canonical-URL settings for a second policy.
- Validate certificate hostname and SNI with
openssl s_client, then repeat bothcurltests from an external client.
Prevent the loop from returning
- Document where TLS terminates for every environment, including staging and health-check paths.
- Keep origin access restricted to the trusted proxy when forwarded headers control security decisions.
- Ensure the proxy overwrites, rather than appends or preserves,
X-Forwarded-Proto. - Keep one authoritative HTTP-to-HTTPS redirect and make downstream services scheme-aware.
- Test all four redirect status families that your configuration may emit: 301, 302, 307, and 308.
- Include the production hostname in certificate and SNI checks after every proxy or tunnel change.
- Retest the public chain after changing Cloudflare mode, ingress annotations, Nginx configuration, or application URL settings.
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.
