Page 2 of 2
A reverse proxy sits in front of one or more backend servers and forwards client requests to them, then returns the response back to the client - from the client's perspective, they only ever talked to the proxy. Nginx and similar tools get put in front of applications constantly, and it's worth being explicit about why, since "just run the app directly" would technically also work.
A reverse proxy commonly handles things the application itself shouldn't have to: terminating TLS (so the app only ever deals with plain HTTP internally), compressing responses, serving static files directly without bothering the app server, adding request timeouts and buffering, and rewriting or routing paths to different backend services. It's also the natural place to centralize things like rate limiting and access logging across every app behind it, instead of reimplementing that logic in each app separately.
Note the distinction from a forward proxy: a forward proxy sits in front of clients, hiding who's making the request; a reverse proxy sits in front of servers, hiding which one actually handled it.
A VPN (Virtual Private Network) creates an encrypted tunnel between two points over an otherwise untrusted network, making traffic between them behave as if it were on a private, local network even when it's physically crossing the public internet.
In infrastructure work, VPNs show up in two common shapes. A client VPN lets an individual person's laptop join a private network remotely - the classic "connect to the office network from home" use case, often needed to reach internal admin tools or databases that were deliberately never exposed to the public internet. A site-to-site VPN connects two entire networks to each other - say, an on-premises data center and a cloud VPC - so that machines on either side can reach each other by private IP as if they shared one network, without any of that traffic touching the public internet unencrypted.
A CDN (Content Delivery Network) is a network of servers distributed geographically, positioned to be physically closer to end users than your origin server is. When a user requests something a CDN serves, it's answered from a nearby edge location rather than traveling all the way back to wherever your actual server lives - cutting latency substantially.
The part that matters operationally is understanding what gets cached and for how long. Static assets - images, CSS, JS bundles - are ideal candidates and often cached aggressively. Dynamic, personalized responses generally shouldn't be cached at all, or need very deliberate cache rules. Cache behavior is controlled largely through HTTP headers like Cache-Control, and a common production incident is exactly this: a page that should update per-user or per-request gets accidentally cached and served stale to everyone. Purging or invalidating a CDN's cache after a deploy is often a required step, not an optional one, precisely because the CDN doesn't automatically know your origin changed.
Rate limiting caps how many requests a client can make in a given window, protecting a service from being overwhelmed - whether by a genuine traffic spike, a buggy client retrying too aggressively, or a deliberate abuse attempt. It's commonly implemented per API key or per IP, and a well-designed rate limit returns a 429 Too Many Requests status along with a header telling the client when it's safe to retry, rather than silently dropping requests.
Timeouts matter on both ends of a request. A client-side timeout defines how long you'll wait for a response before giving up - too short and you abandon slow-but-successful requests; too long and one hung dependency can stall an entire chain of callers waiting on it. Server-side timeouts protect the server the same way: without one, a single slow client (or a slow-loris-style attack deliberately trickling data) can tie up a connection slot indefinitely. Getting timeout values right - and making sure they're set consistently at every hop in a request chain - is a recurring theme in production incidents where "it just hangs" turns out to mean "nothing ever times out."
Sometimes application-level logs aren't enough, and you need to see what's actually crossing the wire. Tools like tcpdump capture raw packets, and while deep packet analysis is its own skill, knowing the shape of what you're looking at goes a long way.
sudo tcpdump -i eth0 port 443 -n
# -i eth0 capture on this network interface
# port 443 only show traffic on this port
# -n don't resolve IPs to hostnames (faster, avoids extra DNS lookups)
At a high level, you're looking for things like: does the three-way handshake even complete, are packets arriving out of order or being retransmitted (a sign of packet loss), and how much time elapses between a request going out and a response coming back. You don't need to read raw packet dumps for routine debugging, but knowing this tool exists - and reaching for it specifically when application logs show a request simply vanishing with no error - saves enormous time versus guessing at the application layer when the problem is actually underneath it.
Real scenario-based DevOps questions, hands-on practice, and clear explanations for every answer.