IPv4 and IPv6 are separate address systems that can carry visitors to the same website. When a site fails over IPv6 but works over IPv4, the IPv6 route is broken, so test each route separately starting with name records.
Most visitors still reach you through IPv4, so the fault can hide for months. Mobile networks, office networks, and automated checks often prefer IPv6 first. That split explains reports where the site is down for one person and fine for another.
Table of Contents
- Do both address records point to the right server?
- Is the server listening and open on IPv6?
- Why do WordPress and Drupal hide a one-sided fault?
- What should managers and campaign owners ask for?
Do both address records point to the right server?
Every name has two kinds of address records. An A record points browsers to the IPv4 server. An AAAA record, with four As, points browsers to the IPv6 server. A split often starts when the AAAA record points to an old or wrong machine.
Open the site records and compare both answers. Look for these warning signs: Correct the wrong AAAA record at your name provider. Keep the old entry out of service until saved copies refresh. Retest both addresses directly before telling the team the fault is fixed.
- AAAA points to a host you no longer use
- A and AAAA lead to different servers
- IPv4 answers quickly while IPv6 times out
Is the server listening and open on IPv6?
A correct record means nothing if the server ignores it. The web service must bind to the IPv6 address and serve the same site as IPv4. The firewall must also allow web ports on IPv6, not only on IPv4. Test each path by address, not by name. Fetch the home page over IPv4, then fetch it over IPv6.
Compare status codes, redirects, and certificates. A timeout points to firewall or routing, while a fast error points to server setup. Shared hosts and added address blocks cause many misses. The host may add IPv6 to the plan without opening it by default. Added rules for IPv4 do not protect IPv6 unless you copy them across.
Why do WordPress and Drupal hide a one-sided fault?
Content systems can serve a saved page to most people while direct visits fail. A cache, security service, or delivery network may fetch your origin over IPv4 and show that copy to everyone. Your IPv6 fault then shows only when someone connects to the origin itself. Plugins and settings add more traps.
Hard-coded addresses, IP allow lists, login limits, and redirect rules often store only the IPv4 form. Update routines and feed checks may also use IPv4, so the dashboard reports no problem. Check the origin apart from the outer layer. Pause the outer cache briefly in a test window and request the origin over each protocol. Confirm uploads, forms, logins, and scheduled tasks behave the same on both paths.
What should managers and campaign owners ask for?
Treat intermittent reports as protocol clues, not user error. Ask each reporter for network type, device, location, and exact error text. A pattern across mobile carriers or offices often marks IPv6 preference. Give the developer a clear test request.
Ask for the A and AAAA values, the response of each address, and the firewall state for each protocol. Ask which server answered, since staging and old hosts explain many splits. Protect landing pages and budgets during the fix. Send paid traffic to a checked IPv4-stable address only if both paths cannot be repaired fast. Ask for a screenshot of passing IPv4 and IPv6 checks before closing the ticket.
