Configuring NGINX Reverse Proxy

Introduction

Welcome back to "Getting Started with NGINX Web Server"! You're making great progress on your NGINX journey. In the previous lesson, we set up a basic web server that serves static files. Now, in this second lesson, we'll expand NGINX's capabilities by configuring it as a reverse proxy . A reverse proxy is one of NGINX's most powerful features, allowing you to route requests to backend applications seamlessly. By the end of this lesson, you'll configure NGINX to forward API requests to a Flask backend while continuing to serve static files. This pattern is fundamental to modern web architecture, where frontend and backend services work together through a unified entry point. We'll explore the proxy_pass directive, learn about essential proxy headers, and see how NGINX acts as an intermediary between clients and your application server.

What is a Reverse Proxy?

Before we dive into configuration, let's understand what a reverse proxy actually does. A reverse proxy sits between clients and backend servers, forwarding client requests to the appropriate backend and returning the backend's response to the client. Think of it like a receptionist at a large office building. When visitors arrive, they don't go directly to individual offices. Instead, they speak to the receptionist, who directs them to the right department or person. The visitors don't need to know the internal layout or where each person sits; the receptionist handles all the routing. In web terms, clients make requests to NGINX (the receptionist), and NGINX forwards those requests to backend applications like Flask, Node.js, or Java servers. The client only sees NGINX; they don't need to know about the backend infrastructure.

Why Use NGINX as a Reverse Proxy?

NGINX as a reverse proxy offers several important advantages for modern web applications: Unified entry point : Clients connect to a single server on a standard port, while backends can run on any port. Security : Backend servers aren't directly exposed to the internet; NGINX acts as a protective layer. Load distribution : NGINX can distribute requests across multiple backend servers (we'll explore this in later courses). SSL termination : NGINX can handle HTTPS encryption, letting backends focus on application logic. Static file optimization : NGINX excels at serving static files, freeing up application servers for dynamic content. This architecture separates concerns cleanly, with NGINX handling web traffic efficiently while your application focuses on business logic.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Adding Essential Proxy Headers

When NGINX forwards requests, we need to pass along information about the original client. We do this using proxy_set_header directives:

nginx

            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;

            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;

Each directive sets an HTTP header that the backend server will receive. These headers preserve important information that would otherwise be lost when NGINX acts as an intermediary. Let's examine each one:

Host: The Host header tells the backend server which domain name the client requested. The $host variable contains the hostname from the request line or the Host header from the client. This is crucial when a single backend serves multiple domains or when the backend needs to generate URLs that match the original request.
X-Real-IP: This header preserves the client's IP address. Without it, the backend would only see NGINX's IP address (127.0.0.1) as the client. The $remote_addr variable contains the actual client's IP address. Backends use this for logging, security decisions, or geolocation features.
X-Forwarded-For: This header tracks the request's journey through proxies. The special variable $proxy_add_x_forwarded_for appends the client's IP to any existing X-Forwarded-For chain. If the request passes through multiple proxies, this header maintains the complete path, which is valuable for security auditing and troubleshooting.
X-Forwarded-Proto: This header indicates the original protocol. The $scheme variable contains either http or https, indicating how the client connected to NGINX. Even if NGINX communicates with the backend over plain HTTP, the backend knows whether the original client connection was secure. This helps backends generate correct redirect URLs and make security decisions.

Introduction

What is a Reverse Proxy?

Why Use NGINX as a Reverse Proxy?

Join the 1M+ learners on CodeSignal

The Basic Structure Revisited

Introducing the API Location Block

Understanding proxy_pass

Adding Essential Proxy Headers

Completing the Server Configuration

Creating a Simple Flask Backend

Starting Both Servers

Testing Direct Backend Access

Testing Through the Reverse Proxy

Verifying Proxy Headers

Conclusion and Next Steps