proxy – the basics

/ SprUng, KEEPERS, CODE-NOW-NOW-NOW, CODING / 4 minutes of reading

To set up a proxy that routes requests for spiffberrypi.space to 192.168.1.50 on port 8123, here’s the process:

NGINX Proxy Setup

Your NGINX server is acting as the reverse proxy, so you can configure NGINX to route traffic from spiffberrypi.space to 192.168.1.50:8123. Here’s how to configure the NGINX proxy:

server {
    listen 80;
    server_name spiffberrypi.space;

    return 301 https://$host$request_uri;  # Redirect all HTTP to HTTPS
}

server {
    listen 443 ssl;
    server_name spiffberrypi.space;

    ssl_certificate /etc/letsencrypt/live/brains.spiffynasty.com/fullchain.pem;  # Path to SSL cert
    ssl_certificate_key /etc/letsencrypt/live/brains.spiffynasty.com/privkey.pem;  # Path to SSL key
    include /etc/letsencrypt/options-ssl-nginx.conf;  # SSL options
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;  # SSL DH param

    location / {
        proxy_pass http://192.168.1.50:8123;  # Forward to internal IP and port
        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;
    }
}

Router Port Forwarding

On your router, you will need to forward port 443 (HTTPS) to your proxy server's IP (let’s say 192.168.1.17). Here’s what needs to happen:

  1. Port Forwarding on Router:

    • Forward port 443 (HTTPS) to the proxy server (e.g., 192.168.1.17).
    • You don’t need to worry about port 8123 on the router since it’s only being used for internal routing by the proxy.

  2. Proxy Pass in NGINX: NGINX will take care of forwarding the traffic to 192.168.1.50:8123 internally using the proxy_pass directive in the configuration above.

Summary of How it Works:

  1. External Request: A user makes a request to https://spiffberrypi.space.
  2. Router: The router forwards the request on port 443 to the proxy server (192.168.1.17).
  3. NGINX: The NGINX proxy server forwards the request to 192.168.1.50:8123.
  4. Internal Service: The service running on 192.168.1.50:8123 handles the request and sends a response back through the NGINX proxy.

This way, you don't need to open or forward port 8123 on the router, and the proxy server will manage routing between external requests and the internal service.

Generally, reverse proxies in NGINX (and web server configurations in general) are set up using separate configuration files placed in the /etc/nginx/sites-available/ directory, with symbolic links created in /etc/nginx/sites-enabled/. This is considered best practice because it allows you to manage individual configurations for each site or proxy more easily. Here’s how it's typically done:

  1. Configuration Files in /sites-available/:

    • Each site, service, or reverse proxy configuration has its own .conf file in /etc/nginx/sites-available/.
    • Example: You might have a nas_proxy.conf or my_website.conf file here.
    • These files are not actively used by NGINX until they are "enabled" by linking them into the /etc/nginx/sites-enabled/ directory.

  2. Symbolic Links in /sites-enabled/:

    • Only the configurations that you want NGINX to use are symlinked into /etc/nginx/sites-enabled/.

    • Example: After creating 

      /etc/nginx/sites-available/nas_proxy.conf

      , you would create a symbolic link:

      sudo ln -s /etc/nginx/sites-available/nas_proxy.conf /etc/nginx/sites-enabled/

  3. Default File (/etc/nginx/sites-available/default):

    • This is typically a catch-all or placeholder configuration created when NGINX is installed. It’s usually used for simple default setups or for catching requests that don’t match any specific configuration.
    • Many users prefer to leave the default file alone and create separate .conf files for each reverse proxy or site, especially in more complex environments.

Example Setup for a Reverse Proxy

Let’s say you want to create a reverse proxy for spiffberrypi.space:

  1. Create a new configuration file in /etc/nginx/sites-available/:

    sudo nano /etc/nginx/sites-available/spiffberrypi.conf

    Add your reverse proxy configuration:

    server {
    listen 80;
    server_name spiffberrypi.space;
    return 301 https://$host$request_uri;  # Redirect all HTTP to HTTPS
}

server {
    listen 443 ssl;
    server_name spiffberrypi.space;

    ssl_certificate /etc/letsencrypt/live/spiffberrypi.space/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/spiffberrypi.space/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://192.168.1.50:8123;
        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;
    }
}

  2. Enable the site by creating a symbolic link in /etc/nginx/sites-enabled/:

    sudo ln -s /etc/nginx/sites-available/spiffberrypi.conf /etc/nginx/sites-enabled/

  3. Test your NGINX configuration to ensure everything is correct:

    sudo nginx -t

  4. Reload NGINX to apply the changes:

    
sudo systemctl reload nginx

Why Use Separate .conf Files?

  • Organization: Each site or reverse proxy configuration is stored in a separate file, making it easier to manage.
  • Enable/Disable Sites Easily: You can quickly enable or disable configurations by adding/removing symbolic links from /sites-enabled/.
  • Avoid Confusion: Keeping everything in the default configuration can lead to a cluttered and confusing setup, especially as you add more sites or services.

In contrast, using the default file might be okay for very simple setups or testing, but it’s not ideal for production environments or complex configurations. It’s better to keep default as a fallback or remove it entirely if not needed.

Scroll to Top