RSS feed redirect loop (too many redirects) — how to fix

Feed readers and validators typically follow redirects, but they often stop after a small number of hops. A loop (A → B → A) guarantees failure.

Fast diagnosis (show the redirect chain)

Use a plain HTTP client so you can see every hop:

curl -I https://example.com/feed.xml
curl -L -I https://example.com/feed.xml

If you see the same Location: values repeating (or bouncing between http/https or www/non-www), you’ve found the loop.

Common causes

• http:// redirects to https://, while the feed URL in the XML points back to http://
• www ↔ non-www rules applied inconsistently
• a CDN/WAF redirect rule that also runs at the origin (double-redirect)
• reverse proxy headers not set correctly (origin thinks it’s HTTP, proxy forces HTTPS)

Typical loop patterns

• http://example.com/feed.xml → https://example.com/feed.xml → http://example.com/feed.xml
• https://example.com/feed.xml → https://www.example.com/feed.xml → https://example.com/feed.xml
• /feed.xml → /feed/ → /feed.xml (rewrite rules fighting each other)

Redirect loop cheat sheet

What it’s bouncing between	Usual root cause	Fix
http ↔ https	Proxy/CDN terminates TLS but origin thinks it’s HTTP	Forward the real scheme (X-Forwarded-Proto) and keep only one “force HTTPS” rule
www ↔ non-www	Two different canonicalization rules at different layers	Choose one canonical host and make everything else 301 to it
/feed.xml ↔ /	Catch-all redirect or rewrite rule	Exclude feed paths from catch-alls; ensure feed route returns XML

How to fix

1. Pick one canonical base URL (e.g. https://example.com).
2. Ensure the feed URL returns 200 at that canonical address.
3. Make any legacy URLs do one 301 hop to the canonical URL.
4. Re-validate and ensure the feed XML’s self-links/canonical URLs match the final destination.

Fixes by layer (CDN, origin, app)

Redirect loops usually come from two systems trying to “help” at the same time.

CDN / proxy

• Ensure you don’t have both “force HTTPS” at the CDN and a separate HTTPS redirect at the origin that disagrees.
• Avoid path rules that redirect /feed.xml to / or to an HTML page.
• If your CDN terminates TLS, make sure it forwards the original scheme so the origin doesn’t think requests are HTTP.

Origin (Nginx/Apache)

• Make canonicalization consistent: pick one of www or non-www, and one scheme (https).
• Ensure your feed route isn’t caught by a “redirect all unknown paths to /” rule.

App / CMS

• Check “site URL” / “home URL” settings (common in CMSes) so generated feed self-links and canonical URLs match the public domain.
• If your app uses proxy headers to detect HTTPS, ensure headers like X-Forwarded-Proto: https are set correctly.

Why this matters

Even if browsers “eventually load”, feed readers may:

• time out
• cache the wrong endpoint
• stop polling entirely

Keeping feed redirects simple is one of the highest leverage reliability improvements you can make.

Best practice summary

• Feed URL should return 200 at the canonical destination.
• Old feed URLs should do one 301 hop to the canonical URL.
• Feed XML should not “fight” the redirects (self-links should match the final URL).

FAQ

Why does my feed have a redirect loop?

It’s usually caused by misconfigured canonical URL settings (www/non-www), HTTP↔HTTPS redirects, a CDN/proxy rule, or a rewrite rule that applies twice.

Do feed readers follow redirects?

Most do, but many have limits (number of redirects, timeouts). Redirect loops and long chains frequently fail.

What’s the best practice?

Serve the feed at a stable canonical URL that returns 200, with at most one 301 from legacy URLs.

Fix RSS/Atom feeds and OPML lists

Paste a feed/OPML URL, upload a file, or paste XML — then validate and fix it.

Fix my feed / Import OPML Back to Help