How to Test Your WebRTC Connection
A step-by-step guide to diagnosing P2P connectivity, testing TURN servers, and measuring real throughput between devices.
Published March 3, 2026 ยท Updated March 4, 2026
When I built SpectrShare, I spent a lot of time looking at the ways WebRTC connections break. Typically, the problem was the network: a firewall blocking UDP, a NAT type that prevents direct connections, a TURN server that was misconfigured and nobody noticed. I also found that testing a TURN server was somehow quite hard. Maybe I was missing something amazing, but the only immediate ways I found to test SpectrShare TURN server was to switch off any other way of connecting and force connections to TURN - not that great for a production service. So I built some tools and wrote this article on how to use both my tools and the others I found useful.
WebRTC is peer-to-peer - two devices need to find a way to talk directly. That sounds simple until you consider that most devices sit behind NAT (Network Address Translation), where a router maps private internal addresses to a single public IP. Old school network engineers used to complain a lot about NAT breaking the end-to-end/any-to-any nature of the earlier internet, and they were right, but many methods have arisen to work around the limitations of NAT.
Most WebRTC connection failures come down to network configuration. Firewalls blocking UDP. Restrictive NAT types. Corporate proxies that strip non-HTTP traffic. The frustrating part is that these problems are silent. The connection hangs, eventually times out, and you get no useful error message.
Better to test before you need it. Figure out what your network allows, whether your TURN fallback actually works, and how much throughput you can realistically get.
Quick primer on what WebRTC does when it tries to connect two peers. The process is called ICE (Interactive Connectivity Establishment). It gathers "candidates" (potential network paths) and tries them one by one until something works.
ICE Candidates
Three types of candidates, tried roughly in this priority:
- Host candidates are your device's local network addresses. Only useful if both peers are on the same LAN (but very cool if you are - super fast speeds.)
- Server-reflexive (srflx) candidates are your public IP as seen by a STUN server. This is the normal path for P2P across the internet. A STUN server doesn't relay any data. It just tells your browser what your public address is so the other peer knows where to send packets.
- Relay candidates are traffic routed through a TURN server. This is the fallback when direct P2P fails. The TURN server sits in the middle and forwards every packet between peers. It works, but it adds latency (proportional to how far away the server is) and costs bandwidth on the server side.
Connection Paths
Peer A
Your browser
Direct P2P
Peer B
Their browser
If direct P2P fails (restrictive NAT, firewall), traffic goes through a TURN relay:
Peer A
TURN Server
Relay
Peer B
NAT Types
Your NAT type determines which of these paths will work:
- Open / Full-cone / 1:1: any external host can reach you. Direct P2P works almost always. Rare outside of servers.
- Moderate / Restricted-cone: direct P2P works with STUN. Most common on residential networks. You'll see server-reflexive candidates and connections generally succeed.
- Strict / Symmetric: your router assigns a different external port for every destination. STUN-mapped addresses become useless because the port changes per peer. This is the troublemaker. Common on corporate networks, mobile carriers, and some ISPs. You need a TURN relay.
Before touching the network, confirm your browser supports what you need. WebRTC has been around since 2017, but specific API support still varies across mobile browsers and older desktop versions.
The Browser Capability Report checks all the relevant APIs in one pass: WebRTC and Data Channels, MediaSource Extensions, File System Access API, codec support (H.264, VP9, AV1), Web Workers, WebAssembly. Everything runs locally. Nothing leaves your browser.
For deeper debugging, Chrome and Edge have chrome://webrtc-internals, a built-in page that shows every ICE candidate, DTLS handshake, connection state change, and real-time stats graph for active connections. Firefox has about:webrtc. I use these a bit when debugging a specific connection that's already established, though they dump raw data rather than walking you through a diagnosis.
This is where you find out what your network actually allows. Two tools, depending on how much detail you want.
Quick check: WebRTC Diagnostic
The WebRTC Network Diagnostic pings four STUN servers in parallel (SpectrShare, Google, Cloudflare, and Nextcloud), gathers your ICE candidates, and classifies your NAT type. It shows you exactly which candidate types were gathered and what your public IP is.
If you see server-reflexive (srflx) candidates, STUN works and direct P2P will succeed for most peers. If you only see host candidates, your network is blocking STUN. Either UDP port 3478 is firewalled, or you're behind a proxy that strips non-HTTP traffic.
Full diagnostic: Connectivity Test
The Connectivity Test is a bit of a one-stop-shop. Five-step pipeline: browser capabilities, STUN connectivity with latency measurement, ICE candidate gathering, NAT analysis, and recommendations. It produces an overall score (excellent/good/fair/poor) and tells you whether to enable TURN relay, what quality settings to expect, and roughly what percentage of peers can connect to you.
Results are shareable via URL. When someone asks me why their connection isn't working, I tell them to run this test and send me the link. Saves a lot of back and forth.
Also worth knowing
Trickle ICE is Google's canonical tool for testing STUN and TURN servers. It lets you enter any ICE server URL and shows the raw candidates as they arrive. It's particularly useful when testing a custom STUN or TURN server. You can verify that candidates appear before involving any application code.
If Step 2 showed that you need a relay (strict/symmetric NAT, corporate firewall), the next question is whether your TURN server actually works. The tools I found just check that a relay candidate appears, which only proves the server responded to an allocation request, not that it actually works and passes data.
The TURN Server Tester goes further - it creates two WebRTC connections in the same browser tab, both forced to iceTransportPolicy: 'relay', so all traffic goes through the actual TURN server. Then five phases: credential validation, TURN allocation, relay connectivity (sends real data end-to-end), latency measurement (50 round-trip pings), and throughput measurement.
Transport comparison
TURN servers typically expose three transports: UDP (port 3478), TCP (port 3478), and TLS (port 443 or 5349). The tester has a "Compare Transports" mode that runs sequential tests against all three and shows the results side by side. Different networks block different things:
- UDP is fastest but most commonly blocked by firewalls
- TCP works through more firewalls but adds overhead from TCP's own reliability layer on top of SCTP
- TLS on port 443 gets through almost everything because it looks like HTTPS to firewalls and proxies
If you're on a corporate network, TLS on 443 is sometimes the only transport that works. Unfortunately at this time, SpectrShare TURN and the web host are running on a single VPS (and I haven't yet implemented the additional complexity required to run both on the same port) so currently our TURN server doesn't run on port 443.
TURN and latency
A TURN relay forwards every packet, so it adds latency proportional to how far the server is from each peer. If the server is in Frankfurt and both peers are in New York, every packet takes a round trip across the Atlantic and back. TURN server location matters. The tester measures the actual relay RTT so you can see the cost.
Firefox relay-only trick
Firefox has a hidden preference media.peerconnection.ice.relay_only in about:config. Setting it to true forces all WebRTC connections to use relay candidates only, which is useful for verifying that your TURN server works end-to-end in a real application, not just in a test tool.
Everything up to this point answers "can I connect?" That's necessary but not sufficient. You might have a working P2P link that maxes out at 2 Mbps because of a congested path. Or a TURN relay that's surprisingly fast because the server is close by. You won't know until you measure.
I couldn't find a browser-based tool that measures real peer-to-peer throughput between two actual devices, so I built the WebRTC Speed Test. Most testing tools use a single-device loopback or test against a server, which doesn't tell you what happens when two real networks are involved.
How it works
One device creates a test room and gets a share code (plus QR for mobile). The second device joins. Once connected, the test runs four phases: connection establishment, latency (100 ping messages), upload (A to B), and download (B to A). Each throughput phase pushes 10MB in 14KB chunks.
The results show connection type (direct or relay), latency (min/avg/max plus jitter), and throughput (min/avg/max Mbps plus stability). If the connection went direct, a "Compare with TURN Relay" button runs a test through the relay so you can see the difference.
Local loopback mode
There's also a single-device mode that wires two connections together locally. No real network involved, so it only measures DataChannel overhead. But it gives you a ceiling: the maximum throughput your browser can push without any network bottleneck.
For load testing
If you need to stress-test a WebRTC infrastructure with many concurrent connections, webrtcperf is an open-source tool that runs headless browsers with configurable network constraints. It's more of a developer tool than something you'd use for a quick check, but it's the best option for capacity planning.
The tools report a few metrics. Some matter more than others depending on what you're doing.
Round-Trip Time (RTT)
How long a message takes to go from one peer to the other and back. Lower is better - the lower the latency, the higher the throughput, all else being equal. Direct connections should beat relay on RTT, but it depends on where the TURN server is relative to both peers and how the networks in between are peering.
Throughput
Actual data transfer speed in Mbps. This is what determines how fast files move. It depends on raw network bandwidth, but also on the browser's SCTP implementation, buffer sizes, latency and flow control.
Jitter
Variation in latency between packets. Low jitter means consistent timing. High jitter means some packets arrive much later than others. File transfers don't care much about jitter since data doesn't need to arrive at precise intervals, but real-time video/voice care a lot.
Stability
A percentage measuring how consistent throughput is over the test duration. 90%+ means the connection speed is steady. Below 70% and throughput is swinging around enough to cause problems for streaming. File downloads handle it fine either way.
Rule of thumb
For file transfers, throughput is all that matters. Even high-latency connections work fine once data starts flowing. Video streaming is pickier: you want reasonable RTT and decent stability. The How It Works article covers how SpectrShare adapts to different connection qualities.
I've seen most of these personally. Here's what to look for and what to do.
No server-reflexive candidates (only host candidates)
Cause: STUN is blocked. Your firewall or proxy is not allowing UDP traffic to the STUN servers (typically port 3478).
Fix: If you control the network, allow outbound UDP on port 3478. If not, you need a TURN server, specifically one with TLS on port 443, which looks like HTTPS to most firewalls.
Symmetric / strict NAT detected
Cause: Your router assigns a different external port for every destination. The address that STUN discovers won't work for connections to other peers. Common on corporate networks and some mobile carriers.
Fix: You need a TURN relay. Direct P2P is not possible from this network (unless the other peer has an open NAT, which sometimes works). Configure a TURN server and verify it using the TURN tester.
TURN server: no relay candidates
Cause: The TURN server is unreachable or credentials are wrong. Could be: hostname not resolving, wrong port, incorrect username/password, expired time-limited credentials, or the server process not running.
Fix: Test with Trickle ICE using your TURN URL and credentials. If no relay candidate appears, check that the server is running, the hostname resolves, and credentials are correct. For coturn, check external-ip configuration.
TURN works on UDP but not TCP/TLS
Cause: The TURN server is configured for UDP only, or the TCP/TLS listening ports aren't open in the server firewall.
Fix: Enable TCP and TLS listeners in your TURN server config. For coturn: listening-port=3478 (TCP), tls-listening-port=5349 or 443 (TLS). Use the TURN tester's transport comparison mode to verify all three.
Connection works but throughput is very low
Cause: Could be a congested network path, a relay server far from both peers, bandwidth throttling by an ISP, or browser-level DataChannel buffer limits.
Fix: Run the Speed Test to measure actual throughput. If using relay, compare with a direct connection to see if the relay is the bottleneck. If direct throughput is also low, the issue is the network path itself. Try a different network or check for bandwidth restrictions.
Everything fails on a corporate network
Cause: Corporate proxies and deep packet inspection firewalls block all non-HTTP traffic, WebRTC included.
Fix: TURNS (TURN over TLS) on port 443. To a corporate firewall, this looks like regular HTTPS traffic. If even that fails, the network is probably doing TLS interception. At that point you're out of options on that network.