Google Unusual Traffic on a Shared VPN Exit: Device or IP?

Being asked to prove you are human feels like an accusation, and the obvious conclusion is that something on the tablet is infected. That conclusion skips a step. A shared VPN exit puts many unrelated sessions behind one public address, and the notice reacts to the request as it arrives, which includes that address. Deciding whether the pattern belongs to your device or to the exit takes three short tests, and the right answer changes what you do next.

What the notice is actually reacting to

Google's unusual-traffic guidance names shared networks and VPN services among the situations that produce the challenge, alongside automated requests from a device. The public address is a signal about a group of users, not a fingerprint of one person. Addresses accumulate reputation from everything that uses them, including traffic you never see.

That cuts both ways, which is why neither story is proven by the notice itself. The challenge is deliberately vague about which signal fired, so treat it as a prompt to gather evidence rather than a verdict.

Three tests that separate device from exit

First, take the same device to a different approved network and repeat an ordinary search. If the challenge follows the device across unrelated connections, the address is not the variable and you should look at extensions, automation and whatever else the device is running. If the device is clean elsewhere and only struggles on one connection, you have learned something about the path. Do that comparison before changing any settings, so it stays clean.

Second, use another device through the same exit and try the same search. Two devices challenged in the same window points at the shared address; one challenged device on its own points back at that device.

Third, look at timing. A notice that appears only during particular hours suggests load on the exit rather than anything installed locally. Compare a weekday evening with a quiet morning, since a shared exit follows other people's schedules.

Respond without disabling your own controls

Complete the human-verification step when it is offered, and try a supported browser if the challenge will not render, since a blocked script or an extension can make a solvable check look broken. Do not hammer the page or script around it, because repeated attempts from the same exit make the address look worse for everyone behind it. If the pattern holds, contact the provider with the exit identifier and the approximate times and ask what they can see about shared-address activity.

There is no reason to send a provider your search history or your VPN credentials, and a support agent who asks for either is worth questioning.

Rotating exits to get around the check is not a diagnosis, and depending on your provider it may put you on an address with even less history.

What a dedicated address changes

A dedicated address removes other users from the picture and leaves prior history, your own request patterns and account-level signals in place. It can help, and it is not a guaranteed cure, because a fresh address that has already been used for bulk traffic carries that past with it. The honest framing is that you are buying isolation from other customers, not a clean reputation.

The useful outcome of all this is a sentence you can defend: the notice follows this device, or it follows this shared path, or it appears under load regardless of either. Everything else is guessing at someone else's traffic.

If a team shares one exit, the same logic scales up: one noisy client affects everyone behind the address, and the fix usually lives inside the team rather than in a new server.