Why Your Cloudflare Tunnel Randomly Drops (and How to Fix It for Good)

Jul 22, 2026

You set up a Cloudflare Tunnel months ago to expose a service from your homelab. It worked flawlessly, you forgot about it, and life was good. Then one day someone messages you: “Your site’s down.” You check the box and everything looks fine: the service is running, the machine is up, nothing in the logs screams disaster. By the time you finish poking around, it’s mysteriously working again.

If that sounds familiar, you’re almost certainly looking at a stale cloudflared install dropping its edge connections. This guide explains why it happens and how to fix it properly, so you stop getting those “is it down again?” messages.

The Symptom: “No recent network activity”

The tell-tale sign lives in the tunnel’s own logs. Pull them up with journalctl:

sudo journalctl -u cloudflared --no-pager -n 50

If the tunnel has been dropping, you’ll see clusters of lines like this, often hitting all four edge connections at once:

ERR Connection terminated error="timeout: no recent network activity"
INF Retrying connection in up to 2s
INF Registered tunnel connection connIndex=0 ...
INF Registered tunnel connection connIndex=1 ...

What’s happening: cloudflared keeps four persistent connections open to Cloudflare’s edge. When the underlying QUIC connections go quiet for too long (a brief network blip, an idle NAT table entry on your router timing out, or a bug in an older build), the tunnel tears them down and reconnects. During that reconnect window, which can last anywhere from a few seconds to a couple of minutes, your service is unreachable from the outside. Locally it looks perfect, which is exactly why this one is so annoying to diagnose.

Step 1: Check What Version You’re Running

The single most common cause is an outdated binary. If you installed cloudflared a while ago (or worse, from your distribution’s default repository), you’re probably running something ancient. Check it:

cloudflared --version

Compare that against the latest release on GitHub. If you’re more than a few versions behind, that’s very likely your problem. The QUIC handling in older builds is far more prone to these “no recent network activity” drops, and newer releases have steadily improved connection resilience.

Step 2: Install From Cloudflare’s Repository (Not Debian’s)

Here’s a trap worth knowing about: many distributions ship a cloudflared package in their own repos, but it can lag the official release by a year or more. Running apt upgrade will happily tell you it’s “already the newest version” while you sit on a build that’s hopelessly out of date.

The fix is to add Cloudflare’s own apt repository so you actually track the current release. First, add the GPG key and repo:

sudo mkdir -p /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null

echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list

Then update and install (or upgrade) from it:

sudo apt-get update
sudo apt-get install --only-upgrade cloudflared   # or just: sudo apt-get install cloudflared

Restart the service and confirm the new version is live:

sudo systemctl restart cloudflared
cloudflared --version

A quick note if you’re tempted by cloudflared update: that built-in self-updater only works when you installed the binary directly. If you installed via a package manager, it will refuse and tell you to update through apt, which is exactly what we just set up.

Step 3: Confirm the Tunnel Reconnected Cleanly

After restarting, check that all four connections registered without immediately dropping:

sudo journalctl -u cloudflared --no-pager -n 20

You want to see four Registered tunnel connection lines and then quiet, with no immediate “Connection terminated” errors following them. It’s also worth confirming your service actually answers through the tunnel rather than just locally:

curl -sS -o /dev/null -w "%{http_code}n" https://your-hostname.example.com/

A 200 (or whatever your app normally returns) confirms the full path from Cloudflare’s edge to your box is healthy.

Still Dropping? Force the Tunnel Onto HTTP/2

Updating fixes the vast majority of cases. But if you’re on a flaky connection (residential internet with an aggressive router, CGNAT, or a link that genuinely goes quiet), QUIC (which runs over UDP) can still get killed by NAT timeouts. In that situation, forcing the tunnel to use HTTP/2 over TCP is a reliable workaround, since TCP connections tend to survive idle NAT entries better.

Add the protocol flag to your tunnel’s run command. If you’re running it as a systemd service, edit the unit and append --protocol http2 to the ExecStart line, or set it in your config.yml:

# In config.yml
protocol: http2

Then restart cloudflared. You’ll trade a small amount of QUIC’s efficiency for noticeably steadier connections on an unreliable link, a trade well worth making if uptime is what you’re after.

A Sensible Habit: Keep It Updated

Because the Debian/Ubuntu-shipped package lags so badly, the real long-term fix is simply making sure cloudflared comes from Cloudflare’s repo and rides along with your normal updates. Once the repo is added, a routine apt upgrade keeps you current, and these random drops largely become a thing of the past.

And that’s it. A tunnel that silently drops for two minutes at a time is one of those problems that’s maddening precisely because everything looks fine when you go to check. Nine times out of ten it’s an old binary. Update it from the right place, and your “is the site down again?” messages should finally stop.