An AAAA record can resolve correctly while every IPv6 connection to your service fails.
For a community website, API, or ML endpoint hosted alongside your NAS apps, check DNS, connectivity, listeners, and routing separately. Run server-side commands on the Linux system actually terminating the connection—often a reverse proxy or VM—not automatically on the NAS host.
1. Check both DNS records
Replace service.example.com with your hostname:
dig +short A service.example.com
dig +short AAAA service.example.com
Check that each returned address belongs to the intended public entry point. An AAAA record publishes an IPv6 address; it does not verify a listener, route, or firewall rule.
If DNS returns several addresses, test each one. One working address can hide another that is unreachable.
2. Compare requests from a suitable client
Use a client with working IPv4 and IPv6 connectivity:
curl -4 -v --connect-timeout 10 --max-time 20 https://service.example.com/health
curl -6 -v --connect-timeout 10 --max-time 20 https://service.example.com/health
Use an existing, safe endpoint; /health is only an example. Compare connection establishment, TLS verification, HTTP status, and the expected response—not just whether something came back.
A failed curl -6 does not, by itself, identify a server fault. Check the client’s IPv6 address and route, then repeat from an independent network with verified IPv6 connectivity. Record the exact error: name resolution failure, “Network is unreachable,” timeout, and connection refusal point to different checks.
3. Inspect the actual listener
On the Linux system accepting the connection:
ss -4 -lnt
ss -6 -lnt
Look for the intended port, such as TCP 443:
127.0.0.1:443or[::1]:443: loopback only.0.0.0.0:443: IPv4 wildcard.[::]:443: IPv6 wildcard; do not assume it also accepts IPv4. That depends on socket settings.
With containers, check both the application’s listener and the host’s published ports or reverse-proxy listener. A listener inside a container does not prove external reachability.
4. Compare routes and firewall rules by address family
On the client and relevant Linux server:
ip -4 route
ip -6 route
Check the return path as well as the incoming path. Review IPv4 and IPv6 rules separately at every applicable boundary: upstream firewall, router, host, and container network. An IPv4 allow rule is not evidence of an equivalent IPv6 rule. IPv6 also needs appropriate ICMPv6 handling for functions such as neighbor discovery and Path MTU Discovery.
Keep a small comparison table: client/network, resolved address, curl result, listener, route, and firewall finding. It makes “works from here” much more useful. Disabling IPv6 or deleting AAAA records should not be the default substitute for locating the fault.
Disclosure: This is brand-associated content for vpsttt VPS; treat any deployment there as an environment whose actual configuration must be checked, not as confirmation of IPv6 support.
Try this checklist on one service you manage and share which check helped distinguish a client-network problem from a server-side problem, with sensitive details removed.