HomeLabFix

Cloudflare Tunnel / Troubleshooting

Cloudflare Tunnel Is Connected but the Public Hostname Returns 502: Unable to Reach Origin Service

Confirm the tunnel is connected and the visitor sees the tunnel-specific 502 Unable to reach the origin service, then match the exact cloudflared log signature to a stopped origin, a wrong ingress scheme, a wrong ingress port, or an untrusted origin certificate.

The official Cloudflare Tunnel common-errors reference defines the boundary precisely: a 502 Bad Gateway response with Unable to reach the origin service on a tunnel route means the tunnel itself is connected to the Cloudflare network, but cloudflared cannot reach the origin service defined in the ingress rule. An error 1033 instead means the tunnel is not connected to Cloudflare at all, which is a different observation with its own procedure.[1]

The same reference states that the tunnel status (Healthy, Inactive, Down, Degraded) only reflects the connection between cloudflared and the Cloudflare network, not whether cloudflared can reach internal services. A tunnel can therefore appear Healthy while visitors still cannot reach the application. The general Cloudflare 502/504 documentation separately distinguishes origin-generated errors from Cloudflare-generated errors; an ordinary 502 produced by the origin itself is not this diagnosis.[1][3]

Applicability

Products
Cloudflare Tunnel
Scope
For an HTTP or HTTPS application published through a Cloudflare Tunnel route where the tunnel is connected and serving traffic, and the visitor receives the tunnel-specific 502 Bad Gateway response stating that cloudflared cannot reach the origin service. The installed cloudflared release must be current; the official troubleshooting page instructs upgrading cloudflared before investigating further. This page does not cover a tunnel that is not connected (error 1033), ordinary origin-generated 502 responses, redirect loops, Access-policy denials, DNS record problems, or non-HTTP tunnel routes.[1][2][3]
Last verified

Symptoms

  • The public hostname served through the tunnel route returns HTTP 502 Bad Gateway with the message that the origin service cannot be reached, while the tunnel reports a connected status (Healthy or Degraded) in the dashboard or in cloudflared tunnel list output. A 1033 response, a branded origin-generated 502 page, or a tunnel that never connects is a different observation.[1]

Quick diagnosis

Confirm the tunnel is connected and the response is the tunnel-specific 502 before matching the exact cloudflared log signature. A 1033 or an ordinary origin 502 is a different observation.

Read-only

Confirm the tunnel is connected

Check the tunnel connection status in the Cloudflare dashboard under Networking, Tunnels, or run cloudflared tunnel list. The official reference lists Healthy, Inactive, Down, and Degraded states and their meanings; only a connected tunnel (Healthy, or Degraded while still serving) keeps this page applicable. An Inactive, Down, or 1033 state needs the tunnel-connectivity procedure instead.[1]

cloudflared tunnel list
Read-only

Capture the exact 502 response text

Record the full visitor-facing response, including whether it states that the origin service cannot be reached or may not be responding to traffic from cloudflared. That wording separates this diagnosis from an ordinary origin-generated 502 and from error 1033. Do not proceed on a remembered paraphrase of the error.[1][3]

Read-only

Do not change the ingress rule, origin service, or TLS settings before classification

Do not edit the tunnel ingress rule, restart the origin service, or change origin TLS settings before confirming the tunnel status and the exact log signature. A change made before classification can hide which of the four documented origin-side boundaries actually failed.[1]

Interactive troubleshooter

Your answers stay in this browser tab. The tool does not connect to your systems or send diagnostic results.

Guided check / step 1

Safe diagnostic guidance

Does the public hostname show the tunnel-specific 502 Unable to reach the origin service?

Confirm the exact visitor response states that the origin service cannot be reached or is not responding to traffic from cloudflared. An error 1033, an ordinary origin-generated 502, a redirect loop, or an Access denial is a different observation.[1][3]

Read the complete diagnostic tree without using the controls
  1. Does the public hostname show the tunnel-specific 502 Unable to reach the origin service?

    Confirm the exact visitor response states that the origin service cannot be reached or is not responding to traffic from cloudflared. An error 1033, an ordinary origin-generated 502, a redirect loop, or an Access denial is a different observation.[1][3]

    • Yes, the tunnel-specific 502 → Is the tunnel connected and serving traffic?
    • No, a different response or error → Investigate the actual tunnel or origin observation
  2. Is the tunnel connected and serving traffic?

    Check the dashboard tunnel status or cloudflared tunnel list. A Healthy tunnel, or a Degraded tunnel that still serves, keeps this page applicable. The status only reflects the cloudflared-to-Cloudflare connection, never origin reachability.[1]

    • Yes, Healthy or serving Degraded → Which error signature appears in the cloudflared tunnel logs?
    • No, 1033, Inactive, or Down → Investigate the actual tunnel or origin observation
    • Tunnel status is unclear → Collect a tunnel 502 evidence packet
  3. Which error signature appears in the cloudflared tunnel logs?

    Match the error-level log line exactly: a dial tcp connection refused line, a malformed HTTP response line with TLS-record bytes, or an x509 certificate line. Each signature selects a different documented branch.[1]

    • connection refused → What does the local check of the origin service show?
    • malformed HTTP response → Correct the ingress scheme to match the origin protocol
    • x509 certificate error → Fix origin certificate validation with originServerName or caPool
    • No matching signature → Collect a tunnel 502 evidence packet
  4. What does the local check of the origin service show?

    Run the local origin request and the socket listing, then observe rather than infer. If the local request fails and nothing listens on the expected port, the origin is stopped or not listening. If the application listens on a different port, the ingress points at the wrong port. If a listener exists on the expected port or the observed behavior matches neither documented signature, do not force a cause.[1]

    • No listener on the expected port and the local request fails → Start the stopped origin service
    • The application listens on a different port → Correct the ingress port to the bound port
    • Listener on the expected port, or behavior matches neither signature → Collect a tunnel 502 evidence packet
  5. Start the stopped origin service

    Start or restart the origin application on its documented port, verify locally that it answers and listens, then retest the public hostname. The tunnel configuration does not change on this branch.[1]

  6. Correct the ingress scheme to match the origin protocol

    Change the ingress service URL scheme to the protocol the origin actually serves, as proven by the local request. This corrects only the ingress addressing mismatch; it does not change the origin itself.[1]

  7. Correct the ingress port to the bound port

    Change the ingress service URL port to the port the application is actually bound to, as proven by the socket listing. Retest the public hostname after the correction.[1]

  8. Fix origin certificate validation with originServerName or caPool

    For a hostname mismatch, set originServerName to the certificate hostname; for an unknown authority, supply the CA with caPool or the system trust store. These are the documented fixes; noTLSVerify is only a last-resort vendor note and is not presented here as a resolution.[1]

  9. Investigate the actual tunnel or origin observation

    A 1033 response or a Down tunnel needs the tunnel-connectivity procedure. An ordinary origin-generated 502 needs the origin application's own investigation, guided by the general 502/504 documentation. Redirect loops, Access denials, DNS problems, and non-HTTP routes each need their own diagnosis.[1][3]

  10. Collect a tunnel 502 evidence packet

    Preserve the exact visitor response, the tunnel status, the cloudflared version, the management mode, the ingress service URL, the local origin verification result, and the full error-level log lines. Send the sanitized evidence to the operator; no documented procedure removes a 502 without a matching signature.[1][2]

Detailed diagnosis

Read-only

1. Classify connected tunnel versus disconnected tunnel

Match the observed state against the documented status table. A Healthy tunnel is active and serving; a Degraded tunnel still serves traffic while at least one connection has failed. Either keeps this page applicable. An Inactive or Down tunnel, or an error 1033 response, means Cloudflare cannot find a healthy cloudflared instance and belongs to the tunnel-connectivity procedure, not this page.[1]

Read-only

2. Read the cloudflared tunnel logs and match the exact error signature

Review the tunnel logs for error-level messages. The official reference assigns each origin-side failure a distinct signature: a dial tcp connection refused message means the origin is not accepting connections; a malformed HTTP response containing TLS-record bytes means the ingress scheme does not match the origin protocol; a connection refused message naming a specific port means the ingress port does not match the bound port; an x509 message means the origin certificate cannot be validated. Match the observed line before choosing a branch.[1]

Read-only

3. Verify the origin answers on the cloudflared host itself

From the cloudflared host, request the origin exactly as the ingress rule addresses it and confirm which port actually listens. The official reference resolves a stopped origin by verifying the service with a local request and confirming the listener with the platform socket listing. A local success proves the fault is in the ingress addressing or TLS handling, not in the origin process.[1]

curl -v <scheme>://<origin-host>:<origin-port>
ss -tlnp | grep <origin-port>
Read-only

4. If the signature is x509, collect the certificate evidence before any TLS change

When the log signature is a certificate failure, record whether the message reports a hostname mismatch (certificate valid for a different name) or an unknown authority, and record the service URL scheme in the ingress rule. The official reference resolves these with originServerName, a caPool file, or the system trust store. noTLSVerify is described by Cloudflare only as a last resort and is not part of the normal remediation path; this page treats it as out of scope for fixes. No TLS setting changes during evidence collection.[1]

Supported scenarios

These observations narrow the next investigation; they do not establish a unique cause.

The origin service is stopped or never started

The official reference shows a dial tcp connection refused log line for an origin that is not accepting connections on the ingress address. The tunnel stays connected because tunnel status does not reflect origin reachability.[1]

How to check: Confirm the refused address and port in the log match the ingress rule, then confirm locally whether the service answers and listens on that port.[1]

The ingress service URL uses the wrong protocol scheme

The official reference shows a malformed HTTP response log line containing TLS-record bytes when the origin expects HTTPS but the tunnel route specifies http, or vice versa. The origin is running; the ingress addressing disagrees with it.[1]

How to check: Compare the ingress service URL scheme with the protocol the origin actually serves, as proven by a local request to the origin.[1]

The ingress service URL points at the wrong port

The official reference states that a connection refused error naming a specific port means the tunnel route port does not match the port the service is bound to. The service may be healthy on a different port.[1]

How to check: Compare the port in the ingress rule against the port the application is actually bound to on the origin host.[1]

cloudflared cannot validate the origin certificate

The official reference shows x509 log lines for a certificate that does not cover the service hostname, or for a certificate authority cloudflared does not trust. The documented resolutions are originServerName, a caPool file, or the system trust store; noTLSVerify is described by Cloudflare only as a last resort, not as a normal fix.[1]

How to check: Distinguish a hostname-mismatch message from an unknown-authority message in the log, and record the ingress scheme before any TLS change.[1]

Next actions and procedure boundaries

Potentially disruptive

Stopped origin: start the origin service on its documented port

Start or restart the origin application on the port the ingress rule addresses, then verify locally that the service answers and listens before retesting the public hostname. The official reference resolves this branch by starting the service and confirming the listener; it does not change the tunnel configuration.[1]

Before changing anything

Risk
Restarting the origin application interrupts whatever that application serves. Confirm the correct service and host before restarting; a restart on the wrong host does not fix the tunnel route.[1]
Safer check
Confirm the refused address and port in the cloudflared log match this origin service, and confirm the tunnel itself is connected so the restart is aimed at the proven boundary.[1]
Expected result
After the restart, the origin answers the local request and the socket listing shows the bound port; the public hostname then returns the application instead of the tunnel 502.[1]
Backup / recovery access
Record the current service state, the ingress service URL, and the log signature before restarting. Preserve the application configuration so the previous state can be restored.[1]
Rollback
If the application misbehaves after the restart, restore its previous configuration and startup state from the recorded values, then re-collect the cloudflared log before further changes.[1]
Potentially disruptive

Wrong scheme or port: correct the ingress service URL to match the origin

Edit the tunnel route so the ingress service URL uses the protocol the origin actually serves and the port the application is actually bound to, matching the locally verified origin. For locally managed tunnels this is the ingress rule in the configuration file; the official reference instructs updating the service URL to the expected protocol as the resolution for the scheme branch.[1]

Before changing anything

Risk
Editing the ingress rule changes what the public hostname reaches. An incorrect edit can move the outage from a 502 to the wrong backend instead of fixing it.[1]
Safer check
Prove the origin protocol and bound port with a local request and socket listing first. Record the current ingress service URL before editing.[1]
Expected result
After the correction, the ingress URL and the locally proven origin address agree, and the public hostname returns the application instead of the tunnel 502.[1]
Backup / recovery access
Record the full current ingress rule, including hostname, service URL, and any originRequest settings, before changing it.[1]
Rollback
Restore the recorded prior ingress service URL if the public hostname does not recover, then re-collect the cloudflared log before further changes.[1]
Potentially disruptive

Certificate validation failure: set originServerName or supply the CA pool

HomeLabFix presents originServerName, caPool, or the system trust store as the normal remediation paths: for a hostname-mismatch signature, set originServerName to the hostname on the origin certificate in the tunnel route; for an unknown-authority signature, provide the CA certificate with caPool, or add the CA to the system trust store and restart cloudflared, as documented. Cloudflare also documents noTLSVerify as a last-resort option that is not recommended for production environments, but HomeLabFix does not present disabling certificate verification as a normal fix and gives no procedure for enabling it.[1]

Before changing anything

Risk
TLS trust changes affect how cloudflared authenticates the origin. A wrong trust change can either keep the outage or silently weaken origin authentication.[1]
Safer check
Confirm the exact x509 signature (hostname mismatch versus unknown authority) and record the current originRequest settings before changing them.[1]
Expected result
After the correction, the x509 log lines stop and the public hostname returns the application over the verified origin certificate.[1]
Backup / recovery access
Record the current originRequest block and the presented certificate details before changing trust settings.[1]
Rollback
Restore the recorded prior originRequest settings if validation still fails, then re-collect the cloudflared log before further changes.[1]
Read-only

noTLSVerify is a last-resort vendor note, not a fix

Cloudflare's reference describes noTLSVerify as a last resort; it is not part of this page's normal remediation path. HomeLabFix safety policy never presents disabling TLS verification as a fix: the normal remedies are originServerName, caPool, or the system trust store. If an operator separately chooses to use noTLSVerify during diagnosis, it must be reverted to the verified trust settings immediately afterwards. That revert requirement is HomeLabFix safety policy, not a Cloudflare instruction.[1]

Read-only

If no documented signature matches: preserve the evidence

Record the exact visitor response, the tunnel status, the cloudflared version from cloudflared --version, whether the tunnel is locally or remotely managed, the ingress service URL, the local origin verification result, and the full error-level log lines. Send the sanitized evidence to the operator; the official references describe no procedure for a 502 without a matching documented signature.[1][2]

cloudflared --version

Warnings and boundaries

Do not confuse this diagnosis with error 1033: 1033 means the tunnel is not connected to Cloudflare, while the tunnel-specific 502 means the tunnel is connected and cloudflared cannot reach the local origin. Each has its own documented procedure.[1]
Do not copy an ordinary origin-generated 502 procedure onto a tunnel route. The general 502/504 documentation distinguishes origin-generated errors from Cloudflare-generated errors; only the tunnel-specific Unable to reach the origin service response belongs on this page. For certificate failures, use originServerName, caPool, or the system trust store; noTLSVerify is a last-resort vendor note, and this site never presents it as a fix.[1][3]

Sources

Links were reviewed on 2026-09-07. Reachability and automated validation do not replace editorial verification of each claim.

  1. Common errors (Cloudflare Tunnel)
    Cloudflare · Tier A · accessed 2026-09-07
  2. Troubleshooting (Cloudflare Tunnel)
    Cloudflare · Tier A · accessed 2026-09-07
  3. Error 502 or 504
    Cloudflare · Tier A · accessed 2026-09-07