"Replace WebRTC IP with proxy IP" is a setting several anti-detect browsers offer, and as worded it cannot exist. The public address in a WebRTC candidate is not a value the browser holds. It is what a STUN server on the internet saw when a UDP packet reached it. If that packet left from your own connection, the server saw your own address, and editing the text afterwards changes what the page is told, not what was observed. What a browser can honestly do is gather no address outside the proxy at all.
We say "cannot" because we shipped an option with exactly that label, and for as long as it existed it did nothing.
Where the WebRTC public address comes from
A page that opens an RTCPeerConnection asks the browser for ICE candidates, the addresses another peer could use to reach it. There are three kinds that matter here. A host candidate is a local interface, which Chrome hides behind a random .local name (the subject of the .local address in your WebRTC test). A server-reflexive candidate, written srflx, is the address a STUN server reports back after receiving a packet. A relay candidate is an address on a TURN server that forwards traffic.
The srflx row is the one people mean by "WebRTC leak". The browser sends a UDP packet to a STUN server, the server replies with the source address it saw, and the browser hands that address to the page. HTTP proxies carry TCP. Most SOCKS setups in a browser carry TCP too. So with no other rule in place, the UDP packet goes straight out of your network card, and the address that comes back is your home line, even while every page loads through a proxy in another country.
A profile does not open until its proxy has answeredIn Mosaic: Checked before every launch. No profile opens behind a proxy that has not answered. Free holds 3 profiles. Pro is $49 a month for any number.
Mosaic is a desktop app
Email yourself the link and open it on your computer.
How it works: Checked before every launch
What a "replace" setting would have to do
A browser could catch the candidate on its way to the page and swap the address for the proxy's exit. Our objection to that is not taste. It fails on two counts.
The first is that the page does not need to believe the candidate. A site that wants the truth runs its own STUN server, and the server's log already has the real source address of the packet. The edited candidate then disagrees with the site's own record, and a disagreement is a stronger signal than a leak, because no ordinary browser produces one.
The second is that a rewrite done in page script is a patch on a JavaScript API, and those patches are findable in ways an engine change is not. We wrote up why we keep every value in C++ in why we change fingerprints in C++, not JavaScript.
What RFC 8828 says a browser may do
The IETF wrote down the options in RFC 8828, "WebRTC IP Address Handling Requirements". It describes four modes. Mode 1 gathers every interface. Mode 2 uses the default route plus its local address. Mode 3 uses the default route only. Mode 4, "force proxy", sends WebRTC through the configured proxy. Where the proxy cannot carry UDP, as with HTTP proxies and most SOCKS ones, the RFC has the browser give up UDP and use TCP through the proxy instead.
None of the four modes replaces anything. Mode 4 is the one that matches what people want from a proxied browser, and Chrome's spelling of it is a command-line switch: --webrtc-ip-handling-policy=disable_non_proxied_udp.
Our own "Replace with proxy IP" option
The WebRTC menu in our profile editor had an option called "Replace with proxy IP". Its entire implementation was a launch flag, --webrtc-ip. When we finally measured the WebRTC row against a real leak test with a proxy attached, we ran strings on three engine binaries, ours, a third-party fork and the machine's Google Chrome, and counted the switch names:
webrtc-ip-handling-policy ours 1 fork 2 stock 2
force-webrtc-ip-handling-policy ours 0 fork 0 stock 0
webrtc-ip ours 0 fork 0 stock 0
--webrtc-ip exists in none of them. Chromium accepts an unknown switch without a word, so the option was taken in silence on every engine and replaced nothing. The full count of what was wrong, including a second flag that never existed, is in two WebRTC flags we used never existed in Chromium.
Then we measured what actually stops the leak, on our own engine, with one fresh user data directory per row:
no policy RTCPeerConnection present, 2 candidates
(an mDNS host candidate and srflx, the host's real public address)
disable_non_proxied_udp RTCPeerConnection present, 0 candidates
Zero candidates with the constructor still present is what a machine on a UDP-blocked network produces, so it reads as an ordinary network rather than as a browser with something removed (a browser with no RTCPeerConnection doesn't exist).
What the option does now
The option kept its place and lost the promise. It is called Confine to the proxy, with the hint "No candidates escape a proxied profile". When a profile has a proxy attached, Tesseract Chrome, Mosaic's own Chromium, launches with disable_non_proxied_udp, through a privacy setting that is on by default. With no proxy, the policy is deliberately not sent: every packet would count as non-proxied, so it would hide an address the site is already talking to and add a signature for nothing. Chrome's mDNS hiding of the local address stays on, as in stock Chrome.
So the honest wording is that Mosaic stops WebRTC from going around the proxy. It does not route WebRTC through the proxy, and it does not put the proxy's address into a candidate. If you are checking another browser's version of this setting, run a leak test against a page that shows srflx rows, with a proxy attached, and look at what comes back. A real address there means the option is a label. No candidates means it works. A proxy address in a srflx row, from a proxy that carries no UDP, means something is being edited, and a site with its own STUN server can catch that.
