A device on a dual-stack network can often reach the same service over both IPv6 and IPv4. DNS may return AAAA records for IPv6 addresses and A records for IPv4 addresses, leaving the client with several possible routes to the destination.
Preferring IPv6 and waiting for a complete failure before trying IPv4 sounds orderly, but it can create a visible pause when the IPv6 path is broken or unusually slow. The reverse ordering can hide IPv6 even when it offers a healthy path. Happy Eyeballs avoids both extremes by giving preferred connection attempts a short head start while allowing another address family to compete soon afterward.
The practical effect is simple: a working path can win before a bad path consumes a long timeout.
Dual-stack reachability can be uneven
IPv4 and IPv6 do not necessarily travel through the same routers, providers, tunnels, firewalls, or translation systems. A host can therefore have valid configuration for both families while only one path works correctly for a particular destination.
A DNS response also proves only that addresses were published. It does not prove that every returned address is reachable from the client at that moment. Routing faults, filtering mistakes, stale network state, captive networks, tunnel failures, and provider problems can affect one family without affecting the other.
This creates a difficult choice for applications. A strict serial strategy might try the first IPv6 address, wait through a transport timeout, then move to another candidate. A person opening a page sees the delay even though a usable IPv4 path was available from the start.
Happy Eyeballs treats address selection as a latency-sensitive competition rather than a rigid sequence with long failure waits.
Connection attempts overlap after a short delay
The algorithm does not normally launch every possible connection at exactly the same instant. Doing that would waste packets, socket state, server work, and local resources on connections that are likely to be abandoned.
Instead, candidates are ordered according to address-selection policy, then connection attempts are paced. The preferred candidate receives an initial opportunity to connect. If it has not succeeded after a short interval, another candidate can start before the first attempt has formally failed.
If the later attempt succeeds first, the application can use that connection and cancel or close competing attempts. If the preferred path succeeds promptly, the fallback attempt may never need to progress far.
This controlled overlap is the central mechanism. It converts a potentially long failover delay into a much shorter race while avoiding an uncontrolled burst toward every address returned by DNS.
Modern Happy Eyeballs behavior is specified in RFC 8305, which refines earlier work and covers both DNS resolution timing and connection-attempt scheduling. Implementations can differ in details, but the goal remains consistent: preserve IPv6 use when it performs normally while keeping a damaged path from imposing a large user-visible penalty.
The fastest successful attempt wins the current connection
A race does not permanently declare one address family superior. It selects a usable candidate for the connection being established.
Suppose a service has both IPv6 and IPv4 addresses. The client begins with an IPv6 candidate. The IPv6 SYN receives no useful response, so an IPv4 attempt starts shortly afterward. If IPv4 completes first, the application proceeds over IPv4 rather than waiting for the IPv6 attempt to reach its full timeout.
On another network, the IPv6 handshake may complete immediately. In that case IPv6 wins naturally, preserving the intended preference without adding a fallback penalty.
This behavior is important during partial outages. A broken IPv6 route can otherwise make a dual-stack service feel slower than an IPv4-only service, creating pressure to disable IPv6 even though the fault may be temporary or local. Connection racing limits that penalty while still allowing healthy IPv6 paths to be selected.
DNS timing is part of the race
Address-family selection begins before a transport handshake if DNS answers do not arrive together. A resolver path might return one record type sooner than the other, and an application that waits too long for a complete set of answers can add latency before any connection starts.
A robust Happy Eyeballs implementation coordinates name resolution and connection scheduling. It can begin useful work when suitable addresses arrive while still giving the other family a chance to participate. The exact behavior depends on the operating system, resolver interface, browser, runtime, or application network stack involved.
This means packet captures can show more than a simple pair of simultaneous SYN packets. DNS queries, cached answers, address ordering, prior network information, and transport behavior can all influence which candidate starts first and how quickly a fallback appears.
The mechanism is therefore broader than a single fixed timer. It is a policy for avoiding excessive delay across multiple viable address candidates.
A winning family does not prove the other family is broken
If IPv4 wins one connection race, IPv6 may simply have been a little slower. Network paths naturally vary in round-trip time, queueing, server placement, and handshake processing. A narrow timing difference is not enough to diagnose a fault.
Likewise, seeing an IPv6 attempt abandoned does not automatically indicate packet loss. The competing connection may have completed first, causing the client to stop work that was no longer needed.
Troubleshooting therefore needs more context than the selected socket alone. Repeated failures, missing responses, ICMP errors, route information, DNS data, and tests across several destinations provide stronger evidence about actual reachability.
Happy Eyeballs can also mask a persistent defect from casual observation. Users may see a site open normally because IPv4 consistently rescues failed IPv6 attempts. The experience is good, but network operators may still want to repair the IPv6 path because each fallback adds unnecessary connection work and can affect applications that do not implement equivalent racing.
Racing is not the same as sending application traffic twice
The competing attempts are candidates for one logical connection. Once a winner is selected, the application normally continues on that connection and discards the alternatives.
That distinction matters for protocols with side effects. Happy Eyeballs is designed around establishing connectivity, not duplicating purchases, uploads, messages, or other application operations across both families. The connection manager decides which transport becomes usable before ordinary application exchange proceeds through the selected path.
Transport evolution can change the exact packets involved. TCP commonly exposes the race as competing connection handshakes, while applications using QUIC operate over UDP and have their own connection establishment behavior. The broader address-selection problem still exists whenever multiple destination addresses or network paths are available.
Proxies and VPNs can also move the decision point. If an application sends traffic to a proxy, the proxy may perform destination resolution and address-family selection instead of the local application. A VPN can alter routes so that IPv4 and IPv6 behavior differs from the underlying access network.
Connection racing makes dual-stack failures less disruptive
Happy Eyeballs is a compatibility mechanism for a network where several address candidates can be valid but do not always perform equally. It does not require a client to abandon IPv6 preference, and it does not force users to wait through a long IPv6 failure before IPv4 gets a chance.
By staggering connection attempts and accepting the candidate that becomes usable first, the client keeps normal IPv6 operation fast while gaining a prompt escape path when reachability is impaired. The losing attempt is a small amount of extra work in exchange for avoiding a much larger connection stall.
That tradeoff helps dual-stack networking behave more like a resilient set of choices and less like a strict chain in which one damaged path blocks every healthy option behind it.