Skip to content
IPOK

Discord IP Check: Browser Dual-Stack Exits, Risk Evidence & Split-Tunnel Diagnostics

When Discord registration, phone verification prompts, or account restrictions occur, troubleshooting guides often point to shared datacenter exits, untunneled IPv6, or WebRTC exposure. IPOK scopes its observation strictly to your browser's connection to ipok.io endpoints—combining independent IPv4/IPv6 probes, bounded hosting vs. residential inference, multi-source risk evidence, and on-click WebRTC/DNS checks.

Discord's internal anti-abuse, verification, and account standing rules are not public; account status and appeals follow Discord's official Support Center (https://support.discord.com) and in-app notices, and IPOK cannot confirm why an account was flagged or restricted. The dual-stack, network classification, public risk, and WebRTC/DNS checks on this page are for local network self-checking only—they do not imply that Discord uses those probe metrics as enforcement criteria and never guarantee verification or unban outcomes.

Your public IP
Try a sample IP
Try sample:

Step 1: Clarify the Observation Object—Browser Exit to ipok.io ≠ Discord App or Voice Path

An external web checker only observes the connection your browser makes to ipok.io. Proxy clients frequently apply different split-tunnel rules to discord.com, discord.gg, or the standalone Discord desktop application and its UDP voice gateways.

Furthermore, no web page can inspect local proxy client configurations, TUN interfaces, or private desktop processes. Always pair the browser diagnostics on this page with your proxy client's live connection logs for Discord domains and processes.

Step 2: Probe ip4.ipok.io & ip6.ipok.io Independently and Check RFC 7359 Conditions

IPOK's main card and dual-stack card independently query ip4.ipok.io and ip6.ipok.io to echo each stack's exit IP (without creating an application-level v4/v6 pairing record).

When both IPv4 and IPv6 exits respond, dual-stack reachability by itself is not a leak, and different addresses or ISP labels across the two stacks do not by themselves prove a tunnel bypass. IPOK references RFC 7359 dual-stack tunnel traffic-protection considerations so you can verify against your client routing rules and connection logs whether the other stack left your intended tunnel and exited directly 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.

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

IPOK combines 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; falling back to bash.ws only if initial token issuance fails, not a DNS pollution test); see https://ipok.io/en/privacy.

After reviewing exit risk signals, inspect browser ICE candidates in the WebRTC Leak Test.

FAQ

Why does Discord still ask for phone verification or restrict my account when IPOK shows a low-risk residential IP?

Discord's internal anti-abuse and account standing rules are not public—triggers may involve device state, email/phone history, join/message cadence, or split-tunnel rules routing Discord differently from your browser. The dual-stack, WebRTC, DNS, and risk checks on this page are for local network self-checking only and do not imply that Discord uses those probe metrics as verification or ban criteria; follow official guidance at https://support.discord.com.

What if ip4.ipok.io and ip6.ipok.io show different exits, or the other stack does not respond?

Different addresses or ISP labels across the two stacks do not by themselves prove a tunnel bypass (a dual-stack tunnel or separate protected exits may also present different addresses). It may indicate single-stack coverage or different outbound policies, which you should verify against your client routing rules and connection logs—a bypass under RFC 7359 only applies once you confirm the other stack left your intended tunnel and exited directly 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.

Does a clean browser WebRTC check prove the Discord desktop app's UDP traffic is also tunneled?

No. The WebRTC probe on this page only inspects your current browser's ICE candidates when contacting Google / Cloudflare public STUN (without sending them to IPOK). It cannot inspect standalone desktop application processes; verify Discord desktop traffic in your proxy client's process rules or TUN logs.

Related checks