Cloudflare Tunnel creates outbound connections from the origin to Cloudflare for public applications or private-network access. This can reduce inbound exposure, but Access policies, origin firewalls, connector redundancy and server-initiated traffic behavior still require planning.
According to current Cloudflare documentation, `cloudflared` establishes an outbound-only tunnel from the origin or private network to Cloudflare. Public application traffic reaches the origin through Cloudflare. Private networking also requires routes and Zero Trust client/policy configuration.
cloudflared maintains a persistent outbound tunnel from the origin side. User traffic passes Cloudflare edge policy/WAF layers and is proxied through the tunnel to the private service.
Public hostnames publish applications without direct origin exposure. Private networking lets enrolled clients reach internal services through CIDR or hostname routes.
For critical origins, multiple connectors on different hosts or failure domains provide better resilience.
Commands can differ for locally versus remotely managed tunnels; adapt them to your deployment model.
cloudflared --versionsystemctl status cloudflared --no-pagerjournalctl -u cloudflared --since '-15 min' --no-pagerss -lntup | grep cloudflared || truecloudflared tunnel list 2>/dev/null || trueEvaluate application publishing, private-subnet access and site-to-site traffic separately.
Outbound connector
Peer-to-peer subnet
Firewall/TLS control
The origin does not need direct public inbound exposure because cloudflared connects outbound, but it needs outbound Internet connectivity to Cloudflare.
For some private-app/network-access scenarios yes, but site-to-site and server-initiated traffic behave differently.
No. cloudflared proxies user-initiated traffic to services; server-initiated traffic uses the server's normal routing table.
Share services, private subnets, user groups and HA needs; we can choose Cloudflare Tunnel, WireGuard or a hybrid model.