WebRTC Leak
A browser API that can expose local and public addresses directly, outside the HTTP path your proxy controls.
WebRTC exists so browsers can talk to each other for calls and file transfer. To do that it has to discover which addresses the machine can be reached on, and it asks external servers for help. Those requests do not necessarily follow the proxy your HTTP traffic uses.
The consequence is the uncomfortable one: every page load can go through a German exit while a script on the page reads a real address from a different country. Nothing in your request logs shows a problem, because as far as HTTP is concerned nothing went wrong.
This matters for browser work rather than for scraping with an HTTP client. A curl request has no WebRTC. A headless or antidetect browser does, and that is exactly where profiles are meant to look consistent.
It is also solved at the browser rather than at the proxy. Antidetect browsers expose a setting for it, and a plain headless browser can have the API disabled by policy or flag. No proxy configuration closes this, ours included, and any provider claiming otherwise is describing something they do not control.
Why the browser goes around the proxy
To establish a peer connection a browser gathers candidate addresses: local interface addresses and a public one discovered through an external helper server. That discovery uses its own transport rather than the HTTP proxy path.
A page can start this process without any call in progress. Reading the candidates is a few lines of script, which is why leak testers can show the result instantly.
Disabling or restricting the API removes the candidates, which is why the fix belongs to the browser. Some environments prefer to force the discovery through the proxy instead, which achieves the same visible outcome by a different route.
Checking a browser profile properly
The HTTP check and the browser check are different tests, and passing one says nothing about the other:
Two checks, two layers
# HTTP layer: what the exit reports
curl -s -x login_c_DE:password@proxy.sotaproxy.com:10000 https://ipinfo.io/json
# browser layer: cannot be tested with curl at all
# open a leak test page inside the profile itself and compare
# the address it reports with the one above- Run the browser check inside the profile you will actually use, not in a fresh window with different settings.
- Recheck after updating the browser or the antidetect client: defaults change between versions more often than people expect.
- If the two layers disagree, the profile is inconsistent regardless of how good the address is.
Frequent misunderstandings
A proxy does not close it
The path is outside HTTP. This is a browser setting, and no exit configuration substitutes for it.
It is not the same as a DNS leak
Both reveal you, by different mechanisms. Closing one leaves the other open.
It does not affect HTTP clients
Scraping with curl or a request library has no WebRTC involved at all.
Disabling it is not always harmless
Sites that use calls or screen sharing will break. On a profile meant for ordinary browsing that is usually acceptable; decide deliberately.
Пов'язані терміни
Дивись на практиці
Готовий використовувати webrtc leak?
SotaProxy надає доступ до ротуючих резидентських, мобільних, дата-центр та ISP проксі. Без мінімальних платежів.
Почати