Is HTTP over ZeroTier encrypted? Check where the overlay ends

Work through these checks in order and stop at the first one that fails, because each answer changes what the next step means. The real question is narrow: does plain HTTP on a ZeroTier network travel in clear over the internet? Between two ZeroTier peers it usually does not, since the overlay encrypts that hop. That is a statement about two endpoints, though, not about every segment a request crosses. A router, a bridge or a reverse proxy moves the endpoint, and plaintext resumes on the far side of it.

Check 1: find the address the browser dials

Compare the URL with what the machine actually holds. ip -brief addr show lists the zt interface and the overlay address the network controller assigned; if the URL uses that address, the browser's socket goes into the overlay.

When the name instead resolves to a LAN address, the overlay may not be involved at all, whatever the client's status indicator suggests. ip route get 10.147.20.5 prints the interface and the source address the kernel would pick, so a zt interface there means the packet enters the overlay and your physical NIC name means it does not. Names add another layer: a record pointing at an overlay address behaves differently from one pointing at a LAN address, and a search suffix or a hosts file entry can quietly decide which one you get.

Check 2: confirm both ends are peers, not a decrypting relay

ZeroTier encrypts between peers, and where no direct path exists the packets are relayed through a root that forwards them still encrypted. zerotier-cli peers marks each peer's path DIRECT or RELAY with a latency figure. A relayed path costs round trips, not confidentiality.

What does change the answer is a member that is not really an endpoint. When the far side is a ZeroTier member routing or bridging into a physical LAN, the overlay ends at that member and the next hop is ordinary Ethernet.

Check 3: watch where the request becomes readable

On the host you believe serves the page, capture the overlay interface while you reload: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. A readable request line in that output proves the traffic arrived decrypted on that host, which is the boundary you are hunting.

Then capture on the interface facing the rest of the LAN. If the same request shows up there in clear, it left the overlay before reaching the application and every device on that segment can read it. If nothing appears on the LAN side and the page still loads, the application is terminating on the ZeroTier host itself.

Capturing loopback matters too when a reverse proxy sits in front, since a proxy that accepts HTTPS and forwards HTTP moves the boundary to its own back end.

Check 4: account for every hop behind a router or bridge

A member configured to route between the overlay and a LAN is an ordinary design and the place where most of these assumptions break. The overlay protects the browser-to-router leg and nothing after it. A bridge tells the same story through a different mechanism: the overlay and the physical segment become one broadcast domain, so a request from a bridged laptop crosses plain Ethernet even though that laptop sits on the ZeroTier network.

Trace it instead of assuming it. traceroute from the client to the service address plus the routing table on the gateway member shows whether the last hop is zt or eth.

ZeroTier also offers a trusted-path mode that can drop transport security on designated local paths for performance. A network using it does not inherit the normal encrypted-path assumption, so read the network configuration before quoting one. The protocol documentation describes both the peer encryption and that exception.

Check 5: decide what the application still has to do

Overlay membership authenticates a device to a network and says nothing about whether the service on the other end is the one you meant to reach. HTTPS answers a different question by binding a hostname to a key, so the two protections overlap without replacing each other. An authorized peer can still be the wrong service, and a compromised endpoint reads the request both before encryption and after decryption. Neither mechanism audits what the application records.

For anything with a reusable session or a password, terminate TLS at the application or at a proxy you control and leave certificate validation on. Where a legacy service must stay on plain HTTP, write down the exact host-to-host path it may use, who can reach it and which segment stays unprotected; that note is what a future reviewer needs.

"The VPN is connected" is not an assessment of any of this. The honest version names both endpoints, the path between them, and the first hop that is not covered.

Keep the capture output and the peer listing next to the service documentation, so whoever changes a route or adds a bridge can see which assumption they are about to break.