IPv6 Behind a Proxy Fails in Three Different Places. Learn to Tell Them Apart.

A vendor says "IPv6 supported". You buy a plan, request a v6 address through the exit, and nothing comes back. Support insists the exit is dual-stack. Your logs disagree. Both of you may be right, because IPv6 behind a proxy is not one capability.

It is three: the exit can carry v6, the client can ask for v6, and the target has a v6 address. A failure in any of them looks identical from outside — a timeout.

Three segments, three different owners

The egress segment belongs to the vendor: whether packets leaving their network toward a v6 prefix are routed at all. The client segment is yours: which family your tool resolves and which request type it emits. The target segment belongs to whoever runs the site.

Most stalled tickets merge those three into one question. Ask a vendor "does it support IPv6" and the honest answer depends on which segment they think you mean.

Test the target first, because it is free. Then the client, which you can reproduce at no cost. The exit comes last, since proving it needs a purchased credential and a request you cannot fake from outside.

The protocol already has a field for this

SOCKS5 was specified with IPv6 in mind. RFC 1928 defines three address types in the request, and one is a 16-byte IPv6 literal. A conforming exit therefore needs no special mode to reach a v6 destination; it needs a route.

That explains the most common false negative. A client that never emits ATYP=0x04 keeps resolving to v4 and connecting over v4, on an exit that would have carried v6 fine. The tunnel did not refuse it — it was never asked.

An exit returning REP=0x08 (address type not supported) lacks the v6 branch in its parser. REP=0x03 (network unreachable) is different: the parser understood you, and routing said no.

A probe that separates the layers

Send the request yourself, so no library can quietly downgrade the family for you.

import socket, struct def v6_via_socks(proxy, target6, port, timeout=8): s = socket.create_connection(proxy, timeout) s.sendall(b"\x05\x01\x00") # greeting, no auth  if s.recv(2) != b"\x05\x00": raise RuntimeError("exit rejected no-auth method") req = b"\x05\x01\x00\x04" + socket.inet_pton(socket.AF_INET6, target6) s.sendall(req + struct.pack("!H", port)) rep = s.recv(4) if len(rep) < 4: return "no reply (dropped)" codes = {0x00: "ok", 0x01: "general failure", 0x03: "network unreachable", 0x04: "host unreachable", 0x05: "connection refused", 0x08: "atyp unsupported"} return codes.get(rep[1], hex(rep[1])) 

no reply and atyp unsupported mean very different things to a vendor, and telling them apart is usually what resolves the ticket.

Which side resolves the name

Who does DNS is decided by the request type, not by a setting.

Sending a hostname and letting the exit resolve is convenient, but it hides the family decision inside someone else's resolver. If you care about v6, resolve locally, inspect the answer, and send the type you want.

Resolution also explains a leak unrelated to traffic. A client that resolves locally asks your own resolver for AAAA records even when all traffic leaves through the exit. The packets are tunnel-escaped; the lookups are not.

The vendor's price list has no IP-version column

Plans list concurrency, traffic, session length, and regions. Address family is almost never a row, so "IPv6 supported" carries no plan-level meaning, and two plans from one vendor can differ because they terminate on different pools.

Verify per plan, inside the trial window: run the probe against two or three v6 destinations. One success proves routing exists. Repeated atyp unsupported proves the parser has no v6 branch.

Watch for the half-measure too — inbound v6 on the dashboard while the egress stays v4.

Targets that only publish AAAA

Some hosts are v6-only by design, and a v4 exit cannot reach them. Check the records first: an empty A with a populated AAAA means the answer is architectural, not a setting.

The reverse case is more confusing. A site publishes both families but the v6 front end is broken — an expired certificate, or a path that blackholes after the handshake. A client that prefers v6 fails and never falls back.

Five mistakes that keep the ticket open

1. Testing with a v4 echo page. It proves the tunnel works, not the family you care about.
2. Letting the library choose. Many clients silently retry over v4, so a v6 failure never surfaces.
3. Reading a timeout as a refusal. A dropped packet and REP=0x08 are different diagnoses.
4. Ignoring bracket syntax. Missing [ ] around a v6 literal gives a config that looks fine and resolves to nothing.
5. Swapping the exit before testing the target. Half the "vendor lied" cases end at an AAAA-only destination.

FAQ

Is a dual-stack exit the same as a v6-capable proxy?
No. Dual-stack describes the host's own interfaces. What matters is whether the request parser accepts a 16-byte address and whether routing exists onward.

Why does the same credential work in one tool and fail in another?
Because the family decision lives in each tool's resolver and connection logic, not in the proxy string.

Can I use v6 to dodge v4 rate limits?
Not reliably. Limits are usually keyed on the account, the ASN, or the subnet, and one v6 allocation can cover a range that is trivially bucketed.

Does a v6 exit leak my real address?
Not through the tunnel. But local resolution and any direct connection path still can, which is why the resolution side matters as much as the egress.

Where this sits in an egress stack

Address family is one property of an exit among several, and the one most often assumed rather than measured. The IPv6 three-segment diagnosis on socks5ip.com.cn walks the same split with per-plan verification steps, and the IP check centre shows what your exit looks like from outside before you touch client settings.

Test the target, then the client, then the exit — and keep the reply code. It is the only part of the report a vendor cannot reinterpret.