Can a VPN operator see which sites you visit?

Ask what the VPN can see and the answer depends on where you stand in the path. At the session layer the operator has authentication events and byte counts. At the packet layer it has destination addresses and timing. At the DNS layer it may have the names themselves. Each layer answers a different question, and no single switch moves you between them.

Map the layer before making a claim

The same connection produces different records at each point, and a statement about privacy is only meaningful when it names the point. Read the table column by column: what exists at that layer, what an operator can see there, and what those same records still cannot tell them.

Reading one layer as the whole picture is how both overclaims and false reassurance start. A provider that says it does not log browsing may be accurate about URL logging while still holding session records, and a packet capture that shows only addresses does not turn into a browsing history without reverse lookups and guesswork.

When you evaluate a policy, find the sentence that describes each layer. If the policy does not separate them, ask which records exist rather than accepting a general statement about encryption.

Session inventory: what a stock OpenVPN server keeps

Out of the box, an OpenVPN server does not capture traffic. The normal output is a session inventory: the account that authenticated, the source address it came from, timestamps for the start and end, the tunnel address handed out and the byte totals in each direction. That is an inventory of sessions, not a list of destinations.

Logging options can add detail. A higher verbosity level writes more about the handshake, and a status file can list connected clients, but neither turns the server into a transparent proxy. Producing URLs requires terminating TLS or running an explicit proxy, and both change the trust arrangement rather than enabling a hidden feature.

This is why the accurate version of the no-browsing-log claim is narrower than it sounds. The server does not know the page, but it does know that a session existed and roughly how much data crossed it. Whether that session record is kept, and for how long, is a separate policy question.

Inner and outer packets are different evidence

A packet capture is how you see what actually crosses the tunnel. On the server, name the tunnel interface and write to a file that can be analyzed offline:

sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | head

That file contains decrypted inner traffic: the client's tunnel address as the source, the destination address and port, packet sizes and timing. It does not contain the HTTP path or the response body unless TLS was terminated somewhere, and it is sensitive data whose retention is a policy decision rather than a debugging convenience.

A capture on the physical interface shows something different. There you see outer packets addressed to the VPN endpoint, with the encrypted payload inside. Unrelated addresses appearing in that file are normal once a virtual adapter exists, because the tunnel device carries the inner flows while the encrypted transport carries the outer ones.

Ask what the capture is meant to answer. An application's use of the tunnel is visible on the virtual adapter; the tunnel's reachability to the endpoint is visible on the physical one. Using either file as if it were the complete picture produces conclusions the data cannot support.

DNS is where names become visible

DNS remains the practical exception. The resolver sees the names it is asked to resolve, so whoever operates it learns which sites a client looks up even when the later connections are encrypted. A tunnel capture shows addresses; the resolver shows names.

Check which address the resolver used to reach an outside service. The answer is the resolver's egress address, and comparing it with the VPN exit tells you whether the query travelled through the tunnel:

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

If that address matches the local connection rather than the tunnel exit, the lookup bypassed the VPN and the name was visible on the local path. Repeat the check after a client update, because a new version can change which resolver the profile installs.

Encrypted DNS moves the visibility rather than removing it. The network no longer sees the query, but the resolver still does, and the trust question simply changes hands. The TLS server name in the connection handshake is another partial signal: it often survives even when the payload is opaque, so destination addresses are not the only metadata a forwarding server can observe.

Three record types and who can read them

Session accounting, per-name records and leak evidence are three different products with three different obligations. Session logs are cheap and low sensitivity, and they answer who connected and when. Per-name records require a logging resolver or an explicit proxy, and they create a disclosure obligation to the people affected. Leak evidence is a client-side test that compares what the resolver reveals with the tunnel exit.

Record which of these three you run, who can read it and how long it stays. Statements that a service keeps no logs describe one layer, and they stay true only within that scope. The same provider can be accurate about sessions while being wrong about DNS.

Keep the test reproducible: the same resolver query, the same capture interface and the same comparison. A privacy claim that cannot be tested at a named layer is a slogan, not an operational fact.