Cloudflare zone settings reference

Backdrop: per-zone, not per-account

Zone settings are the knobs that shape how Cloudflare behaves for one domain. They are distinct from the account-level configuration in proxy mode and from the SSL modes that set how Cloudflare talks to the origin. Where a rule targets a URL pattern, a zone setting applies across the whole zone unless a rule narrows it. The dashboard path for most of these is Speed > Settings (for performance) and Security > Settings (for security), with the setting-level API /zones/{zone_id}/settings.

Performance toggles and their defaults

• Brotli compression. Brotli is now always-on for every plan and the toggle was removed from the dashboard (mid-2024). When the requesting client advertises Brotli support, Cloudflare serves the Brotli-compressed asset. There is no per-zone off switch; leave it alone.
• 0-RTT Connection Resumption. Reduces latency for returning visitors by sending data on the first round trip of a resumed TLS session. Available on every plan but off by default; you must enable it under Speed > Settings > Protocol Optimization. Cloudflare supports 0-RTT for GET, HEAD and OPTIONS, not POST, and adds an Early-Data: 1 header so the origin can detect a 0-RTT request. The early-data header is the signal an origin should check before processing possibly-replayed data.
• HTTP/2 to Origin. Cloudflare speaks HTTP/2 to your origin server by default on Free, Pro and Business plans, which helps when origin connection overhead matters (see ALPN and HTTP/2 negotiation). Free, Pro and Business use up to 200 concurrent streams and cannot change the multiplexing ratio; Enterprise starts with multiplexing effectively off and can configure streams per zone.
• IP Geolocation. Off by default. When enabled, Cloudflare adds the visitor country to the request headers it forwards to your origin (most visibly CF-IPCountry), so server code or analytics can regionalize without a separate geolocation lookup. This is a transform on the request path, and is useful for the region-specific failure style of debugging.

Security settings

• Security Level. Defaults to Medium. In the legacy behavioural model it challenges visitors by reputation tier (such as essentially-off above a score of 49, medium above 14, high above 0), but Cloudflare now always reports the threat score as 0 and no longer recommends rules built on it. The practical modern use is the I'm Under Attack option, which presents a managed challenge to all visitors and is intended only during an active layer-7 DDoS attack. Use a configuration rule to scope Under Attack mode to a sub-path such as the API rather than the whole zone.
• Always Use HTTPS / autoplatform. Enforced via redirect rules in the current dashboard, not a legacy toggle; keep in sync with the HTTPS redirect behaviour you want.

Changing a zone setting

The dashboard exposes the toggles; the API exposes the same state. For example, to enable 0-RTT:

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/settings/0rtt" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data '{"value":"on"}'

Because most performance settings are already sane defaults (Brotli always on, HTTP/2 to origin on), the settings that repay attention are the ones that add behaviour with a trade-off, 0-RTT (speed versus replay risk) and IP Geolocation (origin headers versus an extra transmitted signal). Pair any change with a check of the caching defaults so the performance story at the edge and at the origin stays coherent.