IPv4 vs IPv6 Mobile Proxies: What Changes When Your Exit Uses IPv6
Mobile networks use two kinds of addresses: shared IPv4 behind CGNAT and an IPv6 /64 for each connection. Learn which one a website sees through your proxy, what IPv6 changes for rate limits and reputation, and how to check both exits.
Most proxy guides talk about "the IP address" as if there were only one kind. Mobile networks now commonly use two: IPv4, which carriers share between many subscribers through CGNAT, and IPv6, which, where the carrier supports it, gives each mobile data connection its own block of addresses.
Which of the two a website sees changes how that site counts, limits, and remembers your traffic. A proxy that can exit over both may show one address family to one site and the other family to the next.
This guide explains how mobile networks assign IPv4 and IPv6, which address family a website sees through a proxy, what IPv6 changes for reputation and rate limits, and how to check both exits of a mobile proxy.
IPv4 and IPv6 in Brief
Why IPv6 exists
IPv4 addresses are 32 bits long, which allows about 4.3 billion addresses. The IPv6 specification, RFC 8200, "increases the IP address size from 32 bits to 128 bits." The reason is scarcity. On 3 February 2011, the Number Resource Organization announced that "the free pool of available IPv4 addresses is now fully depleted" at the global level. On 25 November 2019, the RIPE NCC, which serves Europe, the Middle East, and parts of Central Asia, made its final /22 allocation and announced: "We have now run out of IPv4 addresses."
IPv4 and IPv6 coexist
IPv6 did not replace IPv4. Many networks run both side by side, which is called dual stack, and some websites are still reachable only over IPv4. Adoption also varies by country. In its 2025 Year in Review, Cloudflare reported: "Globally, less than a third of dual-stack requests were made over IPv6, while in India, over two-thirds were."
Sources: RFC 8200, RIPE NCC, Cloudflare Radar 2025 Year in Review
How Mobile Networks Assign IPv4 and IPv6
IPv4: shared through CGNAT
Because IPv4 addresses are scarce, mobile carriers commonly place subscribers behind Carrier-Grade NAT. Many connections share one public IPv4 address, and a website sees that shared address. What Is CGNAT? covers how this works and why it matters for proxies.
IPv6: a /64 prefix for each mobile data connection
IPv6 works differently on mobile networks. RFC 6459, the IETF document on IPv6 in 3GPP mobile networks, states that each data connection has "its own IPv4 address and/or one /64 IPv6 prefix assigned to it," and that "the 3GPP network allocates each default bearer a unique /64 prefix." A /64 contains more addresses than the entire IPv4 internet, and it is assigned to that mobile data connection.
Here, a connection means the mobile data connection itself, not each browser profile, TCP connection, or proxy port. RFC 6459 also notes that the bearers belonging to the same data connection "share the same IP address(es)/prefix."
A mobile router or modem can extend that /64 to the devices behind it. RFC 7278 describes "extending an IPv6 /64 prefix from a User Equipment" mobile interface to a LAN link. Devices that share a mobile connection this way also share its /64.
IPv6-only networks and translation
Some carriers run IPv6-only networks and translate traffic to reach IPv4-only websites, for example with 464XLAT and NAT64. In that case, the IPv4 address a website sees comes from the carrier's translation infrastructure. The IPv6 section of What Is CGNAT? explains these mechanisms.
The table below compares the two address families on a typical mobile connection:
| IPv4 on a mobile connection | IPv6 on a mobile connection | |
|---|---|---|
| Address size | 32 bits | 128 bits |
| How it is assigned | Usually a private address behind carrier CGNAT | A /64 prefix for each mobile data connection |
| Shared with other users? | Yes, the public IP is commonly shared through CGNAT | The /64 is assigned to one data connection, though devices behind it share it |
| What some services treat as one client | A single IPv4 address | The whole /64 prefix, or sometimes a larger range |
| Reach | Directly reaches IPv4-enabled websites | Directly reaches IPv6-enabled websites; IPv4-only destinations require translation |
Which Address Family a Website Sees Through a Proxy
The proxy side decides
With an HTTP or SOCKS5 proxy, your device does not connect to the website. The proxy does. When the proxy receives a hostname, as with HTTP CONNECT or SOCKS5 with remote DNS, it resolves the name and its own network decides which address family is used. When your client resolves the name first and passes an address, your client has already picked the family. Python Requests documents this difference for SOCKS: "Using the scheme socks5 causes the DNS resolution to happen on the client, rather than on the proxy server," while socks5h resolves the domain on the proxy. SOCKS5 itself supports IPv6 targets: RFC 1928 defines an "IP V6 address" type with "a length of 16 octets."
Dual-stack websites and Happy Eyeballs
When both the proxy's network and the website support both families, the software that makes the outbound connection, here the proxy server, chooses between them. Whether it uses an algorithm such as Happy Eyeballs depends on the proxy software. RFC 8305 describes racing connection attempts and assumes "the preference policy for the host destination address favors IPv6 over IPv4," with a recommended delay of 250 milliseconds before trying the next address. The exact behavior depends on how the proxy is configured. A dual-stack exit may use IPv6 for sites that support it and IPv4 for the rest.
Different websites may see different address families
This means the same browser profile can appear with an IPv4 address on one website and an IPv6 address on another. Each address is looked up on its own in IP intelligence databases, so location, network type, and reputation results can differ between the two. Check both addresses rather than assuming the one you looked up is the one every site sees.
What IPv6 Changes for Proxy Users
More separation between connections
Under CGNAT, two separate mobile connections can end up behind the same public IPv4 address. On IPv6, the 3GPP design gives each connection its own /64, so two separate connections normally have different IPv6 prefixes. For workflows that need separate network identities, such as profiles on separate dedicated ports, IPv6 can provide clearer separation than shared IPv4, as long as those ports run over separate mobile data connections. Different port numbers alone do not prove different IPv6 prefixes, and carrier implementations vary, so check the prefixes actually in use.
Some services count the whole /64
Because one connection controls an entire /64, a limit on a single IPv6 address does not cover traffic from the rest of the prefix if the client changes addresses within it. Some services therefore apply limits to IPv6 prefixes. Cloudflare's previous rate limiting product, which is no longer available, applied its thresholds to "an individual IPv4 address or IPv6 /64 IP range." Let's Encrypt limits new account registrations per IP address and separately per IPv6 range, allowing "up to 500 accounts" from "a single /48 IPv6 subnet every 3 hours." Changing to another address inside the same /64 may therefore not look like a new client to services that group traffic by prefix, although some tools still limit each IPv6 address separately.
Reputation is less shared, not automatically clean
A shared IPv4 address carries the history of everyone behind it. An IPv6 /64 on a mobile connection is assigned to that connection, so it is not shared with other subscribers the way a CGNAT IPv4 address is. That does not guarantee how its reputation is assessed: the prefix may previously have been assigned to another connection, and services can also assess larger ranges that include it. Mobile Proxy IP Reputation covers how reputation services assess an address.
Reach still depends on IPv4
An exit that only works over IPv6 cannot reach IPv4-only websites without translation somewhere in the network.
WebRTC can show an IPv6 address
Browsers can expose addresses through WebRTC, including IPv6 addresses, outside a conventional application proxy. If you use antidetect browser profiles, keep WebRTC in a proxy-aware mode and check the result, as described in Mobile Proxies for Antidetect Browsers.
How to Check Which Family Your Proxy Uses
The free ipify service offers separate endpoints for each family: api.ipify.org returns your IPv4 address, api6.ipify.org returns your IPv6 address and fails if there is none, and api64.ipify.org returns whichever family the connection uses. Requesting all three through the proxy shows what websites can see:
import requests
PROXY = "http://user:pass@proxy-endpoint:8000"
PROXIES = {"http": PROXY, "https": PROXY}
def exit_ip(url):
try:
response = requests.get(
url, params={"format": "json"}, proxies=PROXIES, timeout=15
)
response.raise_for_status()
return response.json()["ip"]
except requests.RequestException as exc:
return f"not available ({type(exc).__name__})"
print("IPv4 exit: ", exit_ip("https://api.ipify.org"))
print("IPv6 exit: ", exit_ip("https://api6.ipify.org"))
print("Default exit:", exit_ip("https://api64.ipify.org"))
The "Default exit" line shows which family that one request to api64.ipify.org used. Other websites can be reached over a different family. If the IPv6 line returns "not available," that request did not confirm an IPv6 exit. The same message also appears for authentication errors, timeouts, and other connection problems, so check the IPv4 line and the proxy details before drawing conclusions. To check inside a browser profile, open browserleaks.com/webrtc and compare two things: the address the page receives directly, which should be the proxy exit, and the addresses it finds through WebRTC. WebRTC can also list local or relay addresses, so a difference alone does not prove a leak. An unexpected public IP address in the WebRTC results may point to a leak and is worth investigating.
IPv4 or IPv6: Which Fits Your Workflow
| Workflow | What to aim for |
|---|---|
| Reaching any website | An exit with IPv4 available, or dual stack, because many sites still do not support IPv6 |
| Logged-in account work | A dedicated port, and a check of which family each target site actually sees |
| Testing your own site or app over IPv6 | A connection with a working IPv6 exit |
| Collecting public data at volume | Pacing that assumes a site may count the whole IPv6 /64 as one client |
What matters most is knowing which family each target sees, and keeping that consistent for logged-in work.
FAQ
Is IPv6 better than IPv4 for mobile proxies?
Neither is better in general. Where the carrier supports IPv6, each mobile data connection is assigned its own /64, which is less exposed to the shared history of CGNAT IPv4 addresses, although its reputation is not guaranteed. Some websites still work only over IPv4, so most workflows need IPv4 available as well.
Do websites block IPv6 addresses differently?
Some do. Because one connection can use any address in its /64, some services group IPv6 traffic by prefix, typically /64 and sometimes larger ranges, while others still count single addresses.
Does rotating a mobile proxy change the IPv6 prefix?
It can. A reconnect starts a new data connection, and the carrier may assign a different /64. Carriers handle this differently, so check the IPv6 exit after a rotation instead of assuming it changed.
Can I use a proxy that exits only over IPv6?
Connecting to a proxy over IPv6 and having the proxy exit only over IPv6 are different things. A proxy whose exit uses only IPv6 can reach websites that support IPv6 directly, and IPv4-only websites only if the network translates the traffic. For most general work, an exit with IPv4 available is the safer choice.
Platform terms of service still apply. The address family your proxy uses changes how websites see your traffic. It does not authorize activity that a platform prohibits.
Related Reading
Dedicated 4G and 5G Mobile Proxies with IPv4 and IPv6
PowerProxy provides dedicated mobile connections on real carrier SIMs, with HTTP, HTTPS, and SOCKS5 support. In Amsterdam, KPN SIMs support IPv4 + IPv6.
No credit card required · 4.7 / 5 on Trustpilot ★★★★★ · 1,200+ businesses
Narmin Kamilsoy
Contributing author sharing insights and stories on our blog.