Synology Reverse Proxy with Let's Encrypt: HTTPS for Every App on DSM 7

Once you start running apps on a Synology NAS, you end up with a mess of addresses: DSM on 5001, Uptime Kuma on 3001, a wiki on 8080, Home Assistant on 8123. Remembering ports is annoying, browsers complain about self-signed certificates, and opening a router port for every app is a security problem waiting to happen.

DSM 7 already has everything needed to fix this: a built-in reverse proxy and a free Let's Encrypt client. The result is one open port (443), a proper certificate, and a clean name for each app, such as status.example.com.

How the pieces fit together

A reverse proxy sits in front of your apps. The browser connects to the NAS on port 443 and asks for, say, status.example.com. DSM's nginx reads that hostname, terminates TLS with the right certificate, and forwards the request to the app running on localhost:3001. The app itself never needs to know about HTTPS.

You need three things:

1. A domain name you control (or a free Synology DDNS name like yourname.synology.me).
2. DNS records pointing each subdomain at your public IP.
3. Ports 80 and 443 forwarded from your router to the NAS. Port 80 is only there so Let's Encrypt can validate your domain and so plain HTTP can redirect to HTTPS.

Step 1: Point DNS at your NAS

At your DNS provider, create an A record for each app (or one wildcard record if your provider supports it):

status.example.com.   300  IN  A  203.0.113.25
wiki.example.com.     300  IN  A  203.0.113.25

Replace 203.0.113.25 with your public IP. If your ISP changes your IP, use DDNS (Control Panel > External Access > DDNS) and create CNAME records pointing at the DDNS name instead. Check the record from outside your network:

dig +short status.example.com

On some home routers, browsing to your own public IP from inside the LAN doesn't work (no NAT loopback). If the site works on mobile data but not on Wi-Fi, that's the reason, and a local DNS override fixes it.

Step 2: Get a Let's Encrypt certificate

1. Go to Control Panel > Security > Certificate and click Add > Add a new certificate.
2. Choose Get a certificate from Let's Encrypt.
3. Enter the main domain (for example status.example.com), an email address for expiry warnings, and any extra names in Subject Alternative Name, separated by semicolons: wiki.example.com;photos.example.com.

DSM uses the HTTP-01 challenge, so Let's Encrypt connects to your domain on port 80. If this step fails, it's nearly always one of: the DNS record isn't live yet, port 80 isn't forwarded, or your ISP blocks inbound port 80. With a synology.me DDNS name you can also request a wildcard certificate, which avoids adding SANs every time.

DSM renews Let's Encrypt certificates automatically before they expire. Leave port 80 forwarded so renewals keep working.

Step 3: Create the reverse proxy rule

Go to Control Panel > Login Portal > Advanced > Reverse Proxy and click Create.

• Description: Uptime Kuma (this name shows up later in the certificate list)
• Source protocol HTTPS, hostname status.example.com, port 443
• Tick Enable HSTS once you're sure HTTPS works (browsers will refuse plain HTTP for that host afterwards)
• Destination protocol HTTP, hostname localhost, port 3001

Save it, and then assign the certificate: back in Control Panel > Security > Certificate, click Settings, find the row named after your rule's description, and select the Let's Encrypt certificate. Without this step DSM serves its default certificate and the browser shows a name mismatch.

Step 4: Add WebSocket headers when the app needs them

Apps with live dashboards (Uptime Kuma, Home Assistant, code-server, many chat tools) use WebSockets. Without the right headers they load but never update, or show "disconnected" banners.

Edit the rule, open Custom Header, click Create > WebSocket. DSM adds these two headers for you:

Upgrade      $http_upgrade
Connection   $connection_upgrade

Some apps also need to know the original host and scheme to build correct links or accept logins. If an app complains about origin checks or redirects you to http://localhost, add:

X-Forwarded-Proto   $scheme
X-Real-IP           $remote_addr

Then set the app's own "base URL" or "trusted proxies" setting to your public hostname.

Step 5: Test it properly

From a device outside your network (phone on mobile data is fine):

curl -I https://status.example.com

It should return the app's normal status (200 or a redirect to its login page). For an independent check of the certificate chain, run your hostname through SSL Labs' server test, and confirm that the certificate's issuer is Let's Encrypt and its names match.

Security checklist

A reverse proxy makes apps reachable from anywhere, so be deliberate about what you publish:

• Only publish apps that have their own login. Anything without authentication (a Docker dashboard, an admin panel with no password) should stay on the LAN or behind a VPN. For private-only access, see Tailscale vs WireGuard for remote access to a home NAS.
• Never publish DSM itself on the open internet if you can avoid it, and never forward SSH. My Synology SSH hardening guide explains why.
• Bind containers to localhost where possible. In Compose, "127.0.0.1:3001:3001" means the app is only reachable through the proxy, not directly on the LAN port.
• Turn on Auto Block in Control Panel > Security > Protection and keep DSM and packages updated.
• Use access control profiles (in the reverse proxy rule) to limit admin-only apps to your LAN subnet.

Common problems

• 502 Bad Gateway: the destination port is wrong, the container is stopped, or it only listens on a different interface. Run curl -I http://localhost:3001 on the NAS over SSH to check.
• Certificate warning on one subdomain: the certificate isn't assigned to that reverse proxy entry in Certificate > Settings, or the name isn't in the certificate's SAN list.
• Let's Encrypt fails to issue: check port 80 forwarding and DNS. Another service already listening on 80 with its own redirect can also break validation.
• Redirect loops: the app itself forces HTTPS while the proxy talks to it over HTTP. Tell the app it's behind a proxy (X-Forwarded-Proto) or disable its own HTTPS redirect.
• Uploads fail on large files: the app's own upload limit is usually the cause; check its settings first.

Where this fits

With a reverse proxy in place, adding a new app takes a minute: start the container on a high port, add a DNS record and a reverse proxy rule, then attach the certificate. If you're new to running containers on a Synology, start with my Container Manager guide, and for the production habits that keep those containers healthy, read Docker in production: volumes, networks and Compose secrets.