Many people host their businesses on high-bandwidth servers in Hong Kong and then connect to a CDN, assuming everything is fine: user access goes through the CDN, so the origin server should be under minimal pressure. However, a counterintuitive problem often occurs in practice—the user side seems fine, but the origin server's bandwidth is saturated, leading to origin server congestion during peak hours, even slowing down the entire site.

　　The essence of this problem isn't that "CDN is useless," but rather that CDN isn't truly sharing the traffic load. To solve this, you need to understand "why origin server requests occur, where they occur, and how much they occur," rather than simply increasing bandwidth.

　　Let's start with a key understanding: CDN only saves origin server bandwidth when the cache is hit; if there's a miss, the request will still hit the origin server. The so-called "origin server bandwidth bottleneck" is essentially due to too many misses or an unreasonable origin server request method, causing frequent access to the origin server.

　　The first step in troubleshooting isn't looking at the server, but at the CDN-side data. Most CDN consoles provide metrics such as "hit rate," "origin server traffic," and "origin server request count." Here, we focus on two key metrics: hit rate and origin server bandwidth.

　　If the hit rate is only 60% or lower, the problem is pretty clear—caching isn't working. A healthy static resource site should typically have a hit rate of over 90%, or even higher. If it's significantly lower than this, it indicates a large number of requests are constantly going back to the origin server.

　　Next, we need to figure out: why are there no hits?

　　The most common reason is an improperly configured caching strategy. For example, many people deploy a CDN with the default rule of "no caching for dynamic content," but your website happens to have no cache headers set for images, no expiration times set for CSS/JS, and the API response includes `no-cache`.

　　The result is: every request is judged as uncacheable by the CDN and goes directly back to the origin server.

　　You can check the response headers, for example:

curl -I https://yourdomain.com/image.jpg

　　If you see `no-cache`, `no-store`, or no cache headers at all, it's almost certainly a caching strategy problem.

　　There are generally two solutions: one is to set cache headers on the origin server (Nginx/Apache), and the other is to force caching of certain paths (such as /static/*) in the CDN console.

　　Another very common problem is "dynamic parameters causing cache invalidation." For CDNs, these parameters may be treated as different resources, and each request becomes a new cache key, resulting in "appearing to be the same file, but actually all MISS." This situation is very common in front-end build tools or API requests.

　　The solution is to enable "ignore parameter caching" on the CDN side or specify to retain only key parameters.

　　Further investigation involves checking for "cache penetration." For example, users requesting a large number of non-existent files, crawlers scanning paths (/abc123.jpg), or maliciously requesting random URLs. These requests will never hit the cache and will always return to the origin server. If the volume is large, it will directly overwhelm the origin server's bandwidth.

　　These types of problems can be identified through access logs. For example:

tail -f access.log

　　If you see a large number of 404 requests with disorganized paths, it's basically been scanned. Solutions include: enabling CDN caching of 404 requests (for a short time), adding WAF or protection rules, and limiting the frequency of abnormal requests.

　　Another hidden situation is "too short cache time." For example, you set up caching, but the TTL is only 10 or 30 seconds. Under high concurrency, the cache has just expired, and a large number of requests simultaneously return to the origin server, creating an "origin server storm."

　　In this case, you need to extend the cache time for static resources, such as: images for more than 1 day, JS/CSS for several hours to several days, and infrequently changing resources even for a week. Using version numbers (such as filenames with hashes) can avoid update issues.

　　If the caching strategy is correct, but the origin server request rate is still high, then you need to check if "private resources" or "authentication access" are being used. For example: content that requires login to access, URLs with tokens, and anti-hotlinking parameters.

　　These types of content usually cannot be cached, or the CDN is unwilling to cache them. In this situation, origin pull is normal and can only be mitigated through architectural optimization, such as splitting static and dynamic content and introducing tiered caching.

　　Another easily overlooked point is "origin node selection." Some CDNs have multiple origin nodes globally. If your origin server is in Hong Kong, but the CDN's origin node is in the US or another region, it will cause additional cross-border latency and even bandwidth bottlenecks.

　　This can be optimized by configuring "origin region" or "origin acceleration" in the CDN to ensure that origin pulls are completed within the same region as much as possible.

　　If the above is normal, you can further examine the server side. For example, use tools to monitor real-time bandwidth to see if certain IPs or paths are consuming all the bandwidth. Combined with log analysis, you can pinpoint whether a certain type of request is causing the problem.

　　At the same time, you should also confirm that the server itself has no other traffic sources, such as: being directly accessed by bypassing the CDN (exposed origin IP), APIs being directly called, or other services consuming bandwidth.

　　If the origin IP is exposed, users or attackers can directly access the server, bypassing the CDN. This traffic will not be cached and will directly consume bandwidth. The solution is to restrict access from the origin server to only CDN IPs, using firewalls or security groups for control.

　　From a holistic perspective, origin server bandwidth bottlenecks are usually not a single point of failure, but rather a combination of factors: inappropriate caching strategies, parameters causing MISS errors, insufficient cache time, abnormal requests, and exposed origin servers. A truly effective troubleshooting approach is to start with CDN metrics, then examine request types, caching rules, and origin server behavior layer by layer.

　　Finally, here's a practical troubleshooting strategy: first check the hit rate; if it's low, check the cache; if the hit rate is normal but origin server requests are high, check the request types; if it's abnormal requests, implement protection measures; if it's normal business logic, consider architectural optimization, rather than simply increasing bandwidth.