Skip to content

Proxy server

Every device in this module so far has sat in the path between two endpoints without either one particularly caring it was there. A proxy is different: one side deliberately routes its traffic through it, on purpose, because the proxy is doing something useful — hiding an identity, caching a response, enforcing a policy — on behalf of the client that configured it.

The client knows the server; the server doesn't know the client

A forward proxy — usually just called "a proxy" — is a server that makes requests on a client's behalf. When your browser is configured to use one, connecting to example.com doesn't establish a TCP connection directly to example.com at all. It connects to the proxy instead, and it's the proxy that opens the real connection to example.com, forwards the request, and relays the response back.

In a forward proxy, the client knows exactly which server it's ultimately talking to; the server only ever sees the proxy. That asymmetry is the whole definition, and it's worth holding onto precisely because the next article describes a device that gets this relationship exactly backward.

Client ──configured to use proxy──▶ Proxy ──new connection──▶ example.com
example.com sees: a request from the proxy's IP address, nothing about the original client

What the proxy actually does with your traffic

For plain HTTP, a proxy can read the full request — method, path, headers, body — because nothing is encrypted between the client and the proxy or between the proxy and the destination. For HTTPS, a browser configured to use a proxy typically issues an HTTP CONNECT request asking the proxy to open a raw TCP tunnel to the destination's port 443, and from that point on the proxy just relays encrypted bytes in both directions without being able to read them — the TLS handshake happens end-to-end between the client and the real server, straight through the tunnel. A proxy that instead wants to inspect HTTPS traffic has to actively intercept it: presenting its own certificate to the client and decrypting, inspecting, and re-encrypting the traffic before forwarding it on, which only works if the client is configured to trust that certificate in the first place — otherwise the browser correctly flags it as exactly what it looks like, a person-in-the-middle.

Why anyone routes traffic through a middleman on purpose

  • Content filtering. A corporate or school network can block access to specific sites at the proxy, since every request passes through it by policy — this is the classic "the network won't let me reach this site" experience.
  • Caching. A proxy that's seen a hundred employees request the same static file can serve the 101st request from its own cache instead of hitting the origin server again, saving bandwidth and time. This use has faded somewhat as HTTPS became the default, since an intercepting proxy needs the interception described above to see cacheable content at all.
  • Logging and monitoring. Routing all outbound traffic through one point makes it a natural place to record what left the network and when — valuable for both security auditing and debugging.
  • Limited anonymity. Since the destination server only ever sees the proxy's IP address, a proxy hides the client's address from the far end. This is real but shallow protection: the proxy itself knows exactly who you are, so anonymity from a proxy depends entirely on trusting the proxy operator not to log or hand over that mapping — which is a very different guarantee from what a VPN provides, since a VPN encrypts at the IP layer without needing to understand or terminate the application protocol at all, while a proxy operates at the application layer and, for anything it can read, sees the content going through it.

Common mistakes

  • Treating a proxy as equivalent to a VPN for privacy. A VPN encrypts everything below it and typically doesn't inspect application-layer content; many proxies, especially free public ones, actively read and sometimes modify the traffic passing through them. "It hides my IP" is true of both and is not the same claim as "it's private."
  • Forgetting that some tools ignore system or browser proxy settings entirely. Configuring a proxy in your OS or browser doesn't automatically route every application's traffic through it — a command-line tool, a background service, or a language runtime often needs its own separate proxy configuration (environment variables like HTTP_PROXY and HTTPS_PROXY, or an explicit client option), and assuming "I set the proxy" covers everything is a common source of confusing, inconsistent behavior.

Practical scenario: curl works, the application doesn't

A backend developer, working from inside a corporate network that requires a proxy for all outbound internet access, can browse the web fine and can run curl https://api.example.com successfully from the same terminal. Their application, making what looks like the identical HTTPS request through a standard HTTP client library, fails every time with a connection timeout — never even a TLS error, just silence until the timeout fires.

curl picked up the proxy configuration automatically from the HTTPS_PROXY environment variable already set in the shell. The application's HTTP client library, in this particular language and version, doesn't read that variable by default — it needs the proxy configured explicitly in code or through a library-specific setting. Without it, the application tries to connect directly to api.example.com, and on a corporate network where direct outbound connections are blocked by the network's firewall specifically to force traffic through the proxy, that connection attempt hangs until it times out — the same "silent drop, not an explicit refusal" signature covered in the firewall article, for exactly the same underlying reason.

Confirming this takes one comparison: checking whether env | grep -i proxy shows the variable the working curl command is using, then checking the application's own HTTP client documentation for whether — and how — it expects proxy configuration to be provided. Two tools on the same machine, making requests to the same destination, can have completely different proxy behavior, because "using a proxy" isn't a property of the operating system by default — it's a property each individual piece of software has to actually implement.

Practice exercises

  1. Explain, in terms of what each side can see, why a destination server behind a forward proxy never learns the original client's IP address — and what would have to change for it to find out anyway.
  2. A proxy is configured to intercept and inspect HTTPS traffic by presenting its own certificate to clients. Explain why this requires client devices to explicitly trust that certificate, and what a browser does when it encounters a proxy certificate it doesn't trust.
  3. Run env | grep -i proxy (or check your system's network settings) on your own machine. If a proxy is configured, identify which variable or setting a typical command-line tool would need to read to use it.

A forward proxy exists so a client can reach a destination it already knows about, through a middleman the destination never sees. The next device inverts that completely: the client thinks it's talking to the final destination, when it's actually talking to something standing in front of servers it has no idea exist.

Sources