Cloudflare Tunnel Not Working: 10 Production Fixes

1. Prove the origin works from the connector host

Before changing Cloudflare, request the origin directly from the machine or container network where cloudflared runs. Use the exact scheme, hostname and port from the ingress rule. If that request fails, Tunnel cannot repair the application.

Check whether the service is listening, whether it bound only to a different interface and whether a local firewall blocks the connector. A clean local response gives you a stable baseline for every later test.

curl -v http://127.0.0.1:8080/health
ss -lntp | grep 8080

2. Confirm the public hostname points to the intended tunnel

A healthy connector does not help if DNS points at an old tunnel or a different Cloudflare zone. Confirm the hostname in Cloudflare, the tunnel route and the account where cloudflared is authenticated.

During migrations, remove or document old A, AAAA and CNAME records so operators do not test two different paths under the same name.

• ▸ Check the hostname in the correct zone
• ▸ Verify the route targets the expected tunnel UUID
• ▸ Wait for DNS changes before comparing results

3. Read the connector state before restarting it

Repeated restarts erase the timeline. First capture service status and recent logs. Look for authentication failures, connection registration, protocol negotiation and ingress configuration errors.

If no connector is registered, focus on credentials and outbound connectivity. If the connector is healthy but requests return 502, move toward the local origin and ingress rule.

systemctl status cloudflared --no-pager
journalctl -u cloudflared -n 200 --no-pager

4. Verify the tunnel token or credentials file belongs to this tunnel

A token copied from another environment, a missing credentials mount or a stale secret after tunnel recreation can leave the service running but unauthenticated. Check the service definition and secret source without printing the credential into shared logs.

In Docker, confirm the environment variable or credentials file is present inside the container and that the process user can read it. Rotate exposed credentials instead of trying to hide them after the fact.

5. Check ingress order and the final catch-all rule

Ingress rules are evaluated in order. A broad hostname or path placed too early can capture requests intended for a later service. The configuration also needs a final catch-all response.

Validate the configuration, then compare the requested hostname and path to the first matching rule. Small differences such as www versus apex, or /api versus /api/, can select a different origin than expected.

6. In Docker, localhost usually means the cloudflared container

When cloudflared and the application run in separate containers, http://localhost:8080 points back to the cloudflared container. Put the services on the same Docker network and use the application service name, such as http://nginx:80.

If the application runs on the host, use an explicit host gateway supported by your environment rather than assuming container localhost reaches the host.

7. Match the origin scheme and TLS expectations

An ingress rule using https:// for an HTTP-only origin produces a handshake failure. The reverse is also possible when the origin redirects every HTTP request back to an external HTTPS hostname, creating a loop.

For a private HTTPS origin, validate its certificate name and trust chain. Disabling origin verification can hide the symptom, but it should not become the permanent answer without a documented risk decision.

8. Test outbound connectivity on the connector network

cloudflared needs outbound connectivity to Cloudflare. QUIC and HTTP/2 use different transport behavior, and restrictive egress firewalls can allow general web browsing while blocking the connector path.

Test from the actual host, VLAN or container network. If one transport works and another fails, document the firewall exception or configured protocol instead of relying on an accidental fallback.

9. Separate Access policy failures from tunnel failures

A working tunnel can still return an Access login loop or denial. Check the application hostname, identity provider, include and exclude rules, session duration and the user's group membership.

Test with a known policy account and in a clean browser session. Do not disable the policy globally just to prove the origin works; use a controlled test rule and restore enforcement.

10. Verify replicas and failover instead of assuming them

Multiple connectors for one tunnel improve connector availability, but they do not fix an origin that is down or shared infrastructure that both connectors depend on. Confirm where each replica runs and whether it reaches a healthy origin.

Stop one connector during a maintenance window and watch an application-level check. Record the expected behavior and recovery time in the runbook.

• ▸ Place replicas across independent failure domains when possible
• ▸ Monitor the application, not only the cloudflared process
• ▸ Keep a tested rollback path for configuration changes

When to escalate

Escalate when production is down, the origin has been exposed, credentials may have leaked, or several layers changed at once and there is no known-good baseline. Preserve logs and the current configuration before making another change.

NexaForge can trace the full path, repair the deployment and leave a smaller operating runbook behind.