Gmail now asks QR code verification. It's p0f-based, not IP-based. Some findings on how to bypass it

Google's Gmail signup now triggers a QR code verification prompt based on device and TCP fingerprint analysis, not solely on IP quality, according to testing by a user who runs multiple accounts. The verification decision occurs before JavaScript or IP checks, with desktop fingerprints (Windows, Linux, macOS) consistently prompting QR codes while mobile fingerprints (iOS, Android) trigger SMS verification, though flagged proxy or VPN IPs override device signals. Bypassing the QR prompt requires three combined elements: a clean, unflagged IP (preferably mobile carrier), a proxy that spoofs an iOS TCP fingerprint, and an antidetect browser set to macOS Safari to mimic a legitimate iPhone hotspot connection.

Noticed people often discuss this problem lately, getting the QR code on new Gmail signups and assuming it’s impossible to pass. Been testing this for months since I run multiple accounts often, decided to share my thoughts. Short version: the QR code prompt is mostly about device/TCP fingerprint, not pure IP quality. It triggers before any JavaScript or IP check runs. Clean residential IP, clean datacenter IP, premium VPN, all of them get the same result if the underlying device fingerprint reads as desktop, or if the IP is flagged as proxy/VPN by Google’s checks. Both signals need to be clean. Three things almost guarantee you get the QR prompt: signing up from desktop, any commercial VPN those IPs are pre-flagged as VPN, instant block , or an IP that’s already been used to create multiple Gmail accounts gets the QR even from a real mobile device . What I tested: - Home ISP + Windows 11: QR prompt - Premium residential proxy DE + Windows 11: QR prompt - Commercial VPN US + macOS: QR prompt, instant - Datacenter US + Linux: QR prompt - Mobile proxy “iOS fingerprint” + iOS Safari: got SMS prompt but the verification flow dead-ends at an iMessage link with no fallback OTP field Google thought I am actual phone - Mobile carrier IP with actual iPhone TCP fingerprint + desktop macOS Safari browser profile: got SMS prompt with a standard 6-digit OTP input, account created. What’s actually causing it: Google’s signup checks what kind of device you’re on at the network level, before the page even loads. If it reads desktop Windows/Linux/macOS , you get the QR code. If it reads mobile iOS/Android , you get SMS instead. That’s the whole decision. On top of that, if the IP itself is flagged as proxy/VPN or has signup history, you get pushed to QR regardless of the device side. So a “clean IP” doesn’t help if your device signature still says Windows. And a mobile-spoofed browser doesn’t help if the network layer underneath still says Linux server which is what most VPNs and proxies look like . You need matching/trustful fingerprints. What actually fixes it: Three things together, not one of them on its own: - A clean, fresh IP that hasn’t been used for Gmail signups and isn’t flagged as proxy/VPN mobile carrier IP works best, residential second - A proxy that can spoof its TCP fingerprint to look like iOS, so Google reads it as a mobile device at the network level - An antidetect browser I use AdsPower set up as macOS Safari, so the browser side reads as a Mac. Google then treats the connection as someone using their Mac while connected through their iPhone hotspot, which is normal Apple behavior and triggers SMS verification instead of QR. Without all three, you get back to the QR prompt. A few things worth noting from the privacy-research angle: - The check happens before the page fully renders. JavaScript fingerprinting and IP scoring come after. Solving this with a “cleaner IP” alone is solving the wrong layer. - Most “mobile proxy” providers only route through mobile carrier IPs without modifying the TCP fingerprint. The fingerprint still reads as their underlying server OS Linux usually . You can verify at browserleaks.com http://browserleaks.com - WebRTC has to be fully disabled, not just spoofed. Any leak exposes the actual host OS and the rest of the stack falls apart. - Carrier-native DNS matters too. Using Cloudflare or Google DNS while claiming to be an iPhone on Verizon is one more inconsistency Google can read. For the proxy part, you need one with a spoofable TCP fingerprint, not just a mobile IP. The User-Agent does nothing here, I used Voidmob for this test, they let you to spoof IP fingerprint. There are probably others, that’s just the one that worked for me. Wider point for the sub: this kind of device-level fingerprinting is going to keep showing up. Cloudflare already uses it in their bot scoring docs, Meta’s signup flow shows similar patterns. Worth understanding even if you’re not doing account creation, since it affects how privacy tools VPNs especially are classified and treated. Happy to answer questions or send over the full guide.