CDN Caching and Origin Pull Best Practices: Strategies, Pitfalls, and Solutions

The two most common confusions after integrating CDN are: “I changed the content, but users still see the old version”, and “CDN doesn’t seem to be working”. The former is usually due to unrefreshed cache, while the latter often stems from origin pull configuration issues or source server exposure.

Understand Two Core Concepts

The core trade-off: The longer the cache duration, the lower the pressure on the origin server, but the slower the content updates. Configuring CDN is essentially finding a balance between these two factors.

Caching Strategy: Separate by Resource Type

The most common mistake is setting long cache times for HTML—after changing an article, users still see the old page, and you cannot control when each node refreshes.

Cache Headers on the Origin Server

# Static resources: Long cache
location ~* .(js|css|png|jpg|jpeg|gif|webp|ico|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, max-age=2592000";
}

# HTML: Short cache or no cache
location / {
    add_header Cache-Control "no-cache";   # Cacheable but must validate every time
    # Or more conservatively:
    # add_header Cache-Control "no-store";
}

# Verify response headers
curl -I https://example.com/style.css | grep -i cache-control
curl -I https://example.com/ | grep -i cache-control

Solve “Changes Not Visible” with Version Numbers

Static resources need long caching, but you want immediate effect after changes—the solution is versioned filenames:

<!-- Change the version number when content changes; the URL changes, so old cache is not hit -->
<link rel="stylesheet" href="/style.css?v=2.1">
<script src="/app.js?v=20261008"></script>

// Recommended in WordPress using wp_enqueue version parameter
wp_enqueue_style('theme', get_stylesheet_uri(), [], '2.1');

This is the only method that achieves both “long caching” and “instant updates”: set very long cache policies and force invalidation by changing the URL.

Origin Pull Configuration

# ① Confirm the origin server responds normally (CDN sends Host header during origin pull)
curl -I -H 'Host: example.com' http://origin_server_ip/

# ② Ensure the origin server isn't rejecting normal requests while only allowing CDN
# ③ Keep protocols consistent (HTTPS sites should use HTTPS for origin pull)

Origin Pull Host

The Host header sent by CDN during origin pull determines which virtual host configuration the origin server uses to respond. An incorrect entry will cause the origin to return the wrong site (e.g., the default site).

# Simulate CDN origin pull request (access origin with specified Host)
curl -I -H 'Host: example.com' http://origin_server_ip/
# Should return the normal response for this site, not the default site or 404

Do Not Expose Origin Server IP

If attackers know the origin server IP, they can bypass CDN and attack the origin directly, rendering CDN protection useless.

# Check if origin server is accessible directly
curl -I -H 'Host: example.com' http://origin_server_ip/
# If it returns normal content, the origin is exposed

Protection measures:

• Allow only CDN origin pull IP ranges in security groups (providers usually publish these)
• Modify listening ports or bindings on the origin server to allow access only from CDN

# Allow only CDN origin pull range (example, replace with actual range)
allow 203.0.113.0/24;
deny all;

Verify if CDN is Working

# Check if response headers contain CDN-related fields
curl -I https://example.com/ | grep -iE 'x-cache|via|server|age|cf-|x-cdn'

# Check if DNS points to CDN
dig +short example.com A

# Compare multiple requests (Age increases when cache is hit)
curl -I https://example.com/ | grep -i '^age'

The Age field indicates how long the content has been cached on the node. It increases continuously during repeated requests, indicating cache hits; if it stays at 0 or is missing, it means every request is pulling from the origin.

Cache Refresh

# After changing content, manually refresh (available in provider consoles)
# Command line methods depend on the provider's API

# Verify after refresh
curl -I https://example.com/ | grep -i '^age'   # Should return to 0 or a small value

Specify specific URLs or directories for refresh; full-site refresh is costly and instantly spikes pressure on the origin server.

Decision Tree

CDN Configuration
├─ Caching Strategy (by type)
│  ├─ Static Resources (with versioning) → Long cache
│  ├─ HTML               → Short cache or no cache
│  └─ Dynamic APIs        → No cache
├─ Content Changes Not Effective
│  ├─ Refresh CDN cache
│  ├─ Change version numbers for static resources (more fundamental)
│  └─ Check if origin Cache-Control is too long
├─ CDN Seems Ineffective
│  ├─ Use dig to check if DNS points to CDN
│  ├─ Use curl -I to check x-cache/age fields
│  └─ Verify if Origin Pull Host is correct
└─ Security Issues
   └─ Is origin directly accessible? → Security group allows only CDN origin pull range

Scenario Analysis: Users See Others’ Information After Enabling Cache Acceleration

Symptom: Response speed improves significantly after enabling cache acceleration,
but feedback soon arrives that some users see information not belonging to them.

1. Immediately exclude personalized content from caching → This is the highest priority action to stop the bleeding.
   Stop losses first, then analyze. The cost of such issues far outweighs performance gains.
2. Identify why data mixing occurred → The caching service treated one user’s response as public content
   and served it to subsequent requests. The root cause is that the cache key did not distinguish login states.
3. Categorize content based on “relevance to current user” →
   List pages and detail pages can be cached; account-related and settlement-related content must never be cached.
4. Adjust cache differentiation criteria → Requests carrying login identifiers should bypass cache entirely,
   rather than relying solely on path rules.
5. Verify item by item, not just visually → Test the same URL once with login state and once without,
   confirming that responses differ.
6. Ensure dynamic API callbacks are not cached → Callback addresses must be excluded,
   otherwise more隐蔽 (hidden) issues may arise.

# Verification must include login state—results without Cookie are meaningless
for p in / /product/x/ /cart/ /checkout/ /my-account/; do
  printf '%-22s ' "$p"
  curl -sSI -b 'wordpress_logged_in=test' "https://example.com$p" 
    | grep -iE 'x-cache|cache-control' | tr -d 'r' | paste -sd' '
done

# Callback addresses must be excluded from cache
curl -sSI https://example.com/wc-api/callback/ | grep -iE 'x-cache|cache-control'

# Common Nginx pattern: Exclude by path AND by Cookie
# if ($request_uri ~* "^/(cart|checkout|my-account|wc-api)") { set $no_cache 1; }
# if ($http_cookie ~* "woocommerce_items_in_cart|wordpress_logged_in") { set $no_cache 1; }

Root Cause: The cache did not distinguish user states, treating responses containing personal information as shareable content.
This is technically normal for performance, but the boundary for sharing was drawn incorrectly.

Two Key Takeaways:

• The first principle of caching is “Better not to cache than to cache incorrectly.”
  Sharing personal information with others carries a cost far greater than any benefit from caching.
• Verification must simulate login states.
  Without identity information, almost all configurations appear “correctly excluded,”
  but behavior in real scenarios is completely different.

8 Common Pitfalls

1. Setting long cache for HTML: Updates become invisible.
2. Static resources without version numbers: Cannot be updated after long caching.
3. Incorrect Origin Pull Host: Origin returns the wrong site.
4. Exposing Origin Server IP: CDN can be bypassed.
5. Failing to verify cache hits: You won’t know unless you check Age and x-cache.
6. Not distinguishing dynamic vs. static: Caching APIs causes data corruption.
7. Treating full-site refresh as routine: Instantly spikes pressure on the origin server.
8. Using HTTP for origin pull on HTTPS sites: Protocol mismatch may cause redirect loops.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar IT operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud cloud markets (service providers include our store and competitors; provided for reference only, not fictional tickets):

1****4 Rating: 5.0 2023-05-08 11:53 1****3 Rating: 5.0 2022-09-22 22:01 r****u Rating: 5.0 2020-07-07 15:05

b****4 Rating: 5.0 2025-06-23 16:57 b****4 Rating: 5.0 2025-06-23 16:56 Jian****Wei Rating: 5.0 2021-01-20 15:03 Technology is awesome, speed is fast! Originally caused by trojan causing Baidu global hijacking!!!!1 f****u Rating: 5.0 2021-01-02 20:43 Thanks for assisting in maintaining Yuncai’s normal operation. 1****1 Rating: 5.0 2020-11-20 10:03 Consistently good service as always 1****1 Rating: 5.0 2020-11-17 09:13 Thanks for the consistently good service. 1****1 Rating: 5.0 2020-09-25 15:42 Many thanks. 1****1 Rating: 5.0 2020-08-24 15:34 Many thanks to your company’s technical staff 1****1 Rating: 5.0 2020-07-24 09:49 Many thanks! 1

d****9 Rating: 5.0 2023-02-15 09:11 Yong****Ying Rating: 5.0 2021-03-29 11:04