Free Connection Checker: Check IP, WebRTC & Browser Signals

Your exit IP (HTTP)

The address every website sees when your browser connects over HTTP.

Detected exit IP: Detecting…
ISP: —
Country / City: —
Network (ASN): —
Browser: Detecting…
Check status: Queued

HTTP/3 (QUIC)

Checks whether your connection negotiates QUIC over UDP or falls back to TCP.

Checking…

Negotiated protocol: —

WebRTC leak (STUN)

Checks whether WebRTC exposes a different IP than your proxy or VPN over UDP.

Running test…

Collecting ICE candidates from your browser.

Detected public IP: —
Public IPv6: —
Local LAN IP: —
mDNS candidate: —

WebRTC verification (TURN)

Confirms the browser-reported address against what our relay server actually observes.

Checking…

Browser-reported WebRTC IP: —
Server-observed (STUN source): —
Server-observed (UDP relay): —
Server-observed (TCP relay): —

How anti-bot systems use these signals

A proxy or VPN only hides you if every channel your browser uses agrees on one address. Detection systems do not just read your exit IP, they cross-check the channels below and flag any that disagree.

Exit IP: the baseline address every website sees over HTTP. Every other channel is compared against it.
WebRTC: browsers can reveal your real IP over UDP even when a proxy covers your normal web traffic. A different IP here is a direct leak.
Server-side check: a site can compare the address your browser reports against the one its own server actually receives. An anti-detect browser that rewrites the address is caught here.
HTTP/3 (QUIC): QUIC runs over UDP. A connection that cannot carry it and falls back to TCP stands out from the large share of traffic already on HTTP/3.
Consistency: a real visitor almost always has a working, matching WebRTC address. A fully blocked or missing one is unusual, so it is treated as a signal on its own.

The takeaway is simple: a well-configured proxy binds all of these channels to the same IP. Any channel that shows a different address, or no address at all, makes you easier to detect.

Running Complete Error Detecting… Unavailable Could not detect your exit IP. Check your connection and try again. Running test… Collecting ICE candidates from your browser. No leak possible WebRTC is not available in this browser session, so there is no API to leak through. No leak detected Only mDNS or blocked candidates observed. Your public IP was not exposed via WebRTC. Leak + privacy regression WebRTC exposed a raw LAN address. mDNS obfuscation is disabled. Re-enable browser default privacy settings. Verdict unavailable WebRTC exposed a public IP, but your HTTP exit IP could not be fetched to compare. Leak detected on a different IP family WebRTC exposed a public IP on a different IP family and a different network from your HTTP exit IP, so it did not travel through the same proxy or VPN. It is a separate identity, visible to every site you open. No separate identity exposed WebRTC used a different IP version than your HTTP connection, but both addresses belong to the same network, so this is one connection reachable over IPv4 and IPv6 rather than a second identity. If you expected a proxy or VPN to be active here, it is not covering this traffic. Leak detected WebRTC exposed an IP that does not match the HTTP exit IP. Disable or constrain WebRTC before trusting this browser profile. No leak detected WebRTC and your HTTP exit IP take the same path. No separate identity is exposed. Leak detected (server-verified) Your browser reported an address matching your HTTP exit, but our server observed a different real address over UDP. WebRTC is exposing an identity your browser tried to hide. WebRTC blocked — consistency signal No WebRTC address reached the page. A real user’s public HTTP IP matches their WebRTC STUN/TURN address, so a fully blocked WebRTC is itself a detectability signal — anti-bot systems read the missing WebRTC as an inconsistency. Cheap anti-detect tools and some browser extensions cause exactly this by dropping STUN/TURN requests. It is less exposing than a real leak, but it makes you stand out from a default browser. Test failed Unknown error. None exposed Unavailable Blocked / none None Checking… HTTP/3 works on your connection Your connection negotiated QUIC over UDP. Your traffic blends in with the large share of the web already using HTTP/3. HTTP/3 exposed a different address Your QUIC traffic reached our server from a different address than your HTTP connection. QUIC runs over UDP, which your proxy cannot carry, so it went direct and revealed this address. Falling back to TCP Your connection could not negotiate QUIC and fell back to TCP. A connection that cannot carry UDP stands out next to the share of traffic already on HTTP/3. HTTP proxies and most SOCKS5 setups force exactly this fallback. Could not measure We could not complete a QUIC handshake, so there is nothing to judge here, and this is not a detection. It usually means UDP is not available on this connection. That is expected on HTTP proxies and most SOCKS5 proxies, which do not carry UDP, and on networks that block QUIC. Re-run the check, and if it keeps happening the probe endpoint may be unreachable from your network. Checking… Unavailable TURN check: no spoofing detected The IP our server observed on the TURN relay matches the browser-reported WebRTC candidate. TURN check: spoofing detected The IP our server observed on the TURN relay does not match the browser-reported WebRTC candidate. This browser is altering its WebRTC address before it reaches page JavaScript. Could not complete the TURN check. TURN check: could not verify Your browser reported a public WebRTC address, but no connection carrying that address reached our server, so we could not confirm it. Either your network blocks the connection we use to check, or the browser is reporting an address it is not actually connecting from. TURN check: WebRTC blocked No UDP connection reached our relay and the browser exposed no WebRTC address, so WebRTC appears fully blocked. A real user’s public HTTP IP matches an observable WebRTC STUN/TURN address, so a blocked WebRTC is a detectability signal rather than a clean result. No TCP relay observed HTTP (your exit) WebRTC (browser-reported) WebRTC STUN source (server-observed) WebRTC relay (UDP, server-observed) WebRTC relay (TCP, server-observed) QUIC / HTTP-3 (server-observed) Your device exposed a real address One or more channels revealed an address different from your HTTP exit. That address escaped your proxy or anti-detect browser and is visible to sites that probe these channels. No separate address exposed Every channel we could observe showed the same address as your HTTP exit. Nothing leaked a second identity on this setup. WebRTC blocked — your connection looks inconsistent No separate address leaked, but WebRTC returned nothing. A real user’s public HTTP IP matches their WebRTC STUN/TURN address, so a fully blocked WebRTC is itself a detectability signal that anti-bot systems flag. See the WebRTC check below. View report data Hide report data Copy Copied

Shows the address websites see over HTTP and provides the baseline for the other checks

Checks whether your connection uses QUIC over UDP or falls back to TCP

Checks whether WebRTC exposes a different public IP through STUN, then verifies the browser-reported address against what our TURN relay server observes

Highlights missing or unusual WebRTC results that may make a connection more detectable

Residential Proxies Mobile Proxies

How to Use Residential Proxies: Complete NodeMaven Setup & Best Practices Guide

Try proxies

Playwright Selenium Proxy: How to Set Up and Rotate Proxies in Python Puppeteer Web Scraping: A Practical Guide

Learn more

How to Use NodeMaven Scraping Browser: Step-by-Step Guide

Web Scraping with Python: The Complete Guide [2026] Playwright vs Selenium: Hands-On Comparison for Web Scraping and Automation

Learn more

Try proxies

Browser-reported data does not always tell the whole story

Connection Checker compares information reported by your browser with what NodeMaven servers observe during the test. This is especially useful for WebRTC, where the browser can report connection addresses through STUN while the TURN check provides an additional server-side view.

By comparing these results, Connection Checker can highlight IP mismatches, exposed addresses, and unusual WebRTC behavior that may not be clear from a browser-only check

Connection Checker runs several independent checks on your browser connection. It checks your HTTP exit IP, HTTP/3 and QUIC support, WebRTC through STUN and TURN, and connection consistency. It also summarizes the addresses exposed during the check.

The checker examines the WebRTC information reported by your browser and compares it with what our STUN and TURN servers actually observe.

Yes. WebRTC can expose a different public IP from your HTTP exit. Connection Checker compares the WebRTC result with your HTTP exit IP to identify a different address.

A WebRTC Leak Test focuses specifically on WebRTC exposure. Connection Checker checks several connection signals, including your HTTP exit IP, HTTP/3 and QUIC, WebRTC through STUN and TURN, and connection consistency.

The checker does not rely only on what the browser reports. It compares browser-reported information with what our servers actually observe to verify whether the addresses match across the tested channels.

It checks whether your connection negotiates QUIC over UDP or falls back to TCP, and reports the protocol used during the test.

Yes. Connection Checker can help you see whether your proxy and browser connection expose consistent IP information across HTTP and WebRTC.