Can a CDN Node IP Reveal the Real Server Location? How to Read IP Geolocation and Node Cities

Query a website's IP and the result says it is in the United States, yet access from Shanghai takes only a dozen milliseconds. Check the same address on another IP lookup platform, and it is labeled Singapore. Use a CDN speed-test tool, and you may also see different nodes such as Beijing, Guangzhou, and Hong Kong.

So which one is the server's real location?

Here is the answer first:

A CDN node IP generally only represents the public service address the user is currently connected to. It does not directly indicate the physical server location, nor the website's origin location.

Especially with Anycast, shared IPs, and multi-layer proxy architectures, the same IP can serve users simultaneously from nodes in multiple cities or even multiple countries. The city shown by an IP database may be the network block's registration location, a network operations center, an estimated location, or simply a default coordinate set by the provider for an entire address range.

Therefore, when checking a CDN node, you cannot simply use the following logic:

IP归属地显示美国
→ CDN节点一定在美国
→ 用户请求一定跨境访问美国服务器

All three conclusions may be invalid.

First, distinguish five commonly confused types of 'location'

When discussing CDN node location, there are at least five different meanings.

For example, an IP block registered to a US company does not mean that the block can only be used in the United States. The company can advertise the address simultaneously in Singapore, Tokyo, Frankfurt, and São Paulo via BGP.

Likewise, a user entering a Shanghai edge node does not mean the website origin is located in Shanghai. On a cache hit, content may be returned directly from the Shanghai node; on a cache miss, the node may still fetch content from an origin in Hong Kong, Singapore, or the United States.

Why a CDN node IP cannot directly represent the real location

Reason 1: Anycast makes the same IP appear in multiple regions

Anycast is a very common networking method in CDNs.

In an Anycast architecture, nodes in multiple regions can advertise the same IP address simultaneously. Internet routing uses BGP paths, network policies, and current reachability to direct users to one of the entry points.

The access path may be:

北京用户 → 进入北京或周边节点
新加坡用户 → 进入新加坡节点
美国用户 → 进入美国节点

The public IPs the three users connect to may be exactly the same, but they actually enter different data centers.

Cloudflare's CDN reference architecture explicitly states that Anycast allows multiple nodes in different locations to use and advertise the same IP, with BGP directing client requests to the appropriate location.

Therefore:

相同IP ≠ 相同物理节点

This is also why a CDN using Anycast can provide nearby access even when users worldwide look up the same IP.

Reason 2: Multiple IPs may also belong to the same node

Conversely, different IPs do not necessarily mean different cities.

A CDN data center may have:

• Multiple IPv4 addresses;

• Multiple IPv6 addresses;

• Separate address pools for different services;

• Entry points for different plans or security products;

• Addresses for multiple carrier lines;

• Anycast and unicast addresses;

• Dedicated IPs and shared IPs.

So:

不同IP数量 ≠ CDN节点数量

If you find 20 IPs, you cannot directly write that 'the website uses 20 CDN nodes.' They may be distributed across only a few PoPs, or they may be the result of dynamic rotation within the same address pool.

Reason 3: IP registration location does not equal server location

IP addresses are allocated and registered by Regional Internet Registries. Registration information can usually tell us:

• Address block;

• ASN;

• Registered organization;

• Contact information;

• Responsible Regional Internet Registry;

• Some network descriptions.

But this information mainly describes who manages the address resources; it is not a real-time positioning system for server data centers.

For example:

• A US company can deploy nodes in Tokyo;

• A Chinese company can lease address space from a European cloud platform;

• A CDN can use address blocks from partner carriers;

• Enterprises can use BYOIP to have their own IPs announced globally by a CDN;

• An address block can be split and used in multiple regions.

Therefore, the organization location shown by WHOIS or RDAP can only be used to determine network ownership, not directly as the server's physical location.

Reason 4: IP geolocation databases themselves contain errors

IP geolocation databases typically combine:

• IP registration information;

• Network operator data;

• Routing data;

• Network measurements;

• User feedback;

• Commercial partnership data;

• Geofeeds published by operators;

• Historical location records.

Different databases have different data sources, update times, and estimation algorithms, so the same IP may resolve to different cities.

The IETF-publishedRFC 8805defines the Geofeed format through which network operators can publish geographic information for IP prefixes, but the format intentionally supports only relatively coarse location descriptions.

Even with mature commercial IP databases, city-level geolocation is not absolutely accurate. MaxMind's published accuracy notes state that for US IPs, about 66% of city-level results fall within 50 kilometers of the target city; country-level results are significantly more reliable.

This means:

• Country-level results are usually more trustworthy than city-level results;

• City names should be treated as estimates;

• The database's central coordinates do not equal data center coordinates;

• CDN, proxy, and Anycast addresses are harder to locate using ordinary methods;

• It is not uncommon for different platforms to show different cities.

Reason 5: CDN scheduling targets network quality, not map distance

A CDN does not necessarily send users to the geographically closest node.

The scheduling system may also consider:

• Network latency;

• Carrier interconnection quality;

• Node capacity;

• Current load;

• Packet loss and congestion;

• Node health;

• Cost strategy;

• Data compliance;

• Cache availability;

• DDoS protection and scrubbing status.

AWS's CloudFront documentation explains that DNS routes requests to the PoP best suited to serve the user, usually the edge location with lower network latency.

Note that the emphasis here is on 'more suitable latency,' not the shortest straight-line distance.

For example, a user in Guangzhou may be geographically closer to Hong Kong, but if a carrier's interconnection to Hong Kong is poor, the CDN may schedule the request to another node with better network performance.

Cloudflare also states clearly that Anycast requests do not necessarily enter the geographically closest data center; reliability, congestion, and traffic engineering can all affect the final path.

Reason 6: What the user sees may only be the outermost proxy

The website access path may not involve only one CDN layer:

用户 → WAF或高防节点 → CDN → 区域缓存 → 源站

It may also be:

用户 → CDN A → CDN B → 对象存储

The remote IP shown by the browser generally represents only the outermost entry point the user connects to directly.

It cannot tell you:

• Where the upstream cache is located;

• Which region the CDN passes through when fetching from origin;

• Which country the origin is in;

• Where the database servers are located;

• Which cache layer ultimately returns the content.

Therefore, a node IP not only differs from the origin IP; sometimes it cannot even represent the main content-processing location in the entire CDN chain.

What can a CDN node IP actually tell us?

Although it cannot precisely locate the physical server, a node IP still has investigative value.

It can help determine:

1. Which public IP address the current request is connected to;

2. Which network block and ASN the address belongs to;

3. Whether it belongs to a known CDN or cloud platform;

4. Whether IPv4 and IPv6 use different networks;

5. Whether different regions receive different addresses;

6. Whether the website uses multi-CDN scheduling;

7. Whether the address changes over time, by carrier, or by network;

8. Whether the current path appears to bypass the CDN;

9. Whether the response IP falls within the expected provider's range.

A more accurate statement would be:

“从上海电信观测到该域名连接至某个CDN网络地址”

Rather than:

“这台服务器位于上海某机房”

The former is a verifiable network fact; the latter usually exceeds what public evidence can support.

How to determine which CDN node is actually entered

Step 1: First confirm whether the domain goes through a CDN

Query DNS:

dig www.example.com CNAME +noall +answer
dig www.example.com A +noall +answer
dig www.example.com AAAA +noall +answer

Then record the actual connection IP:

curl -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\n' \
  https://www.example.com/

Then combine:

• CNAME suffix;

• IP ASN;

• HTTP response headers;

• TLS certificate;

• Results from different regions;

• The provider's known address ranges.

If you have not yet confirmed that the response IP is a CDN entry point, you should not directly analyze the so-called 'node city.'

For specific lookup steps, seeHow to check CDN nodes: methods for viewing domain node IPs and regions.

Step 2: Check the provider's public PoP field

Some CDNs provide data center codes in response headers or diagnostic pages, for example:

CF-Ray
X-Amz-Cf-Pop
X-Served-By
Server-Timing

These fields may be closer to the CDN site the request actually passed through than ordinary IP geolocation databases.

But you should still read the provider's definitions first, because the field may represent:

• User access node;

• Request processing node;

• Upper-layer cache node;

• Origin fetch node;

• A certain hop in a multi-layer chain.

For example, in hierarchical caching or intelligent routing scenarios, some node codes may change; do not treat them as the user's initial access location without judgment.

Step 3: Use real probe nodes in multiple regions

To determine CDN node coverage, initiate the same request from different regions and carriers.

Recommended to record:

A single query from one node can only represent a result at one point in time. Only multi-region, multi-carrier, and multi-round observations can gradually form a credible coverage map.

Step 4: Combine with network latency instead of only looking at city names

Suppose an IP database shows the node is in the United States, but access latency from multiple regions in mainland China is only 10–30 ms. That city result is clearly questionable.

You can combine:

• TCP connection time;

• TLS handshake time;

• Ping or TCP Ping;

• Number of route hops;

• Carriers of the last few hops;

• PoP code;

• Probe results from adjacent regions.

Note that Ping and Traceroute also cannot accurately prove data center location:

• ICMP may be rate-limited or disabled;

• Router interface addresses may come from remote network blocks;

• Intermediate networks may hide hops;

• Networks such as MPLS may hide internal paths;

• Anycast may change the entry point with network conditions;

• The name of the last hop does not necessarily correspond to a physical city.

Therefore, latency and routing are supporting evidence, not precision positioning instruments.

Step 5: Compare results at different times

The CDN entry point may change due to:

• Node failure;

• Network congestion;

• BGP route changes;

• Peak capacity expansion;

• DDoS scrubbing;

• Multi-CDN switching;

• DNS weight adjustments;

• IPv4 and IPv6 scheduling changes.

Recommended coverage:

• Weekdays and weekends;

• Daytime and evening peak;

• Multiple consecutive time points;

• Core regions and carriers;

• IPv4 and IPv6.

Only if a region consistently returns the same PoP code and similar latency over time can you describe it with relative confidence as 'the region mainly enters this PoP.'

How should node regions in CdnChart be understood?

When using CdnChart for CDN node lookup or website speed testing, the information on the page should be viewed separately:

Probe region

Indicates where the test request is sent from, such as Shanghai Telecom, Guangzhou Mobile, or a Singapore network.

This is the location of the probe node, not the location of the target CDN node.

Response IP

Indicates the public IP address the probe request actually connects to. When a website uses a CDN, this is usually a CDN edge entry point, not the origin.

IP ownership or geographic information

Comes from IP registration data, ASN, and geolocation databases; it helps understand the network the address belongs to and its possible region, but does not equal the absolute physical data center location.

CDN identification result

Estimates the likely CDN provider based on evidence such as CNAME, IP, ASN, and response headers.

Access time

Represents the result of an actual network request from that probe region to the target. For CDN selection, connection time, TTFB, download speed, and stability are usually more valuable for decision-making than the city shown by an IP database.

If different response IPs are found in different regions, continue readingWhy are CDN node IPs found in different regions different?.

A table for interpreting common query results

Why you should not focus too much on node cities when choosing a CDN

'Whether there are local nodes' is certainly important, but what really determines user experience is the actual network path.

Two CDNs both labeled 'Shanghai node' may produce completely different results due to differences in carrier interconnection, node load, and bandwidth capacity.

When selecting, you should compare:

1. Availability in core regions;

2. Performance on carriers such as China Telecom, China Unicom, and China Mobile;

3. DNS, TCP, and TLS time;

4. TTFB;

5. Cache HIT and MISS;

6. File download speed;

7. P50, P95, and P99;

8. IPv4 and IPv6;

9. Evening peak stability;

10. HTTP/2 and HTTP/3 performance.

If a CDN's page says it covers 100 cities, but target users often cross networks, take detours, or experience packet loss at evening peak, that city count does not directly translate into a faster experience.

Conversely, a CDN with fewer nodes but lines and scheduling better suited to target users may perform better in practice.

How should conclusions be written when investigating competitor nodes?

When investigating competitor websites externally, it is advisable to use expressions such as 'observed,' 'suspected,' 'may,' and 'supported by public evidence.'

For example:

Observed from Beijing Telecom, Shanghai Unicom, and Guangzhou Mobile, the domain connects to the same CDN network in all cases; although the response IP is the same, the address has Anycast characteristics, so it cannot be concluded that the three regions enter the same physical node.

Or:

A probe request from Singapore returns the SIN node code, and a request from Tokyo returns the NRT node code. Combined with the relatively low connection latency, this confirms that the two regions enter different edge PoPs; however, public results cannot determine the number of physical servers in each PoP.

If you need a complete competitor infrastructure analysis, seeHow to check the CDN and node distribution used by a competitor website?.

Do not write:

Eight IPs were found, so the competitor has eight global CDN nodes.

This conclusion looks definitive but has no reliable technical basis.

Evidence strength for determining node location

External queries rarely achieve certainty at the level of 'rack, floor, data center address.' For CDN evaluation platforms, a more reasonable presentation is to provide simultaneously:

• Observation location;

• Response IP;

• ASN;

• Provider;

• PoP clue;

• Latency;

• Data source;

• Confidence;

• Test time.

What is the relationship between node IP and origin location?

In most cases, there is no direct relationship.

Suppose the user connects to a Shanghai CDN node:

上海用户 → 上海CDN节点 → 新加坡源站

On a cache hit, the request may end in Shanghai; on a cache miss, the Shanghai node then connects to the Singapore origin.

Another case is:

上海用户 → Anycast入口 → 香港边缘节点 → 东京上层缓存 → 美国源站

The remote IP seen by the user can only represent the outermost entry point and cannot show the locations of the layers behind it.

So:

• A CDN node IP is not the origin IP;

• The node city is not the origin city;

• Low node latency does not mean origin fetches are necessarily fast;

• Cache HIT and MISS may perform completely differently.

For a complete comparison of the two types of addresses, seeWhat is the difference between a CDN node IP and an origin IP?.

The most practical way to judge IP location results

If you only want to know whether website access is nearby, you do not need to insist on finding an 'absolutely accurate node city.'

A more practical inspection sequence is:

1. Confirm whether the request goes through the expected CDN;

2. Record the actual response IP and ASN;

3. Check whether a provider PoP field exists;

4. Repeat tests from core regions and carriers;

5. Check whether connection latency matches the characteristics of a nearby entry point;

6. Compare cache HIT and MISS;

7. Observe P95 and failure rate;

8. Label the source and confidence level of city information.

What users ultimately experience is connection speed, response time, and stability, not a coordinate point on an IP database map.

Frequently asked questions

1. IP lookup shows the United States; why is access from mainland China still fast?

The IP may use Anycast and also have nodes advertising in mainland China or nearby regions; alternatively, the IP database may record the network block's registration location rather than the actual service location.

2. Can the same CDN node IP correspond to multiple cities?

Yes. Anycast allows nodes in multiple regions to use and advertise the same IP simultaneously, and users enter different nodes based on actual network routing.

3. Do different IPs necessarily represent different CDN nodes?

Not necessarily. A PoP can have multiple IPv4 and IPv6 addresses and can also assign different addresses to different products, lines, or customers.

4. Which platform is most accurate for IP geolocation lookup?

No public IP database can guarantee absolutely accurate city-level results. It is recommended to cross-compare multiple data sources and combine provider PoP fields, multi-region probing, ASN, and network latency.

5. Can Ping latency determine which city the server is in?

It can only assist estimation. Network detours, carrier interconnection, ICMP rate limiting, and Anycast can all affect the result, so physical location cannot be determined by a single Ping.

6. Are CDN node locations the same as origin locations?

Usually not. CDN nodes provide edge access and caching for users, while the origin sits behind the CDN and may be in another city, country, cloud platform, or private network.

7. Why do different speed-test platforms show different node cities?

Platforms may use different IP databases, data update times, geolocation logic, and probe locations. Some platforms show the IP registration location, while others show an estimated PoP; the two meanings are not the same.

8. When choosing a CDN, should you look at node cities or actual measured speed?

Node coverage can be used for initial screening, but the final decision should be based on availability, connection time, TTFB, download speed, and P95 stability in the regions and on the carriers of target users.