Two new fields are now available in rule expressions that surface Layer 4 transport telemetry from the client connection. Together with the existing cf.timings.client_tcp_rtt_msec field, these fields give you a complete picture of connection quality for both TCP and QUIC traffic — enabling transport-aware rules without requiring any client-side changes.
Previously, QUIC RTT and delivery rate data was only available via the Server-Timing: cfL4 response header. These new fields make the same data available directly in rule expressions, so you can use them in Transform Rules, WAF Custom Rules, and other phases that support dynamic fields.
| Field | Type | Description |
|---|---|---|
cf.timings.client_quic_rtt_msec | Integer | The smoothed QUIC round-trip time (RTT) between Cloudflare and the client in milliseconds. Only populated for QUIC (HTTP/3) connections. Returns 0 for TCP connections. |
cf.edge.l4.delivery_rate | Integer | The most recent data delivery rate estimate for the client connection, in bytes per second. Returns 0 when L4 statistics are not available for the request. |
Use a request header transform rule to tag requests from high-latency connections, so your origin can serve a lighter page variant:
Rule expression:
cf.timings.client_tcp_rtt_msec > 200 or cf.timings.client_quic_rtt_msec > 200Header modifications:
| Operation | Header name | Value |
|---|---|---|
| Set | X-High-Latency | true |
cf.edge.l4.delivery_rate > 0 and cf.edge.l4.delivery_rate < 100000For more information, refer to Request Header Transform Rules and the fields reference.
Cloudflare now exposes four new fields in the Transform Rules phase that encode client certificate data in RFC 9440 ↗ format. Previously, forwarding client certificate information to your origin required custom parsing of PEM-encoded fields or non-standard HTTP header formats. These new fields produce output in the standardized Client-Cert and Client-Cert-Chain header format defined by RFC 9440, so your origin can consume them directly without any additional decoding logic.
Each certificate is DER-encoded, Base64-encoded, and wrapped in colons. For example, :MIIDsT...Vw==:. A chain of intermediates is expressed as a comma-separated list of such values.
| Field | Type | Description |
|---|---|---|
cf.tls_client_auth.cert_rfc9440 | String | The client leaf certificate in RFC 9440 format. Empty if no client certificate was presented. |
cf.tls_client_auth.cert_rfc9440_too_large | Boolean | true if the leaf certificate exceeded 10 KB and was omitted. In practice this will almost always be false. |
cf.tls_client_auth.cert_chain_rfc9440 | String | The intermediate certificate chain in RFC 9440 format as a comma-separated list. Empty if no intermediate certificates were sent or if the chain exceeded 16 KB. |
cf.tls_client_auth.cert_chain_rfc9440_too_large | Boolean | true if the intermediate chain exceeded 16 KB and was omitted. |
The chain encoding follows the same ordering as the TLS handshake: the certificate closest to the leaf appears first, working up toward the trust anchor. The root certificate is not included.
Add a request header transform rule to set the Client-Cert and Client-Cert-Chain headers on requests forwarded to your origin server. For example, to forward headers for verified, non-revoked certificates:
Rule expression:
cf.tls_client_auth.cert_verified and not cf.tls_client_auth.cert_revokedHeader modifications:
| Operation | Header name | Value |
|---|---|---|
| Set | Client-Cert | cf.tls_client_auth.cert_rfc9440 |
| Set | Client-Cert-Chain | cf.tls_client_auth.cert_chain_rfc9440 |
To get the most out of these fields, upload your client CA certificate to Cloudflare so that Cloudflare validates the client certificate at the edge and populates cf.tls_client_auth.cert_verified and cf.tls_client_auth.cert_revoked.
For more information, refer to Mutual TLS authentication, Request Header Transform Rules, and the fields reference.
The cf.timings.worker_msec field is now available in the Ruleset Engine. This field reports the wall-clock time that a Cloudflare Worker spent handling a request, measured in milliseconds.
You can use this field to identify slow Worker executions, detect performance regressions, or build rules that respond differently based on Worker processing time, such as logging requests that exceed a latency threshold.
| Field | Type | Description |
|---|---|---|
cf.timings.worker_msec | Integer | The time spent executing a Cloudflare Worker in milliseconds. Returns 0 if no Worker was invoked. |
Example filter expression:
cf.timings.worker_msec > 500For more information, refer to the Fields reference.
You can now control how Cloudflare buffers HTTP request and response bodies using two new settings in Configuration Rules.
Controls how Cloudflare buffers HTTP request bodies before forwarding them to your origin server:
| Mode | Behavior |
|---|---|
| Standard (default) | Cloudflare can inspect a prefix of the request body for enabled functionality such as WAF and Bot Management. |
| Full | Buffers the entire request body before sending to origin. |
| None | No buffering — the request body streams directly to origin without inspection. |
Controls how Cloudflare buffers HTTP response bodies before forwarding them to the client:
| Mode | Behavior |
|---|---|
| Standard (default) | Cloudflare can inspect a prefix of the response body for enabled functionality. |
| None | No buffering — the response body streams directly to the client without inspection. |
{ "action": "set_config", "action_parameters": { "request_body_buffering": "standard", "response_body_buffering": "none" }}For more information, refer to Configuration Rules.
Cloudflare Rulesets now includes encode_base64() and sha256() functions, enabling you to generate signed request headers directly in rule expressions. These functions support common patterns like constructing a canonical string from request attributes, computing a SHA256 digest, and Base64-encoding the result.
| Function | Description | Availability |
|---|---|---|
encode_base64(input, flags) | Encodes a string to Base64 format. Optional flags parameter: u for URL-safe encoding, p for padding (adds = characters to make the output length a multiple of 4, as required by some systems). By default, output is standard Base64 without padding. | All plans (in header transform rules) |
sha256(input) | Computes a SHA256 hash of the input string. | Requires enablement |
Encode a string to Base64 format:
encode_base64("hello world")Returns: aGVsbG8gd29ybGQ
Encode a string to Base64 format with padding:
encode_base64("hello world", "p")Returns: aGVsbG8gd29ybGQ=
Perform a URL-safe Base64 encoding of a string:
encode_base64("hello world", "u")Returns: aGVsbG8gd29ybGQ
Compute the SHA256 hash of a secret token:
sha256("my-token")Returns a hash that your origin can validate to authenticate requests.
Compute the SHA256 hash of a string and encode the result to Base64 format:
encode_base64(sha256("my-token"))Combines hashing and encoding for systems that expect Base64-encoded signatures.
For more information, refer to the Functions reference.
Cloudflare Rulesets now include new functions that enable advanced expression logic for evaluating arrays and maps. These functions allow you to build rules that match against lists of values in request or response headers, enabling use cases like country-based blocking using custom headers.
| Function | Description |
|---|---|
split(source, delimiter) | Splits a string into an array of strings using the specified delimiter. |
join(array, delimiter) | Joins an array of strings into a single string using the specified delimiter. |
has_key(map, key) | Returns true if the specified key exists in the map. |
has_value(map, value) | Returns true if the specified value exists in the map. |
Check if a country code exists in a header list:
has_value(split(http.response.headers["x-allow-country"][0], ","), ip.src.country)Check if a specific header key exists:
has_key(http.request.headers, "x-custom-header")Join array values for logging or comparison:
join(http.request.headers.names, ", ")For more information, refer to the Functions reference.
The ip.src.metro_code field in the Ruleset Engine is now populated with DMA (Designated Market Area) data.
You can use this field to build rules that target traffic based on geographic market areas, enabling more granular location-based policies for your applications.
| Field | Type | Description |
|---|---|---|
ip.src.metro_code | String | null | The metro code (DMA) of the incoming request's IP address. Returns the designated market area code for the client's location. |
Example filter expression:
ip.src.metro_code eq "501"For more information, refer to the Fields reference.
Cloudflare now provides two new request fields in the Ruleset engine that let you make decisions based on whether a request used TCP and the measured TCP round-trip time between the client and Cloudflare. These fields help you understand protocol usage across your traffic and build policies that respond to network performance. For example, you can distinguish TCP from QUIC traffic or route high latency requests to alternative origins when needed.
| Field | Type | Description |
|---|---|---|
cf.edge.client_tcp | Boolean | Indicates whether the request used TCP. A value of true means the client connected using TCP instead of QUIC. |
cf.timings.client_tcp_rtt_msec | Number | Reports the smoothed TCP round-trip time between the client and Cloudflare in milliseconds. For example, a value of 20 indicates roughly twenty milliseconds of RTT. |
Example filter expression:
cf.edge.client_tcp && cf.timings.client_tcp_rtt_msec < 100More information can be found in the Rules language fields reference.
Custom Errors can now fetch and store assets and error pages from your origin even if they are served with a 4xx or 5xx HTTP status code — previously, only 200 OK responses were allowed.
What’s new:
This is especially useful for retrieving error content or downtime banners from your backend when you can’t override the origin status code.
Learn more in the Custom Errors documentation.
You can now use the cf.worker.upstream_zone field in Transform Rules to control rule execution based on whether a request originates from Workers, including subrequests issued by Workers in other zones.
What's new:
cf.worker.upstream_zone is now supported in Transform Rules expressions.For example, to add a header when the subrequest comes from another zone:
Text in Expression Editor (replace myappexample.com with your domain):
(cf.worker.upstream_zone != "" and cf.worker.upstream_zone != "myappexample.com")Selected operation under Modify request header: Set static
Header name: X-External-Workers-Subrequest
Value: 1
This gives you more granular control in how you handle incoming requests for your zone.
Learn more in the Transform Rules documentation and Rules language fields reference.
You can now enable Polish with the webp format directly in Configuration Rules, allowing you to optimize image delivery for specific routes, user agents, or A/B tests — without applying changes zone-wide.
What’s new:
This gives you more precise control over how images are compressed and delivered, whether you're targeting modern browsers, running experiments, or tailoring performance by geography or device type.
Learn more in the Polish and Configuration Rules documentation.
You can now use IP, Autonomous System (AS), and Hostname custom lists to route traffic to Snippets and Cloud Connector, giving you greater precision and control over how you match and process requests at the edge.
In Snippets, you can now also match on Bot Score and WAF Attack Score, unlocking smarter edge logic for everything from request filtering and mitigation to tarpitting and logging.
What’s new:
These enhancements unlock new possibilities for building smarter traffic workflows with minimal code and maximum efficiency.
Learn more in the Snippets and Cloud Connector documentation.
Custom Errors are now generally available for all paid plans — bringing a unified and powerful experience for customizing error responses at both the zone and account levels.
You can now manage Custom Error Rules, Custom Error Assets, and redesigned Error Pages directly from the Cloudflare dashboard. These features let you deliver tailored messaging when errors occur, helping you maintain brand consistency and improve user experience — whether it’s a 404 from your origin or a security challenge from Cloudflare.
What's new:
Learn more in the Custom Errors documentation.
Cloudflare Snippets are now generally available at no extra cost across all paid plans — giving you a fast, flexible way to programmatically control HTTP traffic using lightweight JavaScript.
You can now use Snippets to modify HTTP requests and responses with confidence, reliability, and scale. Snippets are production-ready and deeply integrated with Cloudflare Rules, making them ideal for everything from quick dynamic header rewrites to advanced routing logic.
What's new:
Snippets are now GA – Available at no extra cost on all Pro, Business, and Enterprise plans.
Ready for production – Snippets deliver a production-grade experience built for scale.
Part of the Cloudflare Rules platform – Snippets inherit request modifications from other Cloudflare products and support sequential execution, allowing you to run multiple Snippets on the same request and apply custom modifications step by step.
Trace integration – Use Cloudflare Trace to see which Snippets were triggered on a request — helping you understand traffic flow and debug more effectively.
Learn more in the launch blog post ↗.
We have upgraded and streamlined Cloudflare Rules limits across all plans, simplifying rule management and improving scalability for everyone.
New limits by product:
We're introducing Custom Errors (beta), which builds on our existing Custom Error Responses feature with new asset storage capabilities.
This update allows you to store externally hosted error pages on Cloudflare and reference them in custom error rules, eliminating the need to supply inline content.
This brings the following new capabilities:
You can use Cloudflare API to upload your existing assets for use with Custom Errors:
curl "https://api.cloudflare.com/client/v4/zones/{zone_id}/custom_pages/assets" \--header "Authorization: Bearer <API_TOKEN>" \--header 'Content-Type: application/json' \--data '{ "name": "maintenance", "description": "Maintenance template page", "url": "https://example.com/"}'You can then reference the stored asset in a Custom Error rule:
curl --request PUT \"https://api.cloudflare.com/client/v4/zones/{zone_id}/rulesets/phases/http_custom_errors/entrypoint" \--header "Authorization: Bearer <API_TOKEN>" \--header 'Content-Type: application/json' \--data '{ "rules": [ { "action": "serve_error", "action_parameters": { "asset_name": "maintenance", "content_type": "text/html", "status_code": 503 }, "enabled": true, "expression": "http.request.uri.path contains \"error\"" } ]}'The new Snippets code editor lets you edit Snippet code and rule in one place, making it easier to test and deploy changes without switching between pages.
What’s new:
Try it now in Rules > Snippets ↗.
Rules Overview gives you a single page to manage all your Cloudflare Rules.
What you can do:
Check it out in Rules > Overview ↗.
Now, you can manage Cloudflare Snippets with Terraform. Use infrastructure-as-code to deploy and update Snippet code and rules without manual changes in the dashboard.
Example Terraform configuration:
resource "cloudflare_snippet" "my_snippet" { zone_id = "<ZONE_ID>" name = "my_test_snippet_1" main_module = "file1.js" files { name = "file1.js" content = file("file1.js") }}
resource "cloudflare_snippet_rules" "cookie_snippet_rule" { zone_id = "<ZONE_ID>" rules { enabled = true expression = "http.cookie eq \"a=b\"" description = "Trigger snippet on specific cookie" snippet_name = "my_test_snippet_1" } depends_on = [cloudflare_snippet.my_snippet]}Learn more in the Configure Snippets using Terraform documentation.
Now, you can use Cloud Connector to route traffic to your R2 buckets based on URLs, headers, geolocation, and more.
Example setup:
curl --request PUT \"https://api.cloudflare.com/client/v4/zones/{zone_id}/cloud_connector/rules" \--header "Authorization: Bearer <API_TOKEN>" \--header "Content-Type: application/json" \--data '[ { "expression": "http.request.uri.path wildcard \"/images/*\"", "provider": "cloudflare_r2", "description": "Connect to R2 bucket containing images", "parameters": { "host": "mybucketcustomdomain.example.com" } }]'Get started using Cloud Connector documentation.
It’s now easy to create wildcard-based URL Rewrites. No need for complex functions—just define your patterns and go.
What’s improved:
Try it via creating a Rewrite URL rule in the dashboard.
Now, you can create common rule configurations in just one click using Rules Templates.
What you can do:
Template cards are now also available directly in the rule builder for each product.
Need more ideas? Check out the Examples gallery in our documentation.