How to Test IPv6 Connectivity Manually (and Compare Results with Automated Monitoring)

Even if your website loads perfectly over IPv4, IPv6 connectivity can fail silently for a growing segment of your audience. Mobile carriers in Asia-Pacific, parts of Europe, and major US networks like T-Mobile now route significant traffic over IPv6 by default. If your server, DNS, or firewall has an IPv6 misconfiguration, those users see a timeout while your IPv4-based monitoring reports everything is fine.

Manual testing gives you direct, hands-on insight into how IPv6 behaves for your domain. When combined with continuous automated monitoring from UptyBots, you get a complete picture: real-time alerting for production, plus the diagnostic depth you need when something breaks.

Why IPv6 Testing Deserves Dedicated Attention

IPv6 is not simply "IPv4 with longer addresses." The two protocols travel through different routing paths, hit different firewall rules, and resolve through different DNS record types (A for IPv4, AAAA for IPv6). A misconfigured firewall that blocks ICMPv6 can silently break Path MTU Discovery, causing large responses to hang without any obvious error. A stale AAAA record pointing to a decommissioned server returns connection-refused errors to IPv6-only visitors while IPv4 users browse happily.

These are not edge cases. According to Google's IPv6 adoption statistics, over 45% of users connecting to Google services worldwide use IPv6. In countries like India, France, Germany, and the United States, that number exceeds 50%. If you run a business that serves international traffic, ignoring IPv6 means ignoring a substantial portion of your potential audience.

Step 1: Check Your DNS Records with dig

Before testing connectivity itself, confirm that your domain actually publishes AAAA records. Open a terminal and run:

dig AAAA example.com +short

If the command returns one or more IPv6 addresses (e.g., 2606:4700:3037::6815:1a2b), your DNS is configured for IPv6. If it returns nothing, your domain has no AAAA records and IPv6-only clients cannot reach you at all.

You can also query a specific DNS server to rule out local caching issues:

dig AAAA example.com @8.8.8.8 +short
dig AAAA example.com @1.1.1.1 +short

Compare the results. If they differ, DNS propagation may still be in progress or you have inconsistent zone configurations between your authoritative nameservers.

Common DNS Issues to Watch For

• Missing AAAA record: Your domain simply does not advertise an IPv6 address. Fix this in your DNS zone file or hosting panel.
• Stale AAAA record: The IPv6 address points to an old server that no longer exists. Visitors get Connection refused or a timeout.
• CDN mismatch: You use a CDN for IPv4 but forgot to enable IPv6 at the CDN level. The AAAA record points to your origin server instead of the CDN edge.
• TTL too high: If you recently changed AAAA records, a high TTL means some resolvers still serve the old address for hours or even days.

Step 2: Test Basic Reachability with ping6

The ping6 command (or ping -6 on many Linux distributions) sends ICMPv6 Echo Request packets to an IPv6 address. This is the simplest way to verify that your server is reachable over IPv6:

ping6 -c 5 example.com

A successful result looks like this:

PING example.com(2606:4700:3037::6815:1a2b) 56 data bytes
64 bytes from 2606:4700:3037::6815:1a2b: icmp_seq=1 ttl=57 time=12.3 ms
64 bytes from 2606:4700:3037::6815:1a2b: icmp_seq=2 ttl=57 time=11.8 ms
64 bytes from 2606:4700:3037::6815:1a2b: icmp_seq=3 ttl=57 time=12.1 ms
--- example.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 11.8/12.1/12.3/0.2 ms

If you see Destination unreachable or 100% packet loss, the server is not responding to ICMPv6. Possible causes:

• Firewall blocking ICMPv6: Many administrators block ICMP for security, but blocking all ICMPv6 breaks Path MTU Discovery and Neighbor Discovery Protocol. At minimum, allow ICMPv6 types 1-4 and 128-129.
• No IPv6 route: Your local network or ISP may not support IPv6. Try from a different network or use a VPS with IPv6 connectivity.
• Server has no IPv6 interface: The server OS may not have IPv6 enabled, or the hosting provider has not assigned an IPv6 address.

Interpreting Latency Results

Compare your ping6 latency with regular ping (IPv4) to the same host. A significant difference (e.g., 12 ms for IPv4 vs. 80 ms for IPv6) often indicates suboptimal IPv6 routing. Some ISPs route IPv6 traffic through longer paths or tunnel it over IPv4, adding latency. This is worth documenting and reporting to your hosting provider.

Step 3: Trace the Route with traceroute6

When ping6 fails or shows high latency, traceroute6 reveals where the problem occurs along the network path:

traceroute6 example.com

Each line shows a hop along the route. Look for:

• Asterisks (* * *): A hop is not responding. If every hop after a certain point shows asterisks, the problem is at or near that hop.
• Sudden latency spikes: A jump from 10 ms to 150 ms between two hops indicates a long physical path or congested link.
• Routing loops: The same addresses appearing repeatedly means packets are going in circles. This is an ISP-level routing issue.

Compare with an IPv4 traceroute to the same destination. If the IPv4 path has 8 hops with 15 ms average but the IPv6 path has 14 hops with 60 ms average, your IPv6 routing is suboptimal. Share these results with your hosting provider or ISP when requesting improvements.

Step 4: Test HTTP Endpoints with curl -6

Ping tells you the server is reachable. curl tells you your web application actually responds over IPv6. This distinction matters because a server can respond to ICMPv6 while the web server (Nginx, Apache) only listens on the IPv4 interface.

curl -6 -I https://example.com

The -I flag fetches only headers, which is faster and shows the HTTP status code:

HTTP/2 200
server: nginx
content-type: text/html; charset=UTF-8
x-frame-options: SAMEORIGIN

If this command fails with Could not resolve host, your DNS has no AAAA record. If it fails with Connection refused, your web server is not listening on its IPv6 address. If it fails with SSL certificate problem, your TLS certificate may not cover the IPv6 hostname or the SNI is misconfigured for IPv6 connections.

Testing with Verbose Output

For deeper debugging, add the -v flag:

curl -6 -v https://example.com 2>&1 | head -30

This shows the DNS resolution, TCP connection, TLS handshake, and HTTP exchange step by step. You can see exactly which IPv6 address was chosen, whether the TLS certificate was accepted, and what the server returned.

Testing Specific IPv6 Addresses

If your domain resolves to multiple IPv6 addresses (common with CDNs and load balancers), you can test a specific one:

curl -6 --resolve example.com:443:[2606:4700:3037::6815:1a2b] https://example.com

Step 5: Verify SSL/TLS over IPv6

SSL certificates should work identically over both protocols, but misconfigurations happen. Use openssl to test the TLS handshake explicitly over IPv6:

openssl s_client -connect [2606:4700:3037::6815:1a2b]:443 -servername example.com

Check the output for:

• Certificate chain: Ensure the full chain is presented, including intermediates.
• Verify return code: Should be 0 (ok). Any other code indicates a certificate issue specific to the IPv6 connection.
• Protocol and cipher: Compare with an IPv4 connection to ensure the same TLS version and cipher suite are offered.

Some web servers use different virtual host configurations for IPv4 and IPv6. If your Nginx config has listen 443 ssl; but not listen [::]:443 ssl;, the server will not serve HTTPS on IPv6 at all. Learn more about SSL monitoring in our guide on common IPv6 connectivity issues and how monitoring detects them.

Step 6: Test from Multiple Networks

IPv6 connectivity can vary dramatically between networks. Your office network may have native IPv6 while your home ISP tunnels it, and your mobile carrier may be IPv6-only. Testing from a single location gives you a single data point, not a complete picture.

Practical approaches for multi-network testing:

• Use a VPS in another region: Spin up a cheap VPS (Hetzner, DigitalOcean, Vultr) in a different country and run the same tests.
• Test from your phone: Many mobile carriers use IPv6 by default. Connect to mobile data (not WiFi) and try loading your site.
• Online IPv6 testing tools: Services like test-ipv6.com and ipv6-test.com verify your domain from their infrastructure.
• Ask colleagues on different ISPs: A quick "can you load this URL?" check catches regional routing problems.

Where Manual Testing Hits Its Limits

Manual testing is excellent for diagnosis and one-time verification, but it has fundamental limitations:

• Point-in-time only: You test once. A routing change at 3 AM breaks IPv6, and you do not find out until morning.
• Single location: Even testing from two or three networks cannot cover the global diversity of IPv6 routing.
• No historical data: You cannot analyze trends, spot degrading latency, or correlate outages with infrastructure changes without continuous data collection.
• Human effort does not scale: Manually testing 10 domains across 5 locations every hour is not realistic.

This is where automated monitoring fills the gap. For a deeper look at why tracking both protocols separately matters, see our post on why monitoring both IPv4 and IPv6 matters for modern websites.

Comparing Manual Results with Automated Monitoring

The real power comes from combining both approaches. Use manual testing for deep dives and troubleshooting. Use UptyBots for 24/7 coverage, multi-location checks, and instant alerting. Here is how they complement each other:

Setting Up Dual-Stack Monitoring in UptyBots

UptyBots lets you create separate monitoring targets for IPv4 and IPv6 endpoints. This means you get independent uptime statistics, response time charts, and alert thresholds for each protocol. Here is the recommended setup:

1. Create an HTTP target for IPv4: Enter your domain and select IPv4 as the protocol. Set your preferred check interval and alert channels.
2. Create an HTTP target for IPv6: Create a second target for the same domain with IPv6 selected. Use the same alert channels so both protocols notify you through the same workflow.
3. Add a ping target for each protocol: Ping monitors detect network-level issues that HTTP checks may miss (e.g., routing problems that do not reach the web server layer).
4. Set up SSL monitoring: Verify that your TLS certificate works correctly over both protocols and get alerts before expiry.
5. Configure alert channels: Use email for non-urgent notifications, Telegram for real-time alerts, and webhooks for integration with incident management tools.

For a step-by-step walkthrough, check out our post on diagnosing IPv6 failures using ping, traceroute, and DNS lookup tools.

Real-World Troubleshooting Workflow

Here is how a typical IPv6 troubleshooting session looks when you combine manual testing with automated monitoring:

1. Alert received: UptyBots sends a Telegram notification: "IPv6 HTTP check failed for example.com - Connection timeout."
2. Quick verification: Run ping6 example.com from your terminal. If it responds, the issue is at the HTTP layer, not the network layer.
3. DNS check: Run dig AAAA example.com to confirm the IPv6 address is still correct and has not changed unexpectedly.
4. HTTP test: Run curl -6 -v https://example.com to see exactly where the connection fails (DNS, TCP, TLS, or HTTP).
5. Route analysis: Run traceroute6 example.com to identify if a network hop is dropping packets.
6. Fix applied: Correct the firewall rule, DNS record, or web server configuration.
7. Confirm recovery: Run manual tests again, then watch the UptyBots dashboard to confirm automated checks also turn green.

IPv6 Testing Checklist

Use this checklist whenever you deploy a new server, change DNS providers, or modify firewall rules:

• Verify AAAA record exists and points to the correct IPv6 address
• Confirm ping6 responds with reasonable latency (compare to IPv4)
• Test HTTP/HTTPS response with curl -6
• Verify SSL certificate is valid over IPv6 connections
• Check that ICMPv6 types 1-4 and 128-129 are allowed in firewall rules
• Test from at least two different networks or locations
• Set up automated monitoring for ongoing coverage
• Compare IPv4 and IPv6 latency and investigate significant differences

Want to understand what happens when IPv6-only users cannot reach your site? Read about the hidden downtime you might miss from IPv6-only users. You can also estimate the financial impact of such outages using our Downtime Cost Calculator.

See setup tutorials or get started with UptyBots monitoring today.