OpenPacketLoss™ FAQ: Fix WebRTC Errors & Connection Issues

Having trouble running the test? This guide covers the most common technical errors and steps you can take to fix them.

Last updated: April 30, 2026

Error: Connection Failed

What it means: The test couldn't reach our server. This usually happens during the Interactive Connectivity Establishment (ICE) phase, which is when your browser and the server are trying to find a reliable path to send data back and forth.

WebRTC needs a clear UDP path to work. If it fails here, it means your network didn't allow a connection to be made. This is very common on strict corporate networks or home setups with aggressive firewall settings.

Error: Connection Timeout

What it means: The connection attempt took more than 30 seconds, so we had to stop. This isn't a total failure, but it means the initial handshake was too slow to finish.

This usually happens while your browser gathers ICE candidates, including Host, Server Reflexive, and Relay candidates. These represent different network paths your browser can use to reach the server. If your network is busy or slow, this process can time out before the test even starts.

Error: Data Transfer Error

What it means: The test started successfully but was cut off halfway through. This means the SCTP (Stream Control Transmission Protocol) data channel carrying the packets was dropped, either by your router, our server, or somewhere in between.

Browser-Specific Troubleshooting

Browsers don't all handle WebRTC the same way. If your network seems fine but the test still won't run, check these settings:

Self-Hosted Server

Take control of your network testing by deploying your own OpenPacketLoss server. Perfect for gamers, home labs, and enterprise IT teams who need to test local or private network performance without relying on public internet endpoints.

What is the OpenPacketLoss™ Self-Hosted Server?

Think of it as your own personal network testing tool. It is free, open-source, and lightweight. You can run packet loss, jitter, and latency tests right from your own hardware, whether you are checking your local LAN, Wi-Fi, or a broader WAN connection. The best part is that you don't have to rely on a public internet endpoint to get your results.

What platforms does it support?

It runs on almost everything. For mobile, you can grab it on iOS or Android through their respective app stores. On desktop, it works seamlessly across Windows, macOS (both Intel and Apple Silicon), and various Linux distributions like Debian, Ubuntu, Fedora, and RHEL. If you prefer containers, Docker is fully supported across standard AMD and Intel servers, ARM64 devices like the Raspberry Pi 4 and 5, and older ARMv7 boards.

I am a home user or gamer. How should I install this?

Keep it simple! Your best bet is to download it straight from the Apple App Store, Google Play Store, or Microsoft Store. It is the easiest way to get up and running, and you won't have to worry about manually installing updates later.

Should I use Host Networking or Bridge Mode with Docker?

If you are running Linux, definitely go with Host Networking. It gives you the best performance and makes setting up WebRTC a breeze. Just keep in mind that Host Networking does not work well on Docker Desktop for Windows or Mac. If you are on Windows or Mac, or if you specifically need port isolation for security, Bridge Mode is the way to go.

Which ports do I need to open on my firewall or router?

For everything to work smoothly, you need to open a few specific ports. Port 80 (TCP) handles the web frontend and API signaling. Port 3478 (UDP) is for the integrated STUN server. You will also need to open a UDP range for the WebRTC data stream. The standard range is 49152 to 65535. However, if this is just for personal use with a few people, a smaller range like 40000 to 40050 is totally fine.

My cloud deployment (AWS, Azure, DigitalOcean) keeps failing. What gives?

This is almost always a firewall issue. Cloud providers usually block incoming traffic by default, so you need to jump into your security group settings and manually allow traffic on the ports mentioned above (TCP 80, UDP 3478, and your chosen UDP WebRTC range). If those UDP ports stay closed, you will run into ICE Connection Failures.

Do I have to set up my IP address manually if I use Docker Bridge Mode?

Yes, you do. When you run the server behind a NAT using Bridge Mode, you have to tell it your public IP address using the NAT_1TO1_IP environment variable. You will also need to make sure your STUN_PORT, ICE_PORT_MIN, and ICE_PORT_MAX variables match exactly what you mapped in your setup.

How many users can connect at the same time?

Out of the box, the server allows up to 500 total connections, capping it at 10 simultaneous connections per unique IP address to keep things fair. If you decided to use a restricted 50 port WebRTC range (like 40000 to 40050), that setup comfortably supports about 25 to 50 users at once.

Where is the source code, and how do I report bugs?

The entire project is open-source! You can grab the server code, the frontend UI, Dockerfiles, and compose setups straight from the OpenPacketLoss GitHub page. That is also the best place to report any issues or bugs you run into.

General Questions

Why does this test use UDP/WebRTC instead of TCP?

Most speed tests (like OpenSpeedTest.com) use TCP. This protocol is great for downloading files because it automatically resends any data that gets lost. However, this actually hides packet loss by adding lag while it waits for the missing pieces.

Real-time apps like Discord, Zoom, and Valorant use UDP. If a packet is lost in UDP, it stays lost. This test uses UDP/WebRTC to show you the real performance your apps are seeing, which is why it's the best way to find the root cause of stuttering and lag.

How It Works

The application utilizes the WebRTC DataChannel API with the following constraints:

This configuration forces the transport layer to behave as an unreliable protocol, similar to UDP. The engine transmits JSON-encoded packets containing sequence numbers and high-resolution timestamps. The endpoint analyzes these sequences to identify packet loss and calculate timing jitter.

Is WebRTC safe to use?

Yes. WebRTC is a modern standard used by billions of people every day. Every connection is mandatory-encrypted using SRTP (Secure Real-time Transport Protocol) and DTLS.

While WebRTC can technically show your local IP address, OpenPacketLoss only uses this to make the connection work. We don't log or store any details about your internal network.

How accurate is this test?

OpenPacketLoss is highly accurate because its measurements are based on raw UDP/WebRTC Data Channels. Unlike standard speed tests that use TCP (which masks packet loss through automatic retransmissions), we measure every single packet in real-time. This provides a true representation of how your network handles latency-sensitive traffic like gaming and VoIP.

Does this test store my IP address?

No. We do not log or store your IP address. While your IP is necessary to establish a peer-to-peer WebRTC connection for the duration of the test, it is never saved to our servers or shared with third parties.

Why does my test show 0% but my calls still sound bad?

Packet loss isn't the only cause of poor call quality. High Jitter (variation in packet arrival times) or high Latency (ping) can cause audio to break up even if no packets are lost. Additionally, CPU bottlenecks or local Wi-Fi interference can affect performance without triggering a full packet drop.

Can I use this on mobile browsers?

Yes. OpenPacketLoss works on all modern mobile browsers, including Safari on iOS and Chrome/Edge on Android. No app installation is required, although our self-hosted apps are available if you need to test your own local network hardware.