Cloudflare Cache Rules for an RSS Feed: TTL and Bypass

Short answer: By default Cloudflare does not cache an XML feed, so every request reaches your server. A cache rule for the exact feed path lets the edge answer most requests: mark the path as eligible for cache, set an edge lifetime of a few minutes, keep the browser lifetime short, bypass the cache for any path that must stay live, and add an exception so that bot protection never blocks feed readers or your auto-poster. Test the cache status header, purge the feed address when you publish and then connect the feed to an auto-poster.

Putting a site behind Cloudflare is one of the easiest ways to make it faster and safer, and it also changes how feeds behave. The service sits between your server and everyone who asks for your RSS address: feed readers, search engines, monitoring tools and auto-posters. Many tools fetch a feed every few minutes, and a popular feed can be requested thousands of times a day. If every request reaches a slow application that builds the XML from a database, the server pays for it. If the cache keeps an old copy for hours, new articles reach your social channels late. A cache rule for the feed path solves both problems, provided that you choose the lifetime carefully. This guide explains how to set it up, how to check it and how to avoid the mistakes that turn a good setup into an outage.

What Cloudflare does with a feed by default

Cloudflare caches static files by their extension, for example images, style sheets and scripts. A feed address that ends in feed.xml or one that has no extension at all, such as /feed/, is treated as dynamic content and is passed to your server each time. You can see this in the response headers: the cf-cache-status header shows DYNAMIC, which means that the response was not eligible for cache. That is a safe default, because the service cannot know whether a page changes every second. For a feed, however, you do know that a lifetime of a few minutes is fine, so you can tell the edge to store it.

Create a cache rule for the exact path

In the dashboard, open the Caching section and choose Cache Rules. Create a rule and give it a clear name, such as Feed cache. In the condition, match the host and the exact path of the feed. The expression editor accepts a short formula.

(http.host eq "example.com" and http.request.uri.path eq "/feed.xml")

If your site has several feeds, such as one for each category, add them to the same rule with the in operator or use a prefix match on a folder, but keep the list as short as you can, so that an ordinary page never matches by accident. Then choose the action: set the cache status to eligible for cache. Choose carefully between the edge lifetime options, because they decide who is in charge of the lifetime.

• Use the cache-control header if present. Your application decides; choose it when the application already sends a sensible header.
• Ignore the header and use this lifetime. The rule decides; choose it when the application sends no header or a wrong one.
• Bypass the cache if no header exists. Your application decides, and nothing is cached without an explicit header; choose it for a strict opt-in.

For most feeds, the second option with a lifetime of a few minutes is the simplest. Plans differ in the shortest lifetime they allow, so read the current limits for your plan before you choose a value, and test the result. A feed that is cached for a day will hide every article you publish today.

Choose a lifetime that matches your publishing

The right lifetime depends on how often you publish and how quickly you want posts to appear. A blog with two articles a week can use a lifetime of five to fifteen minutes without anyone noticing. A news site that publishes every hour should stay at a few minutes. The auto-poster checks the feed at its own interval, and the edge lifetime adds to the delay: if the poster checks every minute but the edge keeps a copy for fifteen, a new article waits up to fifteen minutes. Pick a number that you can live with and write it down. The reasons for such delays are explained in why auto-posted content sometimes lags.

Set the browser lifetime separately

The cache rule also has a browser lifetime, which controls how long the visitor’s software may keep its own copy. For a feed, a short value is enough. Feed readers and auto-posters make their own decisions, but a long browser lifetime can confuse a person who reloads the address after publishing. If your application already sends a Cache-Control header with a short maximum age, you can let the rule respect it. Do not mix a very long browser lifetime with a short edge lifetime, because the person who checks the feed will not see the same document as the tools.

Mind the query string and the cache key

By default the cache key includes the full address, with the query string. That is helpful when pages differ by parameter and harmful when it is not. If tools request the feed with extra parameters, such as a timestamp added to defeat caches, each variant is stored separately, and the hit ratio drops. For a feed that does not depend on parameters, change the cache key setting to ignore the query string, or at least make sure that your own tools request the clean address. Do the opposite when you have feeds that depend on a parameter, such as a category filter: keep the query string in the key, otherwise every visitor receives the first version that was stored. Test both cases after a change.

Give the feed an exception from bot protection

The most common reason for a feed that works in a browser and fails in a tool is a security rule. Browser integrity checks, challenges and bot filters are written for people who use web browsers. A feed reader or an auto-poster has no browser, cannot solve a challenge and may be answered with a 403 status or a page that looks like HTML. Add a custom rule for the feed path that skips these protections, or lower their sensitivity for that path. A fuller explanation, with symptoms, is in how a content delivery network blocks a feed. Keep the exception narrow: it should match the exact feed path, not the whole site.

Purge the feed when you publish

A short lifetime already limits the delay, but you can make new articles appear at once by purging the feed address after publication. Many content systems and build pipelines can call the Cloudflare interface at the end of a deployment. The call below removes one address from the cache. Replace the placeholders with your own zone identifier and a token that can purge the cache and nothing else.

curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
  -H "Authorization: Bearer API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/feed.xml"]}'

Store the token in a secret manager or an environment variable and never in the repository or in a page template. Purge only the feed, not the whole zone, so that the rest of the site keeps its cache. If your application cannot call the interface, rely on the short lifetime instead.

Check compression and content type

Cloudflare compresses many text types at the edge when the client accepts it, but test your feed instead of assuming. Request it with an Accept-Encoding header and look for a content encoding line in the answer. Also check that the content type is still an RSS or Atom type with a UTF-8 charset, because a rule that overrides headers can change more than you intended. Background is in the feed compression guide dan the guide to the feed content type.

Test from the outside

curl -sI https://example.com/feed.xml
curl -sI https://example.com/feed.xml
curl -sI -H 'Accept-Encoding: gzip' https://example.com/feed.xml
curl -sI -A 'Mozilla/5.0 (compatible; FeedTest)' https://example.com/feed.xml

• The first request shows MISS or EXPIRED in the cf-cache-status header.
• The second shows HIT, together with an age header that counts the seconds in the cache.
• The third shows a content encoding header, which means that compression works.
• The fourth returns 200 and not a challenge page, which shows that the exception works.
• The address passes the W3C Feed Validation Service without errors.

A longer routine is in the feed validation guide, and a shorter one in debugging a feed with curl.

When a Worker is the better tool

Cache rules suit a feed that your server already produces. If you want to build the feed at the edge, add logic or combine several sources, a Worker is the right tool, and it has its own caching options. That approach is described in the guide to a Cloudflare Workers feed. For most sites the plain rule is easier to maintain, because there is no code to deploy and nothing to update when a library changes.

Common mistakes to avoid

• Assuming that the feed is cached. Check the cache status header.
• A lifetime of hours or days. New articles reach social channels late.
• Caching every path that ends in xml. Keep the rule narrow.
• Bot protection without an exception. Auto-posters receive 403 errors.
• Ignoring the query string for feeds that need it. Visitors see the wrong version.
• A purge token with too many rights. Limit it to cache purge.

How PostRSS works with a feed behind Cloudflare

PostRSS has been publishing RSS and Atom feeds to social networks since 2014. Paste the address of your feed, connect your accounts and choose how each post is built from the title, the description or the page title. PostRSS checks the feed as often as every minute and shares each new entry, with its image and link, to the channels you choose among 66 supported networks, messengers, team chats and blogs, including LinkedIn, X, Bluesky, Mastodon and Telegram. Keyword filters, UTM parameters and posting windows let you tune each channel. See the PostRSS features page and the plan limits on the pricing page. More developer guides are under the Technical Guide tag.

Bacaan Berkaitan

• Static RSS feed with a cron script
• RSS feed XML declaration error
• Express RSS feed in Node.js

The bottom line

A cache rule turns Cloudflare from an obstacle into a help for your feed. Match the exact feed path, mark it as eligible for cache, choose an edge lifetime of a few minutes, keep the browser lifetime short, decide how the query string is handled, give the path an exception from bot protection and purge the address when you publish. Check the cache status header from outside and then connect the address to an auto-poster, so that every article you publish reaches your social channels quickly and your server is not asked the same question a thousand times.

FAQ

Does Cloudflare cache an RSS feed automatically?

No. A feed is treated as dynamic content and shows a cache status of DYNAMIC until you create a cache rule that makes the path eligible for cache.

How long should I cache a feed?

A few minutes suits most sites. A longer lifetime delays new articles on your social channels, and a very short one gives the server little relief.

Why does my auto-poster get a 403 error?

Bot protection or a browser check is probably blocking it. Add a narrow exception for the feed path and test with curl and a custom user agent.

Do I need to purge the cache after publishing?

Not if the lifetime is short. A purge of the feed address makes new articles appear immediately, and it is easy to add to a publishing script.

Can PostRSS read a feed behind Cloudflare?

Yes. PostRSS reads any valid RSS or Atom address that is reachable without a login. Paste the address, connect your channels and new articles are shared as soon as they appear.