IPv6 on carrier networks and what it quietly breaks
A customer of ours ran every check he could think of before he started. The IP page showed a Singapore mobile address on the carrier he was expecting. DNS was resolving through the tunnel. His own leak test came back clean.
The site he was working on saw him from somewhere else entirely, and told him so in an email.
What he’d never checked, because almost nobody does, was that his browser had two ways out and had quietly chosen the one he hadn’t configured.
The thing nobody tells you about mobile data
Singapore mobile networks hand out IPv6. That’s not an experiment or a future thing, it’s how the APN is provisioned, and on several of them IPv6 is the primary address family with IPv4 delivered on top of it through a translation layer.
So a phone on that network has a real, globally routable IPv6 address, and it uses it. Every modern app on that handset prefers it. That’s normal, correct, and exactly how the carrier intends the line to work.
Which means a mobile line is a dual stack environment by default. If your setup only thinks in IPv4, half of what’s available is going somewhere you never configured.
Why the browser picks the one you didn’t want
There’s a mechanism called happy eyeballs, and it’s the reason this catches careful people.
When a client looks up a hostname, it asks for both record types: the A record for IPv4 and the AAAA record for IPv6. If both come back, the client doesn’t pick by preference and then wait. It starts connecting on both, in parallel, with a small head start given to IPv6.
Whichever one answers first wins the race, and IPv6 usually wins because it was given the head start on purpose.
So your traffic taking the IPv6 path is the default behaviour of every current browser and most HTTP libraries. Nothing has gone wrong. The software did exactly what it was designed to do.
Where the leak actually happens
Your proxy carries IPv4. That’s what almost every mobile proxy product is: an IPv4 endpoint you point a client at.
Your machine’s IPv6, meanwhile, is whatever your own connection gives you at home or in your datacentre, and it has its own route that has nothing to do with the tunnel you configured.
So a request that resolves to an IPv6 destination goes out of your machine on your own address, straight past the proxy, and arrives at the target looking exactly like you. The proxy isn’t broken, and it was never asked to carry that traffic.
The reason this survives testing is that the IP check page you use to verify things is usually reached over IPv4, either because it’s IPv4 only or because the check itself was written to report the v4 address. So the test passes, and the real traffic leaks.
The symptoms, in the order people notice them
The first is a login alert or a verification prompt naming a place you haven’t been. That’s the one that arrives by email and makes people open a ticket.
The second is a session that behaves inconsistently. Some requests are treated as being from Singapore and some aren’t, because some hostnames have AAAA records and some don’t, so the same job splits itself across two different origins depending on which site it touched.
The third is content in the wrong language or currency, which is the harmless version and the one that tells you early if you’re paying attention.
And the fourth is nothing at all for weeks, followed by a hard block, because the platform accumulated the inconsistency quietly and acted on it later.
Why a v6 leak is worse than a v4 one
This is the part that changes how seriously you take it.
An IPv4 leak usually shows your home or office address, which is shared with everyone else behind the same NAT and changes when your provider feels like it. It identifies a connection loosely.
An IPv6 address isn’t shared like that. Your provider delegates a prefix to your line, that prefix is generally stable for as long as the line is, and every device behind it sits inside it. So the leak identifies your specific subscriber connection rather than a pool that thousands of people sit in.
It also links things together. Two accounts that leak from the same prefix on different days are visibly the same premises, and no amount of tidying up the IPv4 side undoes that.
So the ranking most people carry in their head is backwards. The family you’re not thinking about is the one carrying the more identifying information.
The mistake I see most often in testing
This one is specific to mobile lines, and it’s worth slowing down on.
IPv6 on a mobile network is per line. Each modem attaches to the carrier separately and gets its own prefix. The address on one line has nothing to do with the address on the line next to it, even in the same rack, on the same box, plugged into the same hub.
So testing IPv6 from the machine that hosts the modems tells you about that machine’s own route. It tells you nothing about what a customer using a specific port would get, because that traffic belongs to a completely different attachment.
I’ve watched this waste entire afternoons, mine included. The host says one thing, the line says another, and the host isn’t lying so much as answering a different question.
The only test that means anything is one bound to the specific line, going to something that reports back the address it saw. Run it through the port you actually sell or use, hit an echo endpoint that will answer over IPv6, and compare what comes back against what the IPv4 echo says. Two different origins means two different paths, and now you know.
The DNS half of the problem
There’s a related failure that produces the same result through a different door, and it’s worth naming separately because the fix is different.
If your client resolves hostnames locally and then connects through the proxy, the lookup itself left your machine on your own connection. That’s the difference between the two SOCKS modes, where one hands the hostname to the proxy to resolve and the other resolves first and hands over an address.
On a dual stack machine, local resolution also means your machine decided which address family to use before the proxy was ever involved. So you get the leak and you get your own resolver’s view of the world at the same time.
Resolving through the tunnel fixes both at once, and it’s one line of configuration in most tools.
So what do you actually do
There are two coherent answers and one incoherent one.
The coherent answers are either to route IPv6 deliberately through the same line as your IPv4, so both families exit from the same place, or to disable IPv6 entirely in the client so nothing goes out that way at all.
The incoherent answer, which is what most setups end up in by accident, is to have IPv6 enabled and unrouted. That’s the configuration that leaks, and it’s the default on nearly every machine.
If you’re disabling it, do it in the right place. Turning it off inside a browser profile or a container is cleaner than turning it off for your whole operating system, because a system-wide change affects everything else you do on that machine and tends to get quietly reverted by an update six weeks later.
The argument against disabling it
I want to be fair to the other side of this, because disabling IPv6 isn’t free.
A client that has no IPv6 at all, on a connection that presents as a Singapore mobile line, is slightly unusual. Real handsets on these networks have working IPv6. A browser that never once attempts an AAAA connection is describing a device that doesn’t quite match the network it claims to be on.
How much that matters depends entirely on what you’re doing, and for most work it matters very little. For anything where the coherence of the whole picture is the point, routing IPv6 properly is the better answer than switching it off, and it’s more work.
What I’d say plainly is that both are defensible, and the accidental middle state isn’t.
Containers and headless browsers
This is worth its own note because the defaults pull in opposite directions, and people assume they’re covered when they’re not.
Docker networking has historically had IPv6 off unless you deliberately turn it on, which accidentally protects a lot of scrapers. That’s luck rather than design, and it stops being true the moment somebody runs with host networking or enables it for an unrelated reason.
A headless browser is the riskier case, because it does whatever the host can do. Running one on a machine with working IPv6 gives you the full happy eyeballs behaviour and the full leak, and the browser flags people usually set for proxying only cover the HTTP side.
So verify inside the environment that’s actually doing the work. A check from your shell on the host proves nothing about what the browser inside the container reached for, and those two answers disagree more often than you’d expect.
The other things IPv6 quietly changes
Fragmentation gets stricter. On IPv6 a router in the middle is never allowed to break up a packet that’s too large, so the only thing preventing a silent hang is an ICMP message getting back to the sender. I did a whole video on that failure, and IPv6 makes it more likely rather than less.
Address rotation looks different too. An IPv4 mobile line gives you one address at a time. An IPv6 prefix can give a device many addresses, and privacy extensions rotate them on their own schedule, so the address a site saw an hour ago may not be the one it sees now even though nothing rotated in the sense you mean.
And your logs get harder to read, because the same client can appear under two families and you’ll count it twice unless something is normalising that.
What we do about it
On our side, the line’s IPv6 is a property of the line, so the useful thing is being able to tell you what it is, per port, rather than pretending it doesn’t exist.
The honest state of the market is that most mobile proxy products are IPv4 endpoints, and the IPv6 story is left to the customer. I’d rather say that out loud than let somebody find out through a login alert. If you need both families going out the same door, that’s a conversation worth having before you buy rather than after.
The honest limit
Nothing here is exotic and none of it is your fault. Dual stack is the correct design, happy eyeballs is a genuine improvement to how the internet works, and carriers deploying IPv6 are doing the right thing.
The mismatch is entirely in the tooling around proxies, which was built when a single IPv4 address was the whole picture, and hasn’t caught up.
So check the thing nobody checks. Bind a request to the actual line, ask an echo service that speaks IPv6 what it sees, and compare it with what your IPv4 check says. If the two answers disagree, you’ve found the reason for an alert you were about to blame on something else entirely.
If you want Singapore lines from somebody who will tell you exactly what each one looks like on both address families rather than hoping you never ask, everything is at Singapore Mobile Proxy.
Get new guides and videos first — join the Telegram channel.