Stack Overflow's Cloudflare Usage FAQ

Question

How does Stack Overflow leverage Cloudflare?

Stack Overflow uses CDNs and their various tools to better serve the site's content. The current primary CDN provider is Cloudflare. While this isn't a comprehensive list of the Cloudflare services we utilize, this post attempts to cover the major ones and give a brief explanation of what this does in order to help people better understand Cloudflare's role in serving site traffic.

Return to FAQ Index

Answer 1

DNS

We use Cloudflare’s DNS service for SENetwork's name resolution. Stack also uses Amazon Route 53 and Google for DNS, however the majority of the domains we have use Cloudflare. Because Cloudflare integrates their DNS service with other services they offer, it makes configuring and maintaining our CDN infrastructure a bit simpler.

CDN

The primary reason to use a content delivery network is to cache and then serve things things as close to the requester as possible to increase web site responsiveness. There is also the benefit of reducing bandwidth and compute usage on our own servers.

• Our new image service i.sstatic.net heavily uses the CDN’s caching features to reduce the amount of bandwidth required from our origin servers to serve images.

DDoS Protection

One of the reasons Cloudflare offers free CDN services is so they can leverage their scale to monitor internet traffic on the macro level. Cloudflare provides CDN services to a large portion of the internet. Through their large presence, they are able to detect and analyze DDoS attacks at scale to better protect all of their customers.

• Their DDoS protection is only the first gate we use to defend the site. Cloudflare tightly controls how their DDoS protections trigger, and the options for configurability are limited. While we can carve out exceptions, we believe it’s generally not a good idea to poke holes at this level.

WAF

Web application firewall. We use this feature to further protect the site from undesired traffic. There are two forms of "protection" that triggers at this level:

1. WAF Block - 403 response code: These generally are static rules that we set to block undesired traffic.

   • We try to avoid blocking IP addresses / ranges because it becomes a game of whack-a-mole and is not a scalable solution to deterring malicious traffic.
   • We generally do not discuss specific block rules we have in place. There is one rule that can be shared, it is one of the most triggered, the WAF rule we have that blocks requests that do not have a User-Agent.

2. Rate Limit - 429 response code: As the name implies, we use this to slow down requests from sources that are sending too many requests in a given period of time.

   • There is no single main rate limiter in place but rather layers of rate limiters that try to protect the site from different kinds of traffic.
   • Different parts of the site have different limiters in place that are tailored to the specific traffic characteristics of the resource.
   • Some rate limit rules will have a "cool off" period that will give a 429 response to all requests during the timeout period. Others will only rate limit requests that exceed the the specified rate.

Managed Challenge

The vast majority of rules we use to protect the site whether they are a block rule or rate limit triggers a managed challenge. Managed challenges help ensure any kind of WAF rule only really affects automated traffic while humans are presented with some sort of gate that allows them to continue to the page they requested.

Ray ID

When users encounter an error when accessing a site, it's very helpful to provide the Ray ID of the request that triggered the error. This helps us quickly identify the request that caused the error in our logs. A Cloudflare block page will display the Ray ID however another way to retrieve the Ray ID is to get the response header CF-Ray using the browser's developer tools.

• user7215: The last three letters are your nearest airport.