If you've noticed your browser consistently choosing IPv4 connections even when IPv6 is available, you're not alone. This behavior is often misunderstood as a simple preference setting, but the reality is far more complex. Modern browsers implement sophisticated algorithms to ensure the fastest, most reliable connection possible—and sometimes that means choosing IPv4 over IPv6, even when both protocols are available.
At the heart of browser protocol selection lies the Happy Eyeballs algorithm, formally defined in RFC 8305 (Happy Eyeballs Version 2). This algorithm was designed to solve a critical problem: how to make dual-stack applications responsive without frustrating users with long connection timeouts.
When your browser attempts to connect to a website that supports both IPv4 and IPv6, Happy Eyeballs doesn't simply try one protocol and wait for it to fail. Instead, it:
This parallel racing approach means users experience minimal delay regardless of which protocol ultimately succeeds. The algorithm is entirely implemented within the browser and cannot be influenced by operating system settings.
Different browsers implement slightly different timing parameters:
Key insight: Safari is currently the only major browser that fully implements all Happy Eyeballs features, including dynamic IPv4 connection attempt delays and intelligent address interlacing.
Several factors can cause your browser to prefer IPv4 even when IPv6 is available:
The most common reason browsers avoid IPv6 is broken IPv6 connectivity. Your device might have an IPv6 address configured, but if the actual path to the destination fails or times out, your browser learns to avoid IPv6.
Windows IPv6 Health Checks: Modern Windows systems (Windows 7 and later) periodically test IPv6 connectivity. If these health checks fail, applications including Edge and legacy Internet Explorer will preferentially use IPv4 until IPv6 passes health checks again.
Symptoms of broken IPv6:
The speed at which DNS servers respond to AAAA (IPv6) versus A (IPv4) record queries significantly impacts protocol selection.
If your DNS resolver:
...then your browser may establish the IPv4 connection before the IPv6 DNS lookup even completes.
DNS parallelism optimization: Some resolvers implement partial parallelism—if the AAAA query doesn't respond within 500ms, they start the A query while waiting. This helps minimize the impact of slow IPv6 DNS responses.
Even with working IPv6, the actual network path quality matters:
Your browser's Happy Eyeballs implementation will consistently choose the faster protocol.
Some Internet Service Providers and network configurations inadvertently disadvantage IPv6:
While browsers implement their own Happy Eyeballs logic, the operating system's address selection policy also plays a role through the getaddrinfo() function.
Linux systems using glibc control IPv6/IPv4 preference via /etc/gai.conf:
Default behavior: IPv6 addresses returned first by getaddrinfo()
To prefer IPv4, edit /etc/gai.conf:
# Find and uncomment this line, then change the weight to 100:
precedence ::ffff:0:0/96 100
Important: When modifying gai.conf, you must supply the complete configuration. Any custom configuration replaces the entire default configuration.
Example complete configuration prioritizing IPv4:
# IPv4 addresses
precedence ::ffff:0:0/96 100
# IPv6 addresses
precedence ::/0 40
label ::1/128 0
label ::/0 1
label 2002::/16 2
label ::/96 3
label ::ffff:0:0/96 4
label fec0::/10 5
label fc00::/7 6
label 2001:0::/32 7
Windows uses the netsh command to configure IP prefix precedence:
View current policy:
netsh interface ipv6 show prefixpolicies
Prefer IPv4 (set IPv4-mapped IPv6 address precedence higher):
netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 50 0
Reset to defaults:
netsh interface ipv6 reset
macOS has limited user-configurable options for protocol preference. The operating system automatically prefers whichever protocol is "faster" for each destination. As of macOS 10.11 (El Capitan) and later, IPv6 receives a slight preference but falls back to IPv4 based on network conditions.
Modern Chrome (version 12 and later) provides no user-accessible configuration for IPv6 preference. The browser:
Historical note: Chrome versions older than 12.0 had an "Enable IPv6" button at chrome://net-internals/dns, but this has been removed.
Firefox implements the same fast fallback mechanism as Chrome but provides more configuration options:
Access configuration: Navigate to about:config
Key settings:
network.dns.disableIPv6 = false (default, enables IPv6)
network.http.fast-fallback-to-IPv4 = true (enables Happy Eyeballs)
To completely disable IPv6 (not recommended):
about:confignetwork.dns.disableIPv6trueWarning: Disabling IPv6 entirely prevents your browser from accessing IPv6-only resources and doesn't align with Internet standards.
Safari provides the most sophisticated Happy Eyeballs implementation with dynamic connection attempt delays. Configuration is minimal and handled automatically by macOS network preferences.
chrome://net-internals/#dns
Developer Tools > Network tab
[2001:db8::1]:443Browser extensions:
about:networking#dns
Developer Tools > Network tab
Test DNS resolution:
# Query both A and AAAA records
dig example.com A
dig example.com AAAA
# Or using nslookup
nslookup -type=A example.com
nslookup -type=AAAA example.com
Test actual connectivity:
# Force IPv4
curl -4 https://example.com
# Force IPv6
curl -6 https://example.com
# Test with timing
curl -w "Connect: %{time_connect}s\n" https://example.com
The best way to understand your browser's actual behavior is to use a comprehensive IPv6 testing tool.
Recommended: test-ipv6.run
Visit https://test-ipv6.run for comprehensive protocol preference detection that includes:
The dual-stack test is particularly valuable because it reveals what your browser does when both protocols are available—the real-world scenario where Happy Eyeballs matters most.
Most likely causes:
Solution: Run comprehensive testing at test-ipv6.run to identify the specific issue. Check latency comparison results.
Diagnosis: This indicates your Happy Eyeballs implementation may be broken or your browser is incorrectly failing over.
Possible causes:
Solution: Test with multiple browsers to isolate the issue. If consistent across browsers, investigate network infrastructure.
Diagnosis: Windows IPv6 health checks failing, or your ISP's IPv6 routing becoming unreliable.
Solution:
When investigating IPv4 preference issues:
Verify IPv6 connectivity exists
fe80::)Test actual IPv6 reachability
ping6 google.com (Linux/macOS) or ping -6 google.com (Windows)Compare protocol latency
Check DNS resolution speed
Examine browser debugging tools
Test across multiple browsers
Review OS-level configuration
Browser preference for IPv4 over IPv6 is rarely a simple configuration choice. Modern browsers implement sophisticated Happy Eyeballs algorithms designed to provide the fastest, most reliable connection regardless of protocol. When your browser chooses IPv4, it's usually because:
Rather than forcing protocol preference, focus on identifying and fixing the root cause. Use comprehensive testing tools like test-ipv6.run to diagnose your specific situation, and work with your ISP or network administrator to improve IPv6 performance if issues are discovered.
The future of the Internet is IPv6, but the path there must be smooth for users. Happy Eyeballs ensures that transition happens transparently, choosing the best protocol for each connection without user intervention.
Last updated: 2025