New Mesh and Workers VPC logging fields improve Cloudflare traffic observability

Cloudflare has added explicit identifiers for Mesh nodes and Workers VPC traffic in both Gateway network logs and the Zero Trust Network Session dataset. The change means you can now see whether a request originated from a laptop, a Mesh endpoint, or a Worker, and which cloudflared replica handled the session.

What the Log Update Introduces

Two new traffic categories appear in the logs: Mesh – traffic that enters or exits a Cloudflare Mesh node, and Workers VPC – traffic generated by a Worker that is bound to a VPC. The zero_trust_network_sessions dataset now includes the fields OnrampType, Offramp, SourceName, SourceID, and DestinationReplicaID. These fields expose the entry point, exit point, originating Worker (when applicable), and the exact replica that served the request.

Why Mesh and Workers VPC logging Matters to Practitioners

Observability is a core requirement for AI engineers, platform teams, and security operators. Previously, Mesh nodes were logged as generic Cloudflare One clients, and Workers VPC sessions were invisible in network logs. The new granularity lets you:

• Distinguish headless Mesh traffic from ordinary endpoint traffic without relying on IP ranges or email tags.
• Trace a Worker‑initiated request through a VPC binding to the exact Mesh node or tunnel replica that delivered the response.
• Build alerts that fire on unexpected OnrampType values, such as a sudden rise in WORKERS_VPC traffic to a sensitive service.

Architectural and Operational Implications

From an architecture perspective, the added fields do not alter data flow, but they do affect how you instrument and monitor the system. Consider the following actions:

1. Dashboard updates: In the Zero Trust Insights UI, enable the Traffic Source and Traffic Destination columns to surface the new identifiers.
2. Log‑based alerting: Adjust existing queries to filter on OnrampType = 'MESH' or OnrampType = 'WORKERS_VPC' as needed. Combine with Offramp = 'MESH' to find Worker‑to‑Mesh interactions.
3. Retention and volume: The extra fields increase the size of each log record. Verify that your Logpush retention policy can accommodate the growth.
4. Incident response: When investigating a breach, you can now pinpoint the exact DestinationReplicaID – whether a Mesh node or a cloudflared tunnel – that handled the compromised request.

Security Considerations

Visibility into Mesh and Workers VPC traffic reduces blind spots that could be exploited. By correlating SourceID with known Worker deployments, you can detect rogue Workers that may have been introduced without proper review. Similarly, tracking DestinationReplicaID helps verify that traffic is being served by expected replicas, limiting the risk of traffic being diverted to an unintended endpoint.

Related CloudNinjas coverage: hands-on guides.

What This Means For Practitioners

Enable the new columns in the Zero Trust logs, update any SIEM or alerting pipelines to reference the added fields, and review retention settings for the larger payload. Treat the new identifiers as first‑class attributes for troubleshooting, capacity planning, and security monitoring. Regularly audit the patterns of OnrampType and Offramp to ensure they align with your intended architecture, and adjust policies if unexpected Mesh or Workers VPC flows appear.