fren
Log In

Test IPv6 connectivity

3 min read07 November 2026

An "included" IPv6 address does not mean a service answers over IPv6. You need an address on the server, a service listening on that stack, a firewall allowing the port and an AAAA record. Test each link instead of guessing.

Test from the client

Open the IPv6 test page from a network announcing IPv6: it shows the address the site sees. If you see an IPv4 address, your access does not use IPv6, and the server test is misleading.

On the command line, force the address family:

Bash
curl -6 -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" https://your-domain.com/
curl -4 -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" https://your-domain.com/

The first command should return 200 and an address containing :. The second is your comparison. Continue with the name:

Bash
dig AAAA your-domain.com +short
ping -6 -c 3 YOUR_IPV6

ping6 still exists as a symlink on Debian, but ping -6 is the portable form. A failed ping proves nothing: many servers filter ICMPv6.

Test on the server

First confirm the address is configured and a default route exists:

Bash
ip -6 addr show
ip -6 route show default

On a system container, the platform provides the address: do not add it by hand. Then look at what actually listens:

Bash
ss -6 -lntp

A [::]:80 line means both stacks are listening. If ss -lntp only shows 0.0.0.0:80, it is IPv4 only: Nginx then needs a listen [::]:80; directive in the same server block. Check the configuration before reloading:

Bash
sudo nginx -t && sudo systemctl reload nginx

UFW handles IPv6 when IPV6=yes is set in /etc/default/ufw, the Debian default. sudo ufw allow 80,443/tcp opens both families. Check with sudo ufw status verbose, or sudo nft list ruleset if you use nftables directly.

Check DNS and the browser

The name needs an AAAA record pointing to the service address. An A record alone is not enough. When both exist, browsers often prefer IPv6: an AAAA added while the port is closed causes timeouts for some visitors.

After a change, wait for the TTL to expire, then check with a public resolver:

Bash
dig @1.1.1.1 AAAA your-domain.com +short

The address bar does not show the family used; developer tools, Network tab, show each request's remote address.

Diagnose

Symptom Likely cause Check
IPv6-only timeout firewall or IPv4-bound service ss -6 -lntp, ufw status
curl -6 works, browser does not broken local IPv6 or AAAA cache IPv6 test, local cache
No AAAA answer missing record or wrong zone dig AAAA, dig NS
Connection refused service not listening on :: web server config
Works on one network, not another client network routing test from another access

Finish with a functional test: full page, form, download. A successful TCP connection does not prove the application answers correctly on both stacks.

Advertisement

Was this article helpful?

Read next