How to Test IPv6 in China: Nationwide Three-Network IPv6 Connectivity and Speed Testing Methods

When doing website operations, you often run into a situation like this: access from your own region is always fine, but as soon as users switch to another province or another carrier, timeouts start appearing. Some sites load quickly over IPv4 but show noticeably higher latency over IPv6. And some sites can be pinged successfully at their IPv6 address, yet the browser keeps failing to connect.

For websites serving users in China, IPv6 testing can't just answer the question of whether IPv6 exists. You also need to confirm whether it's reachable from different regions, whether China Telecom, China Unicom, and China Mobile all work properly, whether latency and packet loss are abnormal, and whether HTTP/HTTPS services can actually be used over IPv6. For domestic IPv6 testing, it's best not to just run a single Ping from your own computer, but to check step by step from DNS and basic connectivity all the way to multi-node testing across the country.

1. What does domestic IPv6 testing mainly cover?

Many people testing IPv6 for the first time start by checking whether their computer has an IPv6 address, or whether the website can be opened. This works for a rough initial judgment, but if the target is a website, server, or API, it's not enough. A reasonably complete domestic IPv6 test usually needs to look at the following:

The easiest thing to misunderstand here is the AAAA record.

For example, the domain already resolves to:

AAAA
example.com → 240e:xxxx:xxxx::1234

This only shows that DNS can return an IPv6 address. It doesn't prove that users can definitely reach the website through that address.

A real IPv6 website visit also passes through the carrier's IPv6 network, routing, firewalls, TCP, TLS, and the web service. If any one of these links is misconfigured, the end result can be a site that won't open, responds slowly, or is only unreachable from certain regions. So to judge whether IPv6 is working properly, it's best to look at all these links together rather than relying on a single result.

2. Why can IPv6 test fine locally but fail to open in other parts of China?

Suppose the server is deployed in Shanghai and you test it yourself on a Shanghai Telecom broadband connection:

IPv6 Ping

28ms
29ms
27ms
30ms

It looks perfectly fine.

But this test only proves that the following path is working:

Your computer
   ↓
Shanghai Telecom
   ↓
Carrier IPv6 network
   ↓
Target server

It can't represent the actual situation for users on Beijing Unicom, Guangdong Mobile, Sichuan Telecom, or anywhere else.

Once you expand the test scope, the results might become:

Shanghai Telecom       28ms
Beijing Unicom         39ms
Hangzhou Telecom       35ms
Chengdu Mobile         82ms
Guangzhou Mobile       timeout
Shenzhen Mobile        timeout

At this point, the problem is completely different. The server clearly isn't unreachable nationwide; the anomalies are mainly concentrated on some mobile networks. If you keep checking whether the server is running or whether Nginx is up, you'll easily head in the wrong direction.

When different regions and carriers in China access the same IPv6 address, the BGP routes, carrier interconnections, and upstream networks involved may differ. If the website also uses a CDN, different regions may even be scheduled to different edge nodes.

Therefore, local IPv6 working only means the current line is fine. It doesn't directly represent the access situation for IPv6 users nationwide. This is why domestic IPv6 testing should ideally include multi-region and three-carrier nodes.

3. How exactly do you do domestic IPv6 testing?

The actual process isn't complicated. The recommended order is:

AAAA resolution
    ↓
IPv6 basic connectivity
    ↓
HTTP/HTTPS access
    ↓
Domestic multi-node testing
    ↓
Telecom / Unicom / Mobile comparison

If you check in this order, you can narrow down the scope of the problem by one layer as soon as something starts going wrong.

1. First check whether the domain has an AAAA record

Start with DNS.

IPv4 websites generally return an IPv4 address through an A record:

A
example.com → 1.2.3.4

IPv6 mainly returns an IPv6 address through an AAAA record:

AAAA
example.com → 240e:xxxx:xxxx::1234

If the domain has no AAAA record at all, then when accessing the website through that domain, there's usually no IPv6 address for the client to connect to.

In that case, check the DNS configuration first rather than rushing to test line speed. If the AAAA record already exists, there are two more things to watch out for: whether the returned IPv6 address is actually the one used by the current server, load balancer, or CDN; and whether the resolution has been changed recently.

When you've just modified an AAAA record, your own computer resolving to the new address doesn't mean recursive DNS servers in all regions have synced the update. Some regions may still get the old result within the TTL period.

So an AAAA lookup is more like the first gate of IPv6 testing: without a correct AAAA record, domain-based IPv6 access is unlikely to work properly; but finding an AAAA record only means the DNS layer is basically fine.

2. Then check whether the IPv6 address is actually reachable

After confirming resolution, you can continue testing basic connectivity to the target IPv6 address.

Windows, Linux, and macOS can all use Ping directly, for example:

ping -6 240e:xxxx:xxxx::1234

You can also use Chahu's online IPv6 Ping tool.

At this stage, the focus is on latency, packet loss, and timeouts.

If repeated tests look like this:

31ms
30ms
32ms
29ms
31ms

At least it shows that the basic network connection from the current test line to the target IPv6 address is fairly normal.

If the results become:

31ms
95ms
timeout
164ms
33ms

Then you need to watch for obvious packet loss or latency fluctuation on the line.

But there's another important distinction here: IPv6 Ping working doesn't mean the website is necessarily fine.

Ping mainly verifies whether the network layer can reach the target, while a browser actually accessing an HTTPS website still needs to complete:

IPv6 network
    ↓
TCP connection
    ↓
TLS handshake
    ↓
HTTP/HTTPS
    ↓
Web service

So in real troubleshooting, you often see "IPv6 can be pinged, but the web page won't open." In that case, you should continue checking the server's ports 80/443, security group and firewall rules, and whether web services like Nginx or Apache are listening on IPv6. If only HTTPS fails, you also need to check TLS and certificate-related configuration.

3. Finally, run domestic multi-node IPv6 tests

The earlier tests answer "is this IPv6 configured" and "can my current line connect."

If the website's users are spread across the country, that's still not enough. A more useful approach is to test the target IPv6 address simultaneously from different provinces and from China Telecom, China Unicom, and China Mobile networks.

Just enter the domain or IP into Chahu's online Ping feature, then observe the responses from Telecom, Unicom, Mobile, and different regional nodes separately. Chahu's current Ping page offers carrier filtering, displays latency distribution across regions along with fastest, slowest, and average response data, and supports both single and continuous tests.

When testing, don't just stare at a single "national average latency."

What's really worth looking at is which nodes are normal, which nodes time out, and whether the anomalies show an obvious pattern of concentration.

For example:

Beijing Telecom       normal
Shanghai Telecom      normal
Zhejiang Unicom       normal
Shandong Unicom       normal
Guangzhou Mobile      timeout
Shenzhen Mobile       timeout
Guangxi Mobile        high latency

With results like this, the direction is fairly clear: Telecom and Unicom are basically fine, while multiple Mobile regions are consistently abnormal. So it's unlikely that the server itself is completely unreachable. You should keep checking the IPv6 routing toward Mobile, carrier interconnections, or upstream lines. If instead you find that a large number of nodes across Telecom, Unicom, and Mobile all fail, then going back to check the server's IPv6, default route, firewall, and upstream network makes more sense. So the biggest value of multi-node testing isn't simply telling you whether IPv6 is fast or slow, but helping you determine: which regions and which carriers the problem actually occurs in.

4. How should you read domestic IPv6 test results?

After testing, you'll usually run into a few typical situations.

1. Most nodes nationwide can access normally

For example:

Beijing Telecom       28ms
Shanghai Unicom       32ms
Guangzhou Mobile      41ms
Chengdu Telecom       47ms
Hangzhou Mobile       36ms

If most regions across the three carriers return normally without widespread timeouts, the website's basic IPv6 connectivity usually has no obvious problems. Even if an individual node occasionally times out, don't immediately conclude there's a line fault. Public networks fluctuate on their own, and a single failure at one node isn't very meaningful. What's more worth watching is: repeated failures in the same region, or clusters of anomalies on the same carrier.

2. Only one carrier is abnormal

For example:

China Telecom       basically normal
China Unicom        basically normal
China Mobile        multiple nodes timeout

In this case, look first at the corresponding carrier's direction. If the server's IPv6 configuration were completely wrong, it usually wouldn't affect only one carrier. You can continue checking the routing between the target network and Mobile's IPv6, upstream interconnection, and whether the CDN schedules IPv6 differently for Mobile networks.

3. Only some regions are abnormal

There's also the case where all three carriers can access overall, but a few provinces remain consistently abnormal.

For example:

Beijing       normal
Shanghai      normal
Jiangsu       normal
Guangdong     abnormal
Guangxi       abnormal
Hainan        abnormal

In this situation, the problem looks more like a regional network path or upstream interconnection issue. It's best not to test only once; repeat the test after some time to see whether the same batch of nodes keeps having problems. If the anomalies are always concentrated in the same regions, it's worth investigating further.

4. A large number of nodes nationwide can't access

If many failures appear across different provinces and across Telecom, Unicom, and Mobile, don't just focus on one carrier.

It's recommended to start checking from the server side again:

AAAA record
    ↓
Server IPv6 address
    ↓
IPv6 default route
    ↓
Security group / firewall
    ↓
Port 80 / 443
    ↓
Web service
    ↓
HTTPS

This is especially true right after you enable IPv6 on a cloud server — one of the easiest things to overlook is the security policy.

Even though the server has already obtained a public IPv6 address, the security group or system firewall may not yet allow the corresponding inbound IPv6 connections.

5. IPv6 works, but it's noticeably slower than IPv4

For example, the same region returns:

IPv4: 32ms
IPv6: 148ms

At this point the question has shifted from "can IPv6 work at all" to "why is IPv6 taking a detour or showing such high latency." You can keep comparing other regions and carriers. If only Guangzhou Mobile shows this behavior while Beijing Mobile and Shanghai Mobile are fine, it looks more like a regional routing issue. If nearly every Mobile node shows IPv6 much higher than IPv4, you'll need to dig deeper into the IPv6 upstream path toward Mobile.

There's no need to judge a route's quality from a single latency figure. What matters is whether there's a clear gap between IPv4 and IPv6, and whether the anomaly follows a regional or carrier pattern.

V. Why must domestic IPv6 testing always look at Telecom, Unicom, and Mobile separately?

With domestic website speed tests, picking just one node easily leads to misjudgment.

This is even more true in an IPv6 environment.

For the same server, traffic from Telecom, Unicom, and Mobile may travel through entirely different network paths.

For example:

Beijing Telecom
   ↓
Telecom IPv6 backbone
   ↓
Target network

Meanwhile, another path might be:

Beijing Mobile
   ↓
Mobile IPv6 backbone
   ↓
Carrier interconnection
   ↓
Target network

Even though the final destination is the same IPv6 address, the actual link is different.

So in real-world conditions, this is entirely possible:

IPv4:
Telecom       OK
Unicom        OK
Mobile        OK

IPv6:
Telecom       OK
Unicom        OK
Mobile        Timeouts in some regions

If you only test on a Telecom broadband line, it's very hard to spot this problem.

Chahu's current multi-node Ping also displays results by Telecom, Unicom, Mobile, and region. This approach is well suited to first determining whether an anomaly has a clear carrier signature. For website operations, what three-carrier testing really solves isn't getting three different latency numbers — it's answering: Is this a problem with the server itself, or a network problem between a particular carrier and the server? Once you've nailed that down, the rest of the troubleshooting goes much faster.

VI. What's the difference between local IPv6 testing and domestic multi-node testing?

If you just want to know whether your own computer or home broadband has IPv6, local testing is usually enough. But if you're managing a website, server, API, or CDN that serves users nationwide, testing only from your own computer is clearly not enough.

You can think of it simply this way: regular users care about "can my IPv6 work," while website operations cares more about "can the users' IPv6 work." The test targets look the same, but the problems they actually solve are different.

VII. What's the correct troubleshooting order when domestic IPv6 has issues?

The most common mistake in IPv6 troubleshooting is checking too many things at once from the start. You change DNS, change the firewall, reboot the server, tweak the CDN config — and even if the site comes back, you have no idea which step actually fixed it.

In real operations, it's better to follow a fixed order:

Check AAAA
      ↓
Confirm IPv6 address
      ↓
Test basic connectivity
      ↓
Check HTTP / HTTPS
      ↓
Run domestic multi-node tests
      ↓
Compare Telecom / Unicom / Mobile
      ↓
Compare IPv4 / IPv6
      ↓
Pin down the affected regions
      ↓
Check routing and upstream network

If all three carriers nationwide can't reach the site, you should check the server side first rather than studying Guangzhou Mobile's routing. If most regions nationwide are fine and only a few Mobile nodes in South China fail consistently, there's no need to modify the server's entire IPv6 configuration right away. If all regions can access it but users occasionally report it's unreachable at night, you can use continuous testing to observe latency, packet loss, and timeouts during peak hours. The truly effective approach to network troubleshooting is to narrow down the problem step by step based on each result.

What domestic IPv6 testing really needs to confirm isn't just whether the server has an IPv6 address — it's whether users across different regions and carriers in China can access the website normally once it serves traffic over IPv6. If you're only checking your own network, local IPv6 testing can solve quite a few problems. But for a website serving users nationwide, it's best to check layer by layer in this order: AAAA resolution, basic connectivity, HTTP/HTTPS, domestic multi-node, three-carrier comparison, IPv4/IPv6 comparison.

That way, when something goes wrong, you can quickly tell whether it comes from DNS, server configuration, or is concentrated in a particular region or carrier network — instead of seeing "the site won't load" and then guessing back and forth between the server, CDN, and DNS. This is especially true for problems like "it works fine on my end but users can't open it" — Chahu's nationwide multi-node IPv6 testing is often more informative than simply running more local tests.

Related Q&A

1. Q: My home router shows IPv6, but my computer can't get an address. What's going on?
A: First check whether your computer's network properties show an address starting with 240e or 2409. If not, the router probably isn't handing out a prefix. After bridging the optical modem, set the router's IPv6 mode to Native or SLAAC — don't leave it on Disabled. Some older routers only support IPv4, so you'd need to replace them.

2. Q: My website uses a CDN. How do I confirm the CDN's IPv6 nodes are active?
A: Run dig AAAA and see whether the response is in the CDN's IPv6 range. Ping from a few regions — if it returns the origin server IP, the CDN's IPv6 isn't configured properly. The response headers usually contain a CDN identifier.

3. Q: IPv6 can open the webpage, but images and videos won't load. What's the problem?
A: Press F12 and see which requests are failing. It could be that resources in the page are hardcoded to IPv4, or there's an issue with CDN origin pull. It could also be MTU — large packets get dropped while small ones go through fine.

4. Q: What MTU should IPv6 use? What happens if it's wrong?
A: Usually 1500; PPPoE might be 1492. If it's wrong, small packets ping fine but webpages hang halfway through loading and TLS handshakes fail. Try ping -6 -l 1472 -f target-address and gradually reduce the size.

5. Q: For IPv6 monitoring, how should I set the frequency and thresholds?
A: Once a minute for core APIs, every five minutes for the main site. Don't alert on a single failure — wait for two or three consecutive failures. Select nodes across all three carriers separately, a few each for Mobile, Telecom, and Unicom, to avoid false alarms from a single point.

6. Q: What types of IPv6 addresses are there? What does fe80 mean?
A: fe80 is a link-local address, only reachable within the same subnet. For external testing you need a global unicast address, typically starting with 240e, 2409, or 2408. Addresses starting with fd00 are private and also can't be accessed over the public internet.