Local 200, but tunnel access reports Hostname mismatch: Duplicati stuck on Host header

When Duplicati's Web UI is accessed through a tunnel, it reports Hostname does not match. A terminal screenshot in Jay's tweet lays out the chain very clearly. Locally, curl -I 127.0.0.1:8200 returns HTTP/1.1 200 OK, showing that the service on port 8200 is alive. But the browser errors out after going through the tunnel.

Duplicati is a backup tool, and its Web UI commonly runs on 8200 by default. It validates the Host in requests. When accessing locally via 127.0.0.1, the Host is 127.0.0.1:8200. When accessing through cftunnel's free HTTPS domain, the Host becomes the tunnel domain. That new Host is not in Duplicati's allowlist, so it rejects the request. The 'port not open' angle can be ruled out first; the local 200 already shows the problem is not with listening.

The fix in the tweet is straightforward: Web server → Allowed hostnames → *. This amounts to allowing any Host. It can quickly troubleshoot, but don't take the easy way out long-term when exposing to the public internet. If you only use one fixed tunnel domain, entering that domain is more restrictive than *.

cftunnel is an MIT-licensed internal network tunnel and reverse proxy. The startup command in the tweet is:

cftunnel quick 8200
# Tunnel ready · free https hostname

It provides a free HTTPS domain. The project is at qingchencloud/cftunnel, and the site is cftunnel.qt.cool. Tools like this make it fast to move an internal network service onto the public internet—so fast that it's easy to forget Host validation and access control. Duplicati's Allowed hostnames is the first gate. First let the request in, then decide how wide to open the gate.

A local 200 only proves the service is alive. When tunnel access reports a Hostname mismatch, first check the Host passed by the reverse proxy, then check Duplicati's allowlist. In Jay's screenshot, these two steps are already laid out side by side.