Changelog

You can now tell a person on a laptop apart from a Mesh node or an AI agent running on Workers, without matching on connector email addresses or Mesh IP ranges — and see exactly which Cloudflare Tunnel and cloudflared replica received each session.

Gateway network logs and Zero Trust Network Session Logs now identify two new kinds of traffic:

• Mesh — Traffic sent from or delivered to a Cloudflare Mesh node. Previously, Mesh nodes were logged the same way as devices running the Cloudflare One Client, because Mesh nodes run the client in headless mode.
• Workers VPC — Traffic sent by a Worker through a Workers VPC binding. Previously, Workers VPC sessions were not recorded in Network Session Logs.

To view these values in the dashboard, go to Zero Trust > Insights & Logs > Logs > Network logs, select Columns, and turn on Traffic Source and Traffic Destination. Both values also appear under Network query details when you open a log entry.

The zero_trust_network_sessions dataset, available through Logpush, includes the following fields:

For example, OnrampType = 'WORKERS_VPC' AND Offramp = 'MESH' returns every session where a Worker reached a service behind a Mesh node, and SourceName tells you which Worker it was.

With DestinationReplicaID, you can now confirm which Cloudflare Tunnel and which cloudflared replica received traffic for a specific session. Combine it with the existing DestinationTunnelID field to trace a session to an exact tunnel replica — or Mesh node replica — when you run multiple replicas for high availability. The replica ID matches the Connector ID shown in the dashboard, so you can stream that replica's logs with cloudflared tail --connector-id.

Sessions logged before this change are not backfilled. For all available fields, refer to Zero Trust Network Session Logs.

Workers using a VPC Network binding with network_id: "cf1:network" now egress to public Internet destinations through Cloudflare Gateway. This means your existing Zero Trust traffic policies — DNS, HTTP, Network, and egress — extend to traffic that originates from your Workers, the same way they do for WARP users today.

What you get by default:

• Visibility. Worker egress shows up in Gateway DNS, HTTP, and Network logs alongside your other traffic, so you can audit what your Workers are calling and when.
• Enforcement. Any existing Gateway policy whose selectors match a Worker request will apply — including allow / block lists, DNS category filtering, and HTTP destination rules. If you have already blocked a category for your workforce, your Workers inherit that block.

{
	"vpc_networks": [
		{
			"binding": "EGRESS",
			"network_id": "cf1:network",
			"remote": true,
		},
	],
}

[[vpc_networks]]
binding = "EGRESS"
network_id = "cf1:network"
remote = true

// Egress to a public destination — subject to your Gateway policies and logged
const response = await env.EGRESS.fetch("https://api.example.com/data");

// Egress to a public destination — subject to your Gateway policies and logged
const response = await env.EGRESS.fetch("https://api.example.com/data");

For configuration options, refer to VPC Networks. For policy authoring, refer to Cloudflare Gateway traffic policies.