Are more CDN nodes always better? How to assess node count, coverage, and real-world speed

Different IPs for the same domain across regions, different carrier latencies for the same Anycast address, IPv4 working while IPv6 fails, or incomplete failover after a primary CDN outage can all make DNS appear “random.” More nodes do not necessarily mean faster service for users. Coverage, carrier interconnection, traffic steering quality, cache hits, and node load jointly determine the experience; node count is only a background metric.

Analyze routing and delivery in five layers: DNS answers, network ingress, address family, edge services, and caching and origin fetches. One layer working correctly does not mean the next one does. This article narrows down issues by grouping tests by region, carrier, and protocol.

Matching or different IP addresses alone are not conclusive

DNS traffic steering may return different addresses based on the recursive resolver, EDNS Client Subnet, region, or network. With Anycast, multiple locations may share the same IP prefix, with BGP directing traffic to different locations. The same IP does not mean the same physical server, and different IPs do not necessarily mean different CDN providers.

If node counts and coverage maps look impressive but P95 remains poor for the target carrier, examine interconnection, traffic steering, and load first. Procurement acceptance criteria should specify thresholds by user group, not node counts.

When changing public DNS affects node selection—and its limits

Switching public DNS changes the recursive resolver and any client network information it may carry. It may also change the final CNAME or A/AAAA answer. But DNS only determines the ingress point; subsequent HTTP connections still depend on Anycast paths, carrier interconnection, edge load, and cache hits. If performance improves after switching DNS, do not simply conclude that “this DNS is faster.” Identify which stage changed.

DNS standards documentationandCloudflare's DNS record type documentationcan help verify the basic semantics of DNS records and recursive answers. DNS/CDN administrators should confirm actual support for EDNS Client Subnet, privacy, and traffic steering policies. Do not infer this from a single public DNS lookup tool.

Test IPv4 and IPv6 at every stage

Windows PowerShell: nslookup www.example.com; curl.exe -I https://www.example.com/; on Linux/macOS, use dig and curl to record response IPs and protocols.

Windows PowerShell：
curl.exe -4 -sS -D - "https://www.example.com/" -o NUL
curl.exe -6 -sS -D - "https://www.example.com/" -o NUL

Linux/macOS：
curl -4 -sS -D - "https://www.example.com/" -o /dev/null
curl -6 -sS -D - "https://www.example.com/" -o /dev/null

If an IPv6 command reports no address, check AAAA first. If AAAA exists but the connection fails, check CDN and origin listeners, firewalls, routes, and ports. If TLS succeeds but HTTP returns an error, check Host, application-generated absolute URLs, and caching. Do not treat removing AAAA as a long-term fix unless it is an explicitly temporary fallback with monitoring in place.

Failover requires more than changing a CNAME

Dual-CDN failover requires defined health criteria, an authorized person to trigger it, DNS TTL, cache warming, certificates, origin Host, WAF, logging, and a recovery sequence. Even if the backup CDN returns 200, it may lack current cached content, fail to handle Range, lack signature rules, or use the wrong origin protocol.

During a staged rollout, route a small set of resolvers or a test domain through the backup path first. Record status codes, response body versions, response IPs, TLS, and origin load. After restoring the primary CDN, verify that the old ingress point does not serve incorrect content during the TTL window. If node counts and coverage maps look impressive but P95 remains poor for the target carrier, examine interconnection, traffic steering, and load first. Procurement acceptance criteria should specify thresholds by user group, not node counts.

Avoiding misdiagnosis of Anycast and network path issues

Running ping or traceroute against the same IP only reveals a particular network-layer path; it cannot replace HTTPS requests. HTTP access also involves DNS, TCP/QUIC, TLS, request queuing, cache lookup, origin fetches, and downloading.Multi-region website speed testsshould be combined with controlled curl tests, browser tests, and MTR results where needed. Do not equate ICMP latency with page speed.

If total times for the same IP differ significantly across China Telecom, China Unicom, and China Mobile, record the carrier, address family, response IP, connection time, and failing nodes. If connection times are similar but TTFB differs substantially, investigate edge queuing, caching, and origin fetches. If the connection itself is slow, investigate network paths and protocol ingress.

CdnChart's approach to multi-region routing analysis

Group samples by region, carrier, IPv4/IPv6, recursive resolver, and time period, keeping the URL, request headers, and cache state consistent. For each group, report the success rate, P50/P95, fastest/slowest times, response IPs, status codes, and failure stages. Label failing nodes as “no DNS answer,” “TCP failure,” “TLS failure,” “HTTP error,” or “incorrect response body.”

If only the DNS answer changes while the HTTP stage remains unchanged, limit your conclusion to DNS traffic steering. If response IPs match but carrier latencies differ, focus on Anycast and network paths. If IPv6 alone fails, do not hide it behind IPv4 averages. If old versions remain prevalent after primary-to-backup failover, document TTL and cache propagation as rollback risks.

The article on identifying multiple CDNscan help interpret multi-CDN results, but identifying two ingress points does not guarantee reliable failover.CDN testing methods and scoring criteriahelp standardize test periods, samples, and percentile definitions, so that node differences in one time window are not presented as permanent network behavior.

Remediation, monitoring, and rollback

After remediation, observe key user groups over several consecutive windows rather than testing only once when the incident begins. Monitoring should include at least DNS answer changes, HTTP status codes, TLS failures, response IPs, P95, and failure rates. For critical services, also check response body versions and cache hits.

Rollback configurations should be restorable without deleting historical records. Retain the previous CNAME, certificates, health checks, origin access authorizations, and cache rules. Specify who can switch, when to switch, and when to restore service. Any dynamic allowlist needs a synchronization mechanism; never permanently hardcode an edge IP observed in a single test.

Frequently asked questions

Why does the same CDN IP have different latencies across regions?

Anycast paths, carrier interconnection, and congestion may differ. The same IP does not imply the same physical node or network path.

Will switching public DNS always select a faster node?

Not necessarily. The resolver may affect the answer, but HTTP paths, Anycast, caching, and origin fetches still determine the final experience.

Is checking AAAA enough to diagnose IPv6 failures?

No. You also need to establish TCP/QUIC and TLS connections and make HTTP requests over IPv6 to verify end-to-end service availability.

Is a backup CDN ready for production failover if it returns 200?

Not necessarily. You must also verify response bodies, caching, certificates, APIs, uploads, downloads, security rules, and origin load.

Why do users still experience failures when health checks pass?

Health checks may test only one path, one region, or IPv4. Users may have different paths, carriers, Host, SNI, and cache conditions.

How can an Anycast IP be accurately mapped to a node's city?

Public IP geolocation generally provides only a rough reference and cannot guarantee a physical node's exact location. Combine it with multi-region access tests and network path observations.