Short answer: Firefox WebRTC behavior can vary by version, privacy settings, profiles, extensions, private windows, and VPN route. A WebRTC test helps separate Firefox browser candidates from the public IP shown by a normal page request.
A VPN can change normal browsing traffic while Firefox still reports WebRTC candidate categories that need review. The test is useful because it shows the current Firefox session, not because it certifies every app or browser profile.
Problem
- This reads the Firefox profile you run it in, including any about:config changes that profile already carries.
- Firefox is the one browser here with named preferences for this, so a result can be changed from inside the browser.
- Applications outside Firefox route independently and are not described by anything on this page.
Run the test
Start with WebRTC Leak Test. Keep the same browser and network when comparing before and after.
- Open the WebRTC Leak Test in the Firefox profile you actually use.
- Run it once before VPN or browser setting changes.
- Change only one thing: VPN server, extension, Firefox preference, or network.
- Run the same test again and compare candidates with the visible public IP.
- Use Safe Copy after the final run for a safe before/after summary.
How to read the Firefox WebRTC Leak Test result
| Result | Usually means | What to do next |
|---|---|---|
| No public candidate | Firefox did not expose a public WebRTC candidate in this run. | Useful signal, not a full anonymity guarantee. |
| Local or masked candidates | Firefox may expose local categories or mask details depending on settings. | Compare with Chrome if you are isolating browser behavior. |
| Public candidate matches VPN | The candidate appears aligned with the VPN path. | Still check DNS and IPv6 if the goal is leak troubleshooting. |
| Public candidate matches ISP | Firefox may be exposing a non-VPN route in this session. | Review VPN app, split tunnel, proxy settings, and Firefox profile settings. |
| API blocked | Firefox settings, extensions, or policy may prevent candidate gathering. | Retest in the same profile after changing one setting at a time. |
Firefox-specific checks
- Compare normal and private windows only if your setup uses both.
- Check extensions that change proxy, VPN, privacy, or WebRTC behavior.
- Use the same Firefox profile for before and after testing.
- Do not change multiple preferences at once or the result becomes hard to interpret.
What to do after the result
Firefox is the browser where you can actually change this, which is why the advice here differs from the Chrome page. about:config exposes three preferences that matter, in increasing order of how much they break: media.peerconnection.ice.default_address_only advertises only the default interface, media.peerconnection.ice.no_host stops host candidates being gathered at all, and media.peerconnection.enabled turns WebRTC off outright. The last one also breaks video and voice calls, so reach for it only in a profile that never makes them.
Change one preference, reload the test, and note which one moved the result. If none of the three changes an ISP-facing public candidate, the route is not Firefox's to set and the VPN app is the next place to look. Reset every preference you flipped that did not help: a profile carrying half-remembered WebRTC changes is the hardest kind to diagnose the next time this question comes up.
Frequently asked questions
Why can Firefox and Chrome show different WebRTC results?
They use different browser implementations, settings, profiles, extension behavior, and privacy defaults. That is why browser-specific testing is useful.
Should I disable WebRTC entirely?
Only if that matches your use case. Disabling WebRTC can break calls and browser features. Prefer testing, understanding the result, and changing the least risky setting first.
Does Firefox WebRTC testing cover every app on the device?
No. It checks the current browser session. Other apps can use different network routes.
Limits and methodology
MyIPScan checks show observable browser and network signals for the current session. Results can change with browser profile, app route, VPN server, router, OS, carrier, DNS, and time. See the methodology and editorial policy.