Skip to content
Country United Kingdom
Silurian in your countryChoose your service region

Products, billing and availability may depend on the selected country.

Contact Silurian

Silurian Docs

All documentation Security and performance

Zone settings

A guide to the TLS, security, performance, caching and network settings you can configure for a Cloudflare-protected domain, and how to change them safely.

Public guideReviewed 2026-09-11

Request path and precedence

Zone settings are defaults applied at different points between the visitor, Cloudflare edge and origin. More specific Rules can override them.

How zone settings are organized

Zone settings control broad behaviour for a domain: edge encryption, origin encryption, caching, content optimization, network protocols, request headers and security defaults. They are not one execution pipeline. A setting can be superseded by a more specific Rule, constrained by the active plan or retained only as legacy state.

Visitor, edge and origin are separate hops

A proxied request has a visitor-to-Cloudflare connection and a Cloudflare-to-origin connection. TLS protocol settings usually govern the visitor hop; SSL/TLS Encryption Mode governs the origin hop. Cache and content transformations happen at the edge, while origin timeouts and headers affect the upstream request.

  • An edge certificate cannot repair an invalid origin certificate.
  • A fast cached response says nothing about uncached origin health.
  • Only proxied traffic receives Cloudflare HTTP-layer behaviour.

SSL/TLS and HTTPS settings

Always Use HTTPS redirects HTTP visitors, Automatic HTTPS Rewrites assists with eligible mixed content, Minimum TLS Version and TLS 1.3 define visitor protocol compatibility, and SSL/TLS Encryption Mode chooses how Cloudflare connects to the origin. Full (strict) is the normal secure target when the origin has a valid matching certificate.

  • Enable working HTTPS before enforcing redirects or HSTS.
  • Keep TLS 1.2 available unless every required client supports a newer minimum.
  • Treat 0-RTT as replayable early data and keep safe HTTP methods idempotent.

Security, TLS and delivery controls

Encryption, caching, content transformation and network settings affect different layers and should not be treated as one global switchboard.

Caching and content transformation

Caching Level, Edge Cache TTL and Browser Cache TTL affect different layers. Development Mode bypasses the edge cache temporarily without purging it. Brotli and protocol settings change transport, while Rocket Loader, image optimization and rewriting features can change delivered content.

  • A Cloudflare purge cannot remove a copy already stored in a visitor's browser.
  • Do not cache personalized responses without a deliberate cache key and privacy review.
  • Test checkout, consent, analytics and script ordering after enabling HTML or JavaScript transformations.

Security settings and Rules

The WAF, Browser Integrity Check, Security Level, bot products and challenge settings provide different signals and actions. Zone-wide toggles are useful defaults, but precise long-lived policy belongs in WAF Custom Rules, rate limiting and product-specific rulesets. Use narrow exceptions instead of disabling an entire protection layer.

Configuration planning

Plan availability, legacy state and product-specific overrides must be understood before changing a production default.

Network protocols and visitor identity

IPv6 Compatibility, WebSockets, HTTP/3 and gRPC affect transport support. IP Geolocation, Pseudo IPv4, CF-Connecting-IP and True-Client-IP affect the identity information delivered to the origin. Forwarded IP headers are trustworthy only when the origin accepts requests exclusively from verified Cloudflare networks.

Plan-controlled, read-only and legacy values

Some API values report a plan capability rather than an editable switch. Others remain on older zones after Cloudflare has deprecated the product. The individual setting guide identifies whether a value is configurable, informational, plan-restricted or historical so that a reported state is not mistaken for an active feature.

Diagnostics and compatibility

Compare the same request at the edge and origin to identify the layer that produced an unexpected result.

Change one layer at a time

Record the current value and the affected hostnames, choose a representative URL and define the expected protocol, headers, status and content. Change one related setting, allow edge propagation, and compare the same request. Several simultaneous TLS, cache and Rules changes make a failure difficult to attribute.

Diagnose unexpected behaviour

First confirm that the hostname is proxied and the active plan includes the capability. Then check whether a Configuration Rule, Cache Rule, Transform Rule, Worker route or more specific product setting overrides the zone default. Finally compare the edge response with a direct, authorized origin test to separate edge behaviour from application behaviour.