When I was away from home, even though I could reach my Synology via Tailscale address or Magic DNS, trying to access something like 192.168.1.144:7878 for Radarr would just time out.

That’s where Tailscale’s subnet routers come in. This feature allows you to access all devices on your home network—including your Docker containers—using their actual LAN IP addresses.

What We’re Solving

We want to access our Docker containers using their LAN IP addresses consistently, regardless of whether we’re connected to our home network or accessing remotely through Tailscale.

Prerequisites

• Tailscale already set up on your machine. You can use this guide to set it up.

Setting Up Subnet Routing

Step 1: Configure Your Synology as a Subnet Router

First, you’ll need to SSH into your Synology. Once you’re connected, run this command:

sudo tailscale up --advertise-routes=192.168.1.0/24 --advertise-exit-node --reset

Important: Make sure to replace 192.168.1.0/24 with the correct subnet for your network. In my case, my Synology has the IP address 192.168.1.144, so I use 192.168.1.0/24. You can find your network’s subnet by checking your router’s configuration or running ip route on your Synology.

Step 2: Enable Subnet Routing in Tailscale Admin Console

The command above advertises your local network routes to Tailscale, but you need to explicitly enable them in the admin console:

1. Go to the Tailscale admin console at https://login.tailscale.com/admin/machines
2. Find your Synology device in the machines list
3. Click on the device and select “Edit route settings”
4. In the “Subnet routers” section, check the box next to your advertised route (e.g., 192.168.1.0/24)

Testing Your Setup

With that configuration complete, you should now be able to access all your Docker containers using their LAN IP addresses, regardless of whether you’re connected to your home network or not.

For example, if you have a container running on 192.168.1.144:7878, you can access it from anywhere by simply navigating to that address in your browser while connected to Tailscale.

Taking It Further: Reverse Proxy Setup

You can make this setup even more elegant by implementing a reverse proxy. This allows you to access your services using clean subdomains like radarr.kunat.dev instead of remembering IP addresses and port numbers. You can read more about it here.

Resources

• Tailscale documentation on subnet routers
• How To Install And Configure Tailscale On Your Synology Nas
• Setting Up Caddy as a Reverse Proxy on Synology NAS

What’s Caddy?

Caddy is a modern, open-source web server that excels at reverse proxying. It’s lightweight, easy to configure, and handles HTTPS automatically. What sets it apart is its human-readable configuration format and automatic certificate management capabilities.

Why I Chose Caddy Over Synology’s Built-in Solution

Synology does include a reverse proxy feature, but it has some limitations:

Platform Agnostic: Caddy runs in Docker, which means it’s not tied to Synology’s ecosystem. If I ever migrate to a different NAS or server setup, my configuration comes with me.

File-Based Configuration: This is the big one for me. Synology’s reverse proxy requires you to configure each service through their GUI interface. When you’re running more than a few containers, this becomes time-consuming. With Caddy, I can define all my services in a single configuration file that’s easy to version control and backup.

Better HTTPS Handling: Caddy’s automatic HTTPS capabilities are far superior to what Synology offers out of the box. We won’t use those, but I listed it for completeness’ sake.

Goals

Access your Docker containers using clean subdomains instead of remembering port numbers. Instead of typing 192.168.1.100:9696 to reach Prowlarr, you’ll use prowlarr.yourdomain.com.

Prerequisites

Before we dive in, you’ll need a few things in place:

Docker Setup: I’m assuming you have Docker set up and running using the Trash Guides. This isn’t strictly required, but I’ll assume your directory structure and permissions match what’s described in their guide.

Cloudflare Domain Management: This guide assumes your domain is managed through Cloudflare’s dashboard. The DNS records must have the proxy status enabled (orange cloud icon). This is crucial for the HTTPS setup we’ll implement later.

Local DNS Server: You’ll need to be running your own DNS server like AdGuard Home or Pi-hole. This is required to add a wildcard DNS rewrite rule that points *.yourdomain.com to your Synology’s IP address.

Setup

Adding Caddy to Your Docker Compose

First, let’s add Caddy to your existing docker-compose.yml file. Here’s the configuration I use:

  caddy:
    container_name: caddy
    image: caddy:latest
    restart: unless-stopped
    network_mode: host
    environment:
      - TZ=${TZ}
    volumes:
      - /volume1/docker/appdata/caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - /volume1/docker/appdata/caddy/data:/data
      - /volume1/docker/appdata/caddy/config:/config
      - /volume1/docker/appdata/caddy/certs:/caddy/certs:ro

Creating the Folder Structure

In your appdata directory (/volume1/docker/appdata), create the necessary Caddy directories:

mkdir -p caddy/{certs,config,data} && touch caddy/Caddyfile

This creates the directory structure that Caddy needs, including directories for certificates, configuration, and data storage, plus the main Caddyfile.

Freeing Up Ports 443 and 80

Here’s something that caught me off guard: Synology automatically binds to ports 443 and 80 even if you’re not using their built-in reverse proxy. Since Caddy needs these ports to handle HTTPS and HTTP traffic, we need to free them up.

sed -i -e 's/80/82/' -e 's/443/444/' /usr/syno/share/nginx/server.mustache /usr/syno/share/nginx/DSM.mustache /usr/syno/share/nginx/WWWService.mustache

synosystemctl restart nginx

I set up a boot script to handle this automatically on each reboot (Control Panel -> Task Scheduler). While I’ve found that this override typically persists between reboots, there’s no harm in ensuring it runs at startup. System updates might reset these settings to their defaults, and I’d rather be safe than sorry.

Setting Up HTTPS (Optional but Recommended)

HTTPS isn’t technically required for local-only access, but it eliminates browser warnings. However, there’s an important caveat with Caddy’s automatic HTTPS feature.

Why Caddy’s Built-in Auto HTTPS Won’t Work: Caddy’s automatic HTTPS uses Let’s Encrypt, which requires ACME challenges to verify domain ownership. These challenges need your server to be accessible from the internet. If your containers are only accessible through Tailscale or similar private networks (like mine), the ACME validation will fail.

The Solution: Cloudflare Origin CA Certificates: Since I use Tailscale to access my containers outside my home network, I opted for Cloudflare’s Origin CA certificates. These certificates are valid for 15 years and don’t require internet accessibility for validation.

Generating Cloudflare Origin Certificates

Your domain needs to be using Cloudflare for this to work. Navigate to the Cloudflare Origin CA dashboard and generate a wildcard certificate for your domain. See Cloudflare Docs for step-by-step instructions.

Save the public and private keys to these files:

• cert.pem (public key)
• key.pem (private key)

Move both files to your caddy/certs directory.

Adding the Certificate to Your Devices

To eliminate browser security warnings, you’ll need to add the public certificate (cert.pem) to your device’s trusted certificate store. On macOS, this means adding it to your keychain and marking it as trusted. You’ll need to repeat this process for each device you want to use to access your containers.

Setting Proper Permissions

Following the Trash Guides approach, set the correct permissions for the docker user:

sudo chown -R docker:users /volume1/docker/appdata/caddy
sudo chmod -R a=,a+rX,u+w,g+w /volume1/docker/appdata/caddy

Configuring the Caddyfile

Here’s a sample Caddyfile configuration. This is where the magic happens:

# Global options
{
	# Disable automatic HTTPS since we're using Cloudflare Origin CA certs
	auto_https off
}

# Prowlarr
prowlarr.kunat.dev {
	reverse_proxy localhost:9696
	tls /caddy/certs/cert.pem /caddy/certs/key.pem
}

# Plex
plex.kunat.dev {
	reverse_proxy localhost:32400
	tls /caddy/certs/cert.pem /caddy/certs/key.pem
}

# AdGuard
adguard.kunat.dev {
	reverse_proxy localhost:3000
	tls /caddy/certs/cert.pem /caddy/certs/key.pem
}

# Synology Dashboard (HTTPS backend)
synology.kunat.dev {
	reverse_proxy https://localhost:5001 {
		transport http {
			tls_insecure_skip_verify
		}
	}
	tls /caddy/certs/cert.pem /caddy/certs/key.pem
}

# Homarr
homarr.kunat.dev {
	reverse_proxy localhost:7575
	tls /caddy/certs/cert.pem /caddy/certs/key.pem
}

Each service follows the same pattern: define the subdomain, specify the reverse proxy target (localhost:port), and point to our TLS certificates.

Running Caddy

Start Caddy with:

sudo docker-compose up -d caddy

If everything is configured correctly, you should see logs similar to these:

caddy  | {"level":"warn","ts":1752004979.244892,"msg":"failed to set GOMAXPROCS","error":"open /sys/fs/cgroup/cpu/cpu.cfs_quota_us: no such file or directory"}
caddy  | {"level":"info","ts":1752004979.2452004,"msg":"GOMEMLIMIT is updated","package":"github.com/KimMachineGun/automemlimit/memlimit","GOMEMLIMIT":18851998924,"previous":9223372036854775807}
caddy  | {"level":"info","ts":1752004979.2452545,"msg":"using config from file","file":"/etc/caddy/Caddyfile"}
caddy  | {"level":"info","ts":1752004979.247973,"msg":"adapted config to JSON","adapter":"caddyfile"}
caddy  | {"level":"info","ts":1752004979.2502022,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]}
caddy  | {"level":"info","ts":1752004979.2507207,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc00079c480"}
caddy  | {"level":"warn","ts":1752004979.2785668,"logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for [cloudflare origin certificate *.kunat.dev]: no URL to issuing certificate"}
caddy  | {"level":"info","ts":1752004979.278835,"logger":"http.auto_https","msg":"automatic HTTPS is completely disabled for server","server_name":"srv0"}
caddy  | {"level":"info","ts":1752004979.2799113,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
caddy  | {"level":"info","ts":1752004979.2799726,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details."}
caddy  | {"level":"info","ts":1752004979.2800903,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
caddy  | {"level":"info","ts":1752004979.280308,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
caddy  | {"level":"info","ts":1752004979.2811198,"msg":"serving initial configuration"}
caddy  | {"level":"info","ts":1752004979.38889,"logger":"tls","msg":"finished cleaning storage units"}

The key things to look for are “server running” and “serving initial configuration” messages. These indicate that Caddy has successfully started and is ready to handle requests.

Now try accessing one of your Docker containers using its subdomain. If everything is working correctly, you should be able to reach your services through clean URLs like https://prowlarr.yourdomain.com.

Troubleshooting

Clean Your DNS Cache: If you’re having trouble accessing your services after setup, try clearing your DNS cache. On macOS, run:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Check Your Wildcard DNS: Make sure your local DNS server (AdGuard Home or Pi-hole) has the wildcard rewrite rule in place. Without *.yourdomain.com -> your_synology_ip, your subdomains won’t resolve locally.

Verify Certificate Trust: If you’re seeing browser security warnings, double-check that you’ve properly installed and trusted the Cloudflare Origin CA certificate on your client devices.

Resources

• Free 80,443 Ports - 3os
• Caddy Documentation
• Cloudflare Origin CA Documentation

Conclusion

Setting up Caddy as a reverse proxy on Synology has been a game-changer for my homelab. The ability to access all my services through clean subdomains makes everything feel more professional and easier to remember. While the initial setup requires some work, especially with the certificate configuration, the long-term benefits are worth it.

Update 14/07/25: If you want to access your Docker containers using their LAN IP addresses consistently, regardless of whether we’re connected to our home network or accessing remotely through Tailscale check out this aritcle on Tailscale subnet routers.

• Media Server - My Synology stores and serves my entire collection of movies, TV shows, and music. Using Plex, I can stream this content to any device, creating a personalized Netflix-like experience.
• Usenet / Torrent Client - I have the standard *ARR stack setup for managing my media library. I can’t recommend it enough. This suite of apps is a crown jewel of the entire setup.
• HomeBridge - HomeBridge allows me to integrate non-HomeKit devices into my Apple HomeKit setup.
• Time Machine Backup Destination - My Synology serves as a Time Machine backup destination for all my Macs. This is a major improvement over manually connecting external HDDs.
• DNS Server - I run AdGuard Home on my Synology as a DNS server. Similar to Pi-hole, it blocks ads across all devices on my network. You can read more about it here.
• Personal Cloud Storage - While I use iCloud for critical documents, my Synology acts as a personal cloud for miscellaneous files. It’s a great way to keep less important documents accessible without cluttering my primary cloud storage.

In the following sections, I’ll dive deeper into this setup, providing a high-level overview and sharing useful resources that have helped me create this system.

The Initial Setup

Storage Pools / Shares / Volumes

The first question I asked myself when setting up the system was “What volume structure should I use?” Initially, I aimed for complete separation between documents, media, and backups. This approach would have resulted in a single storage pool with three separate volumes.

However, I learned that creating separate volumes doesn’t offer significant advantages in this case (if any). It doesn’t provide any real security benefits. Instead, having separate shared folders with properly set up permissions is more than sufficient. So, unless you have a compelling reason to do otherwise, you should default to a single storage pool with a single volume.

95% of users should use a single SHR pool, with a single BTRFS volume. If you need something else, you’re an advanced user with an unusual use case (or just a big nerd who likes to tinker, even when it’s slightly harmful).

Some people make multiple pools for different RAID levels for different uses, or making a separate pool with surveillance-class drives for their cameras. IMO, it’s not worth that level of control, but it’s available. You must make separate pools for HDDs and SSDs.

There’s even less reason to use multiple volumes on the same pool. All of the backup, permissions, quota, etc. management is done at the shared folder level, so there just isn’t much benefit to multiple volumes, unless you’re hitting the 108TB limit and are forced to.

From the synology community on Reddit

Access Control

All of my shared folders use the default permissions, except for docker. The permissions for this directory are described in detail here. The gist of this setup is that the “docker” user has full access to the “docker” shared folder and nothing else. All other users can access anything except the docker folder.

I have three accounts in total:

• An admin account that I only use when I need to make changes to Synology.
• My personal account, which I use day-to-day. All of my client devices use it to access documents, media, and backups.
• The docker account I mentioned earlier.

Setting up Time Machine

Use this video and you should be good to go.

Docker

I started my Docker setup with this guide as part of setting up the *ARR stack. It goes into detail on how to set it up from the ground up. Once you’re done, it should be fairly easy to build on top of it.

I still haven’t gotten around to setting up automation for updating the containers, so I can’t speak on pullio, the solution suggested in the guide above.

Remote Access

With the initial setup done, it’s time to decide how to access your Synology outside of your home network. In my setup, I wanted to balance security and convenience. That’s why I decided against Synology’s Quick Connect and went with Tailscale. The free tier is more than enough for my needs, and this setup is beautifully simple to configure.

I wrote a separate article on how to set up Plex to work with Tailscale. If you want to learn more about the available options for remote access, this video covers the most popular choices.

Backup

I backup my entire system using the built-in Hyper Backup solution. Here’s a tutorial on how to set it up.

I don’t backup media to save space. In the worst-case scenario of two subsequent disk failures, I’ll still have all of my most important documents intact. The media library should be fairly simple to rebuild.

I have a monthly reminder to connect the external HDD and make a backup. You can configure it so that the external disk will be unmounted when the backup is finished. This makes the process easy and hassle-free. I connect the drive, initiate the backup, and detach it the next morning. You could keep it connected, but I prefer to keep my backup offsite. It’s my final safety net when everything else fails.

Resources

• Practical reasons for having multiple storage pools and volumes : r/synology
• Setting up AdGuard Home on Synology NAS with Tailscale | kunat.dev
• Synology - TRaSH Guides
• How to Backup MacOS to Synology NAS using Time Machine (easy) - YouTube
• Secure Remote Access to Your Synology Plex Server via Tailscale | kunat.dev
• The Complete Guide to Remotely Access Synology NAS - All 5 Options Explained - YouTube
• Do this FIRST - How to Backup Synology NAS to USB Hard Drive (Hyperbackup) - YouTube

In this guide, I’ll walk you through the steps to set up AdGuard Home (AGH) as a Docker container on a Synology NAS. This setup will allow you to use AGH both inside and outside of your home network.

AdGuard Home is a network-wide DNS server that blocks ads and trackers for all devices on your network. It filters unwanted content before it reaches your devices, eliminating the need for individual ad blockers. With customizable rules and open-source flexibility, it offers comprehensive protection and can be installed on various platforms, including Raspberry Pi.

Prerequisites

• Basic Docker setup running on your Synology NAS (users, permissions, folders)
  • I highly recommend following the Synology | TRaSH Guides

The following steps assume you have a setup similar (ideally identical) to the one from the article linked above. The most important aspects are user permissions and folder structure.

Configuration

.env:

## Edit/update your settings that will be used for your docker-compose
## This will only work if you follow exactly the path structure in the Guide!
COMPOSE_PROJECT_NAME=trash-guides

## Global Settings
# Change "/volume1/docker/appdata" to your config path
DOCKERCONFDIR=/volume1/docker/appdata
# Change "/volume1/data" to your library + torrent/usenet downloads path
DOCKERSTORAGEDIR=/volume1/data
# Find your PUID/PGID through SSH, run in terminal: id $user
# Change $user to the user you created if needed
PUID=XXXX
PGID=YYY

# Other app-specific settings and variables
# ...

This setup doesn’t use any environment variables specific to AGH. The key thing is to set PUID and PGID correctly.

docker-compose.yml:

version: "3.2"
services:
  adguardhome:
    image: adguard/adguardhome:latest
    container_name: adguardhome
    network_mode: host
    volumes:
      - ${DOCKERCONFDIR}/adguardhome/work:/opt/adguardhome/work
      - ${DOCKERCONFDIR}/adguardhome/conf:/opt/adguardhome/conf
    restart: unless-stopped
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}

# Other containers
# ...

Folder structure

Initial Setup

After running the container for the first time, complete the initial AGH setup:

1. When asked to choose the network interface for DNS requests, select “All Interfaces”.
2. Switch the Web Interface port to 3000 if it’s not already set.
3. Set credentials for your admin account.

If you encounter issues, refer to this guide.

Local Network Setup

To use AGH as your DNS server:

1. Set it on your router (preferred method).
2. If router modification isn’t possible, set it manually for each device on your home WiFi network. Here’s a guide for iOS.

Use your Synology’s local network IP address. Update your DHCP settings to ensure your Synology’s local IP address doesn’t expire.

With this setup, you’ll see the benefits of AGH whenever you’re connected to your home network.

Remote Setup

To use AGH when not on your home network, there are several options:

• Dynamic DNS (DDNS) and port forwarding
• Setting up a VPN server on your NAS
• Using Cloudflare Tunnel
• Tailscale (the method used in this guide)

Tailscale is a modern, user-friendly virtual private network (VPN) solution that leverages the WireGuard protocol to create secure, peer-to-peer connections between devices. It simplifies network configuration by eliminating the need for traditional VPN servers and complex firewall rules.

To set up Tailscale:

1. Set custom DNS in Tailscale admin panel (your Synology’s tailnet IP address)
2. Enable “override local DNS”
3. Set up Tailscale on all devices you plan to use outside your home network
4. Set up VPN On-Demand

With these steps, your device will automatically connect to your Tailscale mesh network, which will use AGH as a DNS server.

Cleanup

For Safari users: Consider disabling Advanced Tracking and Fingerprinting Protection, as it can override local DNS settings and interfere with AGH. More details on this issue can be found here.

Note: Client names may not resolve properly due to Docker’s host network mode. If you find a solution to this issue, please share!

Resources

• Install Adguard Home on a Raspberry Pi 4 and enable remote access with Tailscale | Senior Project Manager in Toronto, Ontario | Nicolas Louge
• AdGuard Home + Tailscale = Erase Ads on the Go
• AdGuard Home in Container Manager on a Synology NAS

A few weeks back, I set up AdGuard Home on my Synology NAS. I’ve been using it without any issues inside and outside of my home network thanks to Tailscale. There was one issue with this setup though: battery drainage on all of my mobile devices. I noticed that my battery usage went up by 25% on my phone.

From what I could find, the increased battery usage might have been caused by a few factors:

• Constant network connection: Tailscale maintains a persistent VPN connection
• Encryption overhead: The VPN encrypts and decrypts all traffic, which requires additional processing power
• Background processes: Tailscale might be doing some work in the background

To solve this issue, I decided to update my config so that I use VPN only when I’m not on my home network. My ISP-provided router does not allow me to change the default DNS, so my only option was to manually set it for each device.

Tailscale’s VPN On-Demand feature is just the tool for the job. It allows you to connect to your mesh network only when some specific rules are satisfied. For example, with the following configuration, my phone will connect to the VPN only when I’m not connected to my home network.

This setup worked beautifully. The battery issue was gone. Tailscale worked as advertised. I could still access my server from anywhere. The only issue was that AdGuard Home seemed to not work in private Safari tabs.

My first suspect was Private Relay. I toggled it on and off, but it didn’t fix the issue. The second suspect was the “Prevent cross-site tracking” setting. Still nothing. Finally, I found this thread that pointed me in the right direction. Turns out, the issue was caused by the Advanced Tracking and Fingerprinting Protection setting located in Advanced settings. Turning it off fixes the issue instantly.

iOS

macOS

Resources

• iOS 17 private browsing overrides DNS - Apple Community

Prerequisites

• Have a Plex server running as a Docker container using this guide. When you’re done, you should have a docker-compose.yml and a .env file with all your environment variables.
• Have Tailscale set up and running on your Synology. You can use this guide.

Make sure to disable the expiry for the IP address assigned to your Synology NAS in the Tailscale dashboard.

Steps

1. Set PLEX_ADVERTISE_URL (in the .env file) to your Synology IP address in the Tailscale dashboard and your local network IP address:

## PLEX
# ... other keys
PLEX_ADVERTISE_URL="http://ds1512p:32400,http://192.168.0.186:32400"

Remember to include port numbers in both IP addresses!

2. Restart the Plex container using the latest changes:

sudo docker-compose up --force-recreate plex

3. Check if the changes have been applied successfully. “Custom server access URLs” should be set to $PLEX_ADVERTISE_URL.

Summary

That’s it! With the above setup, you should be able to connect to your Plex server from your local network as well as from anywhere, as long as you’re connected to Tailscale.

Resources

• How to run Plex through Tailscale