Tunnel and Access

Cloudflare Tunnel creates outbound connections from cloudflared to Cloudflare, so a service can be reached without opening a public inbound port. Cloudflare Access is the authorization layer that decides who or what may reach a protected application.

Choose the route type

A published hostname without an Access application may be public. Configure the access decision before announcing or depending on the hostname.

Build a public application Tunnel

For most production use cases, Cloudflare recommends a remotely managed tunnel through the dashboard, API, or Terraform. The high-level flow is:

1. Create the tunnel and store its token through the approved secret-management path.
2. Install cloudflared on a host that can reach the application locally.
3. Map the public hostname to a narrow local service such as http://127.0.0.1:8080.
4. Add a final catch-all rule that returns 404 for unmatched hostnames when using local ingress configuration.
5. Run at least two replicas on separate failure domains when the application requires high availability.
6. Allow required outbound Tunnel traffic and deny public inbound traffic to the origin.

cloudflared version
cloudflared tunnel list
cloudflared tunnel info app-prod

Do not paste a tunnel token, account certificate, or credentials file into source control, tickets, documentation, shell transcripts, or chat. Treat them as privileged secrets and rotate them after exposure.

Define Access before use

Cloudflare Access is deny-by-default for requests that do not match an Allow policy. Build policy from specific identity and device requirements:

• include the smallest team or group that needs the application;
• require MFA and device posture for sensitive administrative tools;
• use short sessions for higher-risk applications;
• use Service Auth for approved non-user clients;
• avoid Bypass unless the traffic truly must skip Access controls; and
• test an unauthorized user, an authorized user, and a failed device posture before release.

Cloudflare also offers an account setting that requires Access protection for hostnames, helping prevent a new internal hostname from being exposed before its Access application exists. Evaluate it carefully against intentionally public hostnames before enabling it.

Connect a private network

For private IP routes, install cloudflared in the network, advertise only the required CIDR ranges, enroll user devices in the Zero Trust organization, and apply Gateway network policy where needed.

Do not advertise an entire cloud network when users need one subnet or service. Keep production, management, and shared-service routes distinct so policy and incident containment remain understandable.

Operate the connector

Monitor:

• connector and replica health;
• application reachability from cloudflared;
• Access allow and deny events;
• identity-provider and device-posture failures;
• tunnel configuration and route changes; and
• origin latency and errors after traffic enters the tunnel.

A Tunnel can remain connected while the local application is unhealthy. Test the complete path, not only connector status.

Recovery checks

cloudflared tunnel list
cloudflared tunnel info app-prod
curl -fsS http://127.0.0.1:8080/health
curl -sSI https://app.example.com

Confirm DNS still points to the intended tunnel, healthy replicas exist in separate failure domains, Access applies the expected decision, and the origin service is reachable locally.

References

• Cloudflare Tunnel
• Tunnel routing
• Tunnel configuration and replicas
• Cloudflare Access policies
• Private network routes