Cloudflare and Fastly CDN Configuration: What to Set Up First

Published

Jul 14, 2026

Reading time

9 min read

Cloudflare and Fastly can both accelerate a website, protect an origin, and expose fine-grained delivery controls. Neither is a magic speed switch. The first configuration determines whether the edge serves useful content, private responses stay private, and your team can recover when a rule is wrong.

The reliable approach is provider-neutral: define the origin contract, establish DNS and TLS safely, classify cacheable responses, control the cache key, add purge and stale policies, then verify with real requests. Cloudflare commonly expresses these decisions through zone settings and cache rules. Fastly commonly combines service configuration, cache-control headers, VCL, and surrogate keys. The concepts transfer, but the exact precedence, defaults, limits, and UI do not.

1. Define the origin contract

Record the production and staging origins, expected host header, TLS certificate names, supported protocols, health endpoint, connection timeout, first-byte timeout, and acceptable status codes. Make the origin accept traffic from the CDN's egress ranges or private connection, but do not leave it broadly exposed if the CDN is meant to be the public entry point.

Confirm that the origin emits explicit headers. At minimum, decide how it sets Cache-Control, ETag or Last-Modified, Vary, Content-Type, and Content-Encoding. HTTP caching behavior is standardized in RFC 9111. CDN rules should refine this contract, not silently contradict it.

Separate hostnames where possible: the public site, static assets, APIs, and image transformations often have different cache and security policies. A single broad rule for all paths is convenient to create and difficult to make correct.

2. Connect DNS and TLS with a rollback path

Start with a staging hostname or a low-risk subdomain. Provision the CDN certificate for every hostname that will be served, confirm the TLS mode, and test the complete certificate chain. Then point the hostname to the CDN using the provider's required DNS target or CNAME. Keep the previous DNS target documented and usable until the new path has passed production checks.

Lower the DNS TTL ahead of a planned cutover only if you understand the existing resolver caches. A lower TTL improves agility for future changes but cannot evict answers that are already cached under the old TTL. Do not change nameservers, DNSSEC, TLS, and CDN routing in one untested step.

The Optimi CDN guide explains the role of edge delivery, while the DNS performance guide covers the resolution and migration side of this change.

3. Configure cache behavior by content class

Begin with explicit allowlists rather than caching every successful response:

For static assets, publish a new filename when bytes change. For stable URLs, use targeted purge or validation. Set browser and shared-cache lifetimes deliberately; a browser max-age and an edge s-maxage do not have to be identical. Avoid relying on provider fallback TTLs when the origin can send the right policy.

Cloudflare and Fastly differences to check

On Cloudflare, review default cache behavior, cache rules, cache key settings, and whether a response is eligible for caching. On Fastly, review the service configuration, backend selection, VCL branches, and the precedence of Surrogate-Control, s-maxage, max-age, and Expires. Fastly's own caching guidance recommends origin headers, surrogate keys, and stale policies rather than unnecessarily short TTLs.

Do not copy a Cloudflare rule into Fastly or vice versa and assume equivalent precedence. Write down the intended behavior, then implement it in the provider's native controls.

4. Make the cache key intentional

The minimum key generally includes the request method and target URI, but negotiated responses can vary by request headers. Decide which query parameters are meaningful. Remove tracking parameters only when doing so cannot change the response. Keep currency, locale, product filters, and signed parameters when they affect content.

Be cautious with cookies and authorization. A cache key that ignores a personalization cookie can serve one shopper's response to another. A key that includes every cookie can destroy the hit ratio. Prefer bypassing personalized paths, or make the public and private representations explicit.

If format negotiation uses Accept, either use a provider-supported variant mechanism or emit correct Vary: Accept behavior. Test every supported format. The same principle applies to language, device class, and compression.

5. Add invalidation, resilience, and observability

Give editors and deploy automation a scoped purge path: URL for one object, tag or surrogate key for a logical entity, prefix for a controlled collection, and full purge only for a documented incident. Cloudflare documents URL, tag, hostname, prefix, and full purges. Fastly supports URL and surrogate-key purges and can soft-purge in appropriate cases. Verify provider rate limits before building a release hook.

Define whether public pages may use stale-while-revalidate or stale-if-error. Stale content can hide an origin outage, but it is unsuitable for stock, price, account, or other data where an old answer could cause harm. Add cache-status headers or provider diagnostics that operators can inspect, and collect origin status, cache hit ratio, response age, purge outcomes, and regional latency.

6. Roll out in controlled stages

1. Test the origin directly and validate headers.
2. Deploy the CDN configuration to staging or a non-critical hostname.
3. Exercise anonymous, authenticated, mobile, desktop, alternate-language, and API requests.
4. Send repeated requests from multiple regions and confirm expected HIT, MISS, Age, and validator behavior.
5. Shift a small, observable portion of production traffic if your routing supports it.
6. Compare error rate, origin load, TTFB, cache hit ratio, and business flows before increasing traffic.

Keep a before-and-after request capture. A CDN change is not successful merely because a page renders; it must render the correct representation and reduce work without weakening security.

Verification and rollback

Use curl -I for headers, curl -w for timing, browser DevTools for cache and service-worker behavior, and a field or synthetic tool for regional coverage. Check the response body with a deployment marker, not only a cache-status header. Inspect redirects, cookies, compression, range requests, and error responses too.

If errors, data mixing, or origin overload appear, route traffic back to the previous target or disable the changed rule using the emergency procedure. Keep the prior CDN version or configuration active until the new version is stable. Purge only objects created by the bad rule, and avoid a full purge unless the bad response could be broadly cached or poisoned. Re-run the verification matrix after rollback.

Common mistakes

• Enabling a broad cache rule before identifying private paths.
• Ignoring the origin Host header or certificate name during backend setup.
• Assuming DNS TTL changes are instant everywhere.
• Adding every request header or cookie to the key, fragmenting the cache.
• Stripping every query parameter, including parameters that change prices or results.
• Treating Cloudflare and Fastly defaults as interchangeable.
• Skipping purge permissions, rate limits, and an emergency rollback test.

Continue with the static vs dynamic content guide for cache policy design, the cache purging workflow for safer releases, and Optimi's managed CDN page for the broader edge-delivery model. Ecommerce teams can also review the ecommerce solution.

There are only two hard things in Computer Science: cache invalidation and naming things.