How to Use Synology DSM’s Built-In Reverse Proxy for Docker Containers

When you run a web service in a Docker container on a Synology NAS, DSM’s built-in reverse proxy can give it a hostname such as app.example.com and route browser requests to it. A reverse proxy receives a request and forwards it to the service that should handle it.

The basic setup has three separate parts. First, publish the container’s web port on the NAS. Then create a DSM rule that points to that port, and configure DNS and a certificate for the hostname. If people will connect from outside your home or office, you also need a router rule that forwards web traffic to the NAS. A DSM proxy rule alone does not set up DNS or router forwarding.

Publish the container’s web port on the NAS

First, check which port the service uses inside its container. Then publish that port on the NAS. Docker calls this port publishing: the NAS listens on a host port and forwards traffic to the container port. The two port numbers do not have to match, as explained in Docker’s port-publishing documentation.

For example, suppose an app listens on port 80 inside its container. You could publish that port as 8081 on the NAS:

In DSM 7.2 and later, use Container Manager to configure the container’s port mapping. Synology’s container settings documentation describes the port settings. Earlier DSM versions may use the Docker package, and menu names vary by DSM version and NAS model. Choose a host port that is not already in use.

Test the published port from a device on your local network by opening http://192.168.1.20:8081 in a browser. Replace the example address and port with your own. If the app does not respond directly, check its container port and published mapping. Also check its startup status before changing the proxy rule.

This example assumes Docker uses a bridge network and publishes a host port for the container. With Docker host networking, the container shares the NAS network namespace, so port mappings do not apply. Docker explains the difference in its host network documentation.

Create the DSM reverse-proxy rule

In DSM 7, open Control Panel > Login Portal > Advanced > Reverse Proxy, then choose Create. DSM 6.2 uses Control Panel > Application Portal > Reverse Proxy; Synology’s Single Sign-On Quick Start Guide documents the menu paths for those DSM versions.

A rule has a source, which describes the incoming request, and a destination, which tells DSM where to send it. For the example above, enter:

The destination uses the NAS’s LAN IP and the published host port, not the container’s internal port. Select HTTP as the destination protocol when the app serves plain HTTP locally. Select HTTPS only when the app itself accepts HTTPS at that destination. Synology’s reverse-proxy settings let you set the source and destination protocols, hostnames, and ports.

The browser-to-NAS connection in this example uses HTTPS, while the NAS-to-app connection uses HTTP. That leaves the internal hop unencrypted. If your network or security requirements call for encryption on that hop, configure the app for HTTPS and set the destination protocol accordingly.

Some apps also need proxy-specific settings. For example, an app might need to trust the NAS as a proxy or accept forwarded information about the original client. Home Assistant requires configured trusted proxies and forwarded-header handling for reverse-proxy requests; its HTTP integration documentation gives its current instructions. Follow the app’s own guidance rather than applying one proxy configuration to every container.

DSM also provides a WebSocket header preset for apps that use WebSockets, a method for maintaining interactive connections through a proxy. Enable it when the app requires WebSockets, then test the app’s interactive features as well as its home page. A page loading successfully does not confirm that live updates or other WebSocket features work.

Configure the hostname, certificate, and remote access

The hostname in the DSM rule must match the name people enter in their browsers. For remote access, DNS, the service that maps hostnames to IP addresses, must point that hostname to your public IP address. You also need a router rule that forwards incoming traffic to the NAS. Synology’s external-access guide covers router forwarding, while its DDNS guidance explains how DDNS provides a name for reaching a changing public IP address.

For the common setup above, forward external TCP port 443 to the NAS’s HTTPS listener. Do not forward the container’s published app port from the internet unless you have a separate reason to expose it. Router forwarding and the DSM proxy rule serve different purposes: the router gets traffic to the NAS, and DSM routes it to the app.

Assign a valid certificate for the hostname so browsers can verify the HTTPS connection. Synology’s Let’s Encrypt instructions say these certificates last 90 days and DSM renews them automatically when domain authentication succeeds. For a customized domain, Synology’s documented method requires port 80 to reach the NAS during certificate issuance or renewal. Synology notes that this limitation does not apply to Synology DDNS.

DSM access-control profiles can restrict who reaches a reverse-proxy rule. Synology warns that enabling an access-control profile with a Let’s Encrypt certificate can cause automatic renewal to fail. If you change access controls, check that certificate renewal still succeeds rather than assuming it will continue unchanged.

Check what the proxy exposes

Publishing a container port also makes it reachable through routes other than the DSM reverse proxy. Docker says a published port is available beyond the Docker host by default. The NAS firewall and router rules determine which other paths can reach it, so check whether the published port responds directly on your LAN and avoid forwarding that port from the internet unless you intend to expose it.

A user-defined Docker bridge lets related containers communicate by name, but this DSM setup sends traffic to the NAS’s LAN IP and published host port. Docker documents user-defined bridge networking in the Container Manager network help. Do not assume DSM can resolve a container-only name as a destination.

Troubleshoot by testing each connection

If the hostname fails, test each part of the request path separately: the browser’s request to the hostname, the router’s forwarding to the NAS, DSM’s forwarding to the published port, and the published port’s connection to the container. A direct LAN test such as http://192.168.1.20:8081 separates an app or Docker connectivity problem from a proxy-rule problem.

If the direct test works but the hostname does not, check that the DSM destination port is the published host port and that the destination protocol matches what the app serves. Then confirm that the browser hostname resolves to the intended address and that DSM has a certificate covering that name.

If remote access fails while local access works, check the router’s forwarding rule and the NAS firewall. If the public hostname works outside but not inside the LAN, the router may lack NAT loopback, which lets devices inside the network reach the public address and return to the NAS. Synology lists this as a possible cause in its DDNS troubleshooting guidance.

If the page loads but an interactive feature fails, check whether the app uses WebSockets and whether its own proxy settings trust DSM. Also confirm the app’s external URL or forwarded-header settings when its documentation calls for them.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com