An AAAA record can resolve correctly while every IPv6 connection to your website times out.
For a community website, API or ML endpoint on a DirectAdmin server, test DNS, client connectivity, listening sockets and routing separately. Replace service.example.com and port 443 with your actual public endpoint.
• 1. Check both DNS record types.
Run dig +short A service.example.com and dig +short AAAA service.example.com. Confirm that each address points to the intended server, proxy or CDN. An AAAA record publishes an IPv6 destination; it does not prove that the service is reachable there. If DNS points to a proxy, these requests test that proxy, not direct access to the origin.
• 2. Compare requests from a client with working connectivity.
Run curl -4 -v --connect-timeout 10 https://service.example.com/ and curl -6 -v --connect-timeout 10 https://service.example.com/. For an API or ML endpoint, use the same safe health-check path, request method and authentication for both. Compare the connection, TLS verification and expected HTTP response. An HTTP 403 is not the same failure as a connection timeout.
A failed curl -6 does not automatically implicate the server. On a Linux client, inspect ip -6 addr and ip -6 route, then repeat the request from another network with verified IPv6 connectivity. A configured IPv6 address alone does not prove that the client has a working route. Remove credentials and authorization headers before sharing verbose output.
• 3. Check the public listener.
On the server, run ss -lnt and inspect the service port. A listener on 127.0.0.1 or [::1] is loopback-only. A listener on 0.0.0.0 covers IPv4; [::] is an IPv6 wildcard listener, but whether it also accepts IPv4 depends on socket settings. Do not infer dual-stack reachability from that line alone.
If a reverse proxy handles public HTTPS, check its listener separately from the application backend. A loopback-only backend can be intentional; a missing public listener is a different problem.
• 4. Compare routes and filtering for both families.
Inspect ip -4 addr, ip -6 addr, ip -4 route and ip -6 route on the server. Check that the expected public addresses are assigned and that return routes exist to the test client.
Review the firewall actually in use: nft list ruleset for nftables, or iptables -S and ip6tables -S where applicable. If CSF manages your DirectAdmin server's firewall, inspect its IPv6 configuration too. Include provider-side filtering. An IPv4 allow rule does not prove IPv6 is allowed, and blocking essential ICMPv6 can break IPv6 connectivity.
Record the client network, destination address, connection result and HTTP status for each family. If one verified IPv6 client succeeds and another fails, investigate the failing client's network and path before changing the server. If both fail, use the listener, routing and firewall checks to narrow the cause. Neither disabling IPv6 nor deleting AAAA should be the default fix.
This post was prepared in collaboration with vpsttt. If you run a VPS there, verify its assigned addresses, routing and filtering; do not assume IPv6 support without confirmation for that VPS.
Try the checklist on a service you manage and share which check helped distinguish a client-side failure from a server-side one.
For a community website, API or ML endpoint on a DirectAdmin server, test DNS, client connectivity, listening sockets and routing separately. Replace service.example.com and port 443 with your actual public endpoint.
• 1. Check both DNS record types.
Run dig +short A service.example.com and dig +short AAAA service.example.com. Confirm that each address points to the intended server, proxy or CDN. An AAAA record publishes an IPv6 destination; it does not prove that the service is reachable there. If DNS points to a proxy, these requests test that proxy, not direct access to the origin.
• 2. Compare requests from a client with working connectivity.
Run curl -4 -v --connect-timeout 10 https://service.example.com/ and curl -6 -v --connect-timeout 10 https://service.example.com/. For an API or ML endpoint, use the same safe health-check path, request method and authentication for both. Compare the connection, TLS verification and expected HTTP response. An HTTP 403 is not the same failure as a connection timeout.
A failed curl -6 does not automatically implicate the server. On a Linux client, inspect ip -6 addr and ip -6 route, then repeat the request from another network with verified IPv6 connectivity. A configured IPv6 address alone does not prove that the client has a working route. Remove credentials and authorization headers before sharing verbose output.
• 3. Check the public listener.
On the server, run ss -lnt and inspect the service port. A listener on 127.0.0.1 or [::1] is loopback-only. A listener on 0.0.0.0 covers IPv4; [::] is an IPv6 wildcard listener, but whether it also accepts IPv4 depends on socket settings. Do not infer dual-stack reachability from that line alone.
If a reverse proxy handles public HTTPS, check its listener separately from the application backend. A loopback-only backend can be intentional; a missing public listener is a different problem.
• 4. Compare routes and filtering for both families.
Inspect ip -4 addr, ip -6 addr, ip -4 route and ip -6 route on the server. Check that the expected public addresses are assigned and that return routes exist to the test client.
Review the firewall actually in use: nft list ruleset for nftables, or iptables -S and ip6tables -S where applicable. If CSF manages your DirectAdmin server's firewall, inspect its IPv6 configuration too. Include provider-side filtering. An IPv4 allow rule does not prove IPv6 is allowed, and blocking essential ICMPv6 can break IPv6 connectivity.
Record the client network, destination address, connection result and HTTP status for each family. If one verified IPv6 client succeeds and another fails, investigate the failing client's network and path before changing the server. If both fail, use the listener, routing and firewall checks to narrow the cause. Neither disabling IPv6 nor deleting AAAA should be the default fix.
This post was prepared in collaboration with vpsttt. If you run a VPS there, verify its assigned addresses, routing and filtering; do not assume IPv6 support without confirmation for that VPS.
Try the checklist on a service you manage and share which check helped distinguish a client-side failure from a server-side one.
