Configure Nginx Reverse Proxy

The Problem

You've got an application running on an internal port (Node.js, a Python app, Docker container) but need it reachable on standard web ports with a proper domain, SSL and without exposing the raw application port directly to the internet.

About this problem

Running an application server directly exposed on the internet, listening on its own custom port, misses out on the things a proper web server in front provides — SSL termination, request buffering, static file handling, and a layer that can hide internal architecture details from visitors entirely.

This comes up whenever deploying a Node.js, Python, or containerised application that needs to sit behind a standard domain on ports 80/443 rather than a raw custom port.

What's Included

• Configuring Nginx to proxy requests to your internal application port
• Setting correct proxy headers so your application sees the real client IP and protocol
• Configuring timeouts and buffering appropriate to your application's behaviour
• Testing the full path from public domain through to the backend application

What's NOT Included

• Setting up or debugging the backend application itself
• SSL certificate setup (see the Let's Encrypt service, commonly paired with this)
• Load balancing across multiple backend instances (can be scoped as an extension of this service)

How It Works

1. Create a server block with a location block using proxy_pass pointing at the internal application address and port.
2. Set proxy_set_header directives for Host, X-Real-IP and X-Forwarded-For/Proto so the backend sees accurate request details.
3. Adjust proxy timeout and buffer settings to match the backend's actual response behaviour, especially for long-running requests.
4. Confirm WebSocket support is configured correctly if the application needs it (Upgrade/Connection headers).
5. Test the full request path from the public domain through to the application, confirming headers arrive as expected.

In practice: you buy the service, send over whatever access or details the job needs, I investigate and do the work, and you confirm it's resolved before we call it done.

Frequently Asked Questions

What does a reverse proxy actually do?

It sits between visitors and your application, forwarding requests to the right internal service while handling things like SSL, standard ports, and request headers on the application's behalf.

Why can't I just expose my application's port directly?

You can, but you lose SSL termination at a standard layer, expose your application's internal technology choice directly, and miss out on Nginx's buffering and static file handling.

Why does my application see the wrong visitor IP address?

Without the X-Forwarded-For and X-Real-IP headers set correctly in the proxy configuration, the application sees Nginx's own internal connection, not the actual visitor's IP.

Can a reverse proxy handle WebSocket connections?

Yes, but it needs explicit Upgrade and Connection header configuration in the location block — without it, WebSocket connections fail even though normal HTTP requests work fine.

Do I need a reverse proxy for a simple static website?

No, a reverse proxy is specifically useful when there's a backend application process to forward requests to — a static site can be served directly by Nginx without proxying.

Can Nginx reverse-proxy to multiple backend applications?

Yes, using different location blocks or server blocks per domain/path, each pointing at its own backend service.