IPv6 proxies: when they work and where they fail

IPv6 proxies send requests out through IPv6 addresses, and they are plentiful because one network block holds billions of addresses. Two things decide how they behave: whether the target serves its content over IPv6, and whether its rate limiter counts a whole /64 prefix as one client. Pool size decides neither.

The pitch for IPv6 proxies is always the same number: billions of addresses. Then the scraper switches over. Some targets refuse the connection outright. Others answer, and start returning 429s after the same number of requests the old IPv4 pool managed.

How IPv6 proxies actually work

An IPv6 proxy is a gateway that takes a request from your client and sends it to the target from an IPv6 address. Your client can reach the gateway over IPv4 or IPv6, using HTTP or SOCKS5. What matters is the exit: the address the target sees.

The /64 boundary. IPv6 addresses are 128 bits long, and the standard split puts the network prefix in the first 64 bits and the interface identifier in the last 64. RFC 7421 (January 2015) documents why that boundary became fixed: stateless address autoconfiguration (SLAAC) depends on a 64-bit interface ID, so a single subnet is a /64. One /64 holds 2^64 addresses.

Allocations, not addresses. Networks do not hand out single IPv6 addresses. A customer site gets at least one /64, and often a /56 or a /48. A provider holding one /48 has 2^(64-48) = 65,536 separate /64 subnets to route traffic from.

That is where the headline pool sizes come from. It is also where the trouble starts, because a target that understands this arithmetic does not treat each address as a separate client.

IPv6 vs IPv4 proxies

The comparison most sellers draw is address count. For a scraping job, four other axes decide more: whether the target can be reached, what the limiter counts, what history the address carries, and how the traffic is billed.

Supply. IPv4 space ran out years ago, so every IPv4 address is held and paid for. IPv6 space is abundant, so IPv6 pools are sold in bulk, usually by the GB.

Reach. An IPv4 exit reaches every public site. An IPv6 exit reaches only sites with IPv6 enabled, a minority of the web (the next section has the numbers).

History. An IPv4 address often carries years of per-address history, good and bad, in blocklists and IP intelligence databases. IPv6 addresses are rarely scored one by one. Scoring happens at the prefix and the network, so a fresh address inherits the reputation of its /64 and its ASN.

Protocol does not change what a target thinks of a hosting network, and it does not change what it thinks of a home broadband network either.

Check target IPv6 support first

Whether ipv6 proxies work on a given target starts with DNS. An IPv6 exit can only reach a target that publishes an AAAA record (the DNS record for an IPv6 address). No AAAA record, no IPv6 path. Depending on the gateway, the request then fails with a connection error, or quietly falls back to an IPv4 exit you did not plan for.

Most of the web is still on the wrong side of that check. W3Techs usage statistics (September 2026) count 31.8% of the websites they track using IPv6. So on a typical target list, about two hosts in three have no IPv6 path.

Client-side adoption is uneven, and that shapes what servers bother to support. The Cloudflare Radar 2025 Year in Review (December 2025) measured that 29% of requests from dual-stack clients were made over IPv6, up one point from 2024. India led at 67%, while 94 countries or regions sat below 10%. A target that mostly serves low-adoption markets has little reason to publish AAAA records.

Checking takes a minute per list. Put one hostname per line in targets.txt and, on a dual-stack machine, confirm the record exists:

while read -r host; do
  n=$(dig +short AAAA "$host" | grep -c ':')
  echo "$host AAAA_records=$n"
done < targets.txt

A record is not proof of equal service. Some sites serve a different edge, a stripped page or a redirect over IPv6. Compare the two paths directly:

curl -4 -s -o /dev/null -w "v4 %{http_code} %{size_download}\n" https://TARGET_HOST/PATH
curl -6 -s -o /dev/null -w "v6 %{http_code} %{size_download}\n" https://TARGET_HOST/PATH

Same status code and a similar byte count on both lines is a pass. Anything else is a target where ipv6 proxies for scraping will cost debugging time before they pay off.

Check both before running a host on IPv6:

• AAAA record. The hostname returns at least one AAAA record from the dig loop.
• Same answer on both paths. The curl -4 and curl -6 lines return the same status code and a similar byte count.
• Planned exit class. The exits logged on the IPv6 route are IPv6 addresses, not an IPv4 fallback the gateway picked.

The /64 rate-limit problem

Well-built rate limiters count IPv6 traffic per prefix, not per address.

Cloudflare’s rate limiting documentation (updated June 2026) says requests are blocked once an individual IPv4 address or an IPv6 /64 range crosses the threshold. That page covers the previous version of the product; the docs for the current rate limiting rules do not spell out IPv6 grouping, so test rather than assume. Let’s Encrypt goes wider: its rate limits page (updated August 2026) allows up to 500 new accounts per /48 every 3 hours.

Not every target counts by prefix. Adam Pritchard’s survey of IPv6 rate limiting (February 2022) found popular libraries that still counted single addresses, and Nextcloud moving from per-address to per-/64 blocking after a vulnerability report. That split is why the same IPv6 job meets different limits on different targets.

What that means for a pool. A thousand exits inside one /64 look like one client to a /64-aware target, so a pool size claim says little about how a target counts the job.

To see how a prefix-aware target groups the traffic, log the exit address on every request (from an IP echo endpoint you control), then count prefixes:

import ipaddress

exits = [line.strip() for line in open("exits.txt") if line.strip()]
p64 = {ipaddress.ip_network(f"{ip}/64", strict=False) for ip in exits}
p48 = {ipaddress.ip_network(f"{ip}/48", strict=False) for ip in exits}
print(f"{len(exits)} requests, {len(set(exits))} addresses, {len(p64)} /64s, {len(p48)} /48s")

If 10,000 requests land on 10,000 addresses but only a handful of /64s, a prefix-aware target sees a handful of clients. Rotation is not a way past a limit in any case: pace the whole job inside what the target allows.

Datacenter vs residential IPv6 exits

An IPv6 address says nothing about who is behind it until someone looks up the network that announces it. That lookup is the first thing an anti-bot system does, on either protocol.

Hosting networks. Hosting providers hold large IPv6 blocks and hand them out freely, so many bulk IPv6 pools exit from datacenter ASNs. Those exits carry the same ASN reputation as IPv4 datacenter proxies from the same provider. Targets that block hosting ranges block them here too.

Consumer networks. Home broadband providers and mobile carriers also give subscribers IPv6, so a residential or mobile pool can exit over IPv6 as well. Mobile networks often run IPv6 natively and put IPv4 traffic behind carrier-grade NAT. Consumer exits score better with anti-bot systems, whatever the protocol.

So the label on the pool matters less than the ASN on the exits, the same split as in datacenter vs residential proxies. Take a sample of logged exits and look them up:

sort -u exits.txt | head -20 | while read -r ip; do
  whois -h whois.cymru.com " -v $ip" | tail -n 1
done

Each line returns the ASN, the announced prefix, the country and the network name, the same lookup the guide to ASN targeting uses. A column of the same hosting provider means a datacenter pool, whatever the product page calls it. A spread of consumer ISPs or carriers means a residential or mobile pool. Ask the seller before buying, then check anyway.

Where IPv6 fails silently

Most failures with ipv6 proxies do not throw an exception. They return data that looks fine until someone checks it.

Fallback to IPv4. The target has no AAAA record and the request leaves through IPv4. The job succeeds, but on a different exit class than planned.

Different content. The IPv6 path hits another CDN edge or an older origin. Prices, stock or rankings differ slightly from what IPv4 visitors see.

Prefix clustering. The pool rotates addresses inside a few /64s. Nothing errors at first; the 429s and challenges arrive together, across every address in the prefix.

Geolocation drift. Geolocation data for IPv6 ranges can lag behind IPv4, so a city-level exit can resolve to a different city, or only a country, on the target’s side. Check with the target’s own locale signals, not only with a lookup service.

Running IPv6 rotating proxies for scraping

If the target passes the AAAA and content checks, set the job up so it reaches the right hosts and stays inside the target’s limits.

1. Split the target list. Hosts with working AAAA records go to the IPv6 route; the rest go to IPv4. Do not let the gateway decide by fallback.
2. Rotate per request for stateless fetches, and use a timed session for anything paginated, so a page 2 request does not arrive from a different network than page 1.
3. Budget requests for the whole job, not per address or per /64. A target’s rate limit applies to the client, and rotating addresses or prefixes to stay under it is evasion.
4. Log exits and re-run the prefix count and the ASN sample weekly. Pools change, and so does their spread.
5. Spot-check content parity between the IPv4 and IPv6 paths on a sample of pages every run.

proxymint’s IPv6 tier is sold by the GB, with country, region and city chosen on the order, HTTP and SOCKS5 both included, and the same rotation menu as its other per-GB tiers: every request, a 5 to 60 minute timer, or sticky while online.

For the IPv4 side of the split, the choice follows the target. Lenient targets and API polling run fine on IPv4 datacenter proxies billed per port. Targets that block hosting networks on sight need consumer exits, which is a job for rotating residential proxies, whatever the protocol.

When IPv6 is the wrong choice

On the right target ipv6 proxies work. Decide per target, in this order:

• If the target has no AAAA record, or serves different content over IPv6, IPv6 is not an option there. Use IPv4.
• If the target rate-limits per /64, rotating addresses inside a prefix changes nothing. Pace the job as one client, on whichever protocol the target serves best.
• If the exit ASN sample shows a hosting network and the target scores hosting networks as bots, the protocol will not save the job. Use residential exits.
• If the target serves IPv6 with the same content and accepts the exit network, ipv6 proxies do real work there.

Most scraping stacks end up running ipv6 proxies for a subset of hosts, chosen host by host with the checks above, and IPv4 carrying the bulk.