Proxies Explained Simply
The Office Receptionist That Runs the Internet: Proxies Explained Simply
You've heard the word "proxy" a hundred times. Here's what it actually means — and why it matters more than you think.
There's a moment every developer hits: you're on a corporate network, you run your app, and it just... hangs. No error. No timeout. Just silence. You Google the problem. Someone says "check your proxy settings." You nod, pretend you understand, and open a new tab.
This post is for that moment. Let's fix that gap once and for all.
Start With a Building
Picture a large office with 500 employees. If every single person walked out the front door to run their own errands, you'd have chaos. Security doesn't know who's coming and going. You can't control what people bring back. The front entrance is a nightmare.
So the building hires a receptionist. You hand your request to them, they go outside and handle it, and they bring the result back to you. You never leave the building.
That receptionist is a proxy.
Instead of your computer talking directly to the internet:
Your computer ─────────────────► google.com
You get:
Your computer ──► Proxy ──► google.com
◄── ◄──
Your computer only ever talks to the proxy. The proxy handles the internet on your behalf.
Why Would Anyone Want This?
There are actually four solid reasons, and they apply at very different scales.
Security and control. A company can say "nobody on our network can access social media during work hours." The proxy checks every single request. If it's headed to instagram.com, it gets blocked. Employees can't sneak around this because they physically cannot reach the internet without going through the proxy first.
Caching. Imagine 500 employees all downloading the same Windows update simultaneously. That's 500 copies of a 2 GB file hammering your internet connection. A proxy can download it once, store a copy locally, and serve it to all 500 people from that cache. Faster for everyone, and far cheaper on bandwidth. This is exactly what Squid (a popular proxy server) does, and why universities and large companies swear by it.
Privacy. When you go through a proxy, websites see the proxy's IP address, not yours. This is the core idea behind VPNs too, just packaged differently.
Escaping private networks. Some servers have no direct internet connection at all. They live inside a private internal network, and the only way out is through a designated proxy. Banks, hospitals, and government systems work like this. If your app is deployed in one of these environments, no proxy awareness means no internet.
Forward Proxy vs. Reverse Proxy
This is where people get confused, because the names sound interchangeable. They are not. They do opposite things.
A forward proxy protects the client. It sits in front of your users and handles requests going outward.
[Employees] ──► [Forward Proxy] ──► [Internet]
The internet never knows who the real user is. Think of it as a receptionist handling your outgoing calls.
A reverse proxy protects the server. It sits in front of your servers and handles requests coming inward.
[Internet] ──► [Reverse Proxy] ──► [Your Web Server]
Users never know which server actually handled their request. Think of it as a call centre routing incoming calls to the right department.
If you've used Nginx, Traefik, or Cloudflare in front of a web app, you've used a reverse proxy. If you've worked inside a corporate network that blocks certain websites, you've been on the client side of a forward proxy.
How Does an App Actually Use a Proxy?
The Easy Way: Environment Variables
Most tools, including curl, wget, Python's requests library, and Go's standard HTTP client, check for these environment variables automatically:
HTTP_PROXY=http://proxy.example.com:3128
HTTPS_PROXY=http://proxy.example.com:3128
NO_PROXY=localhost,127.0.0.1
Set them, and the app routes all traffic through the proxy without a single line of code changes. You can verify it immediately:
export HTTP_PROXY=http://proxy.example.com:3128
curl https://google.com # goes through proxy
Done. Clean. Simple.
The Hard Way: Some Apps Just Ignore It
Here is where things get painful.
Not every app respects these environment variables. Node.js 18+ ships with a built-in fetch function (powered by a library called undici under the hood). It was written for raw performance and deliberately does not read HTTP_PROXY. You can set the variable, restart your app, and Node.js fetch will still try to go straight to the internet and fail silently in a restricted network.
The same goes for any app that implements its own HTTP client from scratch. The environment variable convention is just a convention, not a requirement.
So what do you do when the app won't listen?
The Nuclear Option: Transparent Proxy
If you can't make the app proxy-aware, you force the proxy at the operating system level. The app never gets a say. This is called a transparent proxy, because the app doesn't even know it's being intercepted.
Here is how the traffic flows:
App (e.g. Node.js fetch)
│ thinks it's going directly to google.com
│
▼
[iptables on the OS] ← intercepts the traffic
│
▼
[redsocks :12345] ← receives it transparently
│
▼
[Company Proxy :3128] ← forwards to the real proxy
│
▼
google.com
Two tools make this work together.
iptables is the Linux firewall. You configure it to intercept all outbound traffic on port 80 and 443 before it can leave the machine:
iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 12345
iptables -t nat -A OUTPUT -p tcp --dport 443 -j REDIRECT --to-ports 12345
redsocks is a small daemon that listens on that local port and forwards everything to your real proxy:
base {
daemon = on;
redirector = iptables;
}
redsocks {
local_ip = 0.0.0.0;
local_port = 12345;
ip = proxy.example.com;
port = 3128;
type = http-connect;
}
One important detail: local_ip = 0.0.0.0 matters if you're running Docker. Docker containers live on their own internal bridge network, and their traffic arrives on that bridge interface, not on loopback. If redsocks only listens on 127.0.0.1, your containers can't reach it. Set it to 0.0.0.0 and everything works.
Putting It All Together: A Real Scenario
You have a server in a private data centre. No direct internet access. All outbound traffic must go through proxy.company.com:3128. You're running a Node.js app that calls a third-party API.
Without any setup:
Node.js app ──► api.thirdparty.com (connection timeout)
After setting env vars:
export HTTPS_PROXY=http://proxy.company.com:3128
curl https://api.thirdparty.com # works, curl respects env vars
node app.js # still fails, undici ignores env vars
After adding the transparent proxy:
sudo iptables -t nat -A OUTPUT -p tcp --dport 443 -j REDIRECT --to-ports 12345
node app.js # works, OS intercepts the traffic before it can fail
No code changes. No patching the library. The operating system just handles it.
The Quick Reference
| Concept | What it does |
|---|---|
| Forward proxy | Middleman for outbound requests from your network |
| Reverse proxy | Middleman for inbound requests to your servers |
| HTTP_PROXY env var | Tells apps to use a proxy, only works if the app supports it |
| Transparent proxy | OS-level interception, works for every app regardless |
| redsocks | Receives intercepted traffic and forwards it to the real proxy |
| iptables | Linux firewall, used to redirect traffic to redsocks |
| Squid | Popular proxy server software used in companies and universities |
| CONNECT tunnelling | How HTTP proxies handle HTTPS without reading the encrypted content |
The Takeaway
A proxy is just a middleman. Forward proxies protect clients going out; reverse proxies protect servers coming in. Most tools respect the standard environment variables, but some (looking at you, Node.js fetch) don't. When that happens, stop fighting the app and fix it at the OS level instead.
The receptionist analogy holds all the way down. Sometimes you change how you write your requests. Sometimes you just station security at the only door and let them handle everything.
Found this useful? Share it with the developer on your team who keeps asking why their curl works but their app doesn't.
Want to build something like this?
I'm available for web, AI, e-commerce, and automation projects. Let's discuss your idea — free 30-min consult.