How Reverse Proxy Works

If you expose a Node.js or Python application directly to the public internet on port 80/443, you are committing architectural malpractice. Application servers are inherently fragile. They block on single threads, they leak memory, and their built-in TLS decryption is often extremely slow. A Reverse Proxy (like NGINX or HAProxy) sits in front of your application as an indestructible, hyper-optimized bodyguard.

---

Part 1: The Mathematics of SSL Termination

Decrypting HTTPS traffic is a mathematically brutal operation. Establishing a TLS 1.3 connection requires asymmetric Elliptic Curve cryptography (to negotiate a shared secret), followed by continuous symmetric AES-GCM decryption for the entire ensuing conversation.

If you force your Application Server (e.g., a Python Django process) to handle this math, you burn CPU cycles that should have been spent querying your database or rendering HTML.

SSL Termination moves this burden to the Reverse Proxy. NGINX is written in C and hooks directly into the hyper-optimized OpenSSL C library. It decrypts traffic in microseconds and forwards purely unencrypted plaintext HTTP traffic over a secure internal VPC network to your Python application. Your Application Server no longer needs to possess or even know about the SSL Certificates.

Part 2: The Caching Edge

The fastest HTTP request in the world is the one that never reaches your application.

If 100,000 users ask for the homepage of your blog in the same hour, a raw application server will painfully re-render the HTML template from the database 100,000 times. A Reverse Proxy entirely eliminates this.

When request #1 hits NGINX, it forwards it to your application, but keeps a copy of the finalized HTML in its own RAM or SSD. When requests #2 through #100,000 arrive, NGINX instantly responds with standard HTTP 200 OK headers directly from cache. Your application server effectively registers zero traffic for those requests.

Part 3: Path-Based Routing (Microservices)

In a modern infrastructure, yourwebsite.com is not a single monolith. It is composed of dozens of specialized services. The Reverse Proxy acts as the master Traffic Cop, seamlessly routing requests based on the URL.

• Requests to /api/* are forwarded to a cluster of Go microservices.
• Requests to /blog/* are forwarded to an internal WordPress container.
• Requests to /static/* never hit a backend at all; NGINX serves the files directly from the disk using the kernel's perfectly optimized sendfile() syscall.

To the user, it feels like a unified, cohesive application.

Part 4: Connection Draining & Slowloris Protection

Malicious users often launch Slowloris attacks, where they open a connection but send data agonizingly slowly (one byte every 10 seconds). In a single-threaded server like Node.js or a thread-per-connection server like Apache, enough slow clients will completely exhaust the connection pool, taking the application totally offline.

Reverse proxies like NGINX and HAProxy are intrinsically immune to this. They use an asynchronous, non-blocking epoll event loop. They can sustain hundreds of thousands of concurrent, hanging connections. NGINX acts as a buffer: it waits patiently until the extremely slow client finishes sending the entire HTTP request before it forwards a perfectly clean, fast request to your fragile backend application.