--- title: Application performance Changelog image: https://developers.cloudflare.com/cf-twitter-card.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/changelog/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Changelog New updates and improvements at Cloudflare. [ Subscribe to RSS ](https://developers.cloudflare.com/changelog/rss/index.xml) [ View RSS feeds ](https://developers.cloudflare.com/fundamentals/new-features/available-rss-feeds/) Application performance ![hero image](https://developers.cloudflare.com/_astro/hero.CVYJHPAd_26AMqX.svg) Apr 28, 2026 1. ### [Account-level enforce DNS-only](https://developers.cloudflare.com/changelog/post/2026-04-28-enforce-dns-only/) [ DNS ](https://developers.cloudflare.com/dns/) You can now disable Cloudflare's reverse proxy across all zones in your account simultaneously using the new `enforce_dns_only` setting. When enabled, Cloudflare responds to DNS queries for all proxied records with your origin IP addresses instead of Cloudflare's anycast IPs. This account-level kill switch is designed for incident response scenarios where you need to quickly route traffic directly to your origin servers. Warning Enabling this setting exposes your origin IP addresses and removes all Cloudflare protections — including DDoS mitigation, WAF, caching, and all other proxy-based features — for every zone in your account. Use with extreme caution and only after proper [preparations](https://developers.cloudflare.com/dns/proxy-status/enforce-dns-only/#preparation). #### Key characteristics * **Account-level** — Affects all zones in the account simultaneously with a single API call. * **Non-destructive** — Does not modify your DNS records. Disabling the setting restores normal proxy behavior. * **API-only** — Available through the API only, not in the Cloudflare dashboard. #### What's affected **Included:** Standard proxied A, AAAA, and CNAME records, Load Balancing records, and records matching Worker routes. **Excluded:** Spectrum applications, Cloudflare Tunnel CNAMEs, R2 custom domains, Web3 gateways, and Workers custom domains continue to operate normally. #### Before you enable * Verify your origin servers can handle direct traffic without Cloudflare's caching and filtering. * Review which origin IPs will become publicly visible through DNS queries. * Test the API in a staging account before relying on it for incident response. #### Availability Available via API to all Cloudflare customers. For information on how to use it, refer to [Enforce DNS-only developer documentation](https://developers.cloudflare.com/dns/proxy-status/enforce-dns-only/) . Apr 27, 2026 1. ### [Cache Response Rules now support zone versioning](https://developers.cloudflare.com/changelog/post/2026-04-27-cache-response-rules-zone-versioning/) [ Cache / CDN ](https://developers.cloudflare.com/cache/) Cache Response Rules now work with [Version Management](https://developers.cloudflare.com/version-management/). You can version response-phase cache settings and promote them through environments, just like Cache Rules and other supported configurations. #### What changed Previously, Cache Response Rules were excluded from zone versioning. Any response-phase rule you created applied globally across all environments with no way to test changes in staging first. Cache Rules already supported versioning, but the response phase, where you modify `Cache-Control` directives, manage cache tags, and strip headers, did not. Cache Response Rules are now fully integrated with Version Management. You can create or modify response-phase rules within a version, and those changes stay scoped to that version until promoted. #### Benefits * **Safe rollout of cache behavior changes**: Test response-phase rules in a staging environment before promoting to production. Catch unintended caching side effects early. * **Parity with Cache Rules**: Cache Response Rules now follow the same versioning workflow as Cache Rules, so you can manage all cache configuration through a single promotion pipeline. * **Independent environment control**: Run different response-phase cache settings per environment. For example, strip `Set-Cookie` headers in staging to validate cacheability without affecting production traffic. #### Get started Configure Cache Response Rules in the [Cloudflare dashboard ↗](https://dash.cloudflare.com/?to=/:account/:zone/caching/cache-rules) under **Caching** \> **Cache Rules**, or via the [Rulesets API](https://developers.cloudflare.com/ruleset-engine/rulesets-api/). For more details, refer to the [Cache Response Rules documentation](https://developers.cloudflare.com/cache/how-to/cache-response-rules/) and the [Version Management documentation](https://developers.cloudflare.com/version-management/). Apr 17, 2026 1. ### [Smart Tiered Cache optimizes public cloud origins](https://developers.cloudflare.com/changelog/post/2026-04-17-smart-tiered-cache-for-public-cloud/) [ Cache / CDN ](https://developers.cloudflare.com/cache/) You can now achieve higher cache HIT rates and reduce origin load for origins hosted on public cloud providers with [Smart Tiered Cache](https://developers.cloudflare.com/cache/how-to/tiered-cache/#smart-tiered-cache). By setting a cloud region hint for your origin, Cloudflare selects the optimal upper-tier data center for that cloud region, funneling all cache MISSes through a single location close to your origin. Previously, Smart Tiered Cache could not reliably select an optimal upper tier for origins behind anycast or regional unicast networks commonly used by cloud providers. Origins on AWS, GCP, Azure, and Oracle Cloud would fall back to a multi-upper-tier topology, resulting in lower cache HIT rates and more requests reaching your origin. #### How it works Set a cloud region hint (for example, `aws/us-east-1` or `gcp/europe-west1`) for your origin IP or hostname. Smart Tiered Cache uses this hint along with real-time latency data to select a primary upper tier close to your cloud region, plus a fallback in a different location for resilience. * **Supported providers**: AWS, GCP, Azure, and Oracle Cloud. * **All plans**: Available on Free, Pro, Business, and Enterprise plans at no additional cost. * **Dashboard and API**: Configure from **Caching** \> **Tiered Cache** \> **Origin Configuration**, or use the API and Terraform. #### Get started To get started, enable [Smart Tiered Cache](https://developers.cloudflare.com/cache/how-to/tiered-cache/) and set a cloud region hint for your origin in the [Tiered Cache settings](https://developers.cloudflare.com/cache/how-to/tiered-cache/#public-cloud-origins). Apr 07, 2026 1. ### [Manage mTLS and BYO CA certificates from the Cloudflare dashboard](https://developers.cloudflare.com/changelog/post/2026-04-07-mtls-byoca-dashboard/) [ SSL/TLS ](https://developers.cloudflare.com/ssl/) You can now manage mutual TLS (mTLS) and Bring Your Own Certificate Authority (BYO CA) configurations directly from the Cloudflare dashboard — no API required. Previously, these advanced workflows required the Cloudflare API. The following are now available in the dashboard: * **AOP certificate management** — Upload and manage your own certificate authorities for [Authenticated Origin Pulls (AOP)](https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/)directly from the dashboard. * **BYO Client mTLS certificate management** — Upload and manage your own CA certificates for [client mTLS enforcement](https://developers.cloudflare.com/ssl/client-certificates/byo-ca/)without needing API access. * **CDN hostname to client mTLS certificate mapping** — Associate client mTLS certificates with specific hostnames directly from the dashboard. Apr 01, 2026 1. ### [New QUIC RTT and delivery rate fields](https://developers.cloudflare.com/changelog/post/2026-04-01-l4-transport-telemetry-fields/) [ Rules ](https://developers.cloudflare.com/rules/) 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](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/) 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. #### New 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. | #### Example: Route slow connections to a lightweight origin 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 > 200 ``` **Header modifications:** | Operation | Header name | Value | | --------- | -------------- | ----- | | Set | X-High-Latency | true | #### Example: Match low-bandwidth connections ``` cf.edge.l4.delivery_rate > 0 and cf.edge.l4.delivery_rate < 100000 ``` For more information, refer to [Request Header Transform Rules](https://developers.cloudflare.com/rules/transform/request-header-modification/) and the [fields reference](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/). Mar 31, 2026 1. ### [Internal DNS - now in open beta](https://developers.cloudflare.com/changelog/post/2026-03-31-internal-dns-open-beta/) [ DNS ](https://developers.cloudflare.com/dns/) Internal DNS is now in open beta. #### Who can use it? Internal DNS is bundled as a part of Cloudflare Gateway and is now available to every Enterprise customer with one of the following subscriptions: * Cloudflare Zero Trust Enterprise * Cloudflare Gateway Enterprise To learn more and get started, refer to the [Internal DNS documentation](https://developers.cloudflare.com/dns/internal-dns/). Mar 25, 2026 1. ### [New mTLS certificate fields for Transform Rules](https://developers.cloudflare.com/changelog/post/2026-03-25-rfc9440-mtls-fields/) [ Rules ](https://developers.cloudflare.com/rules/) Cloudflare now exposes four new fields in the Transform Rules phase that encode client certificate data in [RFC 9440 ↗](https://www.rfc-editor.org/rfc/rfc9440) 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. #### New fields | 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. #### Example: Forwarding client certificate headers to your origin server 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_revoked ``` **Header 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`. Prevent header injection You should ensure that `Client-Cert` and `Client-Cert-Chain` headers received by your origin server can only originate from this transform rule — any client could send these headers directly. * **If you use WAF custom rules to block requests with invalid mTLS connections:** The transform rule is sufficient. For all requests that reach your origin server, the rule will overwrite any existing `Client-Cert` and `Client-Cert-Chain` headers. * **If you do not enforce mTLS at the WAF:** Add another transform rule that removes any incoming `Client-Cert` and `Client-Cert-Chain` headers from all requests (use expression `true`), ordered before the rule above. This ensures your origin server cannot receive client-supplied values for these HTTP headers. For more information, refer to [Mutual TLS authentication](https://developers.cloudflare.com/cloudflare-one/access-controls/service-credentials/mutual-tls-authentication/), [Request Header Transform Rules](https://developers.cloudflare.com/rules/transform/request-header-modification/), and the [fields reference](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/). Mar 24, 2026 1. ### [Cache Response Rules](https://developers.cloudflare.com/changelog/post/2026-03-24-cache-response-rules/) [ Cache / CDN ](https://developers.cloudflare.com/cache/) You can now control how Cloudflare handles origin responses without changing your origin. Cache Response Rules let you modify `Cache-Control` directives, manage cache tags, and strip headers like `Set-Cookie` from origin responses _before_ they reach Cloudflare's cache. Whether traffic is cached or passed through dynamically, these rules give you control over origin response behavior that was previously out of reach. #### What changed Cache Rules previously only operated on request attributes. Cache Response Rules introduce a new response phase that evaluates origin responses and lets you act on them before caching. You can now: * **Modify `Cache-Control` directives**: Set or remove individual directives like `no-store`, `no-cache`, `max-age`, `s-maxage`, `stale-while-revalidate`, `immutable`, and more. For example, remove a `no-cache` directive your origin sends so Cloudflare can cache the asset, or set an `s-maxage` to control how long Cloudflare stores it. * **Set a different browser `Cache-Control`**: Send a different `Cache-Control` header downstream to browsers and other clients than what Cloudflare uses internally, giving you independent control over edge and browser caching strategies. * **Manage cache tags**: Add, set, or remove cache tags on responses, including converting tags from another CDN's header format into Cloudflare's `Cache-Tag` header. This is especially useful if you are migrating from a CDN that uses a different tag header or delimiter. * **Strip headers that block caching**: Remove `Set-Cookie`, `ETag`, or `Last-Modified` headers from origin responses before caching, so responses that would otherwise be treated as uncacheable can be stored and served from cache. #### Benefits * **No origin changes required**: Fix caching behavior entirely from Cloudflare, even when your origin configuration is locked down or managed by a different team. * **Simpler CDN migration**: Match caching behavior from other CDN providers without rewriting your origin. Translate cache tag formats and override directives that do not align with Cloudflare's defaults. * **Native support, fewer workarounds**: Functionality that previously required workarounds is now built into Cache Rules with full Tiered Cache compatibility. * **Fine-grained control**: Use expressions to match on request and response attributes, then apply precise cache settings per rule. Rules are stackable and composable with existing Cache Rules. #### Get started Configure Cache Response Rules in the [Cloudflare dashboard ↗](https://dash.cloudflare.com/?to=/:account/:zone/caching/cache-rules) under **Caching** \> **Cache Rules**, or via the [Rulesets API ↗](https://developers.cloudflare.com/ruleset-engine/rulesets-api/). For more details, refer to the [Cache Rules documentation ↗](https://developers.cloudflare.com/cache/how-to/cache-response-rules/). Mar 20, 2026 1. ### [DNS Analytics for Customer Metadata Boundary set to EU region](https://developers.cloudflare.com/changelog/post/2026-03-20-dns-analytics-cmb-eu/) [ DNS ](https://developers.cloudflare.com/dns/) DNS Analytics is now available for customers with [Customer Metadata Boundary](https://developers.cloudflare.com/data-localization/metadata-boundary/) (CMB) set to EU. Query your DNS analytics data while keeping metadata stored in the EU region. This update includes: * **DNS Analytics** — Access the same DNS analytics experience for zones in CMB=EU accounts. * **EU data residency** — Analytics data is stored and queried from the EU region, meeting data localization requirements. * **DNS Firewall Analytics** — DNS Firewall analytics is now supported for CMB=EU customers. #### Availability Available to customers with the [Data Localization Suite](https://developers.cloudflare.com/data-localization/) who have Customer Metadata Boundary configured for the EU region. #### Where to find it * **Authoritative DNS:** In the Cloudflare dashboard, select your zone and go to the **Analytics** page. [ Go to **Analytics** ](https://dash.cloudflare.com/?to=/:account/:zone/dns/analytics) * **DNS Firewall:** In the Cloudflare dashboard, go to the **DNS Firewall Analytics** page. [ Go to **Analytics** ](https://dash.cloudflare.com/?to=/:account/dns-firewall/analytics) For more information, refer to [DNS Analytics](https://developers.cloudflare.com/dns/additional-options/analytics/) and [DNS Firewall Analytics](https://developers.cloudflare.com/dns/dns-firewall/analytics/). Mar 18, 2026 1. ### [Worker execution timing field now available in Rules](https://developers.cloudflare.com/changelog/post/2026-03-18-worker-timing-field/) [ Rules ](https://developers.cloudflare.com/rules/) 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 details | 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 > 500 ``` For more information, refer to the [Fields reference](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/cf.timings.worker%5Fmsec/). Feb 26, 2026 1. ### [Asynchronous stale-while-revalidate](https://developers.cloudflare.com/changelog/post/2026-02-26-async-stale-while-revalidate/) [ Cache / CDN ](https://developers.cloudflare.com/cache/) Cloudflare's [stale-while-revalidate](https://developers.cloudflare.com/cache/concepts/cache-control/#revalidation) support is now fully asynchronous. Previously, the first request for a stale (expired) asset in cache had to wait for an origin response, after which that visitor received a REVALIDATED or EXPIRED status. Now, the first request after the asset expires triggers revalidation in the background and immediately receives stale content with an UPDATING status. All following requests also receive stale content with an `UPDATING` status until the origin responds, after which subsequent requests receive fresh content with a `HIT` status. `stale-while-revalidate` is a `Cache-Control` directive set by your origin server that allows Cloudflare to serve an expired cached asset while a fresh copy is fetched from the origin. Asynchronous revalidation brings: * **Lower latency**: No visitor is waiting for the origin when the asset is already in cache. Every request is served from cache during revalidation. * **Consistent experience**: All visitors receive the same cached response during revalidation. * **Reduced error exposure**: The first request is no longer vulnerable to origin timeouts or errors. All visitors receive a cached response while revalidation happens in the background. #### Availability This change is live for all Free, Pro, and Business zones. Approximately 75% of Enterprise zones have been migrated, with the remaining zones rolling out throughout the quarter. #### Get started To use this feature, make sure your origin includes the `stale-while-revalidate` directive in the `Cache-Control` header. Refer to the [Cache-Control documentation](https://developers.cloudflare.com/cache/concepts/cache-control/#revalidation) for details. Jan 27, 2026 1. ### [Control request and response body buffering in Configuration Rules](https://developers.cloudflare.com/changelog/post/2026-01-27-body-buffering-settings/) [ Rules ](https://developers.cloudflare.com/rules/) You can now control how Cloudflare buffers HTTP request and response bodies using two new settings in [Configuration Rules](https://developers.cloudflare.com/rules/configuration-rules/). #### Request body buffering 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. | #### Response body buffering 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. | Warning Setting body buffering to **None** may break security functionality that requires body inspection, including the Web Application Firewall (WAF) and Bot Management. Ensure that any paths where you disable buffering do not require security inspection. #### API example ``` { "action": "set_config", "action_parameters": { "request_body_buffering": "standard", "response_body_buffering": "none" } } ``` For more information, refer to [Configuration Rules](https://developers.cloudflare.com/rules/configuration-rules/). Jan 22, 2026 1. ### [New cryptographic functions — encode\_base64() and sha256()](https://developers.cloudflare.com/changelog/post/2026-01-22-sha256-base64-encode-functions/) [ Rules ](https://developers.cloudflare.com/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. --- #### New functions | 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 | Note The `sha256()` function is available as an Enterprise add-on and requires a specific entitlement. Contact your account team to enable it. --- #### Examples **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](https://developers.cloudflare.com/ruleset-engine/rules-language/functions/). Jan 20, 2026 1. ### [New functions for array and map operations](https://developers.cloudflare.com/changelog/post/2026-01-20-array-map-functions/) [ Rules ](https://developers.cloudflare.com/rules/) #### New functions for array and map operations 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. --- #### New functions | 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. | --- #### Example use cases **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](https://developers.cloudflare.com/ruleset-engine/rules-language/functions/). Jan 12, 2026 1. ### [Metro code field now available in Rules](https://developers.cloudflare.com/changelog/post/2026-01-12-dma-metro-code-field/) [ Rules ](https://developers.cloudflare.com/rules/) 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 details | 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](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/ip.src.metro%5Fcode/). Nov 25, 2025 1. ### [Audit Logs for Cache Purge Events](https://developers.cloudflare.com/changelog/post/2025-11-25-audit-logs-for-cache-purge-events/) [ Cache / CDN ](https://developers.cloudflare.com/cache/) You can now review detailed audit logs for cache purge events, giving you visibility into what purge requests were sent, what they contained, and by whom. Audit your purge requests via the Dashboard or API for all purge methods: * Purge everything * List of prefixes * List of tags * List of hosts * List of files #### Example The detailed audit payload is visible within the Cloudflare Dashboard (under **Manage Account** \> **Audit Logs**) and via the API. Below is an example of the Audit Logs v2 payload structure: ``` { "action": { "result": "success", "type": "create" }, "actor": { "id": "1234567890abcdef", "email": "user@example.com", "type": "user" }, "resource": { "product": "purge_cache", "request": { "files": [ "https://example.com/images/logo.png", "https://example.com/css/styles.css" ] } }, "zone": { "id": "023e105f4ecef8ad9ca31a8372d0c353", "name": "example.com" } } ``` #### Get started To get started, refer to the [Audit Logs documentation](https://developers.cloudflare.com/fundamentals/account/account-security/audit-logs/). Nov 07, 2025 1. ### [Inspect Cache Keys with Cloudflare Trace](https://developers.cloudflare.com/changelog/post/2025-11-07-cache-keys-for-cloudflare-trace/) [ Cache / CDN ](https://developers.cloudflare.com/cache/) You can now see the exact cache key generated for any request directly in Cloudflare Trace. This visibility helps you troubleshoot cache hits and misses, and verify that your Custom Cache Keys — configured via Cache Rules or Page Rules — are working as intended. Previously, diagnosing caching behavior required inferring the key from configuration settings. Now, you can confirm that your custom logic for headers, query strings, and device types is correctly applied. Access Trace via the [dashboard](https://developers.cloudflare.com/rules/trace-request/how-to/#use-trace-in-the-dashboard) or [API](https://developers.cloudflare.com/api/resources/request%5Ftracer/methods/trace/), either manually for ad-hoc debugging or automated as part of your quality-of-service monitoring. #### Example scenario If you have a Cache Rule that segments content based on a specific cookie (for example, `user_region`), run a Trace with that cookie present to confirm the `user_region` value appears in the resulting cache key. The Trace response includes the cache key in the `cache` object: ``` { "step_name": "request", "type": "cache", "matched": true, "public_name": "Cache Parameters", "cache": { "key": { "zone_id": "023e105f4ecef8ad9ca31a8372d0c353", "scheme": "https", "host": "example.com", "uri": "/images/hero.jpg" }, "key_string": "023e105f4ecef8ad9ca31a8372d0c353::::https://example.com/images/hero.jpg:::::" } } ``` #### Get started To learn more, refer to the [Trace documentation](https://developers.cloudflare.com/rules/trace-request/) and our guide on [Custom Cache Keys](https://developers.cloudflare.com/cache/how-to/cache-keys/). Oct 30, 2025 1. ### [New TCP-based fields available in Rulesets](https://developers.cloudflare.com/changelog/post/2025-10-30-tcp-rtt-and-tcp-fields/) [ Rules ](https://developers.cloudflare.com/rules/) #### Build rules based on TCP transport and latency 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. --- #### New fields | 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 < 100 ``` More information can be found in the Rules language [fields reference](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/reference/). Oct 16, 2025 1. ### [Monitor Groups for Advanced Health Checking With Load Balancing](https://developers.cloudflare.com/changelog/post/2025-08-15-monitor-groups-for-load-balancing/) [ Load Balancing ](https://developers.cloudflare.com/load-balancing/) Cloudflare Load Balancing now supports Monitor Groups, a powerful new way to combine multiple health monitors into a single, logical group. This allows you to create sophisticated health checks that more accurately reflect the true availability of your applications by assessing multiple services at once. With Monitor Groups, you can ensure that all critical components of an application are healthy before sending traffic to an origin pool, enabling smarter failover decisions and greater resilience. This feature is now available via the API for customers with an Enterprise Load Balancing subscription. #### What you can do: * **Combine Multiple Monitors**: Group different health monitors (for example, HTTP, TCP) that check various application components, like a primary API gateway and a specific `/login` service. * **Isolate Monitors for Observation**: Mark a monitor as "monitoring only" to receive alerts and data without it affecting a pool's health status or traffic steering. This is perfect for testing new checks or observing non-critical dependencies. * **Improve Steering Intelligence**: Latency for Dynamic Steering is automatically averaged across all active monitors in a group, providing a more holistic view of an origin's performance. This enhancement is ideal for complex, multi-service applications where the health of one component depends on another. By aggregating health signals, Monitor Groups provide a more accurate and comprehensive assessment of your application's true status. For detailed information and API configuration guides, please visit our [developer documentation](https://developers.cloudflare.com/load-balancing/monitors/monitor-groups) for Monitor Groups. Sep 16, 2025 1. ### [DNS Firewall Analytics — now in the Cloudflare dashboard](https://developers.cloudflare.com/changelog/post/2025-09-16-dnsfw-analytics-ui/) [ DNS ](https://developers.cloudflare.com/dns/) #### What's New Access [GraphQL-powered DNS Firewall analytics](https://developers.cloudflare.com/dns/dns-firewall/analytics/) directly in the Cloudflare dashboard. ![DNS Firewall Analytics UI](https://developers.cloudflare.com/_astro/DNSFW_Analytics_UI.CgjmZFOO_Z1tNsEz.webp) #### Explore Four Interactive Panels * **Query summary**: Describes trends over time, segmented by dimensions. * **Query statistics**: Describes totals, cached/uncached queries, and processing/response times. * **DNS queries by data center**: Describes global view and the top 10 data centers. * **Top query statistics**: Shows a breakdown by key dimensions, with search and expand options (up to top 100 items). Additional features: * Apply filters and time ranges once. Changes reflect across all panels. * Filter by dimensions like query name, query type, cluster, data center, protocol (UDP/TCP), IP version, response code/reason, and more. * Access up to 62 days of historical data with flexible intervals. #### Availability Available to all DNS Firewall customers as part of their existing subscription. #### Where to Find It * In the Cloudflare dashboard, go to the **DNS Firewall** page. [ Go to **Analytics** ](https://dash.cloudflare.com/?to=/:account/dns-firewall/analytics) * Refer to the [DNS Firewall Analytics](https://developers.cloudflare.com/dns/dns-firewall/analytics/) to learn more. Aug 29, 2025 1. ### [Smart Tiered Cache Fallback to Generic](https://developers.cloudflare.com/changelog/post/2025-08-29-smart-tiered-cache-fallback-to-generic/) [ Cache / CDN ](https://developers.cloudflare.com/cache/) [Smart Tiered Cache](https://developers.cloudflare.com/cache/how-to/tiered-cache/#smart-tiered-cache) now falls back to [Generic Tiered Cache](https://developers.cloudflare.com/cache/how-to/tiered-cache/#generic-global-tiered-cache) when the origin location cannot be determined, improving cache precision for your content. Previously, when Smart Tiered Cache was unable to select the optimal upper tier (such as when origins are masked by Anycast IPs), latency could be negatively impacted. This fallback now uses Generic Tiered Cache instead, providing better performance and cache efficiency. #### How it works When Smart Tiered Cache falls back to Generic Tiered Cache: 1. **Multiple upper-tiers**: Uses all of Cloudflare's global data centers as a network of upper-tiers instead of a single optimal location. 2. **Distributed cache requests**: Lower-tier data centers can query any available upper-tier for cached content. 3. **Improved global coverage**: Provides better cache hit ratios across geographically distributed visitors. 4. **Automatic fallback**: Seamlessly transitions when origin location cannot be determined, such as with Anycast-masked origins. #### Benefits * **Preserves high performance during fallback**: Smart Tiered Cache now maintains strong cache efficiency even when optimal upper tier selection is not possible. * **Minimizes latency impact**: Automatically uses Generic Tiered Cache topology to keep performance high when origin location cannot be determined. * **Seamless experience**: No configuration changes or intervention required when fallback occurs. * **Improved resilience**: Smart Tiered Cache remains effective across diverse origin infrastructure, including Anycast-masked origins. #### Get started This improvement is automatically applied to all zones using [Smart Tiered Cache](https://developers.cloudflare.com/cache/how-to/tiered-cache/). No action is required on your part. Aug 25, 2025 1. ### [Manage and deploy your AI provider keys through Bring Your Own Key (BYOK) with AI Gateway, now powered by Cloudflare Secrets Store](https://developers.cloudflare.com/changelog/post/2025-08-25-secrets-store-ai-gateway/) [ Secrets Store ](https://developers.cloudflare.com/secrets-store/)[ AI Gateway ](https://developers.cloudflare.com/ai-gateway/)[ SSL/TLS ](https://developers.cloudflare.com/ssl/) Cloudflare Secrets Store is now integrated with AI Gateway, allowing you to store, manage, and deploy your AI provider keys in a secure and seamless configuration through [Bring Your Own Key ↗](https://developers.cloudflare.com/ai-gateway/configuration/bring-your-own-keys/). Instead of passing your AI provider keys directly in every request header, you can centrally manage each key with Secrets Store and deploy in your gateway configuration using only a reference, rather than passing the value in plain text. You can now create a secret directly from your AI Gateway [in the dashboard ↗](http://dash.cloudflare.com/?to=/:account/ai-gateway) by navigating into your gateway -> **Provider Keys** \-> **Add**. ![Import repo or choose template](https://developers.cloudflare.com/_astro/add-secret-ai-gateway.B-SIPr6s_jJjDD.webp) You can also create your secret with the newly available **ai\_gateway** scope via [wrangler ↗](https://developers.cloudflare.com/workers/wrangler/commands/), the [Secrets Store dashboard ↗](http://dash.cloudflare.com/?to=/:account/secrets-store), or the [API ↗](https://developers.cloudflare.com/api/resources/secrets%5Fstore/). Then, pass the key in the request header using its Secrets Store reference: ``` curl -X POST https://gateway.ai.cloudflare.com/v1//my-gateway/anthropic/v1/messages \ --header 'cf-aig-authorization: ANTHROPIC_KEY_1 \ --header 'anthropic-version: 2023-06-01' \ --header 'Content-Type: application/json' \ --data '{"model": "claude-3-opus-20240229", "messages": [{"role": "user", "content": "What is Cloudflare?"}]}' ``` Or, using Javascript: ``` import Anthropic from '@anthropic-ai/sdk'; const anthropic = new Anthropic({ apiKey: "ANTHROPIC_KEY_1", baseURL: "https://gateway.ai.cloudflare.com/v1//my-gateway/anthropic", }); const message = await anthropic.messages.create({ model: 'claude-3-opus-20240229', messages: [{role: "user", content: "What is Cloudflare?"}], max_tokens: 1024 }); ``` For more information, check out the [blog ↗](https://blog.cloudflare.com/ai-gateway-aug-2025-refresh)! Aug 15, 2025 1. ### [Steer Traffic by AS Number in Load Balancing Custom Rules](https://developers.cloudflare.com/changelog/post/2025-08-15-asnum-support-in-custom-rules/) [ Load Balancing ](https://developers.cloudflare.com/load-balancing/) You can now create more granular, network-aware Custom Rules in Cloudflare Load Balancing using the Autonomous System Number (ASN) of an incoming request. This allows you to steer traffic with greater precision based on the network source of a request. For example, you can route traffic from specific Internet Service Providers (ISPs) or enterprise customers to dedicated infrastructure, optimize performance, or enforce compliance by directing certain networks to preferred data centers. ![Create a Load Balancing Custom Rule using AS Num](https://developers.cloudflare.com/_astro/asnum-custom-rule.CtcHu_zj_Z24vRO0.webp) To get started, create a [Custom Rule ↗](https://developers.cloudflare.com/load-balancing/additional-options/load-balancing-rules/) in your Load Balancer and select **AS Num** from the **Field** dropdown. Aug 06, 2025 1. ### [Improvements to Monitoring Using Zone Settings](https://developers.cloudflare.com/changelog/post/2025-08-06-zone-monitoring-improvements/) [ Load Balancing ](https://developers.cloudflare.com/load-balancing/) Cloudflare Load Balancing Monitors support loading and applying settings for a specific zone to monitoring requests to origin endpoints. This feature has been migrated to new infrastructure to improve reliability, performance, and accuracy. All zone monitors have been tested against the new infrastructure. There should be no change to health monitoring results of currently healthy and active pools. Newly created or re-enabled pools may need validation of their monitor zone settings before being introduced to service, especially regarding correct application of mTLS. #### What you can expect: * More reliable application of zone settings to monitoring requests, including * Authenticated Origin Pulls * Aegis Egress IP Pools * Argo Smart Routing * HTTP/2 to Origin * Improved support and bug fixes for retries, redirects, and proxied origin resolution * Improved performance and reliability of monitoring requests within the Cloudflare network * Unrelated CDN or WAF configuration changes should have no risk of impact to pool health Jun 19, 2025 1. ### [Account-level DNS analytics now available via GraphQL Analytics API](https://developers.cloudflare.com/changelog/post/2025-06-23-account-level-dns-analytics-api/) [ DNS ](https://developers.cloudflare.com/dns/) Authoritative DNS analytics are now available on the **account level** via the [Cloudflare GraphQL Analytics API](https://developers.cloudflare.com/analytics/graphql-api/). This allows users to query DNS analytics across multiple zones in their account, by using the `accounts` filter. Here is an example to retrieve the most recent DNS queries across all zones in your account that resulted in an `NXDOMAIN` response over a given time frame. Please replace `a30f822fcd7c401984bf85d8f2a5111c` with your actual account ID. GraphQL example for account-level DNS analytics ``` query GetLatestNXDOMAINResponses { viewer { accounts(filter: { accountTag: "a30f822fcd7c401984bf85d8f2a5111c" }) { dnsAnalyticsAdaptive( filter: { date_geq: "2025-06-16" date_leq: "2025-06-18" responseCode: "NXDOMAIN" } limit: 10000 orderBy: [datetime_DESC] ) { zoneTag queryName responseCode queryType datetime } } } } ``` [Run in GraphQL API Explorer](https://graphql.cloudflare.com/explorer?query=I4VwpgTgngBA4mALgGQIaLAZ0QOQBoAiA8gLICCAkjgEpYAOA9gHaZYwDeAUDDAG4CWYAO6QO3HjFQBjKQxBNEmABQAzfgBsMEAFwdJMuQoAqqAOa6ARKgDMABhUAOAExOVUgCYB2KQBZbARgBOBx8AI0cAVncHFSdUCP9EqQsYAF8ASjEJCXcWMiZUdShEfilMMndUOhLeMCVxbJ41TUhdLkbGyowAfVMwYEsnWycIgFpbADZR-wmLBo6YLrBu9X7B4bHJ6Yc5hYkIemZWAGEGdzBLfGJyKl2F1Pns9X4AW35EXX9bb9tHiQYIOcIAAhKC6ADaSxKL2WBAAogBlY4AXT+mXaCwAXswwCZTH8eKBIFAcKgYQSYAdMIwWGBTucKUToEYoHQwBSoa92R0HtleWlOKkgA&variables=N4XyA) To learn more and get started, refer to the [DNS Analytics documentation](https://developers.cloudflare.com/dns/additional-options/analytics/#analytics). [Search all changelog entries](https://developers.cloudflare.com/search/?contentType=Changelog+entry)