How to find and fix a redirect loop

A redirect loop is the browser refusing to keep knocking. A page sends the request somewhere, that somewhere sends it back, and after a handful of hops the browser stops and reports a redirect error. The site is not down, but nobody can reach it. Almost every loop is two rules pointing at each other.

Start by tracing the hops

Do not guess at the cause from the config. Follow the request and watch where it goes:

# -I 只取响应头，-L 跟随重定向，过滤出状态行与 Location
curl -sIL https://example.com/page | grep -iE '^HTTP/|^location:'

A healthy result is two status lines: one 301, one 200. A loop prints the same pair of URLs over and over:

HTTP/1.1 301 Moved Permanently
location: https://www.example.com/page
HTTP/1.1 301 Moved Permanently
location: https://example.com/page
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/page
...

That first repeating pair is your answer: the two hops that disagree. For a quick count without the wall of output:

curl -sLo /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' https://example.com/page

A high num_redirects with a non-200 code is a loop.

The usual causes

Cause	What it looks like	Fix
Scheme and host rules fight	http→https and https→http, or www→apex and apex→www	Enforce scheme and host in one ordered rule
Edge and origin disagree	CDN rewrites to www, origin rewrites to apex	Make one layer authoritative; remove the rule from the other
Trailing-slash recursion	One rule adds /, another strips it	Choose one form and enforce it once
Self-redirect	A rule matches its own target	Narrow the condition so it excludes the destination
Backend redirects back	Load balancer terminates TLS, backend redirects to https	Trust the forwarding header at the backend, or drop the backend rule
Locale or device redirect	A cookie or user-agent rule always fires	Ensure the redirect target cannot re-trigger the rule

The first two account for the large majority of cases.

Collapse the rules

The fix for a scheme-plus-host loop is to make the decision once and terminate. Two separate rules that each “normalise” one attribute will ping-pong. One ordered set will not:

# 统一规范：https + 裸域 + 保留原路径
# 第一段：把 http 的所有主机名一次性送到 https 裸域
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}

# 第二段：https 上只把 www 收敛到裸域，其余交给应用
server {
  listen 443 ssl;
  server_name www.example.com;
  return 301 https://example.com$request_uri;
}

The first block handles every insecure request. The second handles only the secure www host. Neither target can be matched by the other rule, so the chain terminates in one hop to the canonical host.

If the loop involves the CDN, apply the same logic to the edge: keep a single normalisation rule there and remove the conflicting rule from the origin, or vice versa.

Fix the slash rule the same way

The trailing-slash loop is the same shape at a smaller scale. One rule rewrites /page/ to /page, another rewrites /page to /page/. Pick the form your routes actually serve, enforce it once, and make sure the rule’s condition cannot match its own output — usually by anchoring the pattern so it only matches requests that still carry the wrong form.

Common mistakes

Fixing one layer and forgetting the other. The origin is corrected, the CDN rule remains, and the loop comes straight back.

Reading the config instead of the live chain. Rules are inherited, overridden and reordered by the platform. The traced hops are the only ground truth.

Adding a new normalisation rule without removing the old one. Two rules that normalise the same attribute are the classic loop, even when each one is individually correct.

Letting a redirect target itself. A pattern that is too broad can match the destination URL. Anchor it and test both the source and the destination.

Testing only the homepage. Normalisation rules often behave differently on deep paths and on URLs with query strings. Trace a real, deep URL.

Assuming a cached 301 will clear. Browsers cache permanent redirects hard. After a fix, test in a fresh session or with cache disabled.

Where this tool fits

The redirect chain checker follows every hop, lists the status code and Location at each step, and flags the loop before it reaches users — which turns a guess-and-check debugging session into a single trace.