Confirm that the failure is specific to IPv6
When a browser opens a website, it may try both IPv4 and IPv6 and use whichever connection succeeds first. That fallback can hide an IPv6 problem: one visitor sees a working page, while another encounters a delay or failure. Start by recording the exact hostname and URL that fail. The root domain and a hostname such as www.example.com can have different DNS records and different server settings.
From a network with working IPv6 access, compare requests to the same URL using curl -4 -I https://www.example.com and curl -6 -I https://www.example.com. The -I option requests response headers, which is often enough for an initial check; repeat without -I if the site treats HEAD requests differently. A successful IPv4 request and a timed-out IPv6 request point toward the IPv6 path. If IPv6 returns an HTTP error instead, the connection may be reaching a server but encountering a configuration or application problem. Redirects also matter: note whether the failure occurs on the original hostname or a hostname in the redirect destination.
Check DNS before changing the server
An A record supplies an IPv4 address; an AAAA record supplies an IPv6 address. Query both for the failing hostname, for example with dig A www.example.com and dig AAAA www.example.com. If there is no AAAA record, ordinary DNS is not directing visitors to that hostname over IPv6. If a AAAA record exists, check whether its address belongs to the service intended to answer for the site. A leftover address from an old host or a record created for the wrong hostname can send IPv6 visitors elsewhere while IPv4 remains healthy.
Compare the answers from your usual resolver with the DNS configuration at the domain’s authoritative provider if they disagree with recent changes. Caches can continue serving older answers until their time to live expires. Also check whether the hostname is behind a CDN or reverse proxy: its public AAAA record may point to the proxy rather than your origin server. In that case, distinguish a visitor-to-proxy failure from a proxy-to-origin failure before editing origin records. Avoid posting full diagnostic output publicly if it contains internal hostnames or other sensitive details.
Locate the failing part of the IPv6 path
First make sure the test client itself has usable IPv6 connectivity. An IPv6 address on a device does not, by itself, prove that it has a working route to the internet. Try the same website from another IPv6-capable network. If the failure happens only on one network, investigate that network’s routing, router, or filtering before assuming the website is at fault. If multiple independent IPv6 networks fail, focus on the address published for the site and the service behind it.
On a server you manage, verify that its assigned IPv6 address and route are correct and that the web service listens on IPv6 for the required port. A service listening on an IPv4 address does not necessarily listen on IPv6. Check the host firewall and any provider-level firewall or load balancer as well; each must allow the intended IPv6 traffic. A connection timeout may indicate a routing or filtering problem, while an immediate refusal often suggests that the address is reachable but nothing is accepting that connection. These are clues, not definitive diagnoses.
If a connection succeeds but the page is wrong, examine the virtual host, reverse-proxy, and TLS settings for the hostname. IPv4 and IPv6 requests should reach the intended site and present a certificate valid for the hostname. Testing only the numeric IPv6 address can mislead you because websites and TLS commonly rely on the requested hostname. If small responses work but larger pages stall, consider a path issue such as blocked ICMPv6 messages needed for packet-size discovery; investigate rather than broadly disabling ICMPv6.
Fix the cause and verify both address families
Make the smallest change supported by your tests. Correct a stale AAAA record if it points to the wrong destination. If the address is right, repair the IPv6 listener, route, firewall rule, proxy configuration, or site settings as appropriate. Where IPv6 service cannot be restored promptly, removing an incorrect AAAA record may stop directing new connections to a broken endpoint, but consider visitors who rely on IPv6 and allow for cached DNS answers. Do not treat record removal as a substitute for understanding an intermittent fault.
After the change, repeat the IPv4 and IPv6 requests for every affected hostname, including any redirect targets. Check that both paths reach the intended page over HTTPS, not merely that a port is open. Test from more than one network when possible, and allow time for DNS caches to update if you changed records. Keeping the original symptoms, test results, and final fix together makes the next connectivity problem much easier to diagnose.
