ZTRelay is an encrypted multi-hop transport for raw TCP and UDP. Every connection is split across a chain of nodes, so the one that sees where you are never sees where you're going.
Each route is built from the same three kinds of node. You choose the hop count and the exit country; the relay does the rest.
Your client connects here directly and hands over encrypted traffic. The Entry knows who you are, and nothing about where the traffic is headed.
Relays encrypted bytes between its two neighbors. A Middle node's
real address is never shown to a client — it appears only as a
system-generated [64 hex chars]._ztr alias, unique to
that route.
Makes the final outbound connection. The destination sees the Exit's address, never yours, and rotating the Exit changes what it sees without touching the rest of the route.
Your client already knows the Entry's address, and may be able to infer the Exit's if it controls the destination server. Neither breaks the model on its own. What matters is that no single node, and nothing a client can see, links your original connection to its final destination.
That is the Middle node's job, and it's why its real address is the one thing a client is never shown.
Applications on raw sockets get multi-hop onion-style transport without writing an encryption layer of their own.
There is no HTTP layer in the relay path. Hops forward encrypted bytes and can't inspect application-layer content, by design.
Hops can add randomized delay and decoy traffic to make timing correlation harder. It's an option you turn on per tunnel.
Map an IPv4 you control to a ._ztr alias and hand that out instead. Each one is revocable on its own.
ZTRelay carries raw TCP and UDP, not web traffic as such, so it never parses, caches or understands HTTP.
You can still reach a website through it: forward a local port through the tunnel and point your browser at it, or tunnel raw TCP to a site you mirror on a local network. Whatever speaks the protocol runs on your end.
Build your first route in a few minutes.