A CDN is only as fast as what it’s pulling from. When a CDN edge node needs to fetch an uncached asset from your dedicated server — a cache miss — the speed of that origin response determines how long the user waits. An origin server that responds in 50ms delivers a very different user…
Optimizing your dedicated server as a CDN origin is a different discipline than optimizing it for direct user traffic. The CDN handles concurrency and geographic distribution; the origin needs to respond reliably to CDN pull requests with correct cache headers, compressed assets, and minimal time-to-first-byte.
How CDN Origin Requests Differ from Direct User Requests
When CDN is deployed in front of your dedicated server, user traffic patterns change fundamentally:
Direct traffic (no CDN): Every user request hits your server. High concurrency means many simultaneous connections. Response time directly affects user experience.
CDN-proxied traffic: CDN edge nodes cache responses and serve them to users from geographic PoPs. Your origin sees CDN pull requests — mostly cache misses for new or expired content. Concurrency is lower but requests may be less predictable (cache expiry causes simultaneous pulls from multiple edge nodes).
Cache miss storms: When a high-traffic asset expires simultaneously across CDN nodes, multiple edge nodes request the same resource at once. An origin server that’s slow to respond causes cache misses to queue up, potentially serving stale content or failing requests during the refill window. Cloudflare calls this “origin shield” — routing edge-to-origin traffic through a single intermediate node reduces the number of simultaneous origin pulls during cache refresh.
Nginx Configuration for CDN Origin Performance
The Nginx configuration on your dedicated server needs different tuning for origin service versus direct user service.
Worker processes and connections:
# Match worker count to CPU cores
worker_processes auto;
# Increase for origin serving high–traffic CDN pulls
events {
worker_connections 4096;
use epoll;
multi_accept on;
}
Keepalive for CDN connections: CDN edge nodes make repeated requests to your origin. Keepalive connections eliminate TCP handshake overhead on each request:
# Keep connections to CDN alive
keepalive_timeout 120s;
keepalive_requests 1000;
upstream origin_backend {
server 127.0.0.1:8080;
keepalive 64; # Connection pool size
}
}
Gzip compression at origin: CDN nodes typically cache the compressed version and serve it directly. Configure Gzip at the origin for all compressible types:
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_types
text/plain
text/css
text/javascript
application/javascript
application/json
application/xml
image/svg+xml
font/woff2;
Level 6 balances compression ratio against CPU cost. Levels 7-9 provide marginal additional compression at significant CPU overhead — rarely worth it for static assets.
Cache-Control Headers: The Most Important Origin Configuration
CDN behavior is almost entirely determined by the Cache-Control headers your origin sends. Getting these right determines whether your CDN caches aggressively (reducing origin load) or pulls frequently (adding unnecessary origin requests).
Static assets (CSS, JS, images, fonts): Set long max-age with fingerprinted URLs. When the file content changes, the filename changes (webpack content hash, etc.), so caching aggressively is safe:
expires 1y;
add_header Cache–Control “public, max-age=31536000, immutable”;
add_header Vary “Accept-Encoding”;
}
The immutable directive tells CDN and browsers never to revalidate this URL — the content will never change at this URL.
HTML pages: Short or no cache. HTML changes with content updates and shouldn’t be aggressively cached unless you’ve implemented proper cache invalidation:
add_header Cache–Control “public, max-age=300, stale-while-revalidate=60”;
}
stale-while-revalidate=60 allows CDN to serve a slightly stale HTML response while fetching a fresh copy in the background — reduces origin requests without serving stale content to users for more than 60 seconds.
API responses: Typically no-cache or short TTL:
add_header Cache–Control “private, no-store”;
}
Origin Shield Configuration
An origin shield is a CDN feature that routes all edge-to-origin traffic through a single regional PoP rather than allowing all global edge nodes to pull directly from your origin. The practical benefit: instead of 50 edge nodes each requesting the same asset when a cache expires, one shield node makes the request and distributes the cached response to the other edge nodes.
Cloudflare’s Tiered Cache implements this as a Smart Tiered Cache topology that automatically selects the best intermediate PoP based on your traffic patterns. Enable it in the Cloudflare dashboard under Caching > Tiered Cache.
For origins on InMotion’s Los Angeles data center, Cloudflare’s West US tier provides the lowest latency between the shield and origin. For the Amsterdam data center, the Western Europe tier is appropriate.
Serving Static Assets from NVMe: I/O Configuration
Your dedicated server’s NVMe drives serve static assets to CDN edge nodes. NVMe I/O throughput is rarely the constraint for static file serving — network bandwidth typically hits limits before NVMe does. But file system configuration affects serving speed:
Open file cache: Nginx caches file descriptors and stat() results for frequently-served files:
open_file_cache_valid 60s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
This eliminates repeated open() and stat() system calls for the same files — measurable improvement for high-request-rate static serving.
Sendfile: Use the kernel’s sendfile() system call instead of read()+write() for file transfer. Zero-copy data movement:
tcp_nopush on; # Batch sendfile calls for efficiency
tcp_nodelay on; # Disable Nagle after data is sent
AIO for large files: For video files, large downloads, or other assets over 1MB:
directio 512; # Use direct I/O for files over 512 bytes
output_buffers 2 128k;
Monitoring Origin Performance from the CDN Perspective
Standard server monitoring shows your server’s resource usage. Origin performance from the CDN’s perspective requires monitoring from the CDN layer.
Cloudflare Analytics shows origin response time (the time from CDN edge to your server and back), cache hit ratio, and error rates. Target:
Cache hit ratio: 85%+ for content-heavy sites, 95%+ for static asset heavy sites
Origin response time (TTFB at edge): under 100ms for cached responses, under 500ms for origin pulls
Origin error rate (5xx): under 0.1%
Nginx access log analysis shows what the CDN is actually requesting from your origin. A high volume of requests for the same URL indicates a caching problem — either the URL isn’t being cached or cache is expiring too frequently:
awk ‘{print $7}’ /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
If the same dynamic URLs appear repeatedly, they’re either not cacheable (correct for API endpoints) or missing Cache-Control headers (fixable).
WordPress as CDN Origin
WordPress sites commonly run behind CDN with a dedicated server as origin. WP Rocket, W3 Total Cache, and LiteSpeed Cache all support CDN integration and manage Cache-Control headers automatically for WordPress-specific content types.
Key WordPress configuration for CDN origin serving:
Enable object caching with Redis (reduces dynamic page generation time, improving origin TTFB)
Set page cache TTL to 30-60 minutes for logged-out users
Exclude admin URLs, cart, checkout, and account pages from caching
Enable CDN integration in the caching plugin to rewrite asset URLs to CDN hostnames
InMotion Hosting’s Premier Care includes InMotion Solutions consulting time for teams setting up CDN integration for the first time, that hour of monthly consulting time can be used for CDN configuration review and optimization.
Related reading: Network Latency Optimization for Dedicated Servers | Server Resource Monitoring & Performance Tuning