Setting up Reverse Proxy across Multiple Devices on Local Network

Configure a reverse proxy on a central device, such as a Raspberry Pi running Nginx or Apache, to route local traffic from specific subdomains to various backend services across your network. This approach eliminates the need for complex port forwarding rules on your router and provides a unified, secure entry point for accessing multiple home server applications like Home Assistant, FreshRSS, or media servers from any device on the LAN.

Architecture Overview

Before diving into configuration files, it is essential to understand the logical flow of requests in a multi-device local network. In this setup, you designate one machine as the "gateway" or proxy server. This machine listens on standard HTTP (port 80) and HTTPS (port 443) ports. When a client on your local network requests a URL, the proxy server examines the hostname requested and forwards the connection to the appropriate internal IP address and port where the actual service resides. This architecture offers several advantages over direct access. First, it simplifies client-side configuration; users only need to remember one domain name rather than remembering different IP addresses and ports for each service. Second, it enhances security by keeping backend services hidden behind the proxy, preventing direct exposure of their default ports. Finally, it allows for centralized management of SSL/TLS certificates, ensuring all services use valid encryption without requiring individual certificate management on every device. To implement this effectively, ensure that all devices involved are on the same subnet or that routing between them is properly configured. If you are using virtual machines or containers, verify that they can communicate with the host network interface. For those interested in securing specific storage components within this environment, reviewing Improving NFS Server Security on Local Networks can provide additional insights into protecting data integrity alongside network access.

Selecting Your Proxy Software

The two most popular choices for local reverse proxies are Nginx and Apache. Nginx is generally preferred for its low memory footprint and high performance, making it ideal for resource-constrained devices like a Raspberry Pi. Apache is also robust and often easier to configure for beginners due to its modular structure and extensive documentation. For this guide, we will focus on Nginx due to its efficiency. Ensure that Nginx is installed on your chosen gateway device. On Debian-based systems, this can be achieved with sudo apt update && sudo apt install nginx. Once installed, verify the service is running and accessible via http://localhost. If you are setting up a similar environment for virtualization hosts, checking out Setting Up Nginx Reverse Proxy for Home Assistant OS on KVM may offer useful parallels for containerized deployments.

DNS Resolution for Local Services

A critical component of this setup is resolving custom domain names locally. You cannot rely on public DNS servers to resolve names like homeassistant.local or plex.myhome.net unless you have purchased those domains and configured external DNS records. Instead, you must configure your local router's DHCP settings or use a local DNS server like Pi-hole or AdGuard Home to map these hostnames to the IP address of your proxy server. Alternatively, you can modify the /etc/hosts file on each client device, but this is not scalable. The recommended approach is to set up a local DNS zone. For example, if your proxy server is at 192.168.1.10, you should configure your DNS server to return this IP for any request matching *.yourdomain.com. This ensures that when a user types app.yourdomain.com, their browser sends the request to 192.168.1.10, which then acts as the reverse proxy.

Configuring Nginx Reverse Proxy Rules

Nginx configuration files are typically located in /etc/nginx/sites-available/. Create a new server block for each service you wish to expose. A basic configuration looks like this:

server {
    listen 80;
    server_name app.yourdomain.com;

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

In this example, requests to app.yourdomain.com are forwarded to 192.168.1.20 on port 8123, which might be a Home Assistant instance. The proxy_set_header directives are crucial because many web applications rely on the Host header to generate correct URLs and handle authentication. Without these headers, the backend application might fail to redirect correctly or break WebSocket connections required for real-time updates. After creating the configuration file, enable it by creating a symbolic link to /etc/nginx/sites-enabled/ and test the configuration syntax with sudo nginx -t. If the test passes, reload Nginx with sudo systemctl reload nginx.

Implementing SSL/TLS Encryption

While HTTP works for local networks, HTTPS is strongly recommended to prevent eavesdropping and credential theft. You can obtain free SSL certificates using Let's Encrypt with Certbot. Run sudo certbot --nginx -d app.yourdomain.com to automatically generate and install certificates. Certbot will modify your Nginx configuration to listen on port 443 and redirect HTTP traffic to HTTPS. If you are using self-signed certificates for internal-only use, you can generate them manually and point Nginx to the key and certificate files. However, browsers will display security warnings for self-signed certs, which can be annoying for end-users. For a seamless experience, consider using a local Certificate Authority or tools like mkcert that create trusted local certificates. Troubleshooting connectivity issues after enabling SSL can be tricky. If you encounter sudden unreachability, refer to Troubleshooting Home Server: Suddenly Unreachable Over Internet for diagnostic steps that apply to both local and remote access failures.

Handling WebSockets and Long-Polling

Many modern web applications, including dashboards and chat interfaces, use WebSockets for real-time communication. Standard HTTP proxies may drop these connections if not configured correctly. To support WebSockets, add the following lines to your Nginx location block:

location /ws/ {
    proxy_pass http://backend-service:port;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

This tells Nginx to upgrade the connection protocol when the client requests it. Similarly, if your application uses long-polling, ensure that the proxy_read_timeout is set sufficiently high to prevent premature disconnection. Failure to configure these headers correctly can result in features like live status updates failing silently, which is a common issue reported in forums regarding services like FreshRSS. For more details on such networking quirks, see Strange Networking Issues with FreshRSS behind Nginx Reverse Proxy on Garnet.

Frequently Asked Questions

Can I use a single Nginx instance for multiple subdomains?

Yes, you can define multiple server blocks within the same Nginx configuration, each listening for a different server_name. This allows you to route app.domain.com to one backend and media.domain.com to another, all managed by a single process.

What happens if my proxy server goes down?

If the central proxy server fails, all services behind it become inaccessible via their domain names. Clients will receive a connection refused error. It is advisable to monitor the proxy service and consider clustering solutions if high availability is critical for your local network operations.

Do I need to forward ports on my router for local access?

No, if you are accessing the services only from within your local network, you do not need to forward ports on your router. The traffic stays internal. Port forwarding is only necessary if you intend to access these services from outside your home network via the internet.

How do I handle conflicting ports between services?

Since the reverse proxy handles all incoming traffic on ports 80 and 443, your backend services can run on any available internal port. This resolves conflicts where multiple applications might want to use port 80, as they never directly listen on that port externally.

Is it safe to expose my local network services via HTTPS?

Exposing services via HTTPS within your local network is safe and recommended. It encrypts traffic between the client and the proxy, preventing local network sniffing. Ensure that your backend services also validate the origin of requests to prevent unauthorized access from compromised clients.