--- title: Network security 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/) Network security ![hero image](https://developers.cloudflare.com/_astro/hero.CVYJHPAd_26AMqX.svg) Apr 07, 2026 1. ### [Link aggregation (LACP) support for Cloudflare One Appliance](https://developers.cloudflare.com/changelog/post/2026-04-07-link-aggregation-lacp-appliance/) [ Cloudflare One ](https://developers.cloudflare.com/cloudflare-one/)[ Cloudflare WAN ](https://developers.cloudflare.com/cloudflare-wan/) Cloudflare One Appliance now supports Link Aggregation Control Protocol (LACP), allowing you to bundle up to six physical LAN ports into a single logical interface. Link aggregation increases available bandwidth and eliminates single points of failure on the LAN side of the appliance. This feature is available in beta on physical appliance hardware with the latest OS. No entitlement is required. To configure a Link Aggregation Group, refer to [Configure link aggregation groups](https://developers.cloudflare.com/cloudflare-wan/configuration/appliance/network-options/link-aggregation/). 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 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. ### [Interconnects moved to Connectors](https://developers.cloudflare.com/changelog/post/2026-03-24-interconnects-navigation-update/) [ Network Interconnect ](https://developers.cloudflare.com/network-interconnect/) The top-level **Interconnects** page in the Cloudflare dashboard has been removed. Interconnects are now located under **Connectors** \> **Interconnects**. Your existing configurations and functionality remain the same. Mar 20, 2026 1. ### [Stream logs from multiple replicas of Cloudflare Tunnel simultaneously](https://developers.cloudflare.com/changelog/post/2026-03-20-tunnel-replica-overview-and-multi-log-streaming/) [ Cloudflare Tunnel ](https://developers.cloudflare.com/tunnel/)[ Cloudflare Tunnel for SASE ](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/) In the Cloudflare One dashboard, the overview page for a specific Cloudflare Tunnel now shows all [replicas](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/) of that tunnel and supports streaming logs from multiple replicas at once. ![View replicas and stream logs from multiple connectors](https://developers.cloudflare.com/_astro/tunnel-multiconn.DEOEaLlu_ZDxArh.webp) Previously, you could only stream logs from one replica at a time. With this update: * **Replicas on the tunnel overview** — All active replicas for the selected tunnel now appear on that tunnel's overview page under **Connectors**. Select any replica to stream its logs. * **Multi-connector log streaming** — Stream logs from multiple replicas simultaneously, making it easier to correlate events across your infrastructure during debugging or incident response. To try it out, log in to [Cloudflare One ↗](https://one.dash.cloudflare.com/) and go to **Networks** \> **Connectors** \> **Cloudflare Tunnels**. Select **View logs** next to the tunnel you want to monitor. For more information, refer to [Tunnel log streams](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/) and [Deploy replicas](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/deploy-replicas/). Mar 19, 2026 1. ### [Manage Cloudflare Tunnels with Wrangler](https://developers.cloudflare.com/changelog/post/2026-03-19-wrangler-tunnel-commands/) [ Cloudflare Tunnel ](https://developers.cloudflare.com/tunnel/)[ Workers ](https://developers.cloudflare.com/workers/) You can now manage [Cloudflare Tunnels](https://developers.cloudflare.com/tunnel/) directly from [Wrangler](https://developers.cloudflare.com/workers/wrangler/), the CLI for the Cloudflare Developer Platform. The new [wrangler tunnel](https://developers.cloudflare.com/workers/wrangler/commands/tunnel/) commands let you create, run, and manage tunnels without leaving your terminal. ![Wrangler tunnel commands demo](https://developers.cloudflare.com/_astro/wrangler-tunnel.DOqrtGGg_7EDX0.webp) Available commands: * `wrangler tunnel create` — Create a new remotely managed tunnel. * `wrangler tunnel list` — List all tunnels in your account. * `wrangler tunnel info` — Display details about a specific tunnel. * `wrangler tunnel delete` — Delete a tunnel. * `wrangler tunnel run` — Run a tunnel using the cloudflared daemon. * `wrangler tunnel quick-start` — Start a free, temporary tunnel without an account using [Quick Tunnels](https://developers.cloudflare.com/tunnel/setup/#quick-tunnels-development). Wrangler handles downloading and managing the [cloudflared](https://developers.cloudflare.com/tunnel/downloads/) binary automatically. On first use, you will be prompted to download `cloudflared` to a local cache directory. These commands are currently experimental and may change without notice. To get started, refer to the [Wrangler tunnel commands documentation](https://developers.cloudflare.com/workers/wrangler/commands/tunnel/). 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 20, 2026 1. ### [Manage Cloudflare Tunnel directly from the main Cloudflare Dashboard](https://developers.cloudflare.com/changelog/post/2026-02-20-tunnel-core-dashboard/) [ Cloudflare Tunnel ](https://developers.cloudflare.com/tunnel/)[ Cloudflare Tunnel for SASE ](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/) [Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/) is now available in the main Cloudflare Dashboard at [Networking > Tunnels ↗](https://dash.cloudflare.com/?to=/:account/tunnels), bringing first-class Tunnel management to developers using Tunnel for securing origin servers. ![Manage Tunnels in the Core Dashboard](https://developers.cloudflare.com/_astro/tunnel-core-dashboard.BGPqaHfo_Pi6HO.webp) This new experience provides everything you need to manage Tunnels for [public applications](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/), including: * **Full Tunnel lifecycle management**: Create, configure, delete, and monitor all your Tunnels in one place. * **Native integrations**: View Tunnels by name when configuring [DNS records](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/) and [Workers VPC](https://developers.cloudflare.com/workers-vpc/) — no more copy-pasting UUIDs. * **Real-time visibility**: Monitor [replicas](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/) and Tunnel [health status](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/common-errors/#tunnel-status) directly in the dashboard. * **Routing map**: Manage all ingress routes for your Tunnel, including [public applications](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/), [private hostnames](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname/), [private CIDRs](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-cidr/), and [Workers VPC services](https://developers.cloudflare.com/workers-vpc/), from a single interactive interface. #### Choose the right dashboard for your use case **Core Dashboard**: Navigate to [Networking > Tunnels ↗](https://dash.cloudflare.com/?to=/:account/tunnels) to manage Tunnels for: * Securing origin servers and [public applications](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/) with CDN, WAF, Load Balancing, and DDoS protection * Connecting [Workers to private services](https://developers.cloudflare.com/workers-vpc/) via Workers VPC **Cloudflare One Dashboard**: Navigate to [Zero Trust > Networks > Connectors ↗](https://one.dash.cloudflare.com/?to=/:account/networks/connectors) to manage Tunnels for: * Securing your public applications with [Zero Trust access policies](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/self-hosted-public-app/) * Connecting users to [private applications](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/non-http/self-hosted-private-app/) * Building a [private mesh network](https://developers.cloudflare.com/reference-architecture/architectures/sase/#connecting-networks) Both dashboards provide complete Tunnel management capabilities — choose based on your primary workflow. #### Get started New to Tunnel? Learn how to [get started with Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/create-remote-tunnel/) or explore advanced use cases like [securing SSH servers](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/) or [running Tunnels in Kubernetes](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/deployment-guides/kubernetes/). Feb 17, 2026 1. ### [Cloudflare One Product Name Updates](https://developers.cloudflare.com/changelog/post/2026-02-17-product-name-updates/) [ Cloudflare One ](https://developers.cloudflare.com/cloudflare-one/)[ Cloudflare WAN ](https://developers.cloudflare.com/cloudflare-wan/)[ Cloudflare Network Firewall ](https://developers.cloudflare.com/cloudflare-network-firewall/)[ Network Flow ](https://developers.cloudflare.com/network-flow/) We are updating naming related to some of our Networking products to better clarify their place in the Zero Trust and Secure Access Service Edge (SASE) journey. We are retiring some older brand names in favor of names that describe exactly what the products do within your network. We are doing this to help customers build better, clearer mental models for comprehensive SASE architecture delivered on Cloudflare. #### What's changing * **Magic WAN** → **Cloudflare WAN** * **Magic WAN IPsec** → **Cloudflare IPsec** * **Magic WAN GRE** → **Cloudflare GRE** * **Magic WAN Connector** → **Cloudflare One Appliance** * **Magic Firewall** → **Cloudflare Network Firewall** * **Magic Network Monitoring** → **Network Flow** * **Magic Cloud Networking** → **Cloudflare One Multi-cloud Networking** **No action is required by you** — all functionality, existing configurations, and billing will remain exactly the same. For more information, visit the [Cloudflare One documentation](https://developers.cloudflare.com/cloudflare-one/). Feb 12, 2026 1. ### [Anycast IPs displayed on the dashboard](https://developers.cloudflare.com/changelog/post/2026-02-12-anycast-ips-on-dashboard/) [ Cloudflare WAN ](https://developers.cloudflare.com/cloudflare-wan/) Cloudflare WAN now displays your Anycast IP addresses directly in the dashboard when you configure IPsec or GRE tunnels. Previously, customers received their Anycast IPs during onboarding or had to retrieve them with an API call. The dashboard now pre-loads these addresses, reducing setup friction and preventing configuration errors. No action is required. All Cloudflare WAN customers can see their Anycast IPs in the tunnel configuration form automatically. For more information, refer to [Configure tunnel endpoints](https://developers.cloudflare.com/cloudflare-wan/configuration/how-to/configure-tunnel-endpoints/). Feb 11, 2026 1. ### [Post-quantum encryption support for Cloudflare One Appliance](https://developers.cloudflare.com/changelog/post/2026-02-11-appliance-post-quantum-encryption/) [ Cloudflare One ](https://developers.cloudflare.com/cloudflare-one/)[ Cloudflare WAN ](https://developers.cloudflare.com/cloudflare-wan/) Cloudflare One Appliance version 2026.2.0 adds [post-quantum encryption](https://developers.cloudflare.com/ssl/post-quantum-cryptography/) support using hybrid ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism). The appliance now uses TLS 1.3 with hybrid ML-KEM for its connection to the Cloudflare edge. During the TLS handshake, the appliance and the edge share a symmetric secret over the TLS connection and inject it into the ESP layer of IPsec. This protects IPsec data plane traffic against harvest-now, decrypt-later attacks. This upgrade deploys automatically to all appliances during their configured interrupt windows with no manual action required. For more information, refer to [Cloudflare One Appliance](https://developers.cloudflare.com/cloudflare-wan/configuration/appliance/). Jan 30, 2026 1. ### [BGP over GRE and IPsec tunnels](https://developers.cloudflare.com/changelog/post/2026-01-30-bgp-over-tunnels/) [ Cloudflare WAN ](https://developers.cloudflare.com/cloudflare-wan/)[ Magic Transit ](https://developers.cloudflare.com/magic-transit/)[ Cloudflare One ](https://developers.cloudflare.com/cloudflare-one/) Magic WAN and Magic Transit customers can use the Cloudflare dashboard to configure and manage BGP peering between their networks and their Magic routing table when using IPsec and GRE tunnel on-ramps (beta). Using BGP peering allows customers to: * Automate the process of adding or removing networks and subnets. * Take advantage of failure detection and session recovery features. With this functionality, customers can: * Establish an eBGP session between their devices and the Magic WAN / Magic Transit service when connected via IPsec and GRE tunnel on-ramps. * Secure the session by MD5 authentication to prevent misconfigurations. * Exchange routes dynamically between their devices and their Magic routing table. For configuration details, refer to: * [Configure BGP routes for Magic WAN](https://developers.cloudflare.com/cloudflare-wan/configuration/how-to/configure-routes/#configure-bgp-routes) * [Configure BGP routes for Magic Transit](https://developers.cloudflare.com/magic-transit/how-to/configure-routes/#configure-bgp-routes) Jan 27, 2026 1. ### [Configure Cloudflare source IPs (beta)](https://developers.cloudflare.com/changelog/post/2026-01-27-configure-cloudflare-source-ips/) [ Cloudflare One ](https://developers.cloudflare.com/cloudflare-one/)[ Cloudflare WAN ](https://developers.cloudflare.com/cloudflare-wan/) Cloudflare source IPs are the IP addresses used by Cloudflare services (such as Load Balancing, Gateway, and Browser Isolation) when sending traffic to your private networks. For customers using legacy mode routing, traffic to private networks is sourced from public Cloudflare IPs, which may cause IP conflicts. For customers using Unified Routing mode (beta), traffic to private networks is sourced from dedicated, non-Internet-routable private IPv4 range to ensure: * Symmetric routing over private network connections * Proper firewall state preservation * Private traffic stays on secure paths Key details: * **IPv4**: Sourced from `100.64.0.0/12` by default, configurable to any `/12` CIDR * **IPv6**: Sourced from `2606:4700:cf1:5000::/64` (not configurable) * **Affected connectors**: GRE, IPsec, CNI, WARP Connector, and WARP Client (Cloudflare Tunnel is not affected) Configuring Cloudflare source IPs requires Unified Routing (beta) and the `Cloudflare One Networks Write` permission. For configuration details, refer to [Configure Cloudflare source IPs](https://developers.cloudflare.com/cloudflare-wan/configuration/how-to/configure-cloudflare-source-ips/). 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 15, 2026 1. ### [Network Services navigation update](https://developers.cloudflare.com/changelog/post/2026-01-15-networking-navigation-update/) [ Magic Transit ](https://developers.cloudflare.com/magic-transit/)[ Cloudflare Network Firewall ](https://developers.cloudflare.com/cloudflare-network-firewall/)[ Cloudflare WAN ](https://developers.cloudflare.com/cloudflare-wan/)[ Network Flow ](https://developers.cloudflare.com/network-flow/) The Network Services menu structure in Cloudflare's dashboard has been updated to reflect solutions and capabilities instead of product names. This will make it easier for you to find what you need and better reflects how our services work together. Your existing configurations will remain the same, and you will have access to all of the same features and functionality. The changes visible in your dashboard may vary based on the products you use. Overall, changes relate to [Magic Transit ↗](https://developers.cloudflare.com/magic-transit/), [Magic WAN ↗](https://developers.cloudflare.com/magic-wan/), and [Magic Firewall ↗](https://developers.cloudflare.com/cloudflare-network-firewall/). **Summary of changes:** * A new **Overview** page provides access to the most common tasks across Magic Transit and Magic WAN. * Product names have been removed from top-level navigation. * Magic Transit and Magic WAN configuration is now organized under **Routes** and **Connectors**. For example, you will find IP Prefixes under **Routes**, and your GRE/IPsec Tunnels under **Connectors.** * Magic Firewall policies are now called **Firewall Policies.** * Magic WAN Connectors and Connector On-Ramps are now referenced in the dashboard as **Appliances** and **Appliance profiles.** They can be found under **Connectors > Appliances.** * Network analytics, network health, and real-time analytics are now available under **Insights.** * Packet Captures are found under **Insights > Diagnostics.** * You can manage your Sites from **Insights > Network health.** * You can find Magic Network Monitoring under **Insights > Network flow**. If you would like to provide feedback, complete [this form ↗](https://forms.gle/htWyjRsTjw1usdis5). You can also find these details in the January 7, 2026 email titled **\[FYI\] Upcoming Network Services Dashboard Navigation Update**. ![Networking Navigation](https://developers.cloudflare.com/_astro/networking-overview-and-navigation.CeMgEFaZ_Z20HKl.webp) Jan 15, 2026 1. ### [Verify WARP Connector connectivity with a simple ping](https://developers.cloudflare.com/changelog/post/2026-01-15-warp-connector-ping-support/) [ Cloudflare Tunnel ](https://developers.cloudflare.com/tunnel/)[ Cloudflare Tunnel for SASE ](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/) We have made it easier to validate connectivity when deploying [WARP Connector](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-mesh/) as part of your [software-defined private network](https://developers.cloudflare.com/reference-architecture/architectures/sase/#connecting-networks). You can now `ping` the WARP Connector host directly on its LAN IP address immediately after installation. This provides a fast, familiar way to confirm that the Connector is online and reachable within your network before testing access to downstream services. Starting with [version 2025.10.186.0](https://developers.cloudflare.com/changelog/2026-01-13-warp-linux-ga/), WARP Connector responds to traffic addressed to its own LAN IP, giving you immediate visibility into Connector reachability. Learn more about deploying [WARP Connector](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-mesh/) and building private network connectivity with [Cloudflare One](https://developers.cloudflare.com/cloudflare-one/). 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/). Dec 31, 2025 1. ### [Breakout traffic visibility via NetFlow](https://developers.cloudflare.com/changelog/post/2025-12-31-connector-breakout-traffic-netflow/) [ Cloudflare One ](https://developers.cloudflare.com/cloudflare-one/)[ Cloudflare WAN ](https://developers.cloudflare.com/cloudflare-wan/) Magic WAN Connector now exports NetFlow data for breakout traffic to Magic Network Monitoring (MNM), providing visibility into traffic that bypasses Cloudflare's security filtering. This feature allows you to: * Monitor breakout traffic statistics in the Cloudflare dashboard. * View traffic patterns for applications configured to bypass Cloudflare. * Maintain visibility across all traffic passing through your Magic WAN Connector. For more information, refer to [NetFlow statistics](https://developers.cloudflare.com/cloudflare-wan/analytics/netflow-analytics/). Nov 11, 2025 1. ### [cloudflared proxy-dns command will be removed starting February 2, 2026](https://developers.cloudflare.com/changelog/post/2025-11-11-cloudflared-proxy-dns/) [ Cloudflare Tunnel ](https://developers.cloudflare.com/tunnel/)[ Cloudflare Tunnel for SASE ](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/) Starting February 2, 2026, the `cloudflared proxy-dns` command will be removed from all new `cloudflared` [releases](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/downloads/). This change is being made to enhance security and address a potential vulnerability in an underlying DNS library. This vulnerability is specific to the `proxy-dns` command and does not affect any other `cloudflared` features, such as the core [Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/) service. The `proxy-dns` command, which runs a client-side [DNS-over-HTTPS (DoH)](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/) proxy, has been an officially undocumented feature for several years. This functionality is fully and securely supported by our actively developed products. Versions of `cloudflared` released before this date will not be affected and will continue to operate. However, note that our [official support policy](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/downloads/#deprecated-releases) for any `cloudflared` release is one year from its release date. #### Migration paths We strongly advise users of this undocumented feature to migrate to one of the following officially supported solutions before February 2, 2026, to continue benefiting from secure [DNS-over-HTTPS](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/). #### End-user devices The preferred method for enabling DNS-over-HTTPS on user devices is the [Cloudflare WARP client](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/). The WARP client automatically secures and proxies all DNS traffic from your device, integrating it with your organization's [Zero Trust policies](https://developers.cloudflare.com/cloudflare-one/traffic-policies/) and [posture checks](https://developers.cloudflare.com/cloudflare-one/reusable-components/posture-checks/). #### Servers, routers, and IoT devices For scenarios where installing a client on every device is not possible (such as servers, routers, or IoT devices), we recommend using the [WARP Connector](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-mesh/). Instead of running `cloudflared proxy-dns` on a machine, you can install the WARP Connector on a single Linux host within your private network. This connector will act as a gateway, securely routing all DNS and network traffic from your [entire subnet](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-mesh/routes/) to Cloudflare for [filtering and logging](https://developers.cloudflare.com/cloudflare-one/traffic-policies/). Nov 06, 2025 1. ### [Automatic Return Routing (Beta)](https://developers.cloudflare.com/changelog/post/2025-11-06-automatic-return-routing-beta/) [ Cloudflare One ](https://developers.cloudflare.com/cloudflare-one/)[ Cloudflare WAN ](https://developers.cloudflare.com/cloudflare-wan/) Magic WAN now supports Automatic Return Routing (ARR), allowing customers to configure Magic on-ramps (IPsec/GRE/CNI) to learn the return path for traffic flows without requiring static routes. Key benefits: * **Route-less mode**: Static or dynamic routes are optional when using ARR. * **Overlapping IP space support**: Traffic originating from customer sites can use overlapping private IP ranges. * **Symmetric routing**: Return traffic is guaranteed to use the same connection as the original on-ramp. This feature is currently in beta and requires the new Unified Routing mode (beta). For configuration details, refer to [Configure Automatic Return Routing](https://developers.cloudflare.com/cloudflare-wan/configuration/how-to/configure-routes/#configure-automatic-return-routing-beta). Nov 06, 2025 1. ### [Designate WAN link for breakout traffic](https://developers.cloudflare.com/changelog/post/2025-11-06-connector-designate-wan-link-breakout/) [ Cloudflare One ](https://developers.cloudflare.com/cloudflare-one/)[ Cloudflare WAN ](https://developers.cloudflare.com/cloudflare-wan/) Magic WAN Connector now allows you to designate a specific WAN port for breakout traffic, giving you deterministic control over the egress path for latency-sensitive applications. With this feature, you can: * Pin breakout traffic for specific applications to a preferred WAN port. * Ensure critical traffic (such as Zoom or Teams) always uses your fastest or most reliable connection. * Benefit from automatic failover to standard WAN port priority if the preferred port goes down. This is useful for organizations with multiple ISP uplinks who need predictable egress behavior for performance-sensitive traffic. For configuration details, refer to [Designate WAN ports for breakout apps](https://developers.cloudflare.com/cloudflare-wan/configuration/appliance/network-options/application-based-policies/breakout-traffic/#designate-wan-ports-for-breakout-apps). 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/). Sep 18, 2025 1. ### [Connect and secure any private or public app by hostname, not IP — with hostname routing for Cloudflare Tunnel](https://developers.cloudflare.com/changelog/post/2025-09-18-tunnel-hostname-routing/) [ Cloudflare Tunnel ](https://developers.cloudflare.com/tunnel/)[ Cloudflare Tunnel for SASE ](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/) You can now route private traffic to [Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/) based on a hostname or domain, moving beyond the limitations of IP-based routing. This new capability is **free for all Cloudflare One customers**. Previously, Tunnel routes could only be defined by IP address or [CIDR range](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-cidr/). This created a challenge for modern applications with dynamic or ephemeral IP addresses, often forcing administrators to maintain complex and brittle IP lists. ![Hostname-based routing in Cloudflare Tunnel](https://developers.cloudflare.com/_astro/tunnel-hostname-routing.DSi8MP_7_Z1E6Ym4.webp) **What’s new:** * **Hostname & Domain Routing**: Create routes for individual hostnames (e.g., `payroll.acme.local`) or entire domains (e.g., `*.acme.local`) and direct their traffic to a specific Tunnel. * **Simplified Zero Trust Policies**: Build resilient policies in Cloudflare Access and Gateway using stable hostnames, making it dramatically easier to apply per-resource authorization for your private applications. * **Precise Egress Control**: Route traffic for public hostnames (e.g., `bank.example.com`) through a specific Tunnel to enforce a dedicated source IP, solving the IP allowlist problem for third-party services. * **No More IP Lists**: This feature makes the workaround of maintaining dynamic IP Lists for Tunnel connections obsolete. Get started in the Tunnels section of the Zero Trust dashboard with your first [private hostname](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname/) or [public hostname](https://developers.cloudflare.com/cloudflare-one/traffic-policies/egress-policies/egress-cloudflared/) route. Learn more in our [blog post ↗](https://blog.cloudflare.com/tunnel-hostname-routing/). [Search all changelog entries](https://developers.cloudflare.com/search/?contentType=Changelog+entry)