Starting February 2, 2026, thecloudflared proxy-dns command will be removed from all newcloudflaredreleases.

This change is being made to enhance security and address a potential vulnerability in an underlying DNS library. This vulnerability is specific to theproxy-dns command and does not affect any othercloudflared features, such as the coreCloudflare Tunnel service.

Theproxy-dns command, which runs a client-sideDNS-over-HTTPS (DoH) proxy, has been an officially undocumented feature for several years. This functionality is fully and securely supported by our actively developed products.

Versions ofcloudflared released before this date will not be affected and will continue to operate. However, note that ourofficial support policy for anycloudflared release is one year from its release date.

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 secureDNS-over-HTTPS.

The preferred method for enabling DNS-over-HTTPS on user devices is theCloudflare WARP client. The WARP client automatically secures and proxies all DNS traffic from your device, integrating it with your organization'sZero Trust policies andposture checks.

For scenarios where installing a client on every device is not possible (such as servers, routers, or IoT devices), we recommend using theWARP Connector.

Instead of runningcloudflared 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 yourentire subnet to Cloudflare forfiltering and logging.

You can now route private traffic toCloudflare Tunnel based on a hostname or domain, moving beyond the limitations of IP-based routing. This new capability isfree for all Cloudflare One customers.

Previously, Tunnel routes could only be defined by IP address orCIDR range. This created a challenge for modern applications with dynamic or ephemeral IP addresses, often forcing administrators to maintain complex and brittle IP lists.

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 firstprivate hostname orpublic hostname route.

Learn more in ourblog post ↗.

Magic WAN andWARP Connector users can now securely route their DNS traffic to the Gateway resolver without exposing traffic to the public Internet.

Routing DNS traffic to the Gateway resolver allows DNS resolution and filtering for traffic coming from private networks while preserving source internal IP visibility. This ensures Magic WAN users have full integration with our Cloudflare One features, includingInternal DNS andhostname-based policies.

To configure DNS filtering, change your Magic WAN or WARP Connector DNS settings to use Cloudflare's shared resolver IPs,172.64.36.1 and172.64.36.2. Once you configure DNS resolution and filtering, you can useSource Internal IP as a traffic selector in yourresolver policies for routing private DNS traffic to yourInternal DNS.

StartingDecember 1, 2025, list endpoints for theCloudflare Tunnel API andZero Trust Networks API will no longer return deleted tunnels, routes, subnets and virtual networks by default. This change makes the API behavior more intuitive by only returning active resources unless otherwise specified.

No action is required if you already explicitly setis_deleted=false or if you only need to list active resources.

This change affects the following API endpoints:

• List all tunnels:GET /accounts/{account_id}/tunnels
• ListCloudflare Tunnels:GET /accounts/{account_id}/cfd_tunnel
• ListWARP Connector tunnels:GET /accounts/{account_id}/warp_connector
• List tunnel routes:GET /accounts/{account_id}/teamnet/routes
• List subnets:GET /accounts/{account_id}/zerotrust/subnets
• List virtual networks:GET /accounts/{account_id}/teamnet/virtual_networks

The default behavior of theis_deleted query parameter will be updated.

If you need to retrieve deleted (or all) resources, please update your API calls to explicitly include theis_deleted parameter beforeDecember 1, 2025.

To get a list of only deleted resources, you must now explicitly add theis_deleted=true query parameter to your request:

# Example: Get ONLY deleted Tunnels
curl"https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/tunnels?is_deleted=true"\
-H"Authorization: Bearer$API_TOKEN"
# Example: Get ONLY deleted Virtual Networks
curl"https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/virtual_networks?is_deleted=true"\
-H"Authorization: Bearer$API_TOKEN"

Following this change, retrieving a complete list of both active and deleted resources will require two separate API calls: one to get active items (by omitting the parameter or usingis_deleted=false) and one to get deleted items (is_deleted=true).

This update is based on user feedback and aims to:

• Create a more intuitive default: Aligning with common API design principles where list operations return only active resources by default.
• Reduce unexpected results: Prevents users from accidentally operating on deleted resources that were returned unexpectedly.
• Improve performance: For most users, the default query result will now be smaller and more relevant.

To learn more, please visit theCloudflare Tunnel API andZero Trust Networks API documentation.

Your real-time applications running overCloudflare Tunnel are now faster and more reliable. We've completely re-architected the waycloudflared proxies UDP traffic in order to isolate it from other traffic, ensuring latency-sensitive applications like private DNS are no longer slowed down by heavy TCP traffic (like file transfers) on the same Tunnel.

This is a foundational improvement to Cloudflare Tunnel, delivered automatically to all customers. There are no settings to configure — your UDP traffic is already flowing faster and more reliably.

What’s new:

• Faster UDP performance: We've significantly reduced the latency for establishing new UDP sessions, making applications like private DNS much more responsive.
• Greater reliability for mixed traffic: UDP packets are no longer affected by heavy TCP traffic, preventing timeouts and connection drops for your real-time services.

Learn more about runningTCP or UDP applications andprivate networks throughCloudflare Tunnel.

The latestcloudflared build2024.12.2 ↗ introduces the ability to collect all the diagnostic logs needed to troubleshoot acloudflared instance.

A diagnostic report collects data from a single instance ofcloudflared running on the local machine and outputs it to acloudflared-diag file.

Thecloudflared-diag-YYYY-MM-DDThh-mm-ss.zip archive contains the files listed below. The data in a file either applies to thecloudflared instance being diagnosed (diagnosee) or the instance that triggered the diagnosis (diagnoser). For example, if your tunnel is running in a Docker container, the diagnosee is the Docker instance and the diagnoser is the host instance.

For more information, refer toDiagnostic logs.

Simplifed WARP Connector deployment

You can now deploy WARP Connector using a simplified, guided workflow similar tocloudflared connectors. For detailed instructions, refer to theWARP Connector documentation.

Bugfix for --grace-period

The newcloudflared build2024.10.0 ↗ has a bugfix related to the--grace-period tunnel run parameter.cloudflared connectors will now abide by the specified waiting period before forcefully closing connections to Cloudflare's network.

cloudflared builds available in GitHub for Apple silicon

macOS users can now downloadcloudflared-arm64.pkg directly fromGitHub ↗, in addition to being available via Homebrew.