Who sees your IP during a WhatsApp call, and what a VPN changes
The peer, the service and your access network see different things. Name the observer you want to hide from, then pick a relay setting or a tunnel path.
A WhatsApp call exposes address information to more than one party, and the parties do not all learn the same thing. The person you are talking to may learn something about your network path, the service learns which connection reached it, and your access provider sees the flows you generate. A VPN and an in-app relay each change one part of that picture. That is why "does a VPN hide my IP on calls" has no single answer.
Three observers, three different questions
Start by naming the observer you want to hide from, because the mechanisms are not interchangeable. Hiding from the other participant is an addressing question. Hiding from the service is an account-and-connection question, and it is much harder to answer than it sounds.
| Observer | What it can learn | What changes it |
|---|---|---|
| The other participant | Whether the media path appears to come from your address or from a relay | Relay settings in the app, or a network path that does not expose your address |
| The service | Your account, the connection your client made, and the call's participants | Very little from an address change alone; the account is the identifier |
| Your access network | That encrypted traffic to certain endpoints exists, and how much | Routing through a tunnel moves the visible endpoint |
Each row can be improved independently. An improvement in one row leaves the others exactly as they were, which is why honest answers to this question usually contain the word partly.
What relaying actually changes
WhatsApp documents a setting called Protect IP address in calls, found under the app's advanced privacy options. It routes call media through WhatsApp servers instead of connecting the participants directly. The same guidance states that relayed calls stay end-to-end encrypted. It also warns that call quality may change.
Relaying is a service feature rather than a network configuration, so it applies to the calls the app decides to relay and to nothing else on the device. WhatsApp's help page for the feature is the current authority for which platforms expose it and where the switch lives.
The relay also does not hide the call from the service, because the service is the relay. It changes what the other participant can observe about your address. It may also add latency, which is the trade the setting makes.
What a VPN changes about the call path
A VPN changes where your traffic appears to originate for everything it carries. Whether it carries a particular call depends on the client's routing policy. A full tunnel takes all traffic, while a split tunnel may take only some prefixes. A phone with both Wi-Fi and mobile data can use different paths for different flows at the same moment.
That means an address you verified in a browser is not evidence about the call. The app may hold a long-lived connection that predates the tunnel, or it may use an address family the tunnel does not cover. Check the routing decision for the actual destination rather than for a website you happened to test.
End-to-end content encryption is a separate boundary from all of this. It does not collapse when the path changes, and it does not cover the metadata either.
Encryption and address privacy are different promises
Keeping call content encrypted means the relay cannot listen to the conversation. It does not mean the relay learns nothing: it still sees which accounts are connected, when, and for how long, because that is what a relay does.
Conversely, hiding your address from the peer does not make your account anonymous to the service that authenticates it. Those are two separate claims. A privacy review that merges them produces a false sense of coverage. Write the requirement as a sentence about a specific observer, then check whether the mechanism you chose addresses that observer rather than a neighbouring one.
Verify the claim you actually care about
If the requirement is about your access network, the check is a routing question you can answer locally. If it is about the peer, the check is the app's own setting. No amount of tunnel configuration substitutes for the setting.
ip rule show | head -n 10 ip route get 198.51.100.7 ss -tun state established '( dport = :443 )' tcpdump -ni wg0 -c 20 'udp or tcp port 443'
The routing lookup tells you which interface a destination would use. The socket list tells you whether a long-lived connection already exists. The capture tells you whether traffic is actually crossing the tunnel interface. Replace the documentation address with the endpoint you resolved from the app's own connection, and read the results instead of assuming the tunnel took everything.
Record which mechanism you relied on for which observer, along with the date and app version. Both the relay setting and the client's routing behaviour change over time, and a note that names the observer is the only version of this that stays useful.