Skip to content
Cloudflare Docs
DirectoryAPISDKsChangelog

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Network security
hero image

  1. Zero Trust Networks route endpoints and Cloudflare Tunnel connections field retiring on October 5, 2026

    Cloudflare Tunnel Cloudflare Tunnel for SASE Cloudflare Mesh

    On October 5, 2026, two changes take effect across the Zero Trust Networks API and Cloudflare Tunnel API: the CIDR-encoded route endpoints are removed, and tunnel list and get responses no longer include the connections field. If you manage private network routes or read tunnel connection details through the API, cloudflared, Terraform, or another integration, review the changes in the following sections and migrate before the removal date.

    Route endpoints

    The CIDR-encoded route endpoints are deprecated in favor of the standard, route_id-based endpoints that already exist today. Both sets of endpoints route a private network through Cloudflare Tunnel or Cloudflare Mesh (the API still refers to Mesh nodes as warp_connector) — only the request shape changes.

    Deprecated endpoints (removed October 5, 2026):

    Replacement endpoints:

    What is changing

    Deprecated (CIDR-encoded path)Replacement
    Route identifierURL-encoded CIDR in the path (/network/{ip_network_encoded})route_id in the path (network moves to the request body on create)
    CreatePOST .../teamnet/routes/network/{ip_network_encoded}POST .../teamnet/routes with network and tunnel_id in the body
    UpdatePATCH .../teamnet/routes/network/{ip_network_encoded}PATCH .../teamnet/routes/{route_id}
    DeleteDELETE .../teamnet/routes/network/{ip_network_encoded}DELETE .../teamnet/routes/{route_id}

    Action required

    1. Capture each route's route_id by calling List tunnel routes, or read it from the response the first time you create a route with the replacement endpoint.
    2. Update any scripts, backend services, or CI/CD pipelines that call the CIDR-encoded endpoints directly.
    3. If you manage routes with the cloudflared tunnel route ip add | delete commands, upgrade cloudflared to the latest version ↗.
    4. If you manage routes with Terraform, make sure you are on a current version of the cloudflare_zero_trust_tunnel_cloudflared_route ↗ resource and the Cloudflare Terraform provider ↗.
    Terminal window
    # Before: create a route by URL-encoding the CIDR into the path
    curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/network/172.16.0.0%2F16 \
         -H 'Content-Type: application/json' \
         -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
         -d '{"tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'
    

    # After: create a route with the network in the request body
    curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes \
         -H 'Content-Type: application/json' \
         -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
         -d '{"network": "172.16.0.0/16", "tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'
    

    # After: update or delete a route using its route_id
    curl -X PATCH https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
         -H 'Content-Type: application/json' \
         -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
         -d '{"comment": "Updated comment for this route."}'
    

    curl -X DELETE https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
         -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

    Cloudflare Tunnel and Cloudflare Mesh connections

    Starting the same day, the connections array is removed from list and get responses for Cloudflare Tunnel and Cloudflare Mesh nodes (the cfd_tunnel and warp_connector API resources). Query the dedicated connections endpoint instead of reading the field off the tunnel or node object.

    This affects:

    Action required

    Fetch connection details from the tunnel-specific connections endpoint instead of parsing it off the list or get response. For Cloudflare Tunnel, call GET /accounts/{account_id}/cfd_tunnel/{tunnel_id}/connections. For Cloudflare Mesh, call GET /accounts/{account_id}/warp_connector/{tunnel_id}/connections.

    Terminal window
    # Before: read connections off the tunnel object
    curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID \
         -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
    

    # After: query connections directly
    curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID/connections \
         -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

    Update any dashboards, monitoring scripts, or automation that parses connections from the tunnel list or get response. cloudflared and the Cloudflare Terraform provider do not read this field, so no changes are required on their side for this part of the update.

    Why we are making these changes

    • Smaller, faster responses. Cloudflare Tunnel and Cloudflare Mesh nodes with many connections no longer inflate every list and get call — connection detail is only fetched when you need it.
    • A single way to identify a route. Consolidating on route_id removes the need to URL-encode CIDR ranges into the path and matches how every other resource in the Zero Trust Networks API is addressed.
    • Consistency across the API. Both changes align these endpoints with Cloudflare's standard REST conventions for resource identifiers and nested detail endpoints.

    To learn more, refer to the Zero Trust Networks API, the Cloudflare Tunnel API, and Routes documentation.

  1. IPsec downgrade protection (beta)

    Cloudflare One Cloudflare WAN

    Cloudflare IPsec now supports the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH ↗ IKEv2 extension to protect against downgrade attacks on IPsec tunnels.

    IKEv2's original authentication design has each endpoint sign only its own outbound messages, not the full handshake transcript. A quantum-capable on-path attacker ↗ can exploit this to bypass post-quantum key exchange by downgrading the connection to classical cryptography. The IKE_SA_INIT_FULL_TRANSCRIPT_AUTH extension addresses this by having both peers sign the entire handshake transcript during the authentication exchange, preventing an attacker from manipulating the negotiation without detection.

    Key details:

    • Available in beta for Cloudflare WAN and Magic Transit IPsec tunnels.
    • Cloudflare sends the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification unconditionally as a responder when the feature flag is enabled.
    • Both the initiator (your device) and responder (Cloudflare) must support the extension for downgrade protection to be effective.
    • This feature is currently gated by a per-account feature flag. Contact your account team to turn it on.

    Refer to Downgrade protection for more details.

  1. Self-serve registration of Cloudflare One Virtual Appliance in the dashboard

    Cloudflare One Appliance Cloudflare One Cloudflare WAN

    You can now register a Cloudflare One Virtual Appliance and generate its license key directly from the dashboard, without contacting your account team.

    Registering a Cloudflare One Virtual Appliance and generating its authentication key from the Connectors page
    • On the Connectors page, select Add an appliance and choose Virtual appliance to register a virtual appliance and generate its authentication key.
    • Use Regenerate authentication key from a virtual appliance connector's menu to rotate its key. The previous key is immediately and irrevocably revoked.
    • The authentication key is shown only once — copy and store it securely.

    This complements the existing API and Terraform self-serve workflow for provisioning virtual appliances. Hardware appliances continue to use the existing account-team fulfillment workflow.

    For details, refer to Configure a Cloudflare One Virtual Appliance.

  1. Regionalized IP Bindings for Regional Services

    Data Localization Suite

    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).

    Where 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.

  1. Manage all your routes from one page in the dashboard

    Cloudflare Mesh Cloudflare Tunnel Cloudflare WAN Cloudflare One

    The Routes page in the Cloudflare dashboard now shows the routes across all of your connectors — Cloudflare Mesh and Cloudflare Tunnel routes alongside Cloudflare WAN and Magic Transit static routes — in a single table, instead of a separate routes view per product.

    The unified Routes page in the Cloudflare dashboard, showing routes across connectors in a single table

    From the unified Routes page you can:

    • Visualize your network with an interactive map that shows how your destinations flow through to your connectors — including equal-cost multi-path (ECMP) routes where the same prefix is served by several connectors. Select a node to filter the table down to the routes behind it.
    • See every route in one table, with its destination, type, connector, priority, and source, and filter or sort to find what you need.
    • Create, edit, and delete routes of any supported type without leaving the page. When adding a Cloudflare WAN or Magic Transit static route, you now pick the next hop by connector name instead of typing its IP.
    • Manage virtual networks from a dedicated tab.
    • Test a route to see which connector and next hop a destination resolves to before you commit a change.

    To find it, go to Networking > Routes in the dashboard sidebar.

    Go to Routes

    Your existing routes, APIs, and configurations are unchanged — this is a dashboard experience that brings them together in one place. Learn how to add routes and manage virtual networks.

  1. Cisco IOS XE

    Cloudflare WAN Cloudflare One

    The Cisco IOS XE third-party integration guide for Cloudflare WAN has been updated to include:

    • Post Quantum Cryptography (PQC)
    • Policy-Based Routing (PBR)
    • IP Service Level Agreement (IP SLA)

    This link will take you directly to the updated Cisco IOS XE guide.

  1. Cloudflare Tunnel now runs connectivity pre-checks at startup

    Cloudflare Tunnel Cloudflare Tunnel for SASE

    Starting with cloudflared version 2026.5.2 ↗, Cloudflare Tunnel automates the entire connectivity pre-checks workflow directly inside the binary. Previously, customers had to install dig and netcat and run those commands by hand to verify their environment. Now cloudflared does it natively at startup — and surfaces actionable remediation when something is blocked.

    cloudflared connectivity pre-checks output

    On every cloudflared tunnel run (and cloudflared tunnel diag), the binary now natively checks:

    • DNS resolution — region1.v2.argotunnel.com and region2.v2.argotunnel.com resolve to valid Cloudflare IPs.
    • Transport connectivity — outbound UDP (QUIC) and TCP (HTTP/2) on port 7844.
    • Management API — outbound TCP/443 to api.cloudflare.com for software updates.

    Results are printed in a scannable CLI table with three states:

    • ✅ Pass — the check succeeded.
    • ⚠️ Warn — a non-blocking issue, for example the Management API is unreachable so automatic updates will not work, but the tunnel will still come up.
    • ❌ Fail — a blocking issue, with a specific remediation hint (for example, Allow outbound UDP on port 7844).

    If DNS is unresolvable, or both UDP and TCP fail on port 7844, cloudflared exits early with the failure rather than looping on opaque failed to dial errors.

    Pre-checks now run automatically on every start, which also catches regressions like overnight firewall policy changes — no need to remember to rerun the troubleshooting guide.

    To get the new behavior, upgrade cloudflared to version 2026.5.2 or later. For more details, refer to the Connectivity pre-checks documentation.

  1. Granular permissions for Cloudflare Tunnel and Cloudflare Mesh

    Cloudflare Fundamentals Cloudflare One Cloudflare Tunnel for SASE Cloudflare Tunnel Cloudflare Mesh

    You can now scope Cloudflare permissions to individual Cloudflare Tunnel instances and Cloudflare Mesh nodes. Administrators can delegate access to specific Tunnels or Mesh nodes without granting account-wide control over private networking.

    What is new

    When you add a member or create a permission policy, the resource picker now lists Cloudflare Tunnel instances and Cloudflare Mesh nodes as scopable resource types. You can:

    • Grant a read-only role on a single Cloudflare Tunnel instance to a support operator for log streaming and diagnostics — without exposing other Tunnels or destructive actions.
    • Grant a write role on a specific Cloudflare Mesh node to an application team — without giving them access to the rest of your private network.
    • Scope a single policy to one or many Tunnels and Mesh nodes at once.

    How it works

    Granular permissions are a parallel layer to existing account-level roles — they do not replace them.

    • Existing account-level roles continue to work. A member with Cloudflare Access or Cloudflare Zero Trust retains write access to every Tunnel and Mesh node in the account. This ensures backward compatibility for existing automation and tokens.
    • Granular permissions are additive. For any API request on a specific Tunnel or Mesh node, access is granted if the principal has either the account-level role or a granular permission for that resource.
    • Resource enumeration is authorization-aware. Listing endpoints (GET /accounts/{id}/cfd_tunnel, GET /accounts/{id}/warp_connector) return only the resources the principal has at least read access to.

    Get started

  1. Network Analytics support for Unified Routing

    Cloudflare WAN Magic Transit

    Network Analytics is now fully supported for accounts using Unified Routing mode. Traffic that traverses Unified Routing onramps and offramps is now visible in Network Analytics with the same dimensions and filters as traffic on the standard data plane.

    This closes a parity gap for customers who had moved tunnels onto Unified Routing and lost visibility into their dataplane traffic in the Network Analytics dashboard. No configuration change is required — analytics data is collected automatically for all accounts with Unified Routing enabled.

    For the remaining beta limitations, refer to Traffic steering beta limitations.

  1. New accounts assigned a single IPv4 anycast address

    Cloudflare WAN Magic Transit Cloudflare One

    New Magic Transit and Cloudflare WAN accounts are now assigned a single IPv4 anycast address by default.

    Cloudflare handles failures on its network automatically by advertising your endpoint IP from multiple nodes across many globally distributed data centers. To handle failures on your network, configure two tunnels from separate routers.

    To request additional anycast IP addresses for your account, contact your account team.

    For tunnel configuration guidance, refer to Configure tunnel endpoints for Cloudflare WAN or Configure tunnel endpoints for Magic Transit.

  1. NAT-T support for IKE on UDP port 500

    Cloudflare WAN Magic Transit

    Cloudflare IPsec now supports the standard NAT traversal (NAT-T) flow, where IKE begins on UDP port 500 and switches to UDP port 4500 after NAT is detected.

    Previously, devices behind NAT had to be configured to initiate IKE on UDP port 4500 directly. Devices that started on UDP port 500 could not complete the IKE handshake when NAT was in the path. This required custom configuration on devices such as VeloCloud SD-WAN edges, Cisco IOS-XE routers, and Juniper SRX firewalls, and was not possible on every platform.

    What changed:

    • Devices behind NAT can now initiate IKE on either UDP port 500 or UDP port 4500.
    • Devices that start IKE on UDP port 500 and switch to UDP port 4500 after NAT detection now complete the handshake successfully.
    • No configuration change is required on Cloudflare. The change is available for all IPsec tunnels on Cloudflare WAN and Magic Transit.

    This change does not affect existing tunnels:

    • Tunnels using UDP port 500 with no NAT detected continue to operate as before.
    • Tunnels configured to start IKE on UDP port 4500 continue to operate as before.
    • NAT detection logic is unchanged.

    For configuration details, refer to GRE and IPsec tunnels.

  1. Custom DHCP options on Cloudflare One Appliance

    Cloudflare One Appliance Cloudflare One Cloudflare WAN

    When the Cloudflare One Appliance is acting as the DHCP server for a LAN, you can now configure custom DHCP options on the leases it issues. This unlocks workflows such as PXE / iPXE boot, VoIP phone provisioning, and vendor-specific client configuration.

    Each option is defined by option_number, value, and one of four value types: text, integer, hex, or ip. Configurations are validated on the appliance before being applied — invalid configurations are rejected and the underlying error is returned to the API caller, so a bad option will not disrupt the live DHCP service.

    For details, refer to DHCP server options.

  1. Source-based breakout and prioritization on Cloudflare One Appliance

    Cloudflare One Appliance Cloudflare One Cloudflare WAN

    Breakout and traffic prioritization rules on the Cloudflare One Appliance can now match by source in addition to destination application. You can pin breakout or priority behavior to:

    • A source LAN interface — VLANs attached to that LAN are included automatically.
    • A source IP address, range, or CIDR block.

    This is the natural way to break out a guest VLAN to the local Internet, or to prioritize traffic from a specific subnet, without enumerating destination applications.

    For details, refer to Breakout traffic.

  1. Self-serve provisioning of Cloudflare One Virtual Appliance via API

    Cloudflare One Appliance Cloudflare One Cloudflare WAN

    You can now create, rotate, and delete Cloudflare One Virtual Appliance instances and their license keys directly via the API and Terraform.

    • Create a virtual appliance and receive a license key: POST /accounts/{account_id}/magic/connectors with device.provision_license: true.
    • Rotate the license key for an existing virtual appliance: PATCH /accounts/{account_id}/magic/connectors/{connector_id} with provision_license: true. The previous key is immediately and irrevocably revoked.
    • Delete a virtual appliance to release the associated licensed device.

    The license key is returned in the response only once, at create or rotate time. Copy and store it securely.

    For details, refer to Configure a Cloudflare One Virtual Appliance.

  1. Post-quantum IPsec interoperability with third-party devices

    Cloudflare One Cloudflare WAN

    Cloudflare IPsec now supports post-quantum key agreement with compatible third-party devices. Cisco ↗ and Fortinet ↗ are the first third-party vendors validated to interoperate with Cloudflare IPsec using ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism).

    Post-quantum IPsec uses RFC 9370 ↗ and draft-ietf-ipsecme-ikev2-mlkem ↗ to negotiate hybrid key agreement during the IKEv2 IKE_INTERMEDIATE phase. This combines classical Diffie-Hellman (Group 20) with ML-KEM-768 or ML-KEM-1024 to protect against harvest-now, decrypt-later ↗ attacks.

    Key details:

    • Compatible with Cisco 8000 Series Secure Routers with IOS XR Release 26.1.1 and Fortinet FortiOS 7.6.6 and later.
    • Uses ML-KEM-768 or ML-KEM-1024 as an additional Key Exchange to DH Group 20.
    • Follows RFC 9370 and draft-ietf-ipsecme-ikev2-mlkem standards.
    • No additional licensing required.

    Post-quantum IPsec with third-party devices is now generally available with confirmed interoperability for the platforms listed above. Cloudflare intends to support interoperability with more vendors as they build out support for draft-ietf-ipsecme-ikev2-mlkem. Contact your account team to discuss support for additional vendors.

    For supported key exchange methods and the list of validated platforms, refer to GRE and IPsec tunnels.

  1. Country rules supported in Unified Routing

    Cloudflare Network Firewall Magic Transit Cloudflare WAN

    Cloudflare Advanced Network Firewall Country rules are now supported for accounts using Unified Routing mode. This feature requires a Cloudflare Advanced Network Firewall subscription.

    You can create firewall rules that match traffic based on source or destination country to enforce geographic access policies across your network.

    This is the first of the Cloudflare Advanced Network Firewall features to become available in Unified Routing. Support for additional features - IP Lists, ASN Lists, Threat Intel Lists, IDS, Rate Limiting, SIP, and Managed Rulesets - is planned.

    For the full list of current beta limitations, refer to Traffic steering beta limitations.

  1. Link aggregation (LACP) support for Cloudflare One Appliance

    Cloudflare One Appliance Cloudflare One 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.

  1. New QUIC RTT and delivery rate fields

    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 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

    FieldTypeDescription
    cf.timings.client_quic_rtt_msecIntegerThe 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_rateIntegerThe 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:

    OperationHeader nameValue
    SetX-High-Latencytrue

    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 and the fields reference.

  1. New mTLS certificate fields for Transform Rules

    Rules

    Cloudflare now exposes four new fields in the Transform Rules phase that encode client certificate data in RFC 9440 ↗ format. Previously, forwarding client certificate information to your origin required custom parsing of PEM-encoded fields or non-standard HTTP header formats. These new fields produce output in the standardized Client-Cert and Client-Cert-Chain header format defined by RFC 9440, so your origin can consume them directly without any additional decoding logic.

    Each certificate is DER-encoded, Base64-encoded, and wrapped in colons. For example, :MIIDsT...Vw==:. A chain of intermediates is expressed as a comma-separated list of such values.

    New fields

    FieldTypeDescription
    cf.tls_client_auth.cert_rfc9440StringThe client leaf certificate in RFC 9440 format. Empty if no client certificate was presented.
    cf.tls_client_auth.cert_rfc9440_too_largeBooleantrue if the leaf certificate exceeded 10 KB and was omitted. In practice this will almost always be false.
    cf.tls_client_auth.cert_chain_rfc9440StringThe 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_largeBooleantrue 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:

    OperationHeader nameValue
    SetClient-Certcf.tls_client_auth.cert_rfc9440
    SetClient-Cert-Chaincf.tls_client_auth.cert_chain_rfc9440

    To get the most out of these fields, upload your client CA certificate to Cloudflare so that Cloudflare validates the client certificate at the edge and populates cf.tls_client_auth.cert_verified and cf.tls_client_auth.cert_revoked.

    For more information, refer to Mutual TLS authentication, Request Header Transform Rules, and the fields reference.

  1. Interconnects moved to Connectors

    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.

  1. Stream logs from multiple replicas of Cloudflare Tunnel simultaneously

    Cloudflare Tunnel Cloudflare Tunnel for SASE

    In the Cloudflare One dashboard, the overview page for a specific Cloudflare Tunnel now shows all replicas of that tunnel and supports streaming logs from multiple replicas at once.

    View replicas and stream logs from multiple connectors

    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 ↗ 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 and Deploy replicas.

  1. Manage Cloudflare Tunnels with Wrangler

    Cloudflare Tunnel Workers

    You can now manage Cloudflare Tunnels directly from Wrangler, the CLI for the Cloudflare Developer Platform. The new wrangler tunnel commands let you create, run, and manage tunnels without leaving your terminal.

    Wrangler tunnel commands demo

    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.

    Wrangler handles downloading and managing the cloudflared 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.

  1. Worker execution timing field now available in Rules

    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

    FieldTypeDescription
    cf.timings.worker_msecIntegerThe 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.

  1. Manage Cloudflare Tunnel directly from the main Cloudflare Dashboard

    Cloudflare Tunnel Cloudflare Tunnel for SASE

    Cloudflare Tunnel is now available in the main Cloudflare Dashboard at Networking > Tunnels ↗, bringing first-class Tunnel management to developers using Tunnel for securing origin servers.

    Manage Tunnels in the Core Dashboard

    This new experience provides everything you need to manage Tunnels for public applications, including:

    Choose the right dashboard for your use case

    Core Dashboard: Navigate to Networking > Tunnels ↗ to manage Tunnels for:

    Cloudflare One Dashboard: Navigate to Zero Trust > Networks > Connectors ↗ to manage Tunnels for:

    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 or explore advanced use cases like securing SSH servers or running Tunnels in Kubernetes.

  1. Cloudflare One Product Name Updates

    Cloudflare One Cloudflare WAN Cloudflare Network Firewall 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.