Expose Local Server on VPS Preserving Real Client IPs (OS Level)

To expose a local server on a VPS while preserving real client IPs, configure your reverse proxy (such as Nginx or Apache) to forward the original client address via HTTP headers like X-Forwarded-For and X-Real-IP. You must then instruct your backend application to trust these headers and parse the first IP in the chain, ensuring that the OS-level logging reflects the true visitor rather than the VPS gateway.

Understanding the Proxy Chain

When you place a reverse proxy in front of your local server, the direct connection between the internet user and your application is broken. The proxy acts as an intermediary, accepting the incoming request from the client and forwarding it to your local service. By default, most web servers log the IP address of the immediate connection source. In this architecture, that source is your VPS, not the actual user. Consequently, your logs will show thousands of requests all originating from a single IP address, which destroys the utility of access logs for security auditing, rate limiting, and analytics. The solution lies in standard HTTP headers designed specifically for this purpose. When a proxy forwards a request, it can append the original client's IP to the X-Forwarded-For header. This header contains a comma-separated list of IPs: the original client, followed by each proxy the request passed through. Additionally, many proxies set the X-Real-IP header, which contains only the single IP address of the immediate previous hop. Your backend application needs to be configured to read these headers instead of relying solely on the socket connection details provided by the operating system.

Configuring Nginx as a Reverse Proxy

Nginx is one of the most common tools for this setup due to its performance and flexibility. To ensure Nginx passes the correct information to your backend, you need to modify the server block configuration for your domain. Inside the location block where you proxy the traffic, you must add specific directives to set the forwarded headers.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        
        # Pass the real client IP
        proxy_set_header X-Real-IP $remote_addr;
        
        # Pass the full chain of IPs
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # Preserve the original Host header
        proxy_set_header Host $host;
    }
}

The directive proxy_set_header X-Real-IP $remote_addr tells Nginx to take the IP address of the person connecting directly to the VPS and place it into a new header named X-Real-IP. The proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for command is more robust because it appends the current client IP to any existing X-Forwarded-For header. If there was no previous header, it creates one with just the current IP. This ensures that if your request passes through multiple layers of proxies, the complete history is preserved. After making these changes, reload Nginx using sudo systemctl reload nginx to apply the new configuration without dropping active connections.

Configuring Apache as a Reverse Proxy

If you are using Apache, the process is similar but utilizes different modules. You will need the mod_proxy, mod_proxy_http, and mod_headers modules enabled. These modules allow Apache to act as a gateway and manipulate HTTP headers before sending them to the backend.

<VirtualHost *:80>
    ServerName example.com
    
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/
    
    RequestHeader set X-Real-IP "%{REMOTE_ADDR}s"
    RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}s"
</VirtualHost>

In Apache, ProxyPreserveHost On ensures that the Host header sent by the client is passed through unchanged, which is critical for virtual hosting. The RequestHeader directives manually inject the X-Real-IP and X-Forwarded-For headers. Note that unlike Nginx, Apache does not automatically append to X-Forwarded-For in older versions; you may need to use mod_remoteip for more advanced handling if you are behind multiple proxies. For simple setups, setting these headers explicitly is sufficient. Restart Apache with sudo systemctl restart apache2 after editing the configuration file.

Configuring the Backend Application

Setting up the proxy is only half the battle. Your backend application, whether it is written in Python, Node.js, PHP, or Java, must be configured to trust these headers. Most modern frameworks have built-in support for this, but it often requires explicit enabling for security reasons. For example, in Django (Python), you must add 'django.middleware.common.CommonMiddleware' to your middleware and set SECURE_PROXY_SSL_HEADER if you are also handling SSL termination. More importantly, you should ensure that your WSGI server (like Gunicorn or uWSGI) is configured to respect the HTTP_X_FORWARDED_FOR environment variable. In Node.js applications using Express, you typically need to set app.set('trust proxy', true) or specify the trust function to indicate that the application should trust the headers coming from the reverse proxy. Without this step, the application will ignore the headers and continue to log the VPS IP address.

Verifying the Configuration

To verify that your setup is working correctly, make a request to your site and check the access logs of your backend application. You should see the public IP address of your browser, not the private IP of your VPS. You can also use command-line tools like curl to inspect the headers being received by your backend. Run curl -I http://localhost:8080 (if testing locally) or check the raw request logs to confirm that X-Real-IP and X-Forwarded-For contain the expected values.

Frequently Asked Questions

Why do I still see the VPS IP in my logs?

This usually means your backend application is not configured to trust the proxy headers. Ensure that your framework has "trust proxy" enabled and that it is reading the X-Forwarded-For or X-Real-IP headers instead of the socket remote address.

Is it safe to trust X-Forwarded-For headers?

You should only trust these headers if they come from a proxy you control, such as your own Nginx or Apache instance. If users can send arbitrary headers directly to your backend, they could spoof their IP. Always ensure your reverse proxy strips or overrides these headers before passing them to the backend.

How does this affect SSL/TLS certificates?

Preserving client IPs is separate from SSL termination. If your reverse proxy handles SSL, it decrypts the traffic and forwards plain HTTP to your backend. This does not change how client IPs are logged, provided the proxy headers are correctly forwarded as described above.

Can I use this method with cloud providers like AWS or DigitalOcean?

Yes, but cloud providers often have their own load balancers or firewalls that may insert additional headers. You may need to configure your application to trust the specific IP ranges of the cloud provider's infrastructure to accurately identify the original client IP.

What if I am behind multiple proxies?

The X-Forwarded-For header supports chains by appending IPs. The last IP in the list is the original client, while earlier IPs are intermediate proxies. Your application should parse the rightmost IP in the comma-separated list to get the true client address.