IPv4 or IPv6 proxy? Address space, cost and compatibility

This guide separates the two protocols along four axes: address space, how target sites count rate limits, cost model and compatibility. It shows how to check a target's IPv6 support with dig, what to watch on the client side and how to measure success rate with a small sample. The examples use the WeProxy gateway gw.weproxy.com.tr:8989, with USER and PASSWORD as credential placeholders.

What is the difference between an IPv4 and an IPv6 proxy?

A proxy forwards your request to the target from its own exit address. If that exit address is IPv4, the target server sees an address like 203.0.113.10. If it is IPv6, it sees something like 2001:db8:4a1f::25. The connection between client and proxy and the proxy protocol (HTTP or SOCKS5) are independent of this choice.

The difference shows up on the exit leg. A proxy with an IPv6 exit has to connect to the target over IPv6. If the target has no IPv6 address, there is nothing to connect to. An IPv4 exit does not carry this limitation, because the vast majority of sites that publish IPv6 also keep IPv4 (dual-stack).

Address scarcity versus address abundance

The IPv4 address space is 32 bits, roughly 4.3 billion addresses in total. IANA's free pool ran out in 2011, and the regional registries moved new allocations to waiting lists and the transfer market in the years that followed. Every IPv4 address is therefore a separate cost item, and providers reuse it again and again.

The IPv6 address space is 128 bits (RFC 8200). RFC 4291 reserves the lower 64 bits of an address for the interface identifier, so the standard block assigned to a single local network is a /64. One /64 holds 2^64 addresses, about 18 quintillion. A single /48 held by a provider contains 65,536 /64s. With IPv6 the problem is not finding addresses but how the target groups them.

Why do sites rate-limit IPv6 traffic per /64 or /48?

With IPv4, rate limits are usually kept per address, because one address typically means one subscriber or one group behind a NAT. That logic breaks with IPv6. A single device can generate as many addresses as it likes inside its own /64; the privacy extensions in operating systems (RFC 8981) already do this on a regular schedule. A site counting per address would treat every new address as a new visitor.

That is why many WAFs and rate limiters aggregate IPv6 addresses at the /64 prefix level. Some go a step further and count at /56 or /48, since home and corporate networks are usually assigned blocks of that size. As a result, a thousand different addresses from the same /64 can behave like a single client in the target's eyes.

This means the real criterion when choosing an IPv6 proxy is "how many separate prefixes", not "how many addresses". A pool with a huge address count packed into one /64 gets a 429 like a single IP on a target that counts per prefix. When blocks are spread across different /64s and /48s, the counter spreads too. The level a target counts at is not visible from outside; you have to measure it with a small test.

Reputation travels with the prefix in the same way. When one address in a /64 is abused, the ban is often applied to the whole prefix. Most IPv6 exits come from datacenter networks, and their ASN is public. For the detection gap between datacenter and residential IPs, see the residential vs datacenter comparison; the same signals apply to IPv6.

How does the cost model differ between IPv4 and IPv6 proxies?

Because IPv4 is scarce, IPv4 proxy pricing is tied to addresses or traffic. Rotating IPv4 products (datacenter, residential, mobile) are billed per GB: you use a large shared pool and pay for the traffic you carry. Static IPv4 products are paid per address per period, because that address is reserved for you for the whole period.

With IPv6 the cost of an address drops close to zero. That shifts the calculation from addresses to ports and time. WeProxy's Rotating IPv6 Proxy is sold in monthly, quota-free packages per port; IPv6 port packages have no bandwidth cap. Static Datacenter IPv6 packages come per address, monthly, with unlimited bandwidth.

The practical outcome is this. For high-volume jobs with small responses per page, a per-GB model grows quickly; a quota-free per-port model makes cost predictable. For low-volume jobs that need high trust, per-GB residential IPv4 delivers results with less total traffic. Current packages and starting options are listed on the product pages.

Which sites work with an IPv6 proxy?

An IPv6 proxy only works if the exact hostname you request has an AAAA record. An A record maps a hostname to an IPv4 address, an AAAA record to an IPv6 address. If the proxy finds no AAAA when resolving the target, it has no address to connect to from the IPv6 exit. The result is a connection error on the client side: usually 502 with an HTTP proxy, and a "host unreachable" or "address type not supported" reply with SOCKS5.

Some major platforms, Google for example, publish AAAA records for their main domains. Many smaller sites, e-commerce stacks and older hosting services offer IPv4 only. Support also varies per hostname: the main domain having an AAAA record while the API subdomain does not, or the other way round, is common. So run the check against every hostname your code actually calls, not against the site's name.

Checking a target's AAAA record with dig

The quickest check is dig. Query the A and AAAA records for the same hostname separately:

# Is there an IPv6 address?
dig AAAA google.com +short

# IPv4 address for comparison
dig A google.com +short

# Check the subdomain your code calls separately
dig AAAA api.example.com +short

If the output contains an address with colons, such as 2a00: or 2001:, an AAAA record exists. If the output is empty, it does not. If the output shows only a name ending in a dot (a CNAME) with no address line below it, there is no AAAA at the end of the chain either. On Windows, the same query is nslookup -type=AAAA google.com.

An AAAA record is a necessary condition but not a sufficient one. Some sites apply different WAF rules over IPv6 or treat IPv6 datacenter prefixes more strictly. The record means "I can connect", not "I will be accepted". The success-rate test below separates the two.

Client side: leave the hostname to the proxy

Your client does not need IPv6 connectivity. The leg between client and gateway can run over IPv4; IPv6 is used only between the proxy and the target. The condition is that the client hands the target to the proxy in a form the proxy can reach over IPv6.

The way to do that is to leave the hostname to the proxy. With an HTTP proxy, CONNECT example.com:443 carries the hostname, and the proxy resolves the AAAA record itself. With SOCKS5, the socks5h:// scheme passes the hostname as a domain name (RFC 1928 ATYP 0x03). If the client resolves the name locally with socks5:// and only gets an IPv4 address, it sends that address to the IPv6 exit and the connection fails. Local resolution is also a DNS leak; details are in the DNS leak guide, and the protocol difference is covered in HTTP vs SOCKS5.

If you use an IP whitelist, there is one more detail. If your server connects to the gateway over IPv6, the address registered in the panel must be that IPv6 address. If the whitelist holds only your IPv4 address, you get a 407. The other causes of this error and the order to check them are in the proxy error codes guide. At WeProxy, username/password and IP whitelist authentication can both be used over HTTP and SOCKS5.

How do you test an IPv6 proxy?

The test has three steps: confirm the exit really is IPv6, verify the target's AAAA record and measure the success rate with a small sample. First, the exit address:

# An echo endpoint that can answer over both IPv4 and IPv6
curl -sS -x "http://USER:[email protected]:8989" https://api64.ipify.org
echo

If the response is an address with colons, the exit is IPv6. If it returns four dot-separated numbers, the exit is IPv4; check the package type and connection details. You can run the same check in a browser with the IPv6 checker tool, and confirm the proxy responds in general with the proxy checker.

Then a small sample against the target:

import socket
import requests

PROXY = "http://USER:[email protected]:8989"
proxies = {"http": PROXY, "https": PROXY}

def has_aaaa(host):
    try:
        return bool(socket.getaddrinfo(host, 443, socket.AF_INET6, socket.SOCK_STREAM))
    except socket.gaierror:
        return False

def success_rate(url, attempts=20):
    ok = 0
    for _ in range(attempts):
        try:
            r = requests.get(url, proxies=proxies, timeout=(10, 30))
            if r.status_code == 200:
                ok += 1
        except requests.exceptions.RequestException:
            pass
    return ok / attempts

host = "example.com"
print("AAAA record:", has_aaaa(host))
exit_ip = requests.get("https://api64.ipify.org", proxies=proxies, timeout=(10, 30)).text
print("Exit IP:", exit_ip)
print("Success rate:", success_rate(f"https://{host}/"))

has_aaaa uses the local resolver; it is a pre-check, not part of the production flow. The actual request goes through the HTTP proxy, and the hostname is resolved at the proxy. Run the same script with an IPv4 package as well. The gap between the two rates shows in numbers how the target treats IPv6 traffic. For setup details, see the Python proxy integration page.

IPv4 vs IPv6 proxy comparison table

The "unit rate limits are counted in" row varies by target. Read it as an assumption to test, not a rule.

Which jobs suit an IPv6 proxy, and which do not?

The scenario where an IPv6 proxy is strong is clear: the target supports IPv6, the job needs a large number of requests and each request is short-lived. Examples:

• Collecting search results and SEO data on large platforms that publish IPv6 (SEO proxy use case).
• Sending high-concurrency requests to API endpoints that have an AAAA record.
• Testing the IPv6 reachability of your own or your client's infrastructure from different countries.
• In web scraping, moving IPv6-ready hostnames into a separate queue and scaling volume there.

The weak scenarios are just as clear. If the target offers IPv4 only, an IPv6 proxy cannot be used for that target. If a page pulls resources from several domains (CDN, API, payment provider) and one of them is IPv4-only, browser automation breaks halfway. If the target is strict with IPv6 datacenter prefixes or expects a residential trust signal, IPv4 residential gives a higher success rate.

A mixed approach is the most robust path for most teams. Split hostnames in two by AAAA record. Route the IPv6-ready ones with a high success rate to the IPv6 pool, and the rest plus critical flows to IPv4. This split produces fewer errors than blindly moving every scrape target to IPv6.

How do you choose an IPv6 proxy product at WeProxy?

The choice depends on how long a session needs to last:

Rotating IPv6 is for high-volume jobs that need no session; per the product page, the IP changes on every request in Datacenter packages and at least every 120 seconds in Residential packages. Sticky IPv6 keeps the same exit for 1 to 120 minutes in login or multi-step flows. Static Datacenter IPv6 is for integrations that need a persistent identity or a whitelist on the other side. All three support HTTP and SOCKS5. For the general difference between sticky and rotating, see the sticky vs rotating guide.

If the target turns out to be IPv4-only, switch to IPv4 products for that flow: Rotating Datacenter IPv4 for high volume, Rotating Residential IPv4 for high trust.

What rules apply when using an IPv6 proxy?

More addresses do not change the target's rules. Widening the pool to get past a per-prefix rate limit is not a solution if it violates the target's terms of service. Respect 429 and Retry-After responses and keep concurrency at a level the target can handle.

If the data you collect contains personal data, obligations under KVKK and GDPR must be addressed separately; this article is not legal advice. Automation should stay on the public surface that the rules allow and run within the WeProxy acceptable use policy.

IPv4 or IPv6: decision checklist

1. List every hostname your code calls, not just the main domain.
2. Run dig AAAA <host> +short for each. Move the empty ones to the IPv4 list.
3. For those with an AAAA record, confirm the IPv6 exit with api64.ipify.org or the IPv6 checker tool.
4. Use an HTTP proxy or socks5h://; leave the hostname to the proxy.
5. Run the same 20-request sample on IPv4 and IPv6 packages and compare success rates.
6. If the rates are close and volume is high, move to IPv6. If the rate is low or the flow is critical, stay on IPv4.
7. If you see 429, assume the target counts per /64 or /48; reduce concurrency instead of blindly growing the pool.

IPv4 is the tool for compatibility, IPv6 the tool for scale. The decision comes not from the protocol itself but from the target's AAAA record and the success rate you measure.