How to troubleshoot a Cloudflare Tunnel that is not serving your site

A named Cloudflare Tunnel can fail at several points between a browser and the HTTP service on your machine. This guide gives you a cheap-first diagnostic order so you can tell whether the problem is the local origin, the running connector, the named tunnel, DNS, or a policy/application response.

Scope: CLI-managed named tunnels. Quick Tunnels are out of scope. This guide also assumes you already have a local HTTP origin that the tunnel is meant to proxy. cloudflared connects that origin to Cloudflare’s edge. It does not start your website or application.

Start close to the application, then move outward. A public error page alone rarely identifies the broken layer.

The five layers to check

Check these in order. Do not change a later layer until the earlier one has a sensible result.

1. Local origin. The HTTP service must answer at the address and port that your tunnel is configured to use.
2. Connector process. A cloudflared tunnel run process must be active and able to connect the named tunnel to Cloudflare’s edge.
3. Tunnel identity and credentials. The connector needs the credentials created for that named tunnel. The CLI says a tunnel run identified by UUID does not need the login certificate, but it does need the tunnel credentials created by cloudflared tunnel create.
4. Public hostname and DNS. The hostname must have a DNS route to the intended tunnel. cloudflared tunnel route dns <TUNNEL> <HOSTNAME> creates a CNAME for this purpose.
5. Policy or application behavior. Cloudflare Access can protect a hostname. The application behind the tunnel can also reject or mishandle a request after the tunnel layers are healthy.

The order matters. If the local HTTP request cannot reach the selected address and port, no DNS change can repair that. If Cloudflare sees no active connector, reading a browser response will not tell you why the connector is absent.

Start with the symptom

Use this table to choose the first check. It deliberately avoids treating an HTTP status or browser page as a diagnosis by itself.

What you observe	Cheapest first check	What that check establishes	Next layer
The local request cannot connect	curl -sS -I http://127.0.0.1:8080/	The chosen local address and port did not answer that request.	Compare the address and port with your own ingress configuration.
Local HTTP answers, public HTTP does not	cloudflared tunnel info <TUNNEL_NAME>	Whether Cloudflare reports active connectors for that named tunnel.	Connector, then DNS.
The tunnel appears in the account but has no active connector details	cloudflared tunnel info <TUNNEL_NAME>	The tunnel exists, but the command does not show a currently active connector.	Connector process and its tunnel credentials.
The hostname has no expected CNAME target	dig CNAME <HOSTNAME>	What DNS currently returns for that hostname.	Confirm the intended hostname and tunnel before altering DNS.
Public HTTP returns a status you did not expect	curl -sS -I https://<HOSTNAME>/	The status and headers seen at the public hostname.	Combine that result with the local, connector, and DNS checks.
The hostname is intentionally protected but a test request is denied	curl -sS -I https://<HOSTNAME>/	The public request received a response, not why a policy made its decision.	Verify whether Access is intentionally protecting that hostname.
The failure is intermittent	Repeat the local and public header checks, recording the time	Whether the local and public observations change together.	Connector evidence and a diagnostic archive.

A 4xx, 5xx, timeout, or login page can be useful evidence. It is not enough evidence to change a tunnel, a DNS record, or an Access policy without the other checks.

Decision tree

Replace <TUNNEL_NAME> and <HOSTNAME> with your own values. Replace port 8080 if your own ingress configuration points to another local origin.

1. Can the selected local origin answer?
   curl -sS -I http://127.0.0.1:8080/

   No  -> The selected address and port did not answer this request.
          Compare them with your ingress configuration. Fix that mismatch
          or the local service before changing the tunnel.

   Yes -> Continue.

2. Does the named tunnel exist, and does Cloudflare report a connector?
   cloudflared tunnel list
   cloudflared tunnel info <TUNNEL_NAME>

   Tunnel absent -> Check that you are working with the intended named tunnel
                    and account context before proceeding.

   No active connector information -> Investigate the running connector and
                                     its named-tunnel credentials. Collect
                                     evidence before restarting or cleaning up.

   Active connector information -> Continue.

3. Does DNS show the expected CNAME for the public hostname?
   dig CNAME <HOSTNAME>

   Missing or unexpected -> Record the exact `dig` result, confirm that you
                             queried the intended hostname, and compare the
                             result with the intended tunnel before changing
                             any existing DNS record. The verified command
                             `cloudflared tunnel route dns <TUNNEL> <HOSTNAME>`
                             creates a CNAME to a tunnel.

   Expected CNAME -> Continue.

4. What does the public request show?
   curl -sS -I https://<HOSTNAME>/

   Expected result -> The named tunnel is serving the tested request.

   Unexpected result -> Treat it as an observation. Recheck the local origin,
                        connector information, and CNAME before deciding whether
                        the remaining issue is application or policy behavior.

This tree does not prescribe a restart command, a service manager, or a config-file path because those differ by installation method. The goal is to identify the layer before you make a local operational change.

Run the checks

Check the local origin

curl -sS -I http://127.0.0.1:8080/

This sends a headers-only HTTP request to the local address and port in the command. It bypasses the public hostname and Cloudflare. If it fails, it proves only that this chosen address and port did not answer this request. Compare it with the address and port in your ingress configuration before deciding that the application is down.

If it succeeds while the public request fails, keep that result. It narrows the investigation away from the local HTTP service and toward the connector, the tunnel route, DNS, or a layer in front of the application.

Record the cloudflared build

cloudflared --version

This confirms that the binary is present and records the build you are troubleshooting. Version information belongs in every escalation because command behavior and documentation can change between releases.

Check that the named tunnel exists

cloudflared tunnel list

The CLI lists existing tunnels. Look for the named tunnel you expect to operate. If it is absent, stop and verify that you are using the intended tunnel/account context. Do not create a replacement tunnel just to make the list look right. That can make DNS and credential evidence harder to interpret.

Check connector information

cloudflared tunnel info <TUNNEL_NAME>

The CLI describes this as listing details about active connectors for a named tunnel. Use it after the local origin check. Record whether the command returns connector details for the tunnel you named. If it does not, investigate the local connector process and its credentials before guessing at DNS.

Inspect the DNS route

dig CNAME <HOSTNAME>

This asks DNS for the hostname’s CNAME. For a route made with the verified CLI command, the CNAME points the hostname at the tunnel. A missing or unexpected answer means the DNS route needs investigation. First confirm the hostname and intended tunnel. Then decide whether the existing DNS record should be changed.

The relevant verified command is:

cloudflared tunnel route dns <TUNNEL> <HOSTNAME>

It creates a CNAME record for the hostname pointing to the tunnel. It is not a substitute for understanding an existing DNS record, so avoid overwriting records as a first troubleshooting step.

Inspect the public hostname

curl -sS -I https://<HOSTNAME>/

This shows the status line and response headers received at the public hostname. Use it to compare the outside view with the local origin check. It does not, by itself, identify whether an unexpected response comes from the connector, an ingress mismatch, a policy, or the application.

When the local origin answers, the named tunnel has connector information, and the CNAME looks correct, an unexpected public response points the remaining investigation at application behavior, hostname policy, or the connection path between those layers. Preserve the outputs rather than cycling through speculative fixes.

Create a diagnostic archive

cloudflared tunnel diag

This creates a diagnostic report from a local cloudflared instance. Use it after recording the basic checks. Inspect the archive locally before sharing it. A diagnostic archive is evidence, not a reason to publish your configuration or credentials in a ticket.

When results conflict

Conflicting evidence is normal when a tunnel has several moving parts. A useful example is a healthy local origin and an expected CNAME, but no active connector information. That pattern keeps the focus on the connector process and its named-tunnel credentials.

Another example is a healthy local origin, connector information, and CNAME, but an unexpected public result. Do not jump straight to disabling TLS verification, exposing the origin, or changing Access. Re-run the same checks, note the timestamp and timezone, and collect a diagnostic archive. The difference between a repeatable result and an intermittent one matters to whoever investigates next.

cloudflared tunnel cleanup may remove old connection records when there are other run problems. It is not a default repair step. Collect diagnostic evidence before using it so that cleanup does not replace the information you needed to understand the failure.

What not to do

• Do not use --no-tls-verify as a generic fix. It disables verification of the certificate presented by the local origin and permits any origin certificate. The CLI also states that this does not weaken the machine-to-Cloudflare-edge connection. Use it only when you have a specific local-origin certificate test to make, not to hide an unexplained failure.
• Do not expose the local origin publicly to test faster. That creates a different network path and a different security surface. It does not prove that the tunnel configuration is correct.
• Do not paste tunnel credentials, tokens, or a raw diagnostic archive into chat or a public issue. Sanitize configuration excerpts and review any archive before sharing it.
• Do not enable debug logging by default. The CLI warns that debug logging can record request URLs, methods, protocols, content lengths, and request and response headers. Those can expose sensitive data. If a narrow investigation requires it, review and redact the output before it leaves the machine.
• Do not change an Access policy only because a public request is unexpected. Access can intentionally protect a hostname. Confirm whether that protection is expected before making a policy change.

When to escalate

Escalate after you have checked each layer and can state what is known. A useful report includes:

• cloudflared --version output
• The local-origin check and the address/port it tested
• cloudflared tunnel list and cloudflared tunnel info <TUNNEL_NAME> output
• dig CNAME <HOSTNAME> output
• The public curl -sS -I https://<HOSTNAME>/ result
• The hostname, tunnel name, timestamp, and timezone
• A sanitized configuration excerpt, with credentials and tokens removed
• A locally reviewed diagnostic archive from cloudflared tunnel diag

Keep raw debug logs private until they have been inspected and redacted. Include the exact observation instead of a conclusion such as “DNS is broken.” That gives the next operator something they can verify.

Sources

Official documentation

• Cloudflare Tunnel troubleshooting
• Cloudflare Tunnel local management
• Cloudflare Tunnel get started

Official source repository

• cloudflared GitHub repo

Last verified

Last verified July 10, 2026 against cloudflared 2026.5.2 on Linux and the official URLs above. Re-run cloudflared --version and compare the current official documentation before following a command after an upgrade. If the version you are running differs from the one listed here, include that difference in any escalation.

See also

• Source notes for this guide — claim audit, evidence, and reviewer-driven revisions.

Accuracy note

This guide was written by MiniMax M3 via the abs-guides-cron-pipeline skill and fact-checked against the live CLI and the official documentation above. The full source-notes audit and editorial review is at the Source notes page.