Onion Service vs VPN Service: Different Access Models

People describe an onion service and a VPN-only service as two flavours of the same idea: hide the port, share the secret address. They differ in what the address is bound to, who can reach it and what has to happen before a request arrives. One is a rendezvous inside Tor; the other is a route inside a private network. Comparing them as if they were interchangeable produces designs that are neither private nor maintainable.

The myth: both designs are just a hidden door

The shared property is real but thin: neither design puts the administrative interface on a directly reachable public port. Everything after that diverges. An onion address is derived from the service's own key, so the name is bound to an identity; a VPN address is just an address inside a network you were admitted to. One hides the service inside an overlay, the other admits you to a private topology. Treating the second as a synonym for the first is where the confusion starts.

Neither property is a security control for the application itself. A hidden location does not patch the software behind it, and a private route does not add authentication to the login page. Both designs still need the application's own permissions, and both still need someone responsible for updates and recovery.

What an onion address actually points at

A v3 onion address encodes the service's public key, which is why nobody can choose an address for a service they do not control. The client connects through Tor to a rendezvous point, and the service reaches the same point from its side; no ordinary exit node carries that connection to the service. The name is an identity, not a DNS record.

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

That is why adding a route or a hosts entry for an onion name does nothing useful. The lookup is not the mechanism; the Tor client and its circuits are. If the service is meant for a small set of people, onion client authorization can require a key before the connection is accepted, but that is still not application login. Publishing the address is a deliberate act as well, since anyone who learns it can attempt a connection unless you restricted it.

Stop if the only reason for the onion design is to avoid configuring authentication. The overlay does not provide that, and you will be building it later anyway.

What a VPN route actually grants

A VPN admits a device to a network and gives it a route to a gateway or a subnet. The service behind that gateway sees an address from the tunnel pool and applies whatever authorization it has. The route says nothing about who the user is; it says where packets may go.

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

That model fits a known group with managed devices, because the gateway can enforce device posture and the network can be audited. It is a poor fit for anonymous or ad hoc visitors, who would need to be enrolled first. The application's own login is still the thing that decides what a connected user may read. Confusing reachability with permission is how a VPN ends up granting a whole subnet to everyone who can connect.

Stop if the audience is unknown or changes constantly. Enrolling strangers into a private network to show them one page is a large commitment compared with publishing a service.

Choosing between them, and what stays the same

Choose the onion model when the audience is technical, the service must not have a public address at all, and you can accept Tor's client requirements. Choose the VPN model when the audience is a defined group whose devices you manage and whose access you want to log at the network layer. Neither choice removes the need for application authentication, patching or a recovery path. Neither is automatically more private in the sense that matters to your users.

In both designs, write down who can reach the service, how they are identified, and what happens when a credential is lost. The answer for an onion service includes its client-authorization keys and the address itself; the answer for a VPN includes the account, the device and the gateway policy. Those are different inventories, and only one of them will be obvious to the next administrator.

The comparison ends where the application begins. A hidden address and a private route are transport choices, and the application still has to decide what a request is allowed to do. Keep those decisions in separate documents and neither design will quietly absorb the other's job.