Why This Site Exists
Anyone who has deployed a WebRTC application knows the moment: video works perfectly on your office Wi-Fi,
then a user on hotel Wi-Fi or a corporate VPN reports a black screen. Nine times out of ten the culprit is
connectivity — a STUN server that is unreachable, a TURN server with expired credentials, or a firewall
that silently eats UDP. Diagnosing this used to mean digging through chrome://webrtc-internals
dumps or spinning up command-line tools.
icetester.org was built to shorten that loop. Paste in your ICE server details, click one button, and see within seconds whether each server actually produces the candidates your application needs — using the same browser WebRTC stack your users run.
How the Tool Works
The tester creates a real RTCPeerConnection in your browser for each server you configure and
starts ICE candidate gathering. It then inspects what comes back:
- For STUN servers, it checks whether a server-reflexive (srflx) candidate is returned — proof that the server answered and reported your public address.
- For TURN and TURNS servers, it checks whether a relay candidate is allocated — proof that authentication succeeded and the server is willing to relay traffic for you.
Because everything runs client-side, results reflect your actual network path — including your NAT, your firewall, and your browser's WebRTC implementation. Nothing you enter is sent to our servers; see the privacy policy for details.
Who It's For
- WebRTC application developers verifying their ICE configuration before a release
- DevOps engineers monitoring self-hosted coturn deployments
- Network administrators checking whether a corporate firewall permits STUN/TURN traffic
- Students and hobbyists learning how NAT traversal actually behaves in practice
Who Builds and Maintains This Site
icetester.org is an independent project — not a company landing page and not backed by any TURN vendor.
It is built and maintained by Guibo Dong, a software developer who has spent the better
part of a decade shipping and operating WebRTC applications: video-calling features, self-hosted
coturn clusters, and the unglamorous on-call work of figuring out why a call that connects in
the office drops on a client's corporate network. The tool and every article here come out of that
hands-on experience, not from rephrasing someone else's documentation.
Guibo writes and reviews every article personally and is reachable directly at me.aellan@gmail.com — questions, corrections, and "your tool says X but my server does Y" reports all land in the same inbox and get a human reply.
How We Research, Test, and Fact-Check
"Low-effort content that summarises what everyone already published" is exactly what we try not to write. Every article on this site follows the same working rules:
- Claims are verified against primary sources. Protocol behaviour is checked against the relevant RFCs (STUN — RFC 8489, TURN — RFC 8656, ICE — RFC 8445) and the W3C WebRTC specification, not against second-hand blog posts.
-
Config, code, and ports are tested before they're published. The
turnserver.confsnippets,getStats()examples, and command-line checks in our guides are ones we have actually run against a live coturn install and current browsers. - Fast-moving facts are dated. Prices, browser-version support, and market figures are written with an explicit "as of" date and a note that you should re-check them, because they go stale.
- We separate what we measured from what we estimate. When a number is a rule of thumb (for example, the share of connections that need a relay), we say so rather than presenting it as a hard statistic.
Found something wrong or out of date? That's a real contribution — email us and we correct the page, usually within a few days, and note the update date on the article.
About the Blog
The blog covers the infrastructure side of WebRTC: NAT traversal, STUN and TURN deployment, coturn configuration, debugging workflows, codec trade-offs, and architecture decisions. Articles are written from hands-on experience, kept technically specific (real config keys, real port numbers, working code), and updated when browser behavior or best practices change. When a claim depends on fast-moving facts — prices, browser versions — we say "as of" and encourage you to verify.
Contact
Found a bug in the tool, an error in an article, or have a topic suggestion? We genuinely want to hear it. Email me.aellan@gmail.com or use the contact page.