Error guide

508 Loop Detected

The server aborted a request because it was going round in circles — usually a redirect or rewrite loop.

A 508 Loop Detected means the server terminated a request because processing it would not have finished — it detected an infinite loop and stopped rather than exhausting itself. The code comes from the WebDAV extensions, but it is used more widely, and some hosting platforms return it for any detected recursion.

The usual underlying situation is a rewrite or redirect loop. A rule sends the request somewhere; the destination matches the same rule; round it goes. The classic examples are an HTTPS redirect running behind a proxy that terminates TLS — so the application always believes the request is insecure and redirects it forever — and a trailing-slash rule that fights another rule with the opposite opinion.

Many clients see the loop before the server does: browsers and HTTP libraries usually stop after a fixed number of redirects and report their own error rather than a 508. So the same misconfiguration can present as a 508, as a too-many-redirects error, or as a request that simply never completes, depending on who noticed first.

Common causes

  • An HTTPS redirect behind a TLS-terminating proxy that does not forward the X-Forwarded-Proto header.
  • Two rewrite rules with opposite opinions about trailing slashes, canonical hosts or letter case.
  • A CDN and an origin each redirecting to what they consider canonical, disagreeing.
  • Application middleware redirecting to a route whose own middleware redirects back.
  • A symlink or alias in the filesystem pointing into its own path.

How to diagnose it

  1. Follow the redirects explicitly with curl -IL and read the chain — the loop is usually obvious after two hops.
  2. If HTTPS redirection is involved, check whether the application can actually see the original protocol, and that it is configured to trust the forwarded header.
  3. Disable rules one at a time: loops are nearly always a pair of rules, not one.
  4. Compare requests direct to the origin against requests through the CDN — a loop that appears only through the CDN identifies itself.
  5. Check for an alias or symlink cycle if the loop is in file resolution rather than in routing.

Whose fault is it? The server's side

A configuration problem on the server side. It is not a hosting fault or a client fault, and it does not resolve by itself.

What monitoring sees

How a monitor reports this depends on whether it follows redirects. A monitor that does will fail with a redirect-limit error; one that does not will record whatever the first hop returned, which may look like a normal 301. Uptimely lets redirect following be configured per monitor, so a check can be pointed at the final page rather than reporting a redirect as success.

Related error guides

Terms used on this page

Questions

Why do I get a redirect loop only behind a CDN or proxy?

Usually because the application cannot see that the original request was HTTPS. It redirects to HTTPS, the proxy terminates TLS and forwards over HTTP, and the application redirects again. Trusting the forwarded protocol header fixes it.

Is 508 the same as ERR_TOO_MANY_REDIRECTS?

They usually come from the same misconfiguration, but different parties notice. The browser error is the client giving up after its own limit; a 508 is the server detecting the recursion and stopping first.

One of the Uptimely HTTP and network error guides, written for the person who operates the server rather than the one refreshing the page. Something here read wrong to you? Email support@getuptimely.com.