When you don't want to go yourself, the proxy goes for you. Hide your identity with Forward Proxy, protect your server with Reverse Proxy. Same middleman, different loyalties.
Why does my server crash? OS's desperate struggle to manage limited memory. War against Fragmentation.
Two ways to escape a maze. Spread out wide (BFS) or dig deep (DFS)? Who finds the shortest path?
A comprehensive deep dive into client-side storage. From Cookies to IndexedDB and the Cache API. We explore security best practices for JWT storage (XSS vs CSRF), performance implications of synchronous APIs, and how to build offline-first applications using Service Workers.
Fast by name. Partitioning around a Pivot. Why is it the standard library choice despite O(N²) worst case?
When I first developed on a company network, external API calls wouldn't work. Just "Connection timed out" errors everywhere. A senior developer asked me, "Did you set up the proxy?" I added the company's http_proxy environment variable, and suddenly everything worked.
Back then, I only understood "I need to use this magical thing to connect outside." I truly grasped what proxies were much later when I started using Nginx for my own service.
Honestly, when I first started my startup, I didn't care about proxies at all. I had one server running on my laptop—why would I need a proxy? But as users grew, I had to scale to multiple servers, implement HTTPS, attach a CDN, and that's when I encountered Reverse Proxy. And it clicked: "Oh, this is all just proxies."
"Forward Proxy" and "Reverse Proxy" threw me off completely. Forward means "forward"? Then Reverse means "backward"? Both relay requests in the middle, so what's the actual difference?
And I kept confusing it with VPNs. VPNs also hide my IP, so aren't they the same thing? Even more confusing: the client's IT team told me "Turn on VPN AND set up the proxy." Wait, so VPN and proxy are different? Do I use them together?
Then there was Transparent Proxy. My ISP inserts a proxy at the network level, but I never configured anything—how does that even work? None of it made sense.
I couldn't grasp the core concept. I just had this vague idea: "proxy = something in the middle."
Then I heard this analogy and everything clicked:
"A proxy is an agent. Like sending a personal shopper to a luxury store when you're too shy to go yourself.
- Forward Proxy: Your (client's) agent. Hides who you are and buys stuff for you.
- Reverse Proxy: The store's (server's) agent. Greets customers at the entrance because the store is busy."
The key: who are you working for? This analogy hit home for me. They both relay requests in the middle, but they represent different parties.
Let me extend the luxury store analogy. If I go to the store myself, the salesperson sees my face and knows exactly what I bought. But if I send a personal shopper? The salesperson only sees the shopper's face and has no idea who the real buyer is. That's Forward Proxy.
On the flip side, the store has too many customers. They let VIPs into the inner sanctum, but regular customers get served at the entrance. Customers have no idea what the stockroom looks like or where the warehouse is. That's Reverse Proxy.
Once I accepted this mental model, everything about proxies made sense.
Forward Proxy sits before the client (me).
Me → Forward Proxy → Internet → Target Website
When I try to access a website, the Forward Proxy goes there and fetches the page for me. The website only sees the proxy's IP. My real IP is hidden.
Hide my IP when using public WiFi at cafes. The proxy server acts as a shield—websites only see the proxy's IP. Tor Browser works exactly like this, routing through multiple proxies so no one can trace my IP.
Company blocks YouTube? Route through a Forward Proxy to bypass. (Obviously don't violate company policy.) Traveling abroad and need a Korean IP? Use a Korean proxy server. Netflix region restrictions? Same trick.
If the whole company uses the same proxy, frequently visited sites are cached. 100 people visit the same homepage? Proxy fetches it once and shares it. Saves bandwidth and speeds things up.
I thought all proxies were the same, but turns out there are different types.
HTTP Proxy only handles HTTP/HTTPS traffic. It's for web browsing. When you set http_proxy environment variable, that's an HTTP proxy.
SOCKS Proxy operates at a lower level. It can proxy HTTP, FTP, SMTP, even game traffic. I use it a lot for SSH tunneling.
# SSH SOCKS Proxy setup (what I actually use)
ssh -D 1080 user@remote-server
# Now localhost:1080 becomes a SOCKS5 proxy
Point your browser or app to localhost:1080 and all traffic routes through the SSH server. Super useful for bypassing corporate firewalls. (For legitimate purposes only, of course.)
What I experienced at work:
# Set environment variables
export http_proxy=http://proxy.company.com:8080
export https_proxy=http://proxy.company.com:8080
# Now curl and npm go through the proxy
curl https://api.github.com
Company firewall blocks direct external access, but allows proxy connections. Proxies can log and filter everything.
The problem? Not all programs respect environment variables. Git needs separate configuration:
git config --global http.proxy http://proxy.company.com:8080
git config --global https.proxy http://proxy.company.com:8080
Python pip too:
pip install --proxy http://proxy.company.com:8080 requests
Got tired of typing this every time, so I just dumped it all in my .bashrc.
Your ISP can insert a proxy in the middle even if you didn't configure one. That's a Transparent Proxy.
ISPs use this to monitor traffic, block certain sites, or cache content to save bandwidth. Users don't even know the proxy exists—hence "transparent."
I once couldn't access a website in Korea, but turning on a VPN fixed it. Turned out my ISP was using a Transparent Proxy to filter that site. VPN encrypted everything, so the ISP couldn't see where I was going, and I bypassed the block.
This shattered my assumption that "proxies are something I configure." Proxies can be inserted anywhere in the network path.
Reverse Proxy sits before the server.
Me → Internet → Reverse Proxy → Real Servers
When I access a website, I'm actually hitting the Reverse Proxy. The Reverse Proxy receives my request and forwards it to the real servers (possibly multiple).
I have no idea where the real servers are or how many exist.You have 10 servers, but users only see "example.com." The Reverse Proxy (Nginx) distributes requests across those 10 servers.
upstream backend {
server 192.168.1.10;
server 192.168.1.11;
server 192.168.1.12;
}
server {
location / {
proxy_pass http://backend;
}
}
Without this, users would have to connect directly to "192.168.1.10" or DNS would round-robin IPs. If one server dies, users get errors. Reverse Proxy does health checks and only routes to live servers.
HTTPS encryption/decryption is expensive. Instead of 10 servers each handling HTTPS, the Reverse Proxy does it once, then uses plain HTTP internally.
User ← HTTPS → Reverse Proxy ← HTTP → Real Servers
SSL certificates only need to be installed on the Reverse Proxy. Managing and renewing certificates on 10 servers separately? Total nightmare.
Hides real server IPs. Attackers only see the Reverse Proxy. DDoS attacks can be mitigated at the Reverse Proxy layer. Cloudflare and other CDNs are essentially massive Reverse Proxy networks.
Static files (images, CSS) are cached by the Reverse Proxy for instant responses. No need to hit the real servers. Nginx is excellent at this—serve static files from Nginx, send dynamic requests to the backend.
Cloudflare, AWS CloudFront, and other CDNs are basically Reverse Proxies. My server is in Korea, but US users hit a US CDN server (Reverse Proxy). The CDN fetches content from my server, caches it, and serves it fast.
CDNs are just "agents for the server." Once I understood this, setting up CDNs felt like "oh, this is just Reverse Proxy configuration."
I use Nginx as a Reverse Proxy in my service:
server {
listen 80;
server_name myapp.com;
# Nginx serves static files directly
location /static/ {
alias /var/www/static/;
}
# API requests forwarded to backend
location /api/ {
proxy_pass http://localhost:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Users only access myapp.com, but /static/ requests are handled by Nginx, and /api/ requests go to the Node.js server (port 3000).
One domain can bundle multiple services. Frontend at /, API at /api/, admin panel at /admin/—route each to different servers.
I pass X-Real-IP and X-Forwarded-For headers because the backend sees all requests coming from Nginx (localhost). To get the real user's IP, you need these headers.
When I first learned about MSA (Microservices Architecture), I encountered API Gateway. "Routes user requests to the appropriate microservice," they said. But it's just a Reverse Proxy.
Say my service has separate auth, payment, and product servers:
User → API Gateway → /auth → Auth Server
→ /payment → Payment Server
→ /product → Product Server
API Gateway looks at the path and routes to the right server. That's exactly what Reverse Proxy routing does.
When studying Kong, AWS API Gateway, Spring Cloud Gateway, I wondered "how is this different from Nginx?" Turns out the core is the same. API Gateway is a Reverse Proxy with added features like authentication, rate limiting, and logging.
| Item | Forward Proxy | Reverse Proxy |
|---|---|---|
| Location | Before Client | Before Server |
| Protects | Client | Server |
| Who Sets Up | Client configures | Server admin configures |
| Hides IP | Client IP | Server IP |
| Main Use | Bypass, Anonymity, Cache | Load Balancing, SSL, Security |
| Examples | Company Proxy, VPN | Nginx, Cloudflare |
After making this table, I never got confused again. Look at "Who Sets Up"—if you configure it, it's Forward; if the server admin does, it's Reverse.
Both "hide my IP," but they work differently:
VPN covers game traffic, email, even DNS queries—everything goes through the VPN server. Forward Proxy only works with apps that support proxies, like web browsers and curl.
VPN is more powerful but can be slower. Forward Proxy is lighter but only covers HTTP. I use VPN when traveling abroad, Forward Proxy when developing on corporate networks.
At work, npm install failed inside Docker containers. Turns out Docker doesn't auto-inherit host environment variables.
# Had to specify in Dockerfile
ENV http_proxy=http://proxy.company.com:8080
ENV https_proxy=http://proxy.company.com:8080
I wasted a full day on this. npm install worked fine on the host but failed inside Docker. Eventually found the answer buried in Docker docs.
Got 502 errors from Nginx as Reverse Proxy. Backend was running on 127.0.0.1:3000, not localhost:3000.
In Docker networks, localhost points to the container itself, not the host. Had to use host.docker.internal:3000.
# This fails in Docker
proxy_pass http://localhost:3000;
# This works
proxy_pass http://host.docker.internal:3000;
I spent hours debugging this. Nginx logs just said "Connection refused," but the backend was clearly running. Took forever to figure out the issue.
I needed to go through the office proxy, then through another external proxy. This is called Proxy Chaining.
My PC → Company Proxy → External Proxy → Internet
Problem: most proxies don't support chaining. I tried putting the external proxy in the company proxy settings—didn't work. Ended up using SSH tunneling as a workaround.
# SSH through company proxy to external server
ssh -o "ProxyCommand nc -X connect -x proxy.company.com:8080 %h %p" user@external-server
# Then set up SOCKS proxy
ssh -D 1080 -o "ProxyCommand nc -X connect -x proxy.company.com:8080 %h %p" user@external-server
Now localhost:1080 becomes a SOCKS proxy routing through the external server. Convoluted, but it worked.
Some proxies require authentication. The office proxy did.
# Proxy with username/password
export http_proxy=http://username:password@proxy.company.com:8080
Problem: special characters in passwords need URL encoding. If my password is P@ssw0rd!, I have to change it to P%40ssw0rd%21. Took me ages to figure this out.
Besides Nginx, HAProxy is widely used, especially for its robust load balancing and health checks.
frontend http_front
bind *:80
default_backend http_back
backend http_back
balance roundrobin
option httpchk GET /health
server server1 192.168.1.10:3000 check
server server2 192.168.1.11:3000 check
server server3 192.168.1.12:3000 check
option httpchk periodically checks the /health endpoint and automatically removes unresponsive servers. Nginx Plus can do this, but the free version can't. HAProxy can, and it's free.
Some organizations implement mTLS (Mutual TLS) through Reverse Proxy. Both client and server verify each other's certificates. Common in finance.
server {
listen 443 ssl;
ssl_certificate /path/to/server.crt;
ssl_certificate_key /path/to/server.key;
# Require client certificate
ssl_client_certificate /path/to/ca.crt;
ssl_verify_client on;
location / {
proxy_pass http://backend;
}
}
Only clients with valid certificates can connect. Useful for protecting internal APIs or admin panels.
What I learned from understanding proxies:
Initially I only knew "must set proxy to work." Now I run Nginx as a Reverse Proxy and truly appreciate its value. Bundling multiple servers under one domain, managing HTTPS in one place, caching static files for fast delivery—all thanks to Reverse Proxy.
In the end, I accepted this truth: proxies are "agents," and whether they're Forward or Reverse depends on whose side they're on. Once I internalized this, I naturally consider proxies when designing network architecture.