Skip to content
IPOK

Google Voice IP Check: Bounded Diagnostics from Dual-Stack Exits to Risk Evidence

When Google Voice number selection or verification fails, many guides claim that "any US native residential IP will pass." In practice, you first need reproducible evidence of what your browser actually exposes. IPOK scopes its observation strictly to your browser's connection to ipok.io endpoints—combining independent IPv4/IPv6 single-stack probes, bounded hosting vs. residential inference, multi-source risk evidence, and on-click WebRTC/DNS checks.

Google Voice's anti-abuse and number-allocation rules are internal to Google and not publicly disclosed; account, region, and forwarding-number eligibility follow Google's official setup guidance (such as https://support.google.com/voice/answer/115061) and prompts. The network classifications, public risk feeds, and local connection probes on this page are for browser network self-checking only—they do not represent Google's registration criteria and never guarantee number claiming or account outcomes.

Your public IP
Try a sample IP
Try sample:

Clarify the Observation Object First: Browser Exit to ipok.io ≠ Google's Internal Verdict

An external IP checker can only observe the network connection your browser makes to that checker. Proxy clients frequently use domain-based split-tunnel rules where google.com or voice.google.com may follow a different outbound policy than ipok.io.

Furthermore, no web page can inspect local proxy client configurations, TUN interfaces, or private system processes. Always pair the diagnostics on this page with your proxy client's live connection logs for voice.google.com.

Dual-Stack Exit Check: ip4.ipok.io, ip6.ipok.io & RFC 7359 Considerations

Google services support IPv6 natively. If your local network provides IPv6 while your proxy rule only tunnels IPv4, dual-stack connections may reach Google over native IPv6. IPOK's main card and dual-stack card independently query ip4.ipok.io and ip6.ipok.io to echo each stack's exit address (without creating an application-level v4/v6 pairing record).

When both IPv4 and IPv6 exits are reachable, dual-stack reachability by itself is not a leak, and IPOK references RFC 7359 dual-stack tunnel traffic-protection considerations prompting you to verify whether your proxy covers only one stack while the other exits via your local ISP. If the other stack times out or does not respond, that does not prove IPv6 is disabled or absent, nor does it prove safety or absence of a leak.

Hosting vs. Residential Inference, Public Risk Feeds & On-Click WebRTC/DNS Checks

Public guides often note that datacenter or heavily shared exits face stricter VoIP checks. IPOK uses public ASN/BGP declarations and upstream metadata (such as ipapi.is company.type, asn.type, and is_datacenter) for bounded hosting (35-point contextual floor) vs. residential/ISP inference, and compares GeoIP country (geo.countryCode) with registration country (rdap.country ?? intel.asn.country) for native vs. broadcast clues (see https://ipok.io/en/t/datacenter-or-residential and https://ipok.io/en/t/native-ip). This is heuristic inference, not 100% absolute identification.

Across up to 10 registered risk sources, IPOK shows AbuseIPDB report counts and confidence when returned, while Scamalytics is attempted on explicit IP lookups when the shared cache misses and quota permits (or under narrow residential top-up rules). EvidenceSummary.confidence (and directSources) indicates only whether direct risk flags (Tor 90, blocklists 70, proxy/VPN 65, abuser 55) came from a single source or multiple sources (collection independence unverified). Pair this with the on-click WebRTC probe (contacting Google / Cloudflare public STUN with local ICE parsing and no candidate upload to IPOK) and leak.ipok.io DNS resolver exit check (5 minutes of readable lifetime; expired records become unreadable, are cleared on subsequent session activity, and may remain in memory while idle; not a DNS pollution test); see https://ipok.io/en/privacy.

To verify whether your exit IP is classified as residential ISP or cloud hosting, use the Datacenter or Residential IP check.

FAQ

Why is the claim that 'a US residential IP guarantees Google Voice registration' misleading?

Residential and native labels are heuristic classifications of public network metadata. Google Voice's internal risk rules are not public—account, region, and number eligibility follow Google's official prompts, and IPOK cannot confirm why a request was declined. The dual-stack (IPv4/IPv6), WebRTC, and DNS checks on this page are for local network self-checking only and do not imply that Google uses those probe metrics as registration criteria; no IP metric guarantees number allocation.

How can I check WebRTC candidates and DNS resolver exits on this page?

Click to run the WebRTC test (which contacts Google / Cloudflare public STUN and parses ICE candidates locally in your browser without sending them to IPOK) and the DNS test (which prefers our self-hosted authoritative domain leak.ipok.io to observe the recursive resolver exit IP reaching our server). If either differs from your intended tunnel, review your browser WebRTC settings or proxy UDP/DNS rules.

Why can the number of returned risk sources differ between a self-check and an explicit IP lookup?

IPOK integrates up to 10 registered risk sources, but IPQS is currently dormant and Scamalytics is attempted on explicit IP lookups when the shared cache misses and quota permits (or under narrow residential top-up rules). Returned rows also depend on IPv4/IPv6 support and live upstream availability.

Related checks

IP speed test · proxy node bandwidth
IP Purity Check — Multi-Source Risk Score & Abuse Evidence
Native IP Check — Native IP vs Broadcast IP
IP fraud score check — every source's verdict shown
ChatGPT Degraded or IP Blocked? Check IP-Side & Degrade Clues
WebRTC Leak Test — Check Browser STUN & Real IP Exposure
Datacenter or Residential IP Checker — Multi-Source ASN & ISP Audit