When a website server enables both IPv4 and IPv6, theoretically, more users can access the site using a dual-stack architecture, improving compatibility and global reach. However, many system administrators encounter problems in actual deployments such as "website accessible via IPv4 but not via IPv6," "IPv6 is normal but IPv4 is inaccessible," or "both stacks are configured but inaccessible in some regions." These failures are often not caused by a single factor but involve multiple levels, including DNS, server network stack, firewall rules, web service listening configuration, route publishing, and differences in ISP links.

　　During the configuration of dual-stack access, DNS resolution errors are the most common source of failure. If a domain name has both A and AAAA records configured, but the IPv6 address pointed to by the AAAA record is not actually enabled on the server, user devices will prioritize connecting to IPv6, leading to access failure. This problem is more common in Apple devices and modern browsers because they default to the Happy Eyeballs policy, prioritizing IPv6. Therefore, when checking for access failures, the first step should be to verify that the DNS records are consistent with the server configuration. The following command can be used to check the resolution results:

dig A example.com
dig AAAA example.com

　　If the AAAA record returns an incorrect IPv6 address, or if that address is disabled, user access will inevitably fail. Deleting the invalid AAAA record or correcting it to the correct IPv6 address will restore access. Some DNS providers' smart resolution may mistakenly distribute IPv6 addresses to regions that do not support IPv6, causing access failures in some areas. In this case, smart resolution needs to be disabled or the node needs to be ensured to support IPv6.

　　Besides DNS configuration, the server's own IPv6 address not being active is also a common cause of access failure. Administrators often forget to set IPv6 as a persistent configuration, causing the IPv6 address to disappear after a server restart. The following methods should be used to confirm whether the current network stack is loading correctly:

ip addr show

　　If you do not see the corresponding global unicast address (usually starting with 2), it means that IPv6 is not enabled. Additionally, you need to check if your network card has IPv6 enabled.

cat /proc/sys/net/ipv6/conf/all/disable_ipv6

　　If the return value is 1, it means that IPv6 functionality is disabled and needs to be enabled.

sysctl -w net.ipv6.conf.all.disable_ipv6=0
sysctl -w net.ipv6.conf.default.disable_ipv6=0

　　Next, ensure that IPv6 is permanently enabled in `/etc/sysctl.conf`, otherwise it will be lost again after a reboot.

　　In an IPv4/IPv6 dual-stack environment, one of the most easily overlooked aspects is the incomplete listening method of the web service. Many web servers only listen on IPv4 by default. For example, the default Nginx configuration `listen 80` is actually equivalent to listening on `0.0.0.0:80`, not `:::80`. This means that when an IPv6 request arrives at the server, the connection will be rejected because no service is listening on the IPv6 port. The following are methods to check this:

ss -tulnp | grep nginx

　　If you only see:

0.0.0.0:80

　　However, it did not appear:

[::]:80

　　This indicates that Nginx is not using IPv6 and requires configuration modification.

server {
    listen 80;
    listen [::]:80;
}

　　The same applies to HTTPS:

listen 443 ssl;
listen [::]:443 ssl;

　　Restart the service after making the changes:

systemctl restart nginx

　　Services such as Apache, Caddy, and Node.js may also experience the same issue, requiring all services to ensure they are listening on IPv6.

　　Incorrect firewall policy configuration is another key factor causing dual-stack access failure. Many servers default to allowing IPv4 rules in firewallD or iptables, while the corresponding ip6tables or nftables rules for IPv6 are not synchronously allowed, resulting in IPv4 access being permitted while IPv6 is blocked. This can be checked using the following command:

ip6tables -L -n

　　If DROP exists on port 80 or 443, then the port needs to be allowed:

ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT

　　Servers using firewallD also need to check if the IPv6 zone is enabled:

firewall-cmd --list-all

　　If you do not see a v6 address or IPv6 rule, you need to do the following:

firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

　　Some cloud servers also offer security groups. A common problem is that the security group allows IPv4 ports but not IPv6 ports, causing traffic to be directly blocked by the cloud platform. You need to go to the console and allow IPv6 ports 80 and 443 simultaneously.

　　If you still encounter access problems after confirming the above steps are correct, it's mostly related to IPv6 routing or the ISP's backhaul link. For example, although the server is configured with an IPv6 address, it may not have correctly assigned a gateway, causing outbound IPv6 requests to fail to reach the public network. Check the default IPv6 route using the following command:

ip -6 route

　　Under normal circumstances, it should include:

default via 2408:XXXX::1 dev eth0

　　If not, you need to add the route manually:

ip -6 route add default via <Gateway address>

　　Some cloud providers require enabling IPv6 routing in the control panel; otherwise, even if the server is bound to IPv6, it will not be able to communicate properly. Furthermore, some regional ISPs have incomplete IPv6 support, meaning users may be able to resolve AAAA addresses but cannot access the website. In this case, online tools can be used to check global IPv6 reachability to determine if the issue is with the ISP's network.

　　Another complex situation is where the server has enabled IPv6, but resources referenced within the website (such as images, scripts, and APIs) are still bound to IPv4 addresses. Clients are forced to access these resources using IPv6, causing resource loading failures and page rendering issues. Cross-protocol incompatibility of front-end resources is particularly common; therefore, it is essential to ensure that all resources referenced within the site support dual-stack access or use domain names for access.

　　After fixing dual-stack access issues, it is recommended to perform local testing using curl.

curl -4 http://example.com
curl -6 http://example.com

　　If both return correct results, it means that IPv4 and IPv6 are working successfully. Additionally, you can perform a local traceroute test:

traceroute -6 example.com

　　This is used to confirm the existence of link blockage.

　　To prevent future failures, a continuous IPv6 monitoring mechanism needs to be established, including: detecting changes in IPv6 values, periodically verifying the correctness of AAAA records, monitoring link latency, and automatically detecting web service listening protocols. Dual-stack environments are more complex than single-stack environments; therefore, continuous monitoring is crucial to ensuring the long-term stable operation of the website.