Why do CDN node IPs differ depending on the region?

With the same domain, a query from Beijing may return one IP, Guangzhou may return another, and the result may differ again over China Telecom versus China Mobile networks.

Seeing this for the first time, many people wonder: Is DNS resolution wrong? Was the website hijacked? Or has the CDN configuration not taken effect?

Do not rush to change DNS settings.

When a website uses a CDN, it is normal for different regions and different carriers to see different IPs. The CDN directs requests to more suitable edge nodes based on user location, network path, node health, and current traffic-steering policy.

But the reverse can also occur: seeing the same IP in different regions does not necessarily mean all users are entering the same server. A CDN using Anycast can have nodes in multiple regions advertise the same IP simultaneously, with internet routing taking users to different data centers.

Therefore, when judging whether CDN traffic steering is normal, you cannot rely only on whether IPs are the same or different.

Why does a CDN not let all users access the same IP?

Without a CDN, a domain may keep pointing to a fixed origin IP for a long time. Whether users are in Beijing, Shanghai, or Singapore, requests ultimately go to the same server or the same data center.

After the CDN is enabled, the request path changes.

The user first resolves the domain, and the CDN returns an address based on the location and network clues it can obtain. The user then visits that address, and an edge node either directly returns cached content or fetches content from the origin.

If users from all regions were fixed to a single node, users farther away would still have to traverse a very long network path, making distributed CDN nodes pointless.

Amazon CloudFront is one example. AWS official documentation states that DNS routes requests to an edge location that can best serve that user, usually an access point that is closer in terms of latency. Being closer here is not only about distance on a map; the actual network path also matters.View CloudFront content delivery documentation.

This is also why different people querying the same CDN domain from different regions may get different IPs.

Reason 1: DNS-based traffic steering by region

Many CDNs use a DNS-based traffic steering system.

When users in Beijing and Guangzhou query the same domain, the steering system may direct them to edge resources in North China and South China, respectively. Overseas users may receive addresses corresponding to overseas regions.

The goal is not to give every city a unique IP, but to choose a more appropriate serving node under current conditions.

Note that different IPs do not necessarily mean two nodes are in different cities. A node may serve several nearby provinces, and an IP range may correspond to a broader area.

CDN traffic steering generally considers network quality, capacity, and availability as a whole, rather than assigning nodes one by one according to administrative region.

Reason 2: Different carriers may have different suitable network entry points

In the same city, users on China Telecom, China Unicom, and China Mobile may resolve to different CDN nodes, which can also be normal.

The domestic network involves different carriers and interconnection paths. If an IP is easy to reach from China Telecom, it does not mean China Mobile users will necessarily take the same path.

A CDN may return different addresses to different carriers in order to minimize cross-network traffic and unnecessary detours.

So when troubleshooting a report like local access is normal but users elsewhere say it is slow, recording only one city is not enough. It is best to also record:

• Query region;

• Network carrier;

• Query time;

• DNS resolver used;

• A or AAAA record returned;

• Whether the actual HTTP request succeeded and how long it took.

If you compare only Beijing China Telecom with Guangzhou China Mobile, the difference may involve both region and carrier, making it hard to tell which factor is actually responsible.

Reason 3: The CDN may see recursive DNS, not the actual user

When users query a domain, the query does not usually go directly to the CDN authoritative DNS. It is first sent to carrier DNS, public DNS, or internal corporate DNS.

These servers, which perform queries on behalf of users, are called recursive DNS resolvers.

If the authoritative DNS can only see the recursive resolver location, it may return results based on the resolver rather than the end user location.

This causes a common phenomenon: users in the same location can get a different CDN IP after switching to a different DNS.

EDNS Client Subnet (ECS) is a DNS extension designed to improve this situation. A recursive resolver that supports ECS can pass part of the client subnet information to the authoritative DNS, making it easier for the authoritative DNS to return results related to the user location.

Google Public DNS'sEDNS Client Subnet documentationalso emphasizes that whether the authoritative DNS and recursive resolver correctly support ECS affects how location-related responses are cached and used.

However, not all resolvers and CDNs use ECS in the same way. For privacy, cache efficiency, or product policy reasons, the actual information passed and the resulting traffic steering decisions may differ.

Therefore, an IP change after switching public DNS does not necessarily mean the original DNS had a problem.

Reason 4: DNS caching and TTL can make different users temporarily see different results

DNS responses are usually not re-queried every time. Computers, routers, carrier recursive DNS, and browsers may all cache results for a period of time.

The TTL of a record determines how long a DNS response may be cached.

Different recursive resolvers may obtain answers at different times. Therefore, even after the CDN has adjusted its traffic steering, some users may still use the old cache temporarily while others have already obtained the new IP.

Cloudflare'sDNS TTL documentationexplains that TTL affects how long a record is cached and how much time an update takes to reach end users.

This situation is especially common in the following cases:

• Immediately after connecting to a CDN or modifying a CNAME;

• After switching CDN provider;

• When the CDN adjusts node addresses;

• When a node failure triggers a temporary switch;

• When local or recursive DNS still retains the old cache.

So if two queries are made a long time apart, a change in IP is not surprising. When comparing results, save the time and TTL together as well.

Reason 5: Node load, failures, and traffic steering policies change dynamically

A CDN is not a fixed node table that never changes.

When a node is under maintenance, has failed, is under high load, or has degraded path quality to a certain carrier, the steering system may shift new requests to another node.

During major events and traffic peaks, the CDN may also change its assignments based on capacity.

This means that the same region and the same carrier may return different IPs when queries are made at different times.

This kind of change is not necessarily abnormal. What really matters is whether the IP after the switch still belongs to the expected CDN, whether requests complete normally, and whether latency and success rates are continuously degrading.

Reason 6: Anycast can make the same IP reach different nodes

DNS-based traffic steering often looks like different regions returning different IPs, but that is not the only way CDN traffic is routed.

Anycast allows nodes in multiple locations to advertise the same IP address at the same time, and BGP routing then sends requests to the appropriate network entry point.

Cloudflare'sCDN reference architecturestates this clearly: the same IP can be advertised by multiple nodes in different regions, and traffic steering is done by internet routing.

As a result, two seemingly opposite outcomes can both be normal:

Therefore, based on an IP string alone, you can neither confirm the physical node nor fully determine the actual network path taken by the user.

How can you check the CDN node IPs returned by different DNS servers?

In a Windows command prompt, you can query different public DNS servers separately:

nslookup static.example.com 1.1.1.1
nslookup static.example.com 8.8.8.8

On macOS or Linux with dig installed, run:

dig @1.1.1.1 static.example.com A +noall +answer
dig @8.8.8.8 static.example.com A +noall +answer

To view IPv6 results, query the AAAA record:

dig @1.1.1.1 static.example.com AAAA +noall +answer

If the domain is connected to the CDN via a CNAME, you can also inspect the CNAME chain first:

dig static.example.com CNAME +noall +answer

The abovestatic.example.comis a demo domain. In actual operation, replace it with the real accelerated domain you need to query.

If no public CNAME is found, you cannot conclude from that alone that no CDN is in use. Some products use proxy access, root domain CNAME flattening, or other resolution methods, so you need to check the actual product configuration.

Here is an easy pitfall to fall into:

Switching between 1.1.1.1 and 8.8.8.8 on the same computer only compares the answers given by different recursive DNS servers. It cannot replace real multi-region queries from Beijing, Guangzhou, Shanghai, and other locations.

Because the query still originates from your current network, whether the public DNS forwards ECS and how the authoritative DNS handles ECS will also affect the final result.

To observe actual responses from different regions and carriers, useCDNChart website speed testto run multi-region tests on the same domain and view the monitoring location, response IP, resolution time, and connection time together.

How should multi-region IP results be interpreted in CDNChart?

If your main goal is to identify which CDN a domain uses, first open theCDN detection and node lookup tool, enter the specific domain, and review identification evidence such as CNAME, response headers, and public network signals.

Then use website speed testing to observe the response IPs and access performance returned from different regions.

Use the following order to evaluate:

1. First, confirm that the same domain is being queried. www.example.com,static.example.comandimg.example.commay use different CDNs and should not be compared together;

2. Distinguish IPv4 from IPv6.A and AAAA records are different address types and may use different network paths;

3. Check the CNAME chain.Verify whether the final destination is the target assigned by the expected CDN;

4. Record the response IP returned in each region.Check whether there are stable differences across regions and carriers;

5. Combine ASN with response characteristics.Do not rely only on the company name shown in an IP ownership database;

6. Check whether the request succeeds.Status code, connection time, and download behavior show whether user access is normal better than whether the IP is the same;

7. Save the time and sample conditions.Test results represent the observation at that time, not an unchanging complete node list of the provider.

CDN identification itself should not rely only on one IP. To understand how CNAME, response headers, ASN, and TLS evidence can work together, continue readingHow to determine which CDN a website uses.

What situations can be considered normal changes?

The following phenomena usually do not require immediate configuration changes:

• Different regions return different IPs, but access works normally;

• Different carriers are assigned different addresses, and speed or success rate is not obviously abnormal;

• The node occasionally changes in the same region, and access is still normal afterward;

• Multiple IPs all fall within the expected CDN network range;

• Different regions see the same Anycast IP, but actual access latency differs;

• The city shown by the IP geolocation database does not match the user location, but HTTP access behaves normally.

IP geolocation databases should be treated only as clues.

The registration location of an IP, the location of the network operator, the routing announcement location, and the data center a user actually enters are not necessarily the same place.

Seeing that an IP is located in the United States is not enough to conclude that Chinese user requests actually detoured to the United States.

What situations require further investigation?

If you see the following phenomena, normal CDN traffic steering alone cannot explain them:

The most valuable thing for troubleshooting is not a vague phrase like the IP changed, but a complete record. The record can be formatted as:

Date and time:; Test region and carrier: Guangzhou China Mobile; Domain:static.example.com; Response IP:; Request result: timeout; at the same time, access from Guangzhou China Telecom and Shanghai China Mobile was normal.

Only with region, carrier, time, domain, IP, and access results can the issue be reproduced and located.

Different IPs do not mean an anomaly, and the same IP does not mean the same node

The value of a CDN is precisely to distribute user requests across different regions and network entry points.

Different IPs in different regions often indicate that the traffic steering system is working, not that the configuration has a problem.

There are really three things to judge:

1. Whether the returned address matches the expected CDN or proxy chain;

2. Whether users can obtain content stably and correctly;

3. Whether access performance in major regions and carriers meets business requirements.

If you are checking your own domain, you can first useCDNChart CDN node lookupto view identification evidence, and then usemulti-region website speed testto compare response IPs and access latency from different regions.

Do not rush to pursue the same IP everywhere.

For CDNs, different is often by design. Whether users can be stably routed to the right service entry point is the result that matters more.