Set Up a Reverse Proxy on Your NAS for Web Apps

Self-hosting web apps from a NAS has quietly become one of the most popular weekend projects for Australian tech enthusiasts. Whether running Jellyfin for the household, Nextcloud for personal documents, or a small business intranet, the appeal of owning your data without paying monthly cloud fees is hard to ignore once you have the right gear humming away in the study.

A reverse proxy is the piece that ties everything together when you want those services reachable beyond your lounge room. It sits in front of your apps, accepts incoming requests on a single entry point, and forwards them to the correct container or package running on your NAS. Done well, it hides the messy backend, lets you run multiple services on standard ports, and makes securing traffic far more manageable.

Australian networks add a few wrinkles that make the reverse proxy approach particularly valuable. Residential NBN connections are notoriously asymmetric, with upload speeds often capped at a fraction of the download rate, which means every byte sent over an open port should be intentional. Some ISPs, including several of the larger ones, also block inbound traffic on ports 80 and 443 by default or assign customers to carrier-grade NAT pools, which complicates direct exposure of home services. A reverse proxy lets you centralise the workaround in one place rather than juggling exceptions for every app.

This walkthrough covers the practical steps for getting a reverse proxy running on a Synology or QNAP device, from domain registration and DDNS through to certificate installation and the everyday gotchas that catch first-timers out.

Understanding Reverse Proxies and Why NAS Owners Need Them

A reverse proxy receives requests from the public internet and routes them to one of several internal services based on the hostname, path, or other criteria. For a typical home setup, that means a request to jellyfin.yourname.example lands on your media server, while files.yourname.example reaches Nextcloud, even though both share the same public IP and port 443.

The alternative, opening a unique port for every service, becomes painful fast. Port numbers climb into obscure ranges, firewall rules multiply, and remembering which app lives on which port turns into guesswork. Worse, every open port is another surface area to defend. Centralising traffic through a proxy means only one entry point needs certificates, and logging, rate limiting, and access controls all happen in one place.

For Australians running self-hosted stacks, the proxy also provides a way to work around strict CGNAT deployments common on NBN plans from some providers. Combined with a tunnel such as Cloudflare Tunnel or a small VPS, the proxy can be the receiving end of an outbound-only connection, sidestepping inbound blocks entirely.

Preparing Your NAS and Network Environment

Before configuring anything, the underlying hardware and storage layout need to be solid. Reverse proxies are lightweight, but the apps they serve often are not, and the proxy will be the only thing standing between your data and the open internet. A reliable RAID arrangement protects the services and their data from drive failure, and reviewing best RAID configuration is a sensible first step before exposing anything externally.

On Synology, DSM ships with the Web Station package and a built-in reverse proxy under Control Panel. QNAP users can use the built-in nginx setup accessed through QTS or Container Station. Either way, the NAS should be on a fixed local IP, ideally reserved on the router through DHCP reservations so it never moves.

A quick checklist before going further: confirm your upload speed by running a few speed tests at different times of day, since NBN performance can swing noticeably between peak and off-peak hours. Decide on a host naming convention early, since renames later mean certificate reissues. And if your NAS lives in a garage or roof cavity in a city like Brisbane or Perth, remember that Australian summers push ambient temperatures high enough to shorten drive life, so airflow or a small fan is worth the investment.

Securing a Domain and Dynamic DNS Setup

A reverse proxy needs a stable hostname, and home internet connections usually get a fresh IP every few days. Dynamic DNS solves the first half by mapping a friendly hostname to whatever IP your ISP hands you, and most NAS vendors ship their own DDNS service free of charge. Synology's synology.me and QNAP's myqnapcloud.com both work out of the box, but for a more polished look, a personal domain from an Australian registrar or any major provider gives you full control.

Pointing the domain at the NAS involves creating an A record with a short TTL, then either enabling DDNS updates through the NAS or running a small client on the network that pings a service such as DuckDNS or Cloudflare whenever the IP changes. Cloudflare's free tier is popular with Australian self-hosters because it offers proxied DNS, free wildcard certificates, and content caching that helps mask slower NBN uploads.

Pick the registrars and DNS hosts that suit your wallet, but keep the renewal calendar somewhere visible. Expired domains are one of the leading causes of self-hosted services vanishing overnight, and there is no quicker way to lose a Sunday than discovering your Jellyfin library is unreachable because a credit card expired six months ago.

Configuring the Reverse Proxy on Synology or QNAP

The actual reverse proxy configuration is the part most people expect to be complicated and discover it is mostly just filling in fields. On Synology DSM, open Control Panel, choose Login Portal, then Advanced, and the Reverse Proxy tab. Add a rule with the source hostname you set up earlier, set the source port to 443 (or 80 if you are not running HTTPS yet), and point the destination at the internal NAS IP and the port your app listens on.

QNAP QTS exposes a similar screen under Network and Virtual Host, and users running apps in Container Station can route to specific container IPs instead of localhost. For services that live behind Docker, the trick is keeping the internal ports consistent and documenting them somewhere, since the proxy configuration has no way to discover them automatically.

For more advanced setups, running nginx directly inside a container on the NAS gives access to features not exposed in the GUI, such as custom headers, WebSocket upgrades, and per-location authentication. Tools like Nginx Proxy Manager, also containerised, provide a friendly web interface for managing many hostnames at once and are worth considering once you have more than two or three services.

Adding SSL Certificates and Hardening the Setup

Plain HTTP over a reverse proxy is fine for a quick test but should never be the final state. Let's Encrypt certificates are free, auto-renewing, and supported natively by both Synology and QNAP through their respective certificate managers. The DNS-01 challenge is preferred over HTTP-01 when the proxy itself handles requests, because it works even before the certificate is issued.

Beyond the certificate, hardening matters. Disable TLS 1.0 and 1.1, prefer modern cipher suites, and turn on HSTS once you are confident the certificate pipeline works. Add fail2ban or the built-in auto-block feature on the NAS to slow down credential-stuffing attempts, which are constant background noise on any public-facing service.

Two-factor authentication on the NAS itself is non-negotiable once it is reachable externally. The same goes for any web app exposed through the proxy. A reverse proxy fronting a service with a weak password is a much bigger problem than the proxy itself, and the proxy can give a false sense of security if the apps behind it are left at their defaults.

Troubleshooting Common Reverse Proxy Issues

Most reverse proxy problems fall into a small set of categories. 502 Bad Gateway errors usually mean the destination app is not listening on the expected port, or the NAS firewall is blocking the loopback connection. Subdomain not resolving points back to DNS, often a typo in the A record or a DDNS update that has not propagated.

Upload-heavy services sometimes crawl on Australian connections because the reverse proxy lacks proper buffering settings. Adjusting proxy buffers, timeouts, and request body size in the nginx config restores throughput without exposing the backend to memory pressure. Apps that stream large files or handle long-lived connections, such as remote desktop or video calls, often need explicit WebSocket upgrade headers added to the proxy rule.

When all else fails, checking the NAS logs while reproducing the issue is the fastest path forward. Both vendors keep reverse proxy logs accessible through their management interfaces, and most containerised apps log to stdout, which can be tailed through Container Station or Portainer.

A reverse proxy is one of those rare tools that, once set up properly, fades into the background and just works. Spend a quiet arvo getting the domain, certificates, and rules in order, back up the NAS configuration before changing anything, and start with one app to get the workflow down before bringing the rest online. The result is a self-hosted stack that feels every bit as polished as any paid service, with the added comfort of knowing exactly where your data lives and who can reach it.