Website Fast on China Telecom but Slow on China Mobile: How Can You Tell If It's a CDN Issue?

The website loads quickly over China Telecom broadband, but slows down noticeably on China Mobile networks. Images take a long time to appear, the admin panel sometimes spins, and the same page can feel like two different websites on the two connections.

The first reaction for many people is: "The CDN's mobile routing is poor."

That suspicion is understandable, but it isn't enough to draw a conclusion.

China Telecom being fast and China Mobile being slow could mean the CDN is directing China Mobile users to unsuitable nodes, or that congestion exists on the route from China Mobile to the node. It could also be because mobile networks use IPv6 more often, DNS resolution returns different results, cache misses occur, or the comparison simply pits a phone on 4G against a computer on wired broadband—which isn't a fair test.

To determine whether the CDN is the problem, you can't just compare two "load speeds." You need to align the test conditions and then check, in order:where DNS resolves to, which stage the connection slowdown occurs in, whether cache is hit, whether IPv4 and IPv6 behave consistently, and whether the issue can be reliably reproduced across multiple mobile nodes.

First, clarify: does "China Mobile is slow" mean China Mobile the carrier, or slow on mobile devices?

In Chinese, "移动" often refers to two things at once:

• China Mobile, the carrier;

• mobile devices and access methods such as phones, 4G, or 5G.

If you compare a computer on China Telecom wired broadband with a phone accessing over China Mobile 5G, you're changing more than the carrier: device, browser, wireless signal, network type, IPv4/IPv6, cache, and page version all differ.

This kind of test can show that "the two usage scenarios perform differently," but it can't directly prove the difference comes from CDN routing.

When comparing CDN performance across carriers, keep the following conditions as consistent as possible:

• the same city or a similar geographic location;

• the same device and browser;

• the same test URL;

• the same time window;

• the same network type, e.g., fixed broadband versus fixed broadband;

• test IPv4 on both, or compare IPv4 and IPv6 separately;

• consistent browser cache, login state, and cookie conditions;

• the same test file size and cache status.

If different devices are unavoidable, record the device model, OS, browser, and network type. Don't attribute every difference to "mobile routing."

Start with one direction for diagnosis: see where mobile users are actually being routed

CDNs typically return different edge nodes to different users based on DNS, user location, carrier, node load, and scheduling policies.

Within the same city, China Telecom and China Mobile users resolving to different IPs is not abnormal in itself. What really matters is:

• whether China Mobile users are hitting reasonable nodes with China Mobile or multi-carrier coverage;

• whether the node's region is too far from the user;

• whether China Mobile users are crossing networks to access nodes on China Telecom routes;

• whether repeated DNS resolutions are stable;

• whether IPv4 and IPv6 are scheduled to completely different networks;

• when problems occur, whether China Mobile users are concentrated on the same set of abnormal IPs.

You can useCDNChart CDN Checkto view the CNAME, resolved IPs, node ownership, and possible CDN in use, then useCDNChart Website Speed Testto observe results across different regions and carriers.

If multiple China Mobile test points are routed to clearly distant nodes while China Telecom in the same city hits local nodes, CDN scheduling should be the first area to investigate.

If China Telecom and China Mobile resolve to the same node IP, but China Mobile's connection time, packet loss, or download speed is clearly worse, it looks more like a routing, interconnection, or capacity issue between China Mobile and that node.

China Telecom fast, China Mobile slow: common causes go beyond too few CDN nodes

China Mobile users are routed to distant nodes

This is the most obvious type of CDN issue.

For example, in Guangzhou, China Telecom users may hit a Guangzhou node while China Mobile users are sent to Shanghai or another distant region. In that case, TCP connection, TLS, and TTFB on the China Mobile side usually increase.

Possible causes include:

• a local China Mobile node failure or maintenance;

• insufficient node capacity causing the scheduling system to bypass it;

• DNS misidentifying the user's location or carrier;

• the recursive DNS used not matching the user's actual network;

• the CDN lacking suitable China Mobile routing resources in that region;

• the scheduling policy choosing a farther backup node for availability.

Don't judge solely by the city name in an IP geolocation database. IP ownership data can be inaccurate, so also consider actual connection time, ASN, routing, and results from multiple tests.

The node is local, but China Mobile routing quality is poor

Geographic proximity doesn't guarantee a good network path.

A CDN node may be deployed in the same city, but interconnection bandwidth with China Mobile may be insufficient, or congestion may occur during peak evening hours.

Common signs include:

• DNS resolution and node region look normal;

• China Mobile's TCP connection time is higher than China Telecom's;

• small files are barely normal, but large file download speeds are clearly insufficient;

• normal during the day, consistently slower at night;

• the P50 gap isn't large, but China Mobile's P95 rises noticeably;

• similar problems appear in multiple China Mobile regions.

This is not the same as "whether there are enough nodes." Even if nodes exist, user experience will still suffer if egress capacity, carrier interconnection, or peak-hour scheduling is insufficient.

Mobile networks resolve to a different CDN or backup route

When using multi-CDN, primary/backup CDN, or carrier-specific DNS resolution, China Telecom and China Mobile users may not be using the same provider at all.

For example, China Telecom routes may resolve to the primary CDN, while China Mobile routes hit the backup CDN due to a configuration error, health check, or routing rule.

On the surface it looks like "the same website is slow on China Mobile," but in reality you're comparing two sets of nodes, caches, and origin-fetch policies.

When checking, don't look only at the outermost CNAME of the domain. Trace the final CNAME, A, and AAAA records, and confirm which provider each carrier's resolution results point to.

Mobile networks use IPv6 more often, and the IPv6 path has problems

Some networks and devices prefer IPv6. Even if the website has AAAA records, IPv6 node coverage, certificates, routing, origin fetches, or firewall configuration may not have been fully tested.

Common signs include:

• China Telecom IPv4 access is normal, but mobile devices slow down when IPv6 is preferred;

• the same mobile network returns to normal when IPv4 is forced;

• AAAA records resolve to nodes in a different region from the A records;

• IPv6 connection or TLS time is clearly higher than IPv4;

• only some phones and home routers experience the issue.

This kind of issue is easily misdiagnosed as "poor mobile CDN routing," when what actually needs fixing is IPv6 scheduling or the IPv6 path.

Lower cache hit ratio on mobile nodes

China Telecom and China Mobile users may hit different CDN nodes, and different nodes have different cache warmth.

If the China Telecom node returnsHIT, while the mobile node frequently returnsMISS,EXPIREDor fetches from origin, mobile users experience an extra wait from the node to the origin.

This may show up as:

• China Mobile's TCP and TLS aren't slow, but TTFB is clearly high;

• the same resource is slow on the first request and faster on repeated requests;

• static files are sometimes fast and sometimes slow;

• the origin server is far from the mobile node;

• origin server load rises at the same time as mobile nodes fetch from origin.

Compare HIT and MISS separately. For details, seeHow to Read CDN Cache Hits: Understanding HIT, MISS, and Age.

Longer origin-fetch paths for dynamic requests on China Mobile

Homepages, login pages, APIs, and personalized pages usually can't be cached directly like static images. Even if China Mobile users hit a nearby node, dynamic requests still need to go back to the origin.

If China Mobile edge nodes use different origin-fetch egress, origin ingress, or intermediate links than China Telecom, dynamic requests may be normal on China Telecom while China Mobile dynamic requests are slower.

In this case, don't test only one cached image. Test separately:

• a fixed static file that is a cache HIT;

• a test file that is a cache MISS;

• an uncached dynamic page;

• a critical read-only API.

If mobile HITs are normal while MISSes and dynamic requests are clearly higher, focus on the origin-fetch path from mobile nodes to the origin, not the last mile from users to nodes.

Slow DNS resolution, not slow HTTP transfer

Different carriers usually use different recursive DNS resolvers, and cache state, EDNS Client Subnet support, and network paths to authoritative DNS may differ.

China Mobile users may already wait several hundred extra milliseconds at the DNS stage, while the HTTP connection and download itself aren't slow. Looking only at Ping or total page time makes it easy to blame CDN nodes for a DNS problem.

You can use browser Timing, multi-node speed tests, and DNS tools to check resolution time separately. For troubleshooting methods, seeDoes Slow DNS Resolution Slow Down a CDN? How to Troubleshoot Domain Resolution Time.

Third-party resources perform poorly only on the mobile side

The main domain and CDN resources may both be fast, while the real slowdown comes from fonts, analytics, ads, maps, CAPTCHAs, customer support widgets, or external APIs.

Mobile devices may also load different page templates, image sizes, and ad resources. As a result, the desktop on China Telecom loads the desktop version while the phone on China Mobile loads another set of resources, making direct comparison impossible.

Open browser remote debugging or save a HAR file on a mobile network to determine whether the slow part is the main domain, a static resource domain, or a third-party request.

Unstable local network or wireless signal on the mobile side

If only one user, one phone, or one home mobile broadband connection has a problem, it doesn't prove a nationwide China Mobile routing issue.

Wi-Fi signal, home routers, ONTs, 5G coverage, VPNs, proxies, private DNS, and endpoint security software can all affect results.

Cross-validation is needed using different China Mobile users, different cities, and public probe nodes.

A diagnostic table: which symptoms point more to a CDN issue?

"More likely" here does not mean final attribution. Network problems can occur anywhere: user access, carrier backbone, interconnection, CDN ingress, edge nodes, or origin-fetch paths.

Step 1: Run a three-carrier comparison in the same city, on the same resource, at the same time

Don't rush to deploy probes nationwide. Pick cities with more user complaints and test the same fixed URL on China Telecom, China Unicom, and China Mobile.

The test targets should ideally include at least:

• a small static file that is a cache HIT;

• a large file of fixed size;

• a dynamic page or read-only API;

• the website homepage, to observe all page resources.

Record:

测试时间、城市、运营商、网络类型、IPv4/IPv6、
解析IP、最终URL、HTTP状态码、DNS、TCP、TLS、
TTFB、总耗时、下载速度、响应大小、缓存状态

A same-city comparison reduces interference from geographic distance.

If China Telecom and China Mobile in Guangzhou still show a consistent difference when accessing the same resource, the issue can more easily be narrowed down to carrier scheduling, routing, and nodes.

Step 2: Compare DNS results for China Telecom and China Mobile

Query A, AAAA, and CNAME records separately on each network.

On Windows, use:

nslookup www.example.com

On Linux or macOS, use:

dig www.example.com CNAME +short
dig www.example.com A +short
dig www.example.com AAAA +short

What you need to record is not "whether the IPs are the same," but:

• whether China Telecom and China Mobile hit different nodes;

• whether the different nodes match their respective regions and carriers;

• whether A and AAAA scheduling locations are consistent;

• whether there are unexpected backup CDNs or stale records;

• whether repeated queries vary within a reasonable set of nodes;

• whether the recursive DNS used by users matches their actual network.

CDNs returning different IPs is usually normal scheduling. What is truly abnormal is a certain group of users consistently hitting unreasonable nodes, or resolution results clearly not matching routing performance.

Step 3: Test IPv4 and IPv6 separately

With curl, you can force IPv4 and IPv6 access separately:

curl -4 -L -o /dev/null -sS \
  -w 'ip=%{remote_ip} status=%{http_code} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  https://www.example.com/test.html

curl -6 -L -o /dev/null -sS \
  -w 'ip=%{remote_ip} status=%{http_code} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  https://www.example.com/test.html

If IPv4 is normal on mobile networks while IPv6 is consistently slower, don't keep using a mixed result to broadly claim "mobile routing is slow."

Further check AAAA scheduling, IPv6 node coverage, and paths.

Note that an IPv6 test failure may also mean the current device or network has no usable IPv6. First confirm the device actually has an IPv6 connection.

Step 4: Determine whether the slowdown is in DNS, connection, first byte, or download

Looking only at how many seconds a page takes to open won't locate the fault. Use the browser Network panel or a speed-test platform to break down the stages:

• High DNS: check the resolution service and scheduling chain;

• High TCP: check the network path from users to nodes;

• High TLS: check network round trips, certificates, and connection reuse;

• High TTFB: use cache status to determine edge processing, origin fetch, or origin server;

• Low download speed: check node bandwidth, route congestion, rate limiting, and file size;

• Requests are fast but the page is slow: check JavaScript, rendering, and third-party resources.

Chrome's official Network documentation states that DevTools can show request status, protocol, remote address, response size, total time, and Timing breakdown. See the Chrome DevTools Network reference.

If DNS, TCP, and TLS are close between China Telecom and China Mobile, but China Mobile TTFB is clearly higher, use HIT/MISS to decide whether to investigate edge processing or origin fetches.

If TTFB is close but large-file downloads are slow on China Mobile, the problem is more likely throughput and route capacity.

Step 5: Check cache status and origin-fetch differences

Pick the same public static file, request it multiple times on both China Telecom and China Mobile nodes, and record cache status and Age.

Focus on:

• whether China Telecom consistently gets HITs while China Mobile frequently gets MISSes;

• whether the first China Mobile request is slow and subsequent HITs recover;

• whether the two sides use different cache rules;

• whether query parameters, cookies, or headers fragment the cache key;

• whether China Mobile nodes were just switched or their cache expires frequently;

• whether origin processing time rises at the same time as China Mobile MISSes.

Don't add random parameters in bulk to production URLs to create MISSes when you don't understand the cache key rules.

This can pollute the cache, increase origin-fetch pressure, and may not even bypass the cache. A safer approach is to prepare dedicated test objects and confirm the test method with the CDN vendor.

Step 6: Use routing and packet loss data to support diagnosis

On Windows, use:

tracert /d www.example.com
pathping /n www.example.com

On Linux, usetracerouteormtr. Run it separately from China Telecom and China Mobile networks where possible, and record the final resolved IP so both sides aren't tracing different targets.

Microsoft's official documentation states thattracertidentifies intermediate paths by gradually increasing TTL;pathpingsends multiple requests to routers along the path over a period of time and calculates latency and packet loss statistics.

SeeMicrosoft tracert documentationandpathping documentation.

But routing results can't be interpreted mechanically:

• an intermediate hop not replying may simply be rate-limiting ICMP;

• a hop showing packet loss while later hops and the endpoint are normal doesn't necessarily affect forwarded traffic;

• forward and return paths may differ;

• tracertprobe traffic and HTTPS business traffic may be subject to different policies;

• a single routing snapshot can't represent long-term conditions during evening peak.

What really matters is whether the anomaly persists at subsequent hops and the final destination, and whether it can be reliably reproduced during the problem period.

Step 7: Go back to CDN logs to see whether China Mobile users really perform worse

After external speed tests find China Mobile slowness, use actual traffic data to confirm the scope of impact.

In CDN logs or monitoring, view by carrier, region, and time:

• request volume;

• bandwidth and traffic;

• cache hit ratio;

• proportions of 2xx, 3xx, 4xx, and 5xx;

• origin-fetch requests and origin-fetch status codes;

• response time or download speed;

• affected domains and URLs;

• when the problem started and recovered.

Tencent Cloud CDN's access monitoring documentation shows that its monitoring includes bandwidth, traffic, hit ratio, request count, status codes, and other metrics, and supports filtering by statistical region or carrier.

This also shows that carrier differences can't be judged by a single client-side speed test; they should be verified in logs and monitoring. For details, seeTencent Cloud CDN Access Monitoring documentation.

Different vendors provide different filtering dimensions and data granularity. If your current CDN can't break down data by region and carrier, at minimum build your own analysis from client IPs, node IPs, and request times in access logs.

How should you organize evidence so the CDN vendor can handle it more easily?

Submitting only "China Mobile is very slow" gives technical support almost nothing to reproduce.

It's recommended to organize it in the following structure:

问题时间：2026-09-19 20:00—22:00（UTC+8）
测试城市：广州
对照运营商：中国电信 / 中国移动
测试URL：https://www.example.com/test.html
解析IP：分别记录A与AAAA
缓存状态：HIT / MISS / 其他
状态码：200 / 4xx / 5xx
DNS、TCP、TLS、TTFB、下载和总耗时：附原始数据
问题频率：每次出现 / 偶发 / 仅晚高峰
路由或pathping：附电信与移动两份
受影响范围：静态文件、首页、API或全部请求

If you can also attach multi-node test tasks, HAR files, CDN request IDs, and origin logs from the same period, the vendor can usually pinpoint the specific node, route, or time window more easily.

Before submitting a HAR file, remove cookies, Authorization headers, tokens, and personal information. Don't publicly share complete network records that contain login state.

Once the cause is found, how should each case be handled?

Confirmed to be a CDN scheduling issue

Submit the affected regions, carriers, resolved IPs, and test times to the vendor, and ask them to check node health, scheduling policies, and backup routes.

Don't just ask to "switch nodes"; also verify P50, P95, and availability after the switch.

Confirmed to be a China Mobile routing or capacity issue

Have the vendor check China Mobile egress, interconnection bandwidth, and peak capacity.

In the short term, adjust scheduling or switch to backup nodes; in the long term, confirm whether the region has stable China Mobile routing resources.

Confirmed to be an IPv6 issue

Fix AAAA scheduling, IPv6 nodes, certificates, firewalls, and origin-fetch configuration.

Don't permanently delete AAAA records without assessing the impact, because that can mask the problem and affect IPv6 users who were previously fine.

Confirmed to be a cache or origin-fetch issue

Adjust cache keys, TTL, and refresh policies, and check the origin-fetch path from mobile nodes, connection reuse, and origin location.

For dynamic workloads, also optimize the origin application, database, and external APIs.

Confirmed to be only a single user or local network issue

Check the device, Wi-Fi, router, ONT, VPN, private DNS, and signal quality.

Only when the issue can be reproduced on multiple independent China Mobile networks, different devices, and public probe nodes is it appropriate to escalate it as a carrier or CDN problem.

FAQ

If China Telecom is fast and China Mobile is slow, will switching CDNs definitely solve it?

Not necessarily.

If the current CDN genuinely lacks stable China Mobile routing in the target region, switching CDNs may help. But if the problem comes from IPv6 configuration, origin fetches, third-party resources, or the user's local network, simply changing CDNs may not solve it.

Why is China Mobile Ping low but the page still slow?

Ping reflects only ICMP round-trip latency. It does not cover full DNS, TCP or QUIC, TLS, HTTP processing, cache origin fetches, file downloads, or browser rendering.

For further breakdown, see "Ping Is Fast, but the Website Is Slow? Don't Mistake Latency for Load Speed."

If China Telecom and China Mobile resolve to different IPs, is that a misconfiguration?

Not necessarily. Scheduling different nodes by carrier and region is normal CDN behavior.

You should assess whether those nodes are reasonable and stable, and whether China Mobile nodes' connection and download performance is consistently poor.

If only China Mobile is slow during evening peak and normal during the day, what's most likely?

Check China Mobile routing or node capacity first, but also rule out peak origin load.

Use a fixed file that is a cache HIT to distinguish: if HITs also slow down during evening peak, it's more likely routing or nodes; if HITs are normal and dynamic requests slow down, it's more likely origin fetch or the origin server.

If China Mobile 4G is fast but China Mobile home broadband is slow, is that the same issue?

It can't be directly treated as the same issue.

Although both are China Mobile, the access network, egress, recursive DNS, IPv4/IPv6, and routing may differ, so they should be recorded and tested separately.

What evidence best shows the problem is related to the CDN?

Multiple independent China Mobile nodes accessing the same cache-HIT resource at the same time all show high connection time, TTFB, or low throughput, while China Telecom in the same city performs normally, and the anomalies are concentrated on a set of China Mobile node IPs.

This kind of evidence is more convincing than "it's slow on my phone."

If the problem appears only on MISSes or dynamic requests, don't stop at the conclusion that "the mobile CDN is slow." Continue checking the origin-fetch path from mobile nodes to the origin and the origin's processing time during the same period.