Cloudflare Tunnel shows “Healthy” but your application gets no traffic

Your tunnel status is green. Yet visitors cannot reach the application, an API returns errors, or requests stop appearing in the application log. A useful first step is to compare three things: what happens when you make a public request, what each connector sees, and what reaches the service behind it.

Cloudflare describes tunnel status as a measure of the connection between cloudflared and the Cloudflare network. It does not establish whether the application behind the tunnel is reachable. This distinction helps you narrow down the outage before changing configuration. Q2

How to recognize this problem

This guide is particularly relevant when several of these observations occur together:

• The tunnel looks healthy in the dashboard or your monitoring system.
• A known public application path returns an error or no usable response.
• Your application is not receiving the expected requests, or only some connectors are still handling traffic.
• The connector log shows repeated disconnections, while the connection count appears normal.
• The service was previously reachable, but monitoring and actual use have disagreed since a particular point in time.

First, record which operation is actually failing. Is a customer unable to open a document? Is an API request failing to reach its destination? Or is only a monitoring page reporting an error? This determines what should count as a successful functional test later. A successful check of one endpoint does not yet prove that login or file processing works.

A public production incident report describes this kind of discrepancy with cloudflared 2026.8.2, Kubernetes and QUIC: connection indicators continued to look normal while the affected connectors handled almost no requests. The report describes an observed incident; its author could not reproduce the original trigger on demand. It does not establish a general defect affecting every tunnel that reports healthy. Q1

Which possible causes need to be distinguished

A tunnel can be connected to Cloudflare while still being unable to reach the local service. For a tunnel 502 error containing Unable to reach the origin service, Cloudflare identifies the connection to the origin as the area to investigate. A 1033 calls for a different check of tunnel availability and routing. The exact error message is therefore more useful than simply saying that the service does not work. Q3

Other questions concern the destination that is actually configured: are the protocol, port and hostname correct? Can the connector reach that service from its own runtime environment? For HTTPS, the certificate name and chain of trust also need to match. A successful request from your laptop does not answer those questions for a different host or container. Q4

Safe first steps: seven checks to narrow it down

1. Choose one harmless test request. Use an existing path that only reads data and does not place orders, send messages or make other changes. Record the expected status and an identifiable feature of the response. If the application requires a login, use your normal authorized access and keep access controls in place. Do not use a real customer action as a repeatedly runnable test.

2. Record when the public request fails. Note the full hostname, path without confidential parameters, time and time zone, response status and a short error message. Also record whether every user is affected or only a particular way of accessing the service. Do not share cookies or Authorization headers. A screenshot of a green tunnel status is not enough to correlate the failure.

3. Map the route to the application. Record the public hostname, tunnel, connector or pod, and configured origin service together. Read the existing route from your administration interface. If another route is still working, compare it with the affected one. Do not copy its values without checking: two applications may intentionally use different protocols or ports.

4. Test the origin from the correct environment. An administrator should run the same read-only test from the connector’s environment against the destination actually configured. In a container, localhost may refer to a different environment from the host. For HTTPS, use the correct server name and normal certificate verification as part of the test. The official HTTPS guide explains how to check the public request and the origin separately. Q4

5. Compare evidence from the same time window. Put the public test time, connector log and any available application log side by side. Does the connector have a matching message at the test time? Can you identify the request at the origin? Is there a response from the origin? Empty logs are meaningful only if the relevant logging is actually enabled and you are looking at the right system. Initially, treat an entry you cannot find as missing evidence.

6. Distinguish individual connectors. If metrics are already being collected, compare connections, requests and errors for each connector over the same period. Cloudflare documents metrics including cloudflared_tunnel_ha_connections, cloudflared_tunnel_total_requests and cloudflared_tunnel_request_errors. A single counter reading does not replace that comparison. Q2 Before interpreting the values, check whether the process restarted between readings. Low traffic may also simply mean low demand; the controlled request gives you a known event to look for.

7. State the finding clearly and identify who should investigate next. For example: “The public test fails; the same origin is reachable from the connector’s environment; no matching requests are visible on the connector being examined.” Or: “The connector logs a certificate error when connecting to the origin.” These observations support a targeted next step. If a recovery action is needed, agree on who is responsible, how to reverse it and how to verify the result. Restarting every component makes comparison harder and may interrupt access that is still working.

How to verify that the service is working again

Define the acceptance criteria before making a change. The public request that previously failed must return the expected response. A responsible user should also test the affected business operation with harmless test data. If there are multiple connectors, evaluate the available observations for each one separately. Repeat the checks over a period appropriate to the incident, and record the start and end times.

A green indicator alone is not enough. Equally, one successful response does not prove that an intermittent fault has disappeared. The verification record should state what was actually tested and which parts of the process remain unverified.

Frequently asked questions

Does “Healthy” mean that the entire website is reachable?

The status describes the tunnel connection. The application behind it needs a separate check. For your operation, you also need a test that verifies an expected response from the application you actually depend on. Q2

Is every failure with a green tunnel status the same Cloudflare bug?

No. The reported production incident has a specific set of symptoms. An incorrect origin port, a certificate problem or a route pointing to the wrong destination needs to be distinguished using evidence from your own environment. The title of a similar issue does not replace that diagnosis. Q1 Q3 Q4

Should I immediately restart all pods or the tunnel?

First, preserve the evidence you can observe and establish who is responsible for the service. A restart can interrupt active connections and change the original state. Whether it is appropriate as a controlled recovery action depends on your redundancy, the users affected and a clear way to revert the change. This guide does not prescribe a general restart.

Can I disable certificate verification as a test?

The diagnostic approach here keeps it enabled. A verification failure is already useful evidence: the destination name, certificate and trust configuration need to be examined together. The HTTPS documentation explains this relationship. Q4

Is there a confirmed fix for the reported connection failure?

As of 4 November 2026, the linked pull request #1785 is open. Its author describes a test of address selection and explicitly distinguishes it from a reproduction of the original production outage. That does not establish that a fix has been released. Q5

What information is most useful when asking for help?

An exact test time, version, installation type, affected route, public error message and short, relevant log extracts. Include whether the origin was directly reachable and which operation is failing. Access keys, tunnel tokens, cookies and personal payload data do not belong in a public issue.

Where to get help

Cloudflare’s troubleshooting and observability documentation provide the technical starting points. Q2 Q3 If there is a well-supported suspicion of a defect in cloudflared, its public GitHub issue tracker is the appropriate place for the version and a sanitized account of the sequence. The existing report helps you compare the specific pattern. Q1 Questions about your own application or container environment also need the responsible operator; tunnel status cannot fully establish their condition.

Describe your issue

Do you need help narrowing down the loss of access and defining a reliable functional test? Tell KAN KAI which application is affected, when the failure started and what a public test request returns. Include the observations already collected in the seven steps. That provides a basis for determining whether the local configuration, the operating environment or a provider-side process needs further investigation, and what support would be appropriate.

Include in your request: affected operation · time and time zone · installation type and version · exact error · diagnostic results already available. A complete configuration or access credentials are not needed for this initial description.