Who Can See Your Traffic on a Rented VPN Server?

Renting a server changes who you trust, and it does not remove the question. The tunnel hides your traffic from the networks it crosses, then hands the plaintext to a machine that somebody else's hypervisor runs. Following the packet outward from your client shows where each observer stands and what each of them can actually see. That walk is more useful than any claim about being anonymous.

Start at the Client and Follow the Packet Out

Before anything leaves the laptop, the client wraps the packet and addresses it to the server's public endpoint. Your local network and your ISP see one flow to that address and port, with a size and a rhythm. What they do not see is which site you opened, because that destination sits inside the encrypted payload. The line between metadata and content is the whole walkthrough in one sentence.

That first hop is where most marketing claims stop being interesting. A neighbour on the same Wi-Fi sees what the ISP sees, and neither of them sees the page. Volume and timing stay visible, though, and they describe behaviour even when the payload does not.

The Hosting Network Sees the Tunnel, Not the Page

Inside the provider's network the encrypted flow arrives at a switch, then a virtual interface, then your VM. Whoever operates that network can count bytes and keep flow records without holding any key, and no key is needed for that. It is precisely the position a hosting provider occupies.

On the way out the picture changes. The VM opens a new connection to the destination, so the hosting network can see that destination address and the TLS handshake around it. The payload stays protected by the application's own encryption, and the metadata does not.

Read the rows in order and the shape of the problem appears: each one sees more than the row above it, and none of them has to break the VPN to do so.

Inside the VM, the Tunnel Ends and Plaintext Begins

The tunnel terminates on your VM, so the guest sees the inner packet before anything re-encrypts it. That is not a flaw; it is what a self-hosted exit does. It does mean the exit's security depends on who administers the guest, and on that account you are the administrator.

wg show
ss -tunp | head
nft list ruleset | head -40

Run those on the server and you are inspecting the same sockets an operator with root on the guest could inspect. Anything logged by the services you run sits inside that same trust boundary, which is why guest log settings and infrastructure records are separate questions rather than one setting.

The Hypervisor Sits Below the Guest

A virtual machine does not own the kernel it runs on. The hypervisor maps its memory and its virtual network card, so an operator at that layer is outside the guest's ability to audit. Guest isolation is real and worth relying on between tenants, and it is not a promise that privileged access is impossible. That asymmetry deserves to be stated plainly instead of hidden behind the word isolation.

A dedicated physical server changes the arrangement without removing the network, the physical access or the management interface the provider supplies. Read what the product documents rather than letting one word settle the access question.

Turn the Walkthrough Into a Trust Decision

Write down each observer and the capability you are granting it, then decide whether that grant suits the traffic you plan to send. The list is short: your local network, your ISP, the hosting network, the hypervisor operator, and you. Anything else is a subcontractor of one of those and inherits the same capability. Deciding in advance is cheaper than discovering the list afterwards.

Then verify the parts you can actually check: which logs your own services write, how long you keep them, and what the provider publishes about flow records and retention. Policies you can read and test beat assumptions about what a word like private means.