Proxy servers and CDNs sit in the critical path of nearly every user request, yet they’re often the least-monitored layer of the stack – teams watch origin servers closely and assume the edge just works. Monitoring proxy servers and content delivery networks means tracking cache hit ratios, origin fetch latency, connection pool saturation, and edge node health so that a slow or misconfigured edge layer doesn’t silently degrade every request passing through it.
A forward proxy handling 50,000 concurrent connections for an MSP’s client base behaves nothing like a reverse proxy sitting in front of a single SaaS app, and a CDN edge node in São Paulo can be serving stale content or timing out to origin while every dashboard in the NOC shows green because nobody’s checking region-specific metrics. This article covers what to track, how to catch the failure modes that don’t trip standard uptime checks, and where teams usually get this wrong.
Why proxy and CDN monitoring gets overlooked
Most infrastructure monitoring setups start at the server layer – CPU, memory, disk – and work outward. Proxies and CDNs get added almost as an afterthought, usually just a basic uptime monitoring ping against the edge domain.
That’s a mistake because proxies and CDNs fail in ways a simple ping never catches. A reverse proxy like Nginx or HAProxy can return 200 OK on a health check endpoint while its upstream connection pool is exhausted and 30% of real requests are queuing or timing out. A CDN edge node can be reachable and fast while silently serving a cached 500 error to an entire region because the cache-control headers on an origin response got misconfigured during a deploy.
Core metrics for proxy servers
Whether it’s Nginx, HAProxy, Squid, or Envoy sitting in the request path, a handful of metrics matter more than raw uptime.
Active and queued connections tell you whether the proxy is keeping up with demand. HAProxy exposes this directly through its stats socket – `show stat` returns current sessions, queued requests, and connection errors per backend. When queued requests climb past zero and stay there for more than a minute or two, the backend pool is undersized for current load.
Upstream response time versus proxy processing time is the metric that separates a proxy problem from a backend problem. Nginx’s `$upstream_response_time` variable, logged alongside `$request_time`, shows the gap. If `$request_time` is consistently 200ms higher than `$upstream_response_time`, the proxy itself – not the app behind it – is adding latency, often from SSL termination overhead or buffering large request bodies.
Connection pool exhaustion and file descriptor limits cause a specific failure pattern: the proxy runs fine for days, then starts refusing connections under a traffic spike because `ulimit -n` was left at the distro default of 1024. Squid and HAProxy both log this clearly (`too many open files` in the error log), but only if someone’s watching the logs in real time rather than after an outage ticket comes in.
Backend health check failures matter separately from overall proxy uptime. A proxy with 8 backend servers configured can be “up” while 3 of those backends are marked down and traffic is piling onto the remaining 5. Load balancer health check monitoring covers the failover mechanics in more depth, and most of it applies directly to reverse proxy backend pools.
Core metrics for CDN edge performance
CDNs add a layer of complexity because the infrastructure isn’t under direct control – Cloudflare, Fastly, Akamai, and CloudFront all expose different levels of visibility, and none of them give the same granularity as self-hosted metrics.
Cache hit ratio is the single most important CDN metric. A healthy static-asset-heavy site should see hit ratios above 90%; anything below 80% usually means cache headers are misconfigured, TTLs are too short, or query strings are fragmenting the cache unnecessarily. Fastly’s real-time analytics API and CloudFront’s cache statistics reports both expose this per-distribution, and it’s worth pulling at least hourly rather than glancing at it once a week.
Origin fetch latency and origin error rate show what happens on a cache miss. A CDN can report 99.99% uptime at the edge while origin fetches are failing 15% of the time and getting served from stale cache as a fallback – which works until the stale-while-revalidate window expires and users start seeing real errors.
Time to first byte (TTFB) by region, not just averaged globally, catches the regional degradation problem. A CDN edge node in a specific PoP – say, Singapore or Frankfurt – can have elevated latency due to a peering issue or partial outage while the global average looks fine because it’s averaged across 200+ locations. Synthetic checks from multiple geographic vantage points are the only reliable way to catch this; monitoring network latency across multiple locations is the practical approach here.
Setting up practical monitoring – a walkthrough
A workable setup for a mid-size deployment (say, 3 reverse proxies fronting 12 backend services, plus a CDN in front of the whole thing) looks like this:
First, instrument the proxy layer with structured logging – Nginx’s log_format directive should include `$upstream_response_time`, `$upstream_status`, and `$upstream_addr` at minimum, not just the default combined format. Ship those logs somewhere queryable.
Second, add an agent-based check on each proxy host tracking connection counts, file descriptor usage, and process-level CPU/memory – this is standard server resource monitoring, but it needs to run on the proxy boxes specifically, not just the origin servers behind them.
Third, set up external synthetic checks against the CDN-fronted domain from at least 3–5 geographic regions, checking both response time and response body content (not just status code) to catch stale-cache-serving-errors scenarios.
Fourth, pull cache hit ratio and origin error rate from the CDN provider’s API on a schedule – hourly is usually sufficient – and alert when hit ratio drops more than 15 percentage points from its 7-day baseline.
Fifth, correlate proxy-side backend health checks with CDN-side origin error rates. When both spike together, it’s almost always a real backend outage; when only the CDN-side metric spikes, it’s often a CDN-specific issue like a bad cache purge or edge config push.
Common mistakes
The most frequent mistake is monitoring only the CDN’s public status page and treating “Cloudflare says all green” as sufficient. Status pages report platform-wide incidents, not the misconfigured cache header on one specific origin that’s causing 404s for a subset of users.
A second common mistake is alerting on proxy uptime alone without watching connection queue depth. A proxy process that’s technically running but has 400 requests queued behind an exhausted connection pool passes every uptime check while users experience 10-second page loads.
A third mistake, particularly common with teams new to CDN operations: assuming a high cache hit ratio means everything’s fine, without separately checking origin error rate. A CDN serving 95% of traffic from cache while the 5% hitting origin are all failing looks healthy in aggregate until the cache expires across the board simultaneously – which happens more often than expected after a bulk cache purge or a TTL misconfiguration.
Myth: CDNs eliminate the need to monitor origin performance
A persistent misconception is that once a CDN is in place, origin server performance stops mattering because “the CDN absorbs the load.” In practice, cache misses, dynamic content, and API calls that can’t be cached still hit origin directly, and cache hit ratios fluctuate with content type, campaign traffic, and cache purges. An origin that’s silently degrading can go unnoticed for days behind a CDN with a 92% hit ratio, then cause a full outage the moment a purge or deploy drops that ratio to 60%.
FAQ
How often should cache hit ratio be checked?
Hourly pulls are sufficient for most sites, but immediately after any deploy that touches cache-control headers or CDN configuration, checking within the first 15 minutes catches misconfigurations before they affect a large percentage of traffic.
What’s a normal upstream response time for a reverse proxy?
It depends entirely on the backend, but the proxy’s own added overhead (the gap between total request time and upstream response time) should typically stay under 10–20ms for SSL-terminating proxies handling normal payload sizes. Consistent gaps above 100ms usually point to buffering, connection reuse problems, or DNS resolution delays on the proxy itself.
Can synthetic uptime checks alone catch CDN cache-serving-stale-errors issues?
No. A basic uptime check hitting a status-code-only endpoint will often pass because the CDN is serving a cached 200 response even while origin is broken. Checks need to validate response body content or use cache-bypass headers periodically to confirm origin is actually healthy.
Getting proxy and CDN monitoring right comes down to treating the edge layer as seriously as the origin – tracking connection pools and upstream latency on the proxy side, cache hit ratio and origin error rate on the CDN side, and correlating the two when something breaks. The setup described here takes a day or two to wire up properly, and it’s the difference between finding out about an edge-layer problem from a monitoring alert versus from a support ticket.