# 508 Loop Detected: Proxy and Redirect Loops

> 508 Loop Detected means the server found an infinite loop while processing a request. Learn the WebDAV origin, proxy loops, CDN-Loop and how to find the cycle.

Source: https://howhttpworks.com/status-codes/508
Last reviewed: 2026-10-04

> **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
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

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

```text
< 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:

```bash
# 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](https://howhttpworks.com/status-codes/502)
- [504 Gateway Timeout](https://howhttpworks.com/status-codes/504)
- [500 Internal Server Error](https://howhttpworks.com/status-codes/500)
- [301 Moved Permanently](https://howhttpworks.com/status-codes/301) and [302 Found](https://howhttpworks.com/status-codes/302): where browser-side redirect loops start.
- [Via](https://howhttpworks.com/headers/via)
