Cloudflare changelogs | Cloudflare Tunnel

Cloudflare Tunnel, Cloudflare Tunnel for SASE, Cloudflare Mesh, Gateway, Cloudflare One - Hostname routing is now generally available, with a new public IP range for initial resolved IPs

Tue, 11 Aug 2026 00:00:00 GMT

Hostname routing ↗ is now generally available. Instead of managing static IP lists and routes, you can route traffic by hostname across multiple Cloudflare One connectors:

Cloudflare Tunnel: route a private hostname (for example, wiki.internal.local) to a private application behind your tunnel, or a public hostname (for example, bank.example.com) to egress through a specific tunnel and anchor traffic to a dedicated exit node.
Cloudflare Mesh: attract a private or public hostname's traffic to a Mesh node.

Alongside GA, the default IPv4 range used for initial resolved IPs (also called token IPs) is changing from a Carrier-Grade NAT (CGNAT) range to a public Cloudflare-owned range:

IPv4: 172.64.128.0/20
IPv6: 2606:4700:0cf1:4000::/64

This is the default range. You can configure a custom initial resolved IP range for IPv4 if it conflicts with your existing network.

Why this is changing: Starting with Chrome 142 ↗, Local Network Access (LNA) restrictions block background requests to CGNAT addresses (100.64.0.0/10), which included the previous initial resolved IP default (100.80.0.0/16). LNA is implemented at the Chromium engine level, so it affects all Chromium-based browsers (for example, Microsoft Edge, Brave, and Opera), not only Google Chrome. This could silently break hostname-based Gateway features for users of these browsers, and required Chrome Enterprise policy workarounds. The new default range is public Cloudflare address space, so it is not affected by this restriction.

What is affected: Initial resolved IPs are used by several features that associate a DNS query with the network connection that follows it:

Private and public hostname routing for Cloudflare Tunnel
Hostname routes for Cloudflare Mesh
Access private applications on non-HTTPS ports
Egress policy host selectors (Domain, Host, Application, and Content Categories)

You can check your account's current range, or configure a custom range, at any time from Zero Trust > Team & Resources > Devices > Device profiles, or using the Initial Resolved IP Subnet API.

For full instructions, refer to Configure initial resolved IPs. The IPv6 range (2606:4700:0cf1:4000::/64) is unchanged and is not affected by this restriction.

If you were relying on a Chrome Enterprise policy workaround (such as LocalNetworkAccessRestrictionsTemporaryOptOut) while your account was still on the legacy CGNAT-based range, refer to Google Chrome restricts access to private hostnames for next steps.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Stream live logs from Cloudflare Tunnel in the dashboard

Mon, 10 Aug 2026 00:00:00 GMT

Real-time Tunnel log streaming is now available in the Cloudflare dashboard under Networking > Tunnels. This brings the same live debugging capability previously only available in the Cloudflare One dashboard, including multi-connector aggregated streaming for high-availability deployments.

In the tunnel detail view, a new Live logs tab lets you:

Stream logs from single or multiple connectors — In highly available deployments with multiple cloudflared replicas, logs from all connectors are merged into a single stream grouped by hostname, making it easy to identify which host machine produced each log entry.
Filter by log level, event type, and HTTP method — Narrow the stream to only the events you care about (HTTP, TCP, UDP, or cloudflared internal), at any log level.

Go to Tunnels ↗

For more information, refer to Monitor tunnels and Tunnel log streams.

Cloudflare Tunnel, Cloudflare Tunnel for SASE, Cloudflare Mesh - Zero Trust Networks route endpoints and Cloudflare Tunnel connections field retiring on October 5, 2026

Thu, 09 Jul 2026 00:00:00 GMT

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

Create a tunnel route (CIDR Endpoint): POST /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
Update a tunnel route (CIDR Endpoint): PATCH /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
Delete a tunnel route (CIDR Endpoint): DELETE /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}

Replacement endpoints:

Create a tunnel route: POST /accounts/{account_id}/teamnet/routes
Update a tunnel route: PATCH /accounts/{account_id}/teamnet/routes/{route_id}
Delete a tunnel route: DELETE /accounts/{account_id}/teamnet/routes/{route_id}

What is changing

	Deprecated (CIDR-encoded path)	Replacement
Route identifier	URL-encoded CIDR in the path (`/network/{ip_network_encoded}`)	`route_id` in the path (`network` moves to the request body on create)
Create	`POST .../teamnet/routes/network/{ip_network_encoded}`	`POST .../teamnet/routes` with `network` and `tunnel_id` in the body
Update	`PATCH .../teamnet/routes/network/{ip_network_encoded}`	`PATCH .../teamnet/routes/{route_id}`
Delete	`DELETE .../teamnet/routes/network/{ip_network_encoded}`	`DELETE .../teamnet/routes/{route_id}`

Action required

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.
Update any scripts, backend services, or CI/CD pipelines that call the CIDR-encoded endpoints directly.
If you manage routes with the cloudflared tunnel route ip add | delete commands, upgrade cloudflared to the latest version ↗.
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 ↗.

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

GET /accounts/{account_id}/cfd_tunnel — connections removed from each item in result
GET /accounts/{account_id}/cfd_tunnel/{tunnel_id} — connections removed from result
GET /accounts/{account_id}/warp_connector — connections removed from each item in result
GET /accounts/{account_id}/warp_connector/{tunnel_id} — connections removed from result

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.

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

Cloudflare Mesh, Cloudflare Tunnel, Cloudflare WAN, Cloudflare One - Manage all your routes from one page in the dashboard

Fri, 19 Jun 2026 00:00:00 GMT

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.

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.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Cloudflare Tunnel now runs connectivity pre-checks at startup

Wed, 27 May 2026 00:00:00 GMT

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.

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.

Cloudflare Fundamentals, Cloudflare One, Cloudflare Tunnel for SASE, Cloudflare Tunnel, Cloudflare Mesh - Granular permissions for Cloudflare Tunnel and Cloudflare Mesh

Thu, 21 May 2026 00:00:00 GMT

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

Configure granular permissions for Cloudflare Tunnel.
Configure granular permissions for Cloudflare Tunnel and Cloudflare Mesh in Cloudflare One.
Review the resource-scoped roles on the Cloudflare role reference.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Stream logs from multiple replicas of Cloudflare Tunnel simultaneously

Fri, 20 Mar 2026 00:00:00 GMT

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.

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.

Cloudflare Tunnel, Workers - Manage Cloudflare Tunnels with Wrangler

Thu, 19 Mar 2026 00:00:00 GMT

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.

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.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Manage Cloudflare Tunnel directly from the main Cloudflare Dashboard

Fri, 20 Feb 2026 00:00:00 GMT

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.

This new experience provides everything you need to manage Tunnels for public applications, 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 and Workers VPC — no more copy-pasting UUIDs.
Real-time visibility: Monitor replicas and Tunnel health status directly in the dashboard.
Routing map: Manage all ingress routes for your Tunnel, including public applications, private hostnames, private CIDRs, and Workers VPC services, from a single interactive interface.

Choose the right dashboard for your use case

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

Securing origin servers and public applications with CDN, WAF, Load Balancing, and DDoS protection
Connecting Workers to private services via Workers VPC

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

Securing your public applications with Zero Trust access policies
Connecting users to private applications
Building a private mesh network

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.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Verify WARP Connector connectivity with a simple ping

Thu, 15 Jan 2026 00:00:00 GMT

We have made it easier to validate connectivity when deploying WARP Connector as part of your software-defined private network.

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, WARP Connector responds to traffic addressed to its own LAN IP, giving you immediate visibility into Connector reachability.

Learn more about deploying WARP Connector and building private network connectivity with Cloudflare One.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - cloudflared proxy-dns command will be removed starting February 2, 2026

Tue, 11 Nov 2025 00:00:00 GMT

Starting February 2, 2026, the cloudflared proxy-dns command will be removed from all new cloudflared releases.

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

The proxy-dns command, which runs a client-side DNS-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 of cloudflared released before this date will not be affected and will continue to operate. However, note that our official support policy 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.

End-user devices

The preferred method for enabling DNS-over-HTTPS on user devices is the Cloudflare WARP client. The WARP client automatically secures and proxies all DNS traffic from your device, integrating it with your organization's Zero Trust policies and 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.

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 to Cloudflare for filtering and logging.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Connect and secure any private or public app by hostname, not IP — with hostname routing for Cloudflare Tunnel

Thu, 18 Sep 2025 00:00:00 GMT

You can now route private traffic to 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. 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 first private hostname or public hostname route.

Learn more in our blog post ↗.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Cloudflare Tunnel and Networks API will no longer return deleted resources by default starting December 1, 2025

Tue, 02 Sep 2025 00:00:00 GMT

Starting December 1, 2025, list endpoints for the Cloudflare Tunnel API and Zero 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 set is_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
List Cloudflare Tunnels: GET /accounts/{account_id}/cfd_tunnel
List WARP 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

What is changing?

The default behavior of the is_deleted query parameter will be updated.

Scenario	Previous behavior (before December 1, 2025)	New behavior (from December 1, 2025)
`is_deleted` parameter is omitted	Returns active & deleted tunnels, routes, subnets and virtual networks	Returns only active tunnels, routes, subnets and virtual networks

Action required

If you need to retrieve deleted (or all) resources, please update your API calls to explicitly include the is_deleted parameter before December 1, 2025.

To get a list of only deleted resources, you must now explicitly add the is_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 using is_deleted=false) and one to get deleted items (is_deleted=true).

Why we’re making this change

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 the Cloudflare Tunnel API and Zero Trust Networks API documentation.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Faster, more reliable UDP traffic for Cloudflare Tunnel

Tue, 15 Jul 2025 00:00:00 GMT

Your real-time applications running over Cloudflare Tunnel are now faster and more reliable. We've completely re-architected the way cloudflared 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 running TCP or UDP applications and private networks through Cloudflare Tunnel.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Troubleshoot tunnels with diagnostic logs

Thu, 19 Dec 2024 00:00:00 GMT

The latest cloudflared build 2024.12.2 ↗ introduces the ability to collect all the diagnostic logs needed to troubleshoot a cloudflared instance.

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

For more information, refer to Diagnostic logs.