Guides / Network

When IPv6 works halfway: a DNS-first checklist

Having an IPv6 address is only the first layer; test DNS, routing, VPN coverage, MTU and browser fallback separately.

PUBLISHED · UPDATED · 9 MIN

The most annoying IPv6 failure is partial: a test says “supported,” some sites are instant, others wait for seconds, and disabling IPv6 appears to cure everything.

That last observation is evidence that the IPv6 path matters. It does not identify DNS, routing, VPN coverage, MTU or application fallback as the cause.

An address is only the first layer

An address beginning with fe80:: is normally link-local. Even a global address does not prove that the device has a working default route, resolver or upstream connection.

  1. Address assignment
  2. AAAA resolution
  3. Default route
  4. End-to-end reachability
  5. TLS and HTTP
  6. Timely IPv4 fallback

Test DNS first

A records carry IPv4 and AAAA records carry IPv6. Restore automatic DNS as a baseline before comparing private DNS, router DNS and browser secure DNS. The DNS lookup guide explains the record types.

Compare IPv4 and IPv6 to the same target

ping -6 example.com
curl -6 -I https://example.com
curl -4 -I https://example.com

Command availability varies, and a server may block ping, so no single command is a verdict. The comparison is what matters.

Receiving an IPv6 address is like receiving a ticket. It does not prove that the track, transfers and destination are working.

Why a browser waits and then succeeds

Modern clients race or stagger IPv6 and IPv4 attempts using ideas such as Happy Eyeballs. A path that silently drops traffic rather than failing quickly can delay fallback. “It eventually opened” is not proof that IPv6 is healthy.

VPNs and proxies frequently split the path

A proxy may carry IPv4 while IPv6 remains direct; a VPN may block IPv6; per-app rules may route a browser and a test tool differently. Pair this check with the WebRTC candidate guide when privacy is part of the problem.

When DNS and routing look correct

Small requests succeeding while larger pages or TLS handshakes stall can indicate MTU or path-MTU trouble. Before changing MTU manually, test another network. A phone hotspot working while home Wi-Fi fails sharply narrows the scope.

A controlled order

  1. Disable proxy and private DNS to record a direct baseline.
  2. Check address scope, default route and A/AAAA answers.
  3. Compare IPv4 and IPv6 against one target.
  4. Repeat on another network.
  5. Restore the proxy and verify IPv6 coverage.
  6. Investigate router firmware, firewall and MTU only when evidence points there.

Temporarily disabling IPv6 is reasonable when a class, meeting or upload must work now. Keep the original setting and evidence, then return to diagnose it. A workaround is not automatically the final repair.