Cloudflare

Cloudflare sits between millions of websites and the people who visit them, filtering out bad traffic and serving copies of pages from servers close to each visitor. That position makes sites faster and safer, and it also means that when Cloudflare fails, a large slice of the web fails with it.

Where Cloudflare sits

Without Cloudflare, a browser looks up a site's domain, gets the IP address of the site's own server (the 'origin'), and connects straight to it. When a site turns on Cloudflare's proxy, the domain's DNS answers with Cloudflare's addresses instead. The browser connects to a nearby Cloudflare data centre, and Cloudflare opens its own connection to the origin only when it needs to.

This arrangement is called a reverse proxy: a server that stands in front of other servers and answers on their behalf. A forward proxy works for the client, like an office proxy that all staff traffic leaves through. A reverse proxy works for the website. Because every request passes through it, the proxy can inspect, block, cache or rewrite traffic before the origin ever sees it.

Here is one visitor's request going through the proxy, then a bot that never gets past it:

The security layer

Every request stops at the edge first, and the edge makes a decision about it: allow it, block it, or challenge it (make the client prove it is a real browser before letting it through). A few tools feed that decision:

• DDoS protection. A distributed denial-of-service attack floods a site with traffic from many machines at once. Cloudflare spreads that load across its whole network and drops it there, instead of letting it pile up on one origin server.
• Web application firewall (WAF). Rules that match known attack patterns, such as an SQL injection attempt in a query string, and stop them.
• Bot management. Each request gets a score for how likely it is to come from an automated client. The site owner decides what a low score means: block, challenge or allow.
• Rate limiting. A cap on how many requests one client can make in a given window, which slows down password guessing and scraping.

There is a quieter benefit too. Visitors, and attackers, only ever see Cloudflare's IP addresses, so the origin's real address stays hidden. That only holds if the origin refuses traffic that doesn't come through the proxy, which the mistakes section comes back to.

The CDN: copies close to the visitor

Cloudflare runs data centres in many cities, and each one can keep copies of responses it has already fetched. That network of caches is a content delivery network, or CDN. A visitor in Paris gets the site's logo from a Paris data centre rather than from an origin server in another country, which cuts the round trip and takes load off the origin.

A request the edge can answer from its copy is a cache hit. One it has to fetch from the origin is a miss, and the edge usually stores the answer for next time. By default Cloudflare caches static files such as images, stylesheets and scripts, and the origin controls how long a copy stays fresh with the Cache-Control header.

You can watch this happen with curl. Cloudflare adds a cf-cache-status header to responses it proxies:

curl -sI https://example.com/logo.png \
  | grep -i cf-cache-status
# cf-cache-status: MISS
 
curl -sI https://example.com/logo.png \
  | grep -i cf-cache-status
# cf-cache-status: HIT

The first request missed and was fetched from the origin. The second was served from the edge. A value of DYNAMIC means the response wasn't eligible for caching at all, which is what you want for pages that differ per user.

The origin sets the rules with headers like these:

# Logo: any cache may keep it for a day
Cache-Control: public, max-age=86400
 
# Account page: never store a shared copy
Cache-Control: private, no-store

When the middle fails

Everything above depends on Cloudflare's own network working. If the proxy can't answer, visitors get an error page, even if the origin behind it is perfectly healthy, because DNS still sends them to the proxy.

That is what happened on 18 November 2025. According to Cloudflare's own post-mortem, a permissions change in one of its databases made a query return duplicate rows. That query builds a configuration file used by Cloudflare's bot detection, and the file roughly doubled in size. The proxy software had a fixed limit on what it would load, the oversized file went past it, and the proxy started failing requests with 5xx errors. The file was rebuilt every few minutes and copied across the whole network, so the failure spread with it. Cloudflare stated it was not an attack. Most traffic was flowing normally again after about three hours, and everything was restored later that day.

For users, X wouldn't load, ChatGPT stopped answering and some online games dropped players. Those services' own servers were fine. The shared layer in front of them wasn't.

This is a single point of failure: one part whose failure stops everything that depends on it. Each site made a sensible choice on its own. Together, they all ended up depending on the same layer, so one fault became many outages at once. The same trade-off comes up whenever you hand infrastructure to a provider, as in Cloud vs. on-prem.

Reducing the risk

For most sites, Cloudflare (or any similar provider) still leaves them safer and faster on an ordinary day than going without. The question is how much to spend preparing for the rare bad day, and that depends on what an hour of downtime costs you.

• Know your chain. List every third party a request passes through: DNS, CDN, login, payments. You can't plan for a dependency you haven't written down.
• Host your status page elsewhere. If the page that tells users 'we know, we're on it' sits behind the same provider, it goes down with everything else.
• Keep a fallback route. Some teams keep the DNS record's time to live short, so they can point the domain at the origin or a second CDN during an outage. The cost is real: bypassing the proxy exposes the origin's address and removes its protection, and an origin used to cached traffic may buckle under the full load.
• Use more than one CDN. Large sites sometimes split traffic across two providers. It gives the most resilience, but doubles the configuration to keep in sync and the bills to pay.
• Fail gracefully. If your app calls third-party services, set timeouts and decide what the app does without them, instead of hanging.

Common mistakes

• Leaving the origin open. If attackers find the origin's real IP address, they can go around the proxy and its protections entirely. Only accept connections that come from the proxy, for example by allowing its published IP ranges or using a tunnel.
• Caching personal pages. A cached page holding one user's account details can be served to the next visitor. Mark anything personal private or no-store.
• Blaming the wrong server. A 5xx page branded by the proxy doesn't always mean your origin is down. Check the origin directly and check the provider's status before restarting things.
• Assuming the provider never fails. Every provider has outages. Plan for it before it happens, not during.

Key takeaways

• Cloudflare is a reverse proxy: DNS sends visitors to it, and it talks to the site's origin server for them.
• Its security layer blocks or challenges bad traffic at the edge, before it reaches the origin.
• Its CDN serves cached copies from nearby data centres, controlled by Cache-Control.
• In November 2025, one faulty configuration file broke Cloudflare's proxy and took many healthy sites offline with it.
• Sharing one provider creates a single point of failure; decide in advance how you would cope without it.