Turkey (Turkish)
Germany (German)
Worldwide (English)
A Cloudflare Tunnel can show Healthy while users receive 502; in that case the connector is connected to Cloudflare but cloudflared cannot reach the local origin.
Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
Diagnose Cloudflare Tunnel x509, unknown authority and 502 origin TLS errors using originServerName, caPool, protocol/port and cloudflared logs.
A Cloudflare Tunnel can show Healthy while users receive 502; in that case the connector is connected to Cloudflare but cloudflared cannot reach the local origin.
Cloudflare documents `originServerName` for cases where the origin certificate hostname differs from the service URL hostname.
For private/self-signed CAs, Cloudflare documents custom CA trust through `caPool`; `noTLSVerify` is not the recommended first production fix.
Cloudflare Tunnel 1033 means Cloudflare cannot find a healthy connector for the tunnel. A 502 can occur while the connector is online but cloudflared cannot reach the configured local service. Therefore Healthy plus 502 is not contradictory.
This determines the path: for 1033 inspect connector process, network and credentials; for 502 inspect service URL, port, protocol and origin TLS.
cloudflared tunnel info TUNNEL_ADIsystemctl status cloudflaredIf config says `service: https://localhost:8443`, test that exact address from the same host or network namespace where cloudflared runs. Inside Docker, localhost refers to the container itself, not the host.
With containerized cloudflared, it may need to share a Docker network with the reverse proxy and use the service/container name. Tunnel health does not prove origin routing inside Docker is correct.
curl -vk https://localhost:8443/docker network lsdocker inspect cloudflaredIf the origin speaks plain HTTP on port 8080 but config uses `https://localhost:8080`, cloudflared expects TLS and can report malformed responses or connection errors. The reverse mismatch is also invalid.
Do not infer protocol only from the port number. Use local curl tests to identify what the service actually speaks.
curl -v http://localhost:8080/curl -vk https://localhost:8443/If the certificate is for app.internal.example.com but the service URL is https://localhost:8443, hostname validation fails. Cloudflare documents `originServerName` to specify the hostname expected by the certificate.
This does not disable certificate identity validation; it tells cloudflared which hostname to validate. It is a stronger production approach than turning off TLS verification.
cloudflared tunnel ingress validate`x509: certificate signed by unknown authority` is different from a hostname mismatch. The name can be correct while cloudflared does not trust the issuing private CA. Cloudflare supports a custom CA bundle path through `caPool`.
The CA bundle should contain the correct root/intermediate chain in PEM form and be readable by the cloudflared process/container. In Docker, a host path is not enough; the file must be mounted into the container.
openssl verify -CAfile /etc/cloudflared/origin-ca.pem origin-cert.pemCloudflare exposes TLS verification bypass as an option but positions it as a last resort rather than the preferred production configuration. Disabling verification weakens origin identity protection.
The durable fix is a certificate for the correct hostname, `originServerName`, or trusted private CA through `caPool`. If a bypass is ever used diagnostically, document the reason and rollback plan.
After editing YAML, validate ingress rules, restart the service and inspect logs. A misplaced catch-all rule can route the hostname to a different origin even when TLS settings are correct.
If x509 errors disappear but 502 remains, move to TCP connectivity, protocol/port and application-response diagnosis. Continue layer by layer rather than forcing one hypothesis.
cloudflared tunnel ingress validatejournalctl -u cloudflared -n 200 --no-pager| Symptom | Priority |
|---|---|
| Error 1033 | Is a healthy connector connected to Cloudflare? |
| Healthy + 502 | cloudflared → local origin access |
| x509 valid for X not Y | originServerName / certificate hostname |
| x509 unknown authority | Private CA trust / caPool |
Before production changes, verify context and keep backups and a rollback plan. Do not change several DNS, TLS, recovery, Docker or WordPress variables at once because it obscures the root cause.
No. Healthy can mean the connector reaches Cloudflare while cloudflared still cannot reach the local origin.
It is not the preferred production solution. Configure the correct certificate/hostname or trust the private CA.
Inside a container, localhost refers to that container. Use the correct shared network and service name/IP for another container or host.
If the problem persists in hosting, VPS, Docker, Cloudflare, Windows or WordPress infrastructure, open a technical support request with the exact error output and current architecture.