Cloudflare Tunnel is the best way to expose a local LLM to the internet. It is also a black box that will waste your afternoon if you do not know what to look for. I have been running tunnels for four months, and I have collected six distinct failure modes — each one cost me real time, each one had a simple fix, and each one was completely non-obvious from the error message.
This is the companion to my setup guide: what happens after you follow the instructions and things still break. I will show you the exact error, what I tried that did not work, and what actually fixed it. Every issue has a "time wasted" counter because I think it is important to be honest about how long these things take.
Running total before we start: zero. Let's see where we end up.
Error 1: "Failed to create quic connection"
Time wasted: 35 minutes
I installed cloudflared, ran cloudflared tunnel run local-llm, and got this:
ERR Failed to create quic connection error="failed to dial to edge with quic: timeout: no recent network activity"
INF Retrying connection in up to 2s secondsThe tunnel retried forever. I checked status.cloudflare.com — green. I checked my connection — 800 Mbps. I restarted my router. Nothing changed. I tried --protocol http2. Same error. I read GitHub issues about IPv6 blocking. I checked UFW rules and Pi-hole blocklists. Nothing was blocked.
The actual fix: the error is not about your firewall — it is about DNS resolution. cloudflared needs to resolve region1.v2.argotunnel.com. If your DNS returns an IPv6 address and your network does not route IPv6, the connection times out. The QUIC library tries IPv6 first, fails, and the IPv4 fallback sometimes does not happen fast enough.
I forced IPv4:
cloudflared tunnel run --edge-ip-version 4 local-llmIt connected instantly. I later moved edge-ip-version: 4 into config.yml. The lesson: "timeout: no recent network activity" means DNS gave cloudflared an address it could not reach. IPv6 is the most common culprit.
Error 2: Tunnel Shows Healthy but Requests Timeout
Time wasted: 52 minutes
The tunnel was running. cloudflared tunnel info local-llm showed "Healthy." But visiting https://llm.yourdomain.com produced a 30-second spin followed by a 502 or a straight timeout. The behavior was inconsistent — about one in five requests would return the 502. The rest hung indefinitely.
I checked the cloudflared logs. They showed the tunnel receiving and forwarding the request. No errors. But the "request finished" line never appeared for hung requests. I checked nvidia-smi — vLLM running, GPU idle. I curled http://localhost:8000/v1/models from the server itself. Instant response. The local service was fine.
I tried --log-level debug. The tunnel opened a connection to localhost:8000, then silence. I restarted vLLM and cloudflared, changed the ingress to http://127.0.0.1:8000. No change.
The actual problem: vLLM was bound to 127.0.0.1 only, and cloudflared was connecting over IPv6 loopback ::1 because my system preferred IPv6. glibc resolved "localhost" to ::1 first. vLLM was not listening on ::1. The connection hung until timeout. The intermittent 502s happened when the IPv4 fallback kicked in fast enough.
The fix was to tell vLLM to listen on all interfaces:
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen3-7B-Instruct \
--host 0.0.0.0 \
--port 8000Then I updated the tunnel config to use the explicit IPv4 address:
ingress:
- hostname: llm.yourdomain.com
service: http://127.0.0.1:8000Every request went through instantly. The lesson: "localhost" is not your friend in a dual-stack environment. Be explicit about 127.0.0.1 or bind to 0.0.0.0. The tunnel health check only verifies that cloudflared can reach Cloudflare's edge. It says nothing about whether cloudflared can reach your local service.
Error 3: 502 Bad Gateway — Service Crashed or Wrong Port
Time wasted: 18 minutes
I was testing a new model and had started vLLM on port 8001 instead of 8000. I forgot to update the tunnel config. The browser showed:
502 Bad Gateway
cloudflare-nginxI checked cloudflared tunnel info. Healthy. The raw log at /var/log/cloudflared.log showed:
ERR error="Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared"Once I found that line, the fix was obvious: move vLLM back to 8000 or update the tunnel config. I also learned cloudflared caches the ingress config — editing config.yml requires a full restart:
sudo systemctl restart cloudflaredError 4: Certificate Errors in the Browser
Time wasted: 41 minutes
I visited https://llm.yourdomain.com and Chrome showed:
NET::ERR_CERT_AUTHORITY_INVALID
This server could not prove that it is llm.yourdomain.comThe weird part: Safari on my phone loaded fine. Firefox on my laptop loaded fine. Only Chrome complained. The certificate details showed it was issued by "Cloudflare Origin CA," not the usual DigiCert or Let's Encrypt.
I spent 20 minutes toggling SSL/TLS settings between "Full (strict)," "Full," and "Flexible." I purged the Cloudflare cache. I flushed local DNS. I deleted Chrome's SSL state from chrome://net-internals/#ssl. Nothing helped.
What I had done: I created a Cloudflare Origin certificate and installed it on a local nginx reverse proxy. The origin cert was valid for my domain, but not trusted by my macOS certificate store. Chrome uses the system keychain. Safari and Firefox handled the Cloudflare Origin CA differently.
The fix was switching SSL/TLS encryption mode to "Full" instead of "Full (strict)." "Full" mode encrypts between Cloudflare and the origin but does not validate the origin certificate. Since the traffic never leaves Cloudflare's network, this is still secure.
The real lesson: if you are using Cloudflare Tunnel, you do not need an origin certificate at all. The tunnel itself is the secure transport. Adding nginx with TLS is unnecessary complexity. I removed nginx and let cloudflared talk directly to vLLM.
Error 5: DNS Propagation Taking Forever
Time wasted: 47 minutes
I created the tunnel, ran cloudflared tunnel route dns local-llm llm.yourdomain.com, and waited. The command succeeded. The dashboard showed the CNAME. But the browser returned:
DNS_PROBE_FINISHED_NXDOMAINI checked with dig:
$ dig llm.yourdomain.com
;; ANSWER SECTION:
llm.yourdomain.com. 300 IN CNAME <tunnel-uuid>.cfargotunnel.com.The CNAME was there. But resolving the target cfargotunnel.com returned NXDOMAIN from some resolvers. Google DNS (8.8.8.8) worked. My ISP's DNS failed. Cloudflare's resolver (1.1.1.1) worked. The problem was that my router used my ISP's DNS, which had not cached the new CNAME target.
I flushed my local DNS cache and switched my laptop to 1.1.1.1. That worked, but my phone still failed because it uses the router's DNS. I waited. That was the actual fix.
DNS propagation is not a technical problem you solve — it is a distributed system problem you endure. The TTL was 300 seconds, but some resolvers ignore TTLs. My ISP's DNS took 47 minutes. There is no command to force it.
What I do now: test with dig @1.1.1.1 immediately. If that works, the rest is waiting. I also lower the TTL to 60 seconds before DNS changes, then raise it back to 300 after.
Error 6: Tunnel Randomly Disconnecting
Time wasted: 1 hour 23 minutes
This was the worst one because it was intermittent. The tunnel would run fine for hours, then disconnect without warning. The cloudflared process was still running. Systemd showed "active (running)." But cloudflared tunnel info showed "Down" and requests failed with 502.
The logs showed nothing useful at INFO level. At DEBUG level, I saw periodic "heartbeat" messages that just stopped. No error. No crash. The connection went silent.
I suspected my ISP was dropping idle UDP connections. I tried --heartbeat-interval 5s. It did not help. The systemd service had Restart=on-failure. When the tunnel silently dropped, cloudflared did not exit with a failure code — it just hung. systemd only restarts on failure. A hung process is not a failed process. The tunnel stayed down until I manually restarted it.
I fixed it with a systemd override:
sudo systemctl edit cloudflared
[Service]
WatchdogSec=30
Restart=always
RestartSec=10
StartLimitInterval=0WatchdogSec=30 tells systemd to expect a keepalive every 30 seconds. If it does not arrive, systemd kills and restarts the service. Restart=always restarts on any exit, not just failures. StartLimitInterval=0 removes the rate limit so systemd does not give up.
I also added a cron job:
*/5 * * * * /usr/bin/cloudflared tunnel info local-llm | grep -q "Healthy" || sudo systemctl restart cloudflaredBetween the watchdog and the cron check, the tunnel has been stable for three months. It still drops occasionally, but recovers within 30 seconds. The lesson: systemd defaults are designed for well-behaved daemons. Network tunnels are not well-behaved. You need aggressive restart policies and health checks.
The Final Tally
Let's add it up:
- QUIC connection failure: 35 minutes
- Healthy tunnel, timeout requests: 52 minutes
- 502 from wrong port: 18 minutes
- Certificate mismatch: 41 minutes
- DNS propagation: 47 minutes
- Random disconnections: 83 minutes
Total time wasted: 4 hours 36 minutes.
That is a full afternoon of debugging that could have been avoided if I had known these six patterns in advance. Cloudflare Tunnel is marketed as "zero configuration." It is — for the simple case. Behind a residential ISP with dual-stack networking and systemd services, it is very much not zero configuration. Here is what I do differently now:
- Always set
edge-ip-version: 4in the config - Always bind local services to
0.0.0.0and point the tunnel at127.0.0.1 - Always restart cloudflared after editing config.yml
- Never add TLS between cloudflared and the local service — the tunnel is enough
- Always test DNS with
dig @1.1.1.1and wait patiently for propagation - Always configure systemd with
Restart=alwaysand a watchdog
Cloudflare Tunnel is still the right tool for exposing local AI services. I would not go back to port forwarding or VPNs. But I no longer expect it to "just work" — I expect it to work after I have configured it properly. If you are setting up your first tunnel, budget an extra hour for debugging. Read this article first. Save yourself the 4 hours and 36 minutes I spent earning these lessons.