Disclosure: I work with 98IP. This is vendor-neutral guidance for authorized connectivity testing.
Happy Eyeballs reduces the delay users feel when either IPv6 or IPv4 is slow. But once a proxy gateway is added, a single “IPv6 won” metric can describe the wrong connection.
There are at least two legs:
client --(IPv4 or IPv6)--> proxy gateway --(IPv4 or IPv6)--> destination
The client usually races addresses for the gateway. The gateway may resolve and connect to the destination independently. An IPv6 gateway connection can therefore produce an IPv4 exit, and an IPv4 gateway can use an IPv6 target path.
The IETF HAPPY Working Group's July 2026 Happy Eyeballs v3 draft is still an active Internet-Draft, not a final standard. Its work on scheduling, DNS results and remembered outcomes is a useful reason to make proxy measurement explicit now.
Observe four layers
DNS
Record who resolves the gateway and destination, the A/AAAA answer sets, order, resolver region, cache state and time. SOCKS hostname mode can move target DNS to the gateway; a client-resolved SOCKS request does not.
Gateway connection
Record the first and second attempt start times, gateway family, handshake result, TLS, proxy authentication, winner and cancellation delay. This is the leg a local Happy Eyeballs implementation usually controls.
Tunnel
Record CONNECT/SOCKS status, remote-DNS mode, target family when observable, tunnel time and a structured category such as:
gateway_unreachable
proxy_auth_failed
target_connect_failed
tunnel_timeout
Application result
Record first byte, complete response time, useful-result status and bytes. Keep destination policy results such as 403 and 429 out of the gateway transport score unless evidence connects them to the gateway.
Build a bounded matrix
Use a gateway and destination you own or have explicit permission to test:
- IPv6-only gateway, remote target resolution.
- IPv4-only gateway, same target and request.
- Dual-stack gateway with the production racing logic.
- Dual-stack gateway with a client-resolved destination control.
- Preferred-family delay or loss injected in controlled infrastructure.
- Both families healthy, using cold and warm connection pools.
Keep credentials, region, target, payload, timeout and workload purpose constant. Change one variable per comparison.
The useful metrics are not just connection time:
- winning gateway family;
- observable target family;
- p50/p95 first byte;
- tunnel and complete-response success;
- mid-session reset rate;
- fallback rate and fallback success;
- extra connection attempts per useful result;
- traffic and cost per authorized useful result.
Failure injection must not duplicate the request
A racing algorithm should race connection setup, not execute a purchase, message, upload or other state-changing action twice. Use an idempotent authorized canary, cap attempts and verify losing sockets, timers, pages and sessions are cleaned up.
Do not convert a target 429 into faster IP rotation. Do not claim end-to-end IPv6 because the client reached an IPv6 gateway. And do not penalize a provider for a destination policy decision.
Procurement questions
Ask whether the provider offers dual-stack, IPv4-only and IPv6-only gateway controls; where SOCKS hostname DNS runs; whether target family appears in sanitized logs; whether authentication, allowlists, concurrency and pricing differ by family; and whether direct fallback is impossible after gateway failure.
A public exit-IP check is useful, but it does not explain both routing decisions.
For more practical proxy and Internet-operations guidance, visit 98IP.
Operate only on authorized gateways, destinations, accounts and data. Respect website terms, robots directives, privacy obligations and rate limits. Address-family racing is a reliability technique, not a way to bypass a publisher's decision.
``
Top comments (0)