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.

MeTube is a web GUI for youtube-dl, a command-line tool for downloading videos from YouTube and several hundred other sites.

My goal for this project was to set up automation for downloading YouTube videos directly to my Plex library.

The primary reason is that I can’t trust myself with YouTube Shorts. Once I open YouTube, I’m likely to spend at least a few minutes browsing through them. The simplest solution was to add friction to the process: I removed the YouTube app from all my devices and blocked the domain using my local DNS server.

This worked like a charm. Now, I only visit YouTube every few days to add content that interests me to my Plex library.

You can read more about setting up your own DNS server here.

Prerequisites

• ‼️ Docker must be installed and set up on your system by following the TrashGuides setup for Synology.

This guide assumes you have configured common environment variables like PUID, PGID, TZ, DOCKERSTORAGEDIR, and DOCKERCONFDIR as outlined in the TrashGuides.

Installation Steps

1. Create Required Directories

First, we need to create folders for MeTube’s configuration and downloads. One folder will store MeTube’s application data, and the other will be the destination for your downloaded videos.

SSH into your Synology NAS and execute the following commands:

The commands below assume you’ve followed the linked guide exactly. Adjust paths like /volume1/data/media/youtube and /volume1/docker/appdata/metube if your storage volume or directory structure differs.

• Folder for video downloads (e.g., your Plex library):

  sudo mkdir -p /volume1/data/media/youtube
  

• Folder for the MeTube container’s configuration:

  sudo mkdir -p /volume1/docker/appdata/metube
  

2. Set Permissions

Next, execute the following commands via SSH to configure the correct permissions for the newly created directories:

sudo chown -R docker:users /volume1/data/media/youtube /volume1/docker/appdata/metube
sudo chmod -R a=,a+rX,u+w,g+w /volume1/data/media/youtube /volume1/docker/appdata/metube

This command ensures the docker user has the necessary ownership and read/write permissions.

3. Configure Docker Compose

Append the following service configuration to your main docker-compose.yml file. If you followed the TrashGuides setup, this file is located at /volume1/docker/.

services:
  metube:
    container_name: metube
    image: ghcr.io/alexta69/metube:latest
    restart: unless-stopped
    logging:
      driver: json-file
      options:
        max-file: ${DOCKERLOGGING_MAXFILE:-10}
        max-size: ${DOCKERLOGGING_MAXSIZE:-200m}
    ports:
      - "8081:8081"
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - UMASK=002
      - DOWNLOAD_DIR=/downloads
      - AUDIO_DOWNLOAD_DIR=/downloads
      - STATE_DIR=/config/.metube
      - TEMP_DIR=/downloads/.temp
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ${DOCKERSTORAGEDIR}/media/youtube:/downloads
      - ${DOCKERCONFDIR}/metube:/config

Note on Environment Variables and Volumes:

• ${DOCKERSTORAGEDIR}/media/youtube maps your Synology’s media download folder to the /downloads directory inside the container. Ensure DOCKERSTORAGEDIR is correctly defined (e.g., DOCKERSTORAGEDIR=/volume1/data).
• ${DOCKERCONFDIR}/metube maps your Synology’s MeTube appdata folder to the /config directory inside the container. Ensure DOCKERCONFDIR is correctly defined (e.g., DOCKERCONFDIR=/volume1/docker/appdata).

4. Start the Container

Navigate to the directory containing your docker-compose.yml file via SSH and run the following command:

docker compose up -d metube

The container will now download the image and start. You can then access the MeTube web interface by navigating to http://<your-synology-ip>:8081 in a web browser.

Check out MeTube’s README for a handy iOS shortcut that allows you share video URLs without opening MeTube!

Troubleshooting

• Port Conflicts: If port 8081 is already in use, change the host port in the ports section of your docker-compose.yml. For example, to use port 8082, modify the line to - "8082:8081".
• Permission Issues: If MeTube reports that it cannot write to the download or config directories, double-check the permissions set in Step 2. Also, verify that the PUID and PGID environment variables correspond to a user with write access to those folders.
• Container Logs: If the container fails to start or you encounter other issues, check its logs with this command:

  docker compose logs metube
  

Resources

• MeTube GitHub Repository
• TrashGuides for Synology Docker Setup

Note: This article was originally published 05/2025. Last update 08/2025. Changes:

• Added sockpuppetbrowser to enable Playwright Chromium/Javascript fetch method

Changedetection.io is a powerful open-source tool that monitors websites for changes. It’s incredibly useful for tracking updates on pages that don’t offer their own notification systems. This guide will walk you through setting it up on your Synology NAS using Docker Compose.

Prerequisites

• Docker installed on your system by following the TrashGuides setup for Synology.

Installation

Append this configuration to your docker-compose.yml file. If you’ve followed the guide mentioned above, this file should be located in your Docker application data directory (e.g., /volume1/docker/appdata).

This configuration sets up a changedetection container along with sockpuppetbrowser, which enables you to use the Playwright Chromium/Javascript fetch method. It’s handy in cases where a site requires JavaScript to load. It’s still best to use Basic fast Plaintext/HTTP Client as the default for your change detection watch entries.

  changedetection:
    image: lscr.io/linuxserver/changedetection.io:latest
    container_name: changedetection
    restart: unless-stopped
    logging:
      driver: json-file
      options:
        max-file: ${DOCKERLOGGING_MAXFILE}
        max-size: ${DOCKERLOGGING_MAXSIZE}
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - PLAYWRIGHT_DRIVER_URL=ws://browser-sockpuppet-chrome:3000
    volumes:
      - ${DOCKERCONFDIR}/changedetection:/config
    ports:
      - 5555:5000
    depends_on:
      - browser-sockpuppet-chrome

  browser-sockpuppet-chrome:
    hostname: browser-sockpuppet-chrome
    image: dgtlmoon/sockpuppetbrowser:latest
    container_name: browser-sockpuppet-chrome
    cap_add:
      - SYS_ADMIN
    restart: unless-stopped
    logging:
      driver: json-file
      options:
        max-file: ${DOCKERLOGGING_MAXFILE}
        max-size: ${DOCKERLOGGING_MAXSIZE}
    environment:
      - SCREEN_WIDTH=1920
      - SCREEN_HEIGHT=1024
      - SCREEN_DEPTH=16
      - MAX_CONCURRENT_CHROME_PROCESSES=10

Note on Environment Variables:

• The PUID, PGID, and TZ environment variables above are set consistently with your other containers.

Start the container by running this command in the directory containing your docker-compose.yml file:

docker compose up -d

This command launches Changedetection.io in detached mode, meaning it runs in the background. You should then be able to access it by navigating to http://<your-synology-ip>:5000 in your web browser.

Troubleshooting

If you encounter issues accessing Changedetection.io, try running the container without the -d flag (e.g., docker compose up) to view the live logs directly.

During my initial setup, I discovered that the default host port (5000) was already in use on my Synology. You can resolve such a port conflict by updating the host port (the first number in the ports section) like so:

ports:
  - NEW_PORT:5000 # Example: 5001:5000

The Container Port (the right-hand side of the colon, e.g., 5000 in NEW_PORT:5000) is the port that the application inside the Docker container is programmed to listen on. The Changedetection.io application is configured by its developers to listen on port 5000 within its isolated container environment. Changing this internal container port would require modifying the application’s internal configuration, which is generally more complex and unnecessary for resolving a host port conflict.

Resources

• Changedetection.io GitHub Repository (includes documentation)
• LinuxServer.io Changedetection.io on Docker Hub

Before you start, you should have qBittorrent up and running using this guide.

Implementation

If you’ve used the guide linked above, the qBittorrent container is already running. There are two configuration files that we’ll need to edit: .env and docker-compose.yml.

.env

Make sure the LAN_NETWORK variable is set properly. If you haven’t modified it after the initial setup, it should be set to 192.168.x.0/24. Update it so that your Synology’s LAN IP is within the address range. Example: since my Synology’s LAN IP address is 192.168.1.110, I’ve replaced x with 1: 192.168.1.0/24.

Set VPN_ENABLED to true

Set VPN_PROVIDER to pia

Hotio’s qBittorrent image also supports Proton VPN out of the box. You should be able to use it with any provider that supports the WireGuard protocol.

If you’re using PIA or Proton, set PORT_FORWARD to true.

Add the following variables:

VPN_PIA_USER=YOUR_PIA_USERNAME
VPN_PIA_PASS=YOUR_PIA_PASSWORD
VPN_PIA_PREFERRED_REGION=belgium # optional

Since port forwarding is disabled in some of the regions supported by PIA VPN, you might want to also set VPN_PIA_PREFERRED_REGION. You can see all available regions in docker/appdata/qbittorrent/wireguard/pia-regions.json. This file will be created the first time you run the container after setting your PIA username and password.

docker-compose.yml

Uncomment the devices section in qbittorrent:

devices:
  - /dev/net/tun:/dev/net/tun

Add the following variables to the environment section:

VPN_PIA_USER=${VPN_PIA_USER}
VPN_PIA_PASS=${VPN_PIA_PASS}
VPN_PIA_PREFERRED_REGION=${VPN_PIA_PREFERRED_REGION}

Here’s how your qBittorrent container definition should look:

qbittorrent:
  container_name: qbittorrent
  image: hotio/qbittorrent:latest
  restart: unless-stopped
  logging:
    driver: json-file
    options:
      max-file: ${DOCKERLOGGING_MAXFILE}
      max-size: ${DOCKERLOGGING_MAXSIZE}
  labels:
    - org.hotio.pullio.update=${PULLIO_UPDATE}
    - org.hotio.pullio.notify=${PULLIO_NOTIFY}
    - org.hotio.pullio.discord.webhook=${PULLIO_DISCORD_WEBHOOK}
  ports:
    - ${QBITTORRENT_WEBUI_PORT}:${QBITTORRENT_WEBUI_PORT}
    - ${QBITTORRENT_PRIVOXY_PORT}:${QBITTORRENT_PRIVOXY_PORT}
  cap_add:
    - NET_ADMIN
  devices:                              
    - /dev/net/tun:/dev/net/tun         
  sysctls:
    - net.ipv4.conf.all.src_valid_mark=1
    - net.ipv6.conf.all.disable_ipv6=1  
  environment:
    - PUID=${PUID}
    - PGID=${PGID}
    - TZ=${TZ}
    - UMASK=002
    - VPN_ENABLED=${VPN_ENABLED}
    - VPN_FIREWALL_TYPE=legacy
    - VPN_PROVIDER=${VPN_PROVIDER}
    - VPN_LAN_NETWORK=${LAN_NETWORK}
    - VPN_CONF=wg0-fix
    - VPN_AUTO_PORT_FORWARD=${PORT_FORWARD}
    - VPN_PIA_USER=${VPN_PIA_USER}
    - VPN_PIA_PASS=${VPN_PIA_PASS}
    - VPN_PIA_PREFERRED_REGION=${VPN_PIA_PREFERRED_REGION}
    - VPN_HEALTHCHECK_ENABLED=false
    - PRIVOXY_ENABLED=${QBITTORRENT_ENABLE_PRIVOXY}
    - WEBUI_PORTS=${QBITTORRENT_WEBUI_PORT}/tcp,${QBITTORRENT_WEBUI_PORT}/udp 
  dns:
    - 1.1.1.1
    - 8.8.8.8
  volumes:
    - /etc/localtime:/etc/localtime:ro
    - ${DOCKERCONFDIR}/qbittorrent:/config:rw
    - ${DOCKERSTORAGEDIR}/torrents:/data/torrents:rw

Setting up tun service

/dev/net/tun is a kernel module that provides a network tunnel interface. On Synology NAS systems, it’s used by VPN applications and other networking tools like qBittorrent with VPN functionality.

Installing the Tun Service for Synology and VPN

Testing Changes

With everything done, you need to try running the container with the latest changes: sudo docker-compose up --force-recreate qbittorrent

Here’s a sample output from a successful startup:

qbittorrent  | s6-rc: info: service init-wireguard successfully started
qbittorrent  | s6-rc: info: service service-qbittorrent: starting
qbittorrent  | s6-rc: info: service service-pia: starting
qbittorrent  | s6-rc: info: service service-forwarder: starting
qbittorrent  | s6-rc: info: service service-qbittorrent successfully started
qbittorrent  | s6-rc: info: service service-pia successfully started
qbittorrent  | s6-rc: info: service service-forwarder successfully started
qbittorrent  | s6-rc: info: service legacy-services: starting
qbittorrent  | [INF] [2025-04-12 20:23:44] [PIA] Fetching new forwarded port...
qbittorrent  | s6-rc: info: service legacy-services successfully started
qbittorrent  | [INF] [2025-04-12 20:23:44] [PIA] Forwarded port will expire at [2025-06-14T06:23:44.166007524Z].
qbittorrent  | 
qbittorrent  | *** Legal Notice ***
qbittorrent  | qBittorrent is a file sharing program. When you run a torrent, its data will be made available to others by means of upload. Any content you share is your sole responsibility.
qbittorrent  | 
qbittorrent  | If you have read the legal notice, you can use command line option `--confirm-legal-notice` to suppress this message.
qbittorrent  | 
qbittorrent  | WebUI will be started shortly after internal preparations. Please wait...
qbittorrent  | 
qbittorrent  | [INF] [2025-04-12 20:23:54] [VPN] Forwarded port is [REDACTED].
qbittorrent  | 
qbittorrent  | ******** Information ********
qbittorrent  | To control qBittorrent, access the WebUI at: http://localhost:8080
qbittorrent  | 
qbittorrent  | [INF] [2025-04-12 20:24:04] [QBITTORRENT] Updated forwarded port to [REDACTED].

Troubleshooting

The only issue I’ve encountered was with the /dev/net/tun module. It had overly restrictive permission settings:

ls -al /dev/net/tun
# Overly restrictive; should return `crw-rw---- root root`
crw------- 1 root root 10, 200 Feb 13 02:14 /dev/net/tun

The qBittorrent container needs at least 660 permission. You can fix that by executing:

sudo chmod 660 /dev/net/tun  # Allow root group access

Verifying VPN Works

To verify that the qBittorrent container is hidden behind a VPN, you can use IP/DNS Detect (Torrent Address detection).

Resources

• hotio/qbittorrent

Prerequisites

• Docker installed on your system (follow this Synology setup guide)

Installation

Append this configuration to your docker-compose.yml file:

  homarr:
      container_name: homarr
      image: ghcr.io/ajnart/homarr:latest
      restart: unless-stopped
      logging:
        driver: json-file
        options:
          max-file: ${DOCKERLOGGING_MAXFILE}
          max-size: ${DOCKERLOGGING_MAXSIZE}
      environment:
        - PUID=${PUID}
        - PGID=${PGID}
        - TZ=${TZ}
      volumes:
        - ${DOCKERCONFDIR}/homarr/configs:/app/data/configs
        - ${DOCKERCONFDIR}/homarr/icons:/app/public/icons
        - ${DOCKERCONFDIR}/homarr/data:/data
      ports:
        - 7575:7575

Start the container by running this command in your docker directory (typically /volume1/docker/appdata):

docker compose up -d

This launches Homarr in detached mode (running in the background).

Resources

• Official Homarr Installation Guide

Even with killswitch enabled, I wanted to verify beyond the UI’s “Firewalled” status that my torrent traffic was actually routing through the VPN.

To check this, SSH into your Synology NAS and run:

sudo docker exec qbittorrent curl ifconfig.me

This command retrieves the container’s public IP address. If it matches your VPN IP address rather than your real IP, you’ve confirmed that the container’s traffic is properly routing through the VPN.

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

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