--- title: Application performance Changelog image: https://edgetunnel-b2h.pages.dev/cf-twitter-card.png --- > Documentation Index > Fetch the complete documentation index at: https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/changelog/rss/index.xml) [ View RSS feeds ](https://edgetunnel-b2h.pages.dev/fundamentals/new-features/available-rss-feeds/) Application performance ![hero image](https://edgetunnel-b2h.pages.dev/_astro/hero.CVYJHPAd_26AMqX.svg) Jul 15, 2026 1. ### [Internal DNS is now generally available](https://edgetunnel-b2h.pages.dev/changelog/post/2026-07-15-internal-dns-ga/) [ Gateway ](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/)[ DNS ](https://edgetunnel-b2h.pages.dev/dns/) [Internal DNS](https://edgetunnel-b2h.pages.dev/dns/internal-dns/) is now generally available. Internal DNS provides authoritative and recursive DNS for private networks on the same global network and control plane you already use for public DNS, Zero Trust, and application services. #### Why it matters * **Consolidate DNS operations.** Public and private DNS run on one platform, with one API, one audit trail, and one place to set policy. * **Simplify split-horizon DNS.** Internal and external resolution are defined as separate [views](https://edgetunnel-b2h.pages.dev/dns/internal-dns/dns-views/) over shared zones, managed from a single control plane — so there is no drift to chase down. * **Extend Zero Trust to DNS.** Resolver policies decide which users and devices resolve against which view, enforced by the same [Gateway](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/) that already governs the rest of your traffic. Setting up Internal DNS takes three steps: create a zone, create a view, and define a resolver policy. ```json POST /zones { "account": { "id": "" }, "name": "corp.internal", "type": "internal" } ``` Internal DNS is included with [Cloudflare Gateway](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/) for Enterprise customers. To get started, refer to the [Internal DNS documentation](https://edgetunnel-b2h.pages.dev/dns/internal-dns/). Jul 14, 2026 1. ### [Improved reliability for account-wide Web Analytics dashboards](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-10-improved-reliability-for-web-analytics-dash/) [ Cloudflare Web Analytics ](https://edgetunnel-b2h.pages.dev/web-analytics/) Cloudflare Web Analytics (Real User Monitoring) has rolled out performance optimizations to significantly improve the stability and loading speed of account-wide dashboards. For larger accounts (with >100 Web Analytics sites), loading the aggregate account-wide view would often fail, running into timeouts or unexpected interface errors due to the massive scale of parallel query processing. This update optimizes how high-volume multi-site data is queried to reduce errors and provide a snappier dashboard experience. Accounts with up to 1,000 sites will now be able to load this account-wide aggregate view without experiencing misleading errors. If you have an account with over 1,000 sites, we cannot currently aggregate over this volume due to processing constraints but you will now be presented with a clear error and instruction to filter to the relevant site(s) you wish to see the data for. Jul 09, 2026 1. ### [New DNS Firewall UX with more dashboard settings](https://edgetunnel-b2h.pages.dev/changelog/post/2026-07-09-new-dns-firewall-ux/) [ DNS ](https://edgetunnel-b2h.pages.dev/dns/) The DNS Firewall page in the Cloudflare dashboard has been refreshed, bringing several settings that were previously API-only into the UI and modernizing how you view and manage your DNS Firewall clusters. ![New DNS Firewall UX](https://edgetunnel-b2h.pages.dev/_astro/dnsfw-new-ux.vHgdhBZD_10POx6.webp) #### What is new * **More settings in the dashboard**: cluster options that were previously only configurable through the API — such as attack mitigation, rate limiting, negative TTL, and resolver subnet — are now available directly in the dashboard. * **Better table experience**: the DNS Firewall cluster table has been revised to surface cluster details at a glance, with resizable columns and the option to show or hide columns to tailor the view to your workflow. * **New create and edit UX**: adding and editing clusters now uses a modernized form that groups related settings together, making configuration faster and clearer. #### 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 **Clusters** ](https://dash.cloudflare.com/?to=/:account/dns-firewall/clusters) For more information, refer to [DNS Firewall](https://edgetunnel-b2h.pages.dev/dns/dns-firewall/). Jul 02, 2026 1. ### [Cache multiple versions of a URL with Vary](https://edgetunnel-b2h.pages.dev/changelog/post/2026-07-02-vary-for-cache-rules/) [ Cache / CDN ](https://edgetunnel-b2h.pages.dev/cache/) Your origin can serve different responses for the same URL — different languages based on `Accept-Language`, or different formats based on `Accept` — by returning a [Vary ↗](https://www.rfc-editor.org/rfc/rfc9110.html#name-vary) response header. Cloudflare's cache now honors that header directly in [Cache Rules](https://edgetunnel-b2h.pages.dev/cache/how-to/cache-rules/), so the same URL can hold multiple cached versions and each request is matched to the right one. Content that previously had to bypass cache to stay correct can now be cached, following standard [HTTP caching behavior ↗](https://www.rfc-editor.org/rfc/rfc9111.html#name-calculating-cache-keys-with). #### What changed Your origin now decides which request headers matter by listing them in its `Vary` response, and you control how Cloudflare treats each one. When you have enabled Vary using a cache rule and a response includes a `Vary` header, the request headers listed become part of the cache key. For each header your origin varies on, choose one of three actions: | Action | Behavior | Best for | | ----------- | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | normalize | Converts equivalent header values to the same cache key value before matching, collapsing redundant versions. | Most Accept, Accept-Language, and Accept-Encoding use cases. | | passthrough | Uses the raw header value to select the cached version and forwards it to the origin unchanged. | When byte-for-byte differences in the header value should create versions. | | bypass | Bypasses cache whenever this header name appears in the origin's Vary response. | Per-user values, or headers with too many possible values to cache safely. | #### Benefits * **Higher cache hit ratios**: `normalize` treats semantically equivalent headers as one version. For example, `Accept-Language: en-US, fr;q=0.8` and `Accept-Language: fr;q=0.8, en-GB` both resolve to the same cache key, so you serve more requests from cache instead of the origin. * **Correct content negotiation**: Requests always receive the cached version that matches their headers, so language and format variants stay accurate. * **No origin or Worker changes required**: If your origin already sends `Vary`, you configure the behavior entirely in Cache Rules. * **Standards-aligned**: Cache key calculation follows RFC 9111, and `Vary: *` continues to bypass cache as required by RFC 9110. #### Availability Vary in Cache Rules is available on all plans (Free, Pro, Business, and Enterprise). For per-request control in Workers subrequests, use the [cf.vary](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/request/#the-cfvary-property) property. #### Get started Configure Vary in the [Cloudflare dashboard ↗](https://dash.cloudflare.com/?to=/:account/:zone/caching/cache-rules) under **Caching** \> **Cache Rules**, or through the [Rulesets API](https://edgetunnel-b2h.pages.dev/ruleset-engine/rulesets-api/). To learn how Vary affects cache keys and how each action works, refer to [Vary](https://edgetunnel-b2h.pages.dev/cache/concepts/vary/) and the [Cache Rules Vary setting](https://edgetunnel-b2h.pages.dev/cache/how-to/cache-rules/settings/#vary). Jun 23, 2026 1. ### [Regionalized IP Bindings for Regional Services](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-23-regionalized-ip-bindings/) [ Data Localization Suite ](https://edgetunnel-b2h.pages.dev/data-localization/) Regional Services now supports **Regionalized IP Bindings**, letting you regionalize traffic at the IP layer for prefixes you bring to Cloudflare through [Bring Your Own IP (BYOIP)](https://edgetunnel-b2h.pages.dev/byoip/). Where [Regional Hostnames](https://edgetunnel-b2h.pages.dev/data-localization/regional-services/regional-hostnames/) regionalize traffic by hostname, Regionalized IP Bindings let you bind a CIDR from one of your prefixes to a region — ideal for address-map deployments and any service you address by IP rather than hostname. Cloudflare then terminates TLS and processes traffic to those addresses only within the data centers in that region. Regionalized IP Bindings requires the Regional Services and Regional Services for BYOIP entitlements. Contact your account team to enable them. To get started, refer to [Regionalized IP Bindings](https://edgetunnel-b2h.pages.dev/data-localization/regional-services/ip-bindings/). Jun 23, 2026 1. ### [Cloudflare AMP/SXG is now end of life.](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-23-amp-sxg-end-of-life/) [ Speed ](https://edgetunnel-b2h.pages.dev/speed/) Cloudflare Accelerated Mobile Pages (AMP) and Signed Exchanges (SXG) support has reached end of life. The features have been disabled since October 2025, so customers who had them configured should see no change to their traffic. Customers will no longer be able to configure AMP/SXG through API or rulesets. The Zone API will start throwing errors. Rulesets with the SXG configuration will fail to save until SXG has been removed. Jun 18, 2026 1. ### [Cloudflare Fonts error handling and security improvements](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-18-cloudflare-fonts-error-handling-security/) [ Speed ](https://edgetunnel-b2h.pages.dev/speed/) Cloudflare Fonts now forwards `/cf-fonts` requests to your origin server when it encounters invalid paths or unexpected runtime errors, instead of returning 4xx or 5xx responses directly. This update also adds additional input validation to enhance security. Jun 17, 2026 1. ### [Post-quantum ML-DSA certificates for Authenticated Origin Pulls and Custom Origin Trust Store](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-17-pqc-mldsa-aop-cots/) [ SSL/TLS ](https://edgetunnel-b2h.pages.dev/ssl/) Cloudflare now accepts [ML-DSA ↗](https://csrc.nist.gov/pubs/fips/204/final) (FIPS 204) post-quantum certificates on the connection between Cloudflare's edge and your origin server. Combined with our existing [X25519MLKEM768](https://edgetunnel-b2h.pages.dev/ssl/post-quantum-cryptography/#hybrid-key-agreement) key agreement, this lets you establish end-to-end post-quantum authentication on the Cloudflare-to-origin connection. ML-DSA is supported in two origin-facing features: * [Authenticated Origin Pulls](https://edgetunnel-b2h.pages.dev/ssl/origin-configuration/authenticated-origin-pull/) (AOP) — upload an ML-DSA client certificate that Cloudflare will present during the mTLS handshake to your origin. Available at both zone-level and per-hostname scopes. * [Custom Origin Trust Store](https://edgetunnel-b2h.pages.dev/ssl/origin-configuration/custom-origin-trust-store/) (COTS) — upload an ML-DSA certificate authority that Cloudflare will trust when validating your origin server certificate under [Full (strict) encryption mode](https://edgetunnel-b2h.pages.dev/ssl/origin-configuration/ssl-modes/full-strict/). Refer to [Post-quantum signatures](https://edgetunnel-b2h.pages.dev/ssl/post-quantum-cryptography/pqc-to-origin/#post-quantum-signatures) for certificate generation and setup guidance, and to [PQC in Cloudflare products](https://edgetunnel-b2h.pages.dev/ssl/post-quantum-cryptography/pqc-cloudflare-products/) for the current post-quantum deployment status across Cloudflare. Jun 10, 2026 1. ### [Account-level DNS records quota](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-10-account-level-record-quota/) [ DNS ](https://edgetunnel-b2h.pages.dev/dns/) Cloudflare now enforces DNS records quotas at the account level for Enterprise accounts. Instead of a per-zone limit, these accounts have a quota on the total number of records across all of their zones, letting you distribute records across your zones however you like — regardless of each zone's plan. Public and internal zones are counted separately, each with a default quota of 1,000,000 records. Accounts without an account-level quota are unaffected: existing per-zone quotas behave exactly as before. For more details, refer to [DNS records quota](https://edgetunnel-b2h.pages.dev/dns/manage-dns-records/#dns-records-quota). May 26, 2026 1. ### [BYPASS status now returned for uncacheable responses](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-26-bypass-status-for-uncacheable-responses/) [ Cache / CDN ](https://edgetunnel-b2h.pages.dev/cache/) Cloudflare now returns a `BYPASS` [cache status](https://edgetunnel-b2h.pages.dev/cache/concepts/cache-responses/) whenever a response is not cacheable, instead of the previous mix of `BYPASS` and `MISS` that depended on why Cloudflare chose not to cache the response. There are multiple reasons Cloudflare may refuse to cache a response — for example, the response exceeds the [maximum cacheable file size](https://edgetunnel-b2h.pages.dev/cache/concepts/default-cache-behavior/#cacheable-size-limits) for your plan, the origin sends `Cache-Control: no-cache`, `private`, or `max-age=0`, the response includes a `Set-Cookie` header, or the request includes an `Authorization` header. Previously, only some of these conditions returned `BYPASS`. Others — such as responses exceeding the maximum cacheable file size — returned `MISS` on every request, regardless of whether [Origin Cache Control](https://edgetunnel-b2h.pages.dev/cache/concepts/cache-control/#origin-cache-control-behavior) was on or off. Because the response could never be cached, every subsequent request also returned `MISS`, which looked indistinguishable from a broken cache and made it hard to tell whether Cloudflare was trying and failing to cache the asset or had deliberately chosen not to cache it. `BYPASS` now consistently signals that Cloudflare refused to cache the response, regardless of the reason. `MISS` is reserved for cacheable responses that simply were not in the local cache at request time. #### What to expect in your analytics After this change rolls out, you should see: * **MISS rate decreases**: Uncacheable responses no longer count as cache misses. * **BYPASS rate increases**: These same responses are now reported as bypasses. * **Cache hit ratio increases**: Hit ratio calculations no longer include uncacheable traffic that could never have been cached, giving you a more accurate view of cache effectiveness. Your total request volume and origin traffic are unchanged — only the cache status label is different. #### Browser cache TTL behavior is preserved The cache status label is the only thing changing — browser cache TTL handling for any given response is identical to what it was before: * Responses that historically returned `MISS` because Cloudflare refused to cache them (for example, responses over the maximum cacheable file size) now return `BYPASS`, but continue to have browser cache TTL applied — exactly as they did when they were labeled `MISS`. * Responses that historically returned `BYPASS` and skipped browser cache TTL continue to skip browser cache TTL. In both cases, the decision to apply browser cache TTL depends on the underlying reason Cloudflare did not cache the response, not on the new `BYPASS` label. May 20, 2026 1. ### [New DNS records UX is rolling out](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-20-new-dns-records-ux/) [ DNS ](https://edgetunnel-b2h.pages.dev/dns/) Starting today, everyone can opt in to a refreshed DNS records page in the Cloudflare dashboard. Over the coming weeks, the new experience will become the default for Free plan users first, followed by paid plans. ![New DNS records UX](https://edgetunnel-b2h.pages.dev/_astro/new-dns-ux.Bfs_yXPa_VJoah.webp) #### What is new * **Better table experience**: resizable and hideable columns, row pinning, advanced filters with logical operators (AND/OR), configurable pagination, and expanded input fields so long values are no longer cut off. * **First-class mobile experience**: responsive layout with a touch-friendly, card-based UI and compact controls for small screens. * **DNS quick reference**: bite-sized explainers for DNS, proxy status, and TTL, available directly in the product to help users configure records without leaving the page. * **Modern frontend**: a refactor onto Cloudflare's new UI framework that improves performance and lays the foundation for future improvements. ![New DNS records UX](https://edgetunnel-b2h.pages.dev/_astro/new-dns-ux.DV6gCbme_2cImvu.webp) #### Rollout plan Dates are subject to change based on feedback received during the rollout. * **20 May - 05 June**: ramped rollout to Free, then Pro and Business plans. * **08 June - 03 July**: ramped rollout to Enterprise plans. #### Share your feedback Once the new experience is turned on for your account, look for the feedback link at the top of the DNS records page in the Cloudflare dashboard and let us know what you think. Your input helps us prioritize the next round of improvements. May 13, 2026 1. ### [/cdn-cgi/rum endpoint now returns 405 for non-POST requests](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-13-rum-405-method-not-allowed/) [ Cloudflare Web Analytics ](https://edgetunnel-b2h.pages.dev/web-analytics/) The `/cdn-cgi/rum` beacon endpoint now returns `405 Method Not Allowed` for non-POST requests instead of `404 Not Found`. The response includes an `Allow: POST, OPTIONS` header per [RFC 9110 §15.5.6 ↗](https://www.rfc-editor.org/rfc/rfc9110#section-15.5.6). Previously, sending a `GET` or other non-POST request to this endpoint returned a `404`, which was misleading because it suggested the endpoint did not exist. The new `405` response clearly indicates that the endpoint exists but only accepts `POST` requests. The Web Analytics beacon (`beacon.min.js`) already uses `POST` for all metric submissions, so this change does not affect normal beacon operation. `OPTIONS` requests for CORS preflight continue to work as before. For more information, refer to the [Web Analytics FAQ](https://edgetunnel-b2h.pages.dev/web-analytics/faq/#why-am-i-getting-a-405-method-not-allowed-error-from-cdn-cgirum). May 04, 2026 1. ### [Pingora now powers Cloudflare's cache](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-04-pingora-powers-cache/) [ Cache / CDN ](https://edgetunnel-b2h.pages.dev/cache/) Cloudflare's cache now runs on a new proxy built on [Pingora ↗](https://github.com/cloudflare/pingora), the Rust-based framework that already serves a significant portion of Cloudflare's network traffic. The new proxy is faster, more memory-safe, and designed to evolve our cache architecture. It delivers immediate performance improvements and enables new caching capabilities. #### What this brings * **Lower latency**: The new proxy reduces per-request overhead through improved connection reuse. * **Reduced cache MISSes**: Enhanced cache retention improves origin offload. * **Better RFC compliance**: Caching behavior more closely follows HTTP caching standards. * **Foundation for future features**: The new architecture enables upcoming improvements to cache functionality and efficiency. #### New features * **Asynchronous `stale-while-revalidate`**: Every request returns stale content immediately while revalidation happens in the background, instead of the first request after expiry blocking on the origin. Refer to the [asynchronous stale-while-revalidate changelog](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-26-async-stale-while-revalidate/) for details. * **Unbuffered bypass by default**: Responses that bypass cache are streamed directly to the client without buffering, reducing time-to-first-byte for uncacheable content. #### Behavioral changes The new architecture introduces the following behavioral changes to improve RFC compliance and correctness: * **`Vary: *` results in cache bypass**: According to [RFC 9110 Section 12.5.5 ↗](https://httpwg.org/specs/rfc9110.html#field.vary), a `Vary` header value of `*` indicates the response varies on factors beyond request headers and must not be served from cache. Cloudflare now bypasses cache for these responses instead of storing them. * **`Set-Cookie` stripped on MISS and EXPIRED**: For cacheable assets, `Set-Cookie` is now stripped on MISS and EXPIRED responses, not only on HITs. * **Floating-point TTL values**: Floating-point time-to-live values (for example, `max-age=1.5`) are rounded down to the nearest integer instead of being rejected as invalid. #### What's next A deeper look at the new cache proxy is coming soon to the [Cloudflare blog ↗](https://blog.cloudflare.com/). For background on the underlying framework, read: * [Open sourcing Pingora: our Rust framework for building programmable network services ↗](https://blog.cloudflare.com/pingora-open-source/) * [How we built Pingora, the proxy that connects Cloudflare to the Internet ↗](https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/) Apr 30, 2026 1. ### [Shared dictionaries passthrough now in open beta](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-30-shared-dictionaries-passthrough-beta/) [ Speed ](https://edgetunnel-b2h.pages.dev/speed/) [Shared dictionaries](https://edgetunnel-b2h.pages.dev/speed/optimization/content/shared-dictionaries/) ([RFC 9842 ↗](https://www.rfc-editor.org/rfc/rfc9842.html)) let an origin compress a response against a previous version of the same resource that the browser already has cached, so only the difference between versions travels over the wire. Shared dictionaries passthrough is now in open beta on all plans. #### What changed In passthrough mode, Cloudflare: * Forwards the `Use-As-Dictionary` and `Available-Dictionary` headers between client and origin without modification. * Treats `dcb` (Dictionary-Compressed Brotli) and `dcz` (Dictionary-Compressed Zstandard) as valid `Content-Encoding` values end to end, without recompressing them. * Extends the cache key to vary on `Available-Dictionary` and `Accept-Encoding` so each delta-compressed variant is cached correctly. Your origin manages the dictionary lifecycle: deciding which assets are dictionaries, attaching `Use-As-Dictionary` headers, and producing deltas in response to `Available-Dictionary` requests. Cloudflare handles the transport and the cache. In internal testing on a 272 KB JavaScript bundle, the asset shrinks from 92.1 KB with Gzip to 2.6 KB with delta Zstandard against the previous version — a 97% reduction over standard compression — with download times improving by 81–89% versus Gzip. Shared dictionaries work with browsers that advertise `dcb` or `dcz` in `Accept-Encoding`. Today, this includes Chrome 130 or later and Edge 130 or later. #### Get started Turn on passthrough for your zone with a single API call: ```bash curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/shared_dictionary_mode" \ --request PATCH \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ --json '{ "value": "passthrough" }' ``` You can also turn it on under **Speed** \> **Settings** \> **Content Optimization** in the [Cloudflare dashboard ↗](https://dash.cloudflare.com/?to=/:account/:zone/speed/optimization). For full origin setup instructions and a working test recipe, refer to [Shared dictionaries](https://edgetunnel-b2h.pages.dev/speed/optimization/content/shared-dictionaries/), or try the live demo at [canicompress.com ↗](https://canicompress.com/). Apr 30, 2026 1. ### [Web Analytics adds Navigation Type filtering and reporting](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-30-rum-navigation-types/) [ Cloudflare Web Analytics ](https://edgetunnel-b2h.pages.dev/web-analytics/) Cloudflare Web Analytics now supports **Navigation Type** reporting and filtering. This update allows developers and performance analysts to see how users are navigating between pages — whether through a link click or form submission, a page reload, or using the browser's back/forward buttons — and whether a browser cache hit occurred for these behaviors. Understanding navigation types is critical for optimizing user experience. For example, if a high volume of your traffic consists of "Back-forward" navigations versus "Back-forward Cache", those visitors are not benefiting from the Back/Forward Cache (bfcache) and therefore are experiencing higher load times due to potentially unnecessary network requests. The same applies for regular "Navigate" entries — where "Navigate Cache", "Navigate Prefetch Cache" and "Prerender" would provide instant document retrieval — and "Reload", where "Reload cache" would be more optimal. A high volume of "Reload" entries can also indicate a potential stability problem with your website. By identifying these patterns, you can tune your browser caching strategies to ensure HTML documents are served instantaneously from local caches rather than requiring a roundtrip to the network. For more information, refer to [Navigation Types](https://edgetunnel-b2h.pages.dev/web-analytics/data-metrics/dimensions/#navigation-types). #### Key benefits * **Monitor Cache Effectiveness:** See how often your site is served from the HTTP cache or bfcache. * **Identify Performance Bottlenecks:** Filter by the different types to understand performance opportunity of improving browser cache hit ratio. #### Analyze navigation types in the Cloudflare dashboard You can now find the **Navigation Type** dimension in the Web Analytics dashboard. You can filter to include/exclude one or more specific types using "equals", "does not equal", "in", or "not in" matchers. ![Navigation Type filter](https://edgetunnel-b2h.pages.dev/_astro/dash-web_analytics-navigation-type-filter.Cculflhp_Xm5Gz.webp) To check the list of popular navigation types, select **Page views** on the Web Analytics sidebar and scroll down to the bottom: ![Navigation Types list in Page Views tab](https://edgetunnel-b2h.pages.dev/_astro/dash-web_analytics-navigation-types-list.CWaiEQzO_Z1jlU23.webp) Apr 28, 2026 1. ### [Account-level enforce DNS-only](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-28-enforce-dns-only/) [ DNS ](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/dns/proxy-status/enforce-dns-only/) . Apr 27, 2026 1. ### [Cache Response Rules now support zone versioning](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-27-cache-response-rules-zone-versioning/) [ Cache / CDN ](https://edgetunnel-b2h.pages.dev/cache/) Cache Response Rules now work with [Version Management](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/ruleset-engine/rulesets-api/). For more details, refer to the [Cache Response Rules documentation](https://edgetunnel-b2h.pages.dev/cache/how-to/cache-response-rules/) and the [Version Management documentation](https://edgetunnel-b2h.pages.dev/version-management/). Apr 17, 2026 1. ### [Smart Tiered Cache optimizes public cloud origins](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-17-smart-tiered-cache-for-public-cloud/) [ Cache / CDN ](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/cache/how-to/tiered-cache/) and set a cloud region hint for your origin in the [Tiered Cache settings](https://edgetunnel-b2h.pages.dev/cache/how-to/tiered-cache/#public-cloud-origins). Apr 07, 2026 1. ### [Manage mTLS and BYO CA certificates from the Cloudflare dashboard](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-07-mtls-byoca-dashboard/) [ SSL/TLS ](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/changelog/post/2026-04-01-l4-transport-telemetry-fields/) [ Rules ](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/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:** ```txt 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 ```txt cf.edge.l4.delivery_rate > 0 and cf.edge.l4.delivery_rate < 100000 ``` For more information, refer to [Request Header Transform Rules](https://edgetunnel-b2h.pages.dev/rules/transform/request-header-modification/) and the [fields reference](https://edgetunnel-b2h.pages.dev/ruleset-engine/rules-language/fields/reference/). Mar 31, 2026 1. ### [Internal DNS - now in open beta](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-31-internal-dns-open-beta/) [ DNS ](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/dns/internal-dns/). Mar 25, 2026 1. ### [New mTLS certificate fields for Transform Rules](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-25-rfc9440-mtls-fields/) [ Rules ](https://edgetunnel-b2h.pages.dev/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:** ```txt 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://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/service-credentials/mutual-tls-authentication/), [Request Header Transform Rules](https://edgetunnel-b2h.pages.dev/rules/transform/request-header-modification/), and the [fields reference](https://edgetunnel-b2h.pages.dev/ruleset-engine/rules-language/fields/reference/). Mar 24, 2026 1. ### [Cache Response Rules](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-24-cache-response-rules/) [ Cache / CDN ](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/ruleset-engine/rulesets-api/). For more details, refer to the [Cache Rules documentation ↗](https://edgetunnel-b2h.pages.dev/cache/how-to/cache-response-rules/). Mar 20, 2026 1. ### [DNS Analytics for Customer Metadata Boundary set to EU region](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-20-dns-analytics-cmb-eu/) [ DNS ](https://edgetunnel-b2h.pages.dev/dns/) DNS Analytics is now available for customers with [Customer Metadata Boundary](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/dns/additional-options/analytics/) and [DNS Firewall Analytics](https://edgetunnel-b2h.pages.dev/dns/dns-firewall/analytics/). Mar 18, 2026 1. ### [Worker execution timing field now available in Rules](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-18-worker-timing-field/) [ Rules ](https://edgetunnel-b2h.pages.dev/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: ```plaintext cf.timings.worker_msec > 500 ``` For more information, refer to the [Fields reference](https://edgetunnel-b2h.pages.dev/ruleset-engine/rules-language/fields/reference/cf.timings.worker%5Fmsec/). ```json {"@context":"https://schema.org","@type":"BlogPosting","@id":"https://edgetunnel-b2h.pages.dev/changelog/product-group/application-performance/#page","headline":"Application performance Changelog | Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/changelog/product-group/application-performance/","inLanguage":"en","image":"https://edgetunnel-b2h.pages.dev/cf-twitter-card.png","publisher":{"@type":"Organization","name":"Cloudflare","url":"https://www.cloudflare.com/"},"isPartOf":{"@type":"WebSite","@id":"https://edgetunnel-b2h.pages.dev/#website","name":"Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/"}} ```