< HTTP/1.1 508 Loop Detected

TL;DR: 508 means the server stopped a request because it was going in circles. Originally a WebDAV code for resource-binding cycles, it now mostly signals proxy or CDN loops, where a layer forwards a request back toward itself. Find the cycle with Via and CDN-Loop headers and fix the upstream or DNS target.

What it means

RFC 5842 §7.2 defines 508 for WebDAV bindings: a PROPFIND or COPY with Depth: infinity that reaches a collection through a bind which includes an ancestor of itself would never finish, so the server stops with 508 and the whole operation fails.

Outside WebDAV, 508 is used by platforms and gateways that detect request loops. Vercel documents INFINITE_LOOP_DETECTED as an HTTP 508, raised for self-referencing requests, redirect cycles and recursive middleware or function calls. Standard web servers more often behave differently: nginx and Apache end internal redirect cycles with a plain 500 (“rewrite or internal redirection cycle”, LimitInternalRecursion), and a proxy that loops to itself usually produces 502 or 504 as connections pile up.

HTTP/1.1 508 Loop Detected
Content-Type: text/plain

Loop detected while processing /a/b

Typical causes

1. Proxy pointing at itself. proxy_pass http://example.com; inside the server for example.com, where DNS for the upstream name resolves to the same machine or to the CDN that fronts it. Each pass adds another Via entry.
2. Two layers fetching from each other. The CDN’s origin is set to a hostname that is routed through the same CDN again.
3. Rewrite or middleware loops in platform routers (a rewrite sends /x to /y and a second rule sends /y back to /x).
4. WebDAV bind cycles where a collection contains a binding to its own ancestor, found by a Depth: infinity operation.

Find the cycle

curl -sv https://example.com/ -o /dev/null 2>&1 | grep -i -E '^< (via|cdn-loop|server|x-cache|cf-ray)'

< via: 1.1 edge-1.cdn-a.example, 1.1 edge-2.cdn-a.example, 1.1 edge-3.cdn-a.example
< cdn-loop: cdn-a; loops=3

Repeating Via entries with the same pseudonym show the same node is being revisited. RFC 8586 defines CDN-Loop, where each CDN appends its identifier so that a CDN receiving a request that already carries its own identifier too many times can refuse it. Then check where the proxy sends the request:

# From the proxy host: what does the upstream name resolve to?
dig +short upstream.example.com
getent hosts upstream.example.com
# Is it one of this host's own addresses?
ip -brief addr

In nginx, make sure the upstream is a different address than the listener, and keep proxy_set_header Host coherent with what the upstream expects, since a Host that routes back to the proxy is the classic loop.

Fix it

• Point the upstream at the origin’s own address or an internal hostname that does not go through the proxy.
• Remove one of the two layers’ fetch rules when two CDNs or proxies are chained.
• In platform rewrites, make the rules acyclic, and add conditions so a rewritten request does not match the rule again.
• For WebDAV, avoid Depth: infinity on collections with bindings or break the cyclic binding.

Related

• 502 Bad Gateway
• 504 Gateway Timeout
• 500 Internal Server Error
• 301 Moved Permanently and 302 Found: where browser-side redirect loops start.
• Via