An infinite redirect loop occurred; why?

Short answer

The most common cause is that TLS is terminated on TR7 and the request goes to the Backend Service unencrypted: the application takes the request for HTTP and redirects it to HTTPS, the browser comes back with HTTPS, and the loop repeats. TR7 does not forward this information on its own; the X-Forwarded-Proto header must be added with the Set HTTP Header action and the application must be configured to trust this header, or the redirect must be done only on TR7. The other causes are a Redirect to HTTPS action added without a condition, a CDN or proxy that connects to TR7 over HTTP, and TR7 and the application redirecting in opposite directions (www and non-www, https and http). Whether each redirect in the chain comes from TR7 or from the application is understood from the Backend Service value in HTTP Logs.

Possible Causes

Cause	Chain	Solution
TLS terminates on TR7, the application itself redirects to HTTPS	https://x → https://x (the same address); Backend service = server name	X-Forwarded-Proto is added and the application is configured to trust it (After switching to HTTPS, pages show a "mixed content" warning; how do I fix it?); or the HTTPS enforcement in the application is turned off and the redirect is left to TR7; or SSL Service is turned on in the Backend Service so that TR7 connects to the server over TLS (What does the SSL Service option do; what is needed to connect to the backend over an encrypted connection?)
Redirect to HTTPS is added without a condition	https://x → https://x; Backend service = TR7	The If SSL is NOT terminated condition is added to the action (What is the difference between the HTTP → HTTPS frontend protocol option and the Redirect to HTTPS action?)
The application produces an http:// Location, TR7 redirects HTTP to HTTPS	https → http → https	The Location is rewritten or X-Forwarded-Proto is added (The backend application generates http:// in absolute URLs; how do I fix it?)
A CDN or proxy connects to TR7 over HTTP	The browser uses HTTPS; in HTTP Logs, TLS Version = Plain HTTP and the status is 301	The CDN is made to connect to TR7 over HTTPS
TR7 and the application redirect the host in opposite directions	example.com → www.example.com → example.com	The canonical name is defined in one place (How do I set up a redirect that adds or removes www?)
It keeps returning to the login page	A redirect back to the login page	My application keeps sending users back to the login screen (the session is lost); why?

Definitive rules:

• The Protocol = HTTP → HTTPS option in the vService frontend row redirects with 301 only the requests that come unencrypted to that IP and port; since it does not redirect HTTPS requests, it does not produce a loop on its own.
• If no condition is added, the Redirect to HTTPS action is applied to all requests, including HTTPS requests; there is no built-in loop protection.
• If the Location Redirection action is added without a condition, it does not work at all (Why doesn't a Location Redirection or User Authentication (On HTTP request) action work if I add it without a condition?).

Where Is It Monitored?

Screen	Path	What it shows
HTTP Logs	Load Balancer vServices → vService → Logs & Tracking	3xx records, Backend service (TR7 or server name), Response source and TLS version
Debug Mode Logs → Response	In the same tab (while the vService is in Debug Mode)	The value of the Location header in the response
Load Balancer Management	vService → Load Balancer Management	The actions on the vService and their conditions on a single screen

How to Diagnose?

1. The chain is extracted: curl -sIL --max-redirs 10 https://www.example.com/ is run from the client; the status code and Location value of each step are seen.
2. Who produced the redirect is found: Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → HTTP Logs is opened; in the Filter panel, 3xx is selected from the Status Class card and the Backend Service card is checked (Filter). If it is TR7, TR7 produced the redirect; if it is a server name, the application produced it. If TLS Version is added from the column selector, whether the request came to TR7 unencrypted (Plain HTTP) is also seen.
3. If TR7 produces it: the conditions of the Redirect to HTTPS and Location Redirection actions on the vService and the frontend HTTP → HTTPS option for the same port are checked.
4. If the application produces it: the Status field of the HTTP vService is set to Debug Mode; in Debug Mode Logs, the Location header in the Response tab of the record is checked, and the HTTPS enforcement and canonical name settings of the application are examined. When the investigation is finished, Status is set back to Enabled.
5. After the correction, step 1 is repeated. Since the browser caches the 301, the test is done with curl or a private window.

Common Misconceptions

• "TR7 tells the application that the request is HTTPS." It does not; the X-Forwarded-Proto header is added with the Set HTTP Header action (Execution Level = On Request, Header to edit = X-Forwarded-Proto, Header content = https, condition If SSL is terminated).
• "Using both the frontend HTTP → HTTPS and Redirect to HTTPS is more secure." Two separate redirect definitions are created; one is enough.
• "Adding X-Forwarded-Proto is enough on its own." The application must also be configured to trust this header; this setting is on the application side.
• "The fix did not work." The browser applies the previous 301 from its cache; the test is repeated with a private window or with curl.

How it is done in the documentation

• Redirect to HTTPS · Conditions
• Set HTTP Header · Scenario 2: Forwarding the Protocol Information After SSL Offloading
• HTTP (L7) vService · Protocol
• HTTP Logs · Filter

Related questions

• The backend application generates http:// in absolute URLs; how do I fix it?
• What is the difference between the HTTP → HTTPS frontend protocol option and the Redirect to HTTPS action?
• How do I redirect HTTP to HTTPS?