Synology DSM 7 Docker Mihomo setup:
Point LAN phones and PCs to your NAS as default gateway

1 Why Synology DSM 7, Docker, and a gateway change belong in one story

Home labs evolve in stages. First you buy a Synology NAS for backups and media. Then you notice it is always on, wired to gigabit Ethernet, and already running DSM 7 with a mature Docker stack called Container Manager. Meanwhile your Wi-Fi router might be locked down by the ISP, missing good Clash-compatible firmware, or simply not something you want to risk bricking. The compromise readers keep asking for is: keep the consumer router as the Wi-Fi access point, but move “smart routing” to the NAS, then tell phones and laptops to use the NAS IP as their default gateway so everyday apps inherit policy without per-app proxy toggles. That is the NAS proxy pattern as a side gateway—parallel to the main router, not a wholesale replacement.

Mihomo implements the same YAML vocabulary you already know from desktop Clash clients, which lowers migration cost. You can reuse subscription URLs, rule providers, and DNS blocks you tuned on a PC. The operational difference is Linux networking on the appliance: you must think about kernel forwarding, Docker networking modes, published ports, and whether you are doing simple mixed-port proxying versus full-capture TUN transparent routing. DSM is not a vanilla Ubuntu server—kernel modules, permission boundaries, and the Synology firewall UI all participate. This guide stays practical: enough theory to avoid black holes, enough checklists to finish a Saturday deployment, and explicit warnings where Synology hardware varies.

Legal and policy disclaimer in plain language: transparent interception of traffic on a network you do not own or without informed consent is not acceptable. Apply these steps only on networks you administer, with devices you control, and in compliance with local law and ISP terms. The article assumes you already have legitimate outbound credentials from a provider you trust.

2 Keep the router; teach clients to hop through the NAS

Your existing router still hands out DHCP leases, advertises DNS if you want, and owns the path to the modem. You are not flashing OpenWrt or installing OpenClash on it—those topics are covered elsewhere on this site. Instead you pin the NAS to a static LAN address (DHCP reservation is ideal), run Mihomo there, then either (a) configure DHCP option 3 so participating hosts receive the NAS as their default gateway, or (b) leave DHCP alone and manually set gateway and DNS on each device you want routed. Option (a) scales to guests and consoles; option (b) is safer while you experiment because one mis-click does not take the whole house offline.

Changing the default gateway alone does not magically proxy TCP sessions unless something on the NAS answers ARP for those flows and knows how to forward or redirect them into Mihomo. Two common tiers exist. Tier one is “explicit proxy”: clients still use the router as L3 gateway, but browsers or OS proxy settings point HTTP and SOCKS to nas-ip:7890. That is reliable inside Docker bridge networking because you only publish host ports. Tier two is “transparent side gateway”: the NAS becomes the next hop for off-subnet traffic, enables IPv4 forwarding, and Mihomo runs with TUN plus allow-lan: true so LAN devices are permitted to enter the tunnel policy. Tier two usually requires host networking or extra capabilities so the container can install routes the same way a bare-metal Linux gateway would. Container Manager on Intel-based Synology units typically supports host mode; some entry-level ARM models are pickier—verify before you commit your network design to TUN-in-Docker.

If you are comparing mental models, our Linux Mihomo systemd guide explains the same core YAML and listener knobs without Synology packaging. Read it when you want the “pure Linux” reference, then return here for DSM-specific firewall screens and Docker volume paths.

3 Prerequisites before you touch Container Manager

Update DSM 7 to a current patch level and install Container Manager from Package Center if it is not already present. Create a shared folder such as docker for compose projects, and beneath it a directory like mihomo/config where config.yaml will live on disk outside the container lifecycle. Assign the NAS a reserved IPv4 address on the LAN subnet so downstream clients never chase a moving target when they aim their default gateway at you. Document the upstream router IP (often .1) because Mihomo still needs a path to the internet; the NAS will forward through that neighbor unless you are replacing the entire upstream path, which this guide does not assume.

Decide whether you require TUN. If your goal is only to centralize HTTP/SOCKS for browsers and a few apps, you can skip TUN, skip elevated capabilities, and use bridged networking with explicit port mappings for 7890 (mixed), 9090 (external controller), and optionally 1053 for DNS inbound from LAN. If your goal is true “phone uses NAS as gateway and everything works,” plan for TUN, NET_ADMIN, access to /dev/net/tun, and likely network_mode: host in Docker Compose so Mihomo sees the same interfaces as DSM. Mixed topologies—some devices proxied, some not—are normal; do not assume one YAML fits every VLAN without testing.

Back up the NAS configuration in Control Panel before you experiment. Mistakes in gateway experiments can lock you out of DSM from Wi-Fi until you plug a laptop into Ethernet and revert settings. Keep a console cable or IPMI? Consumer Synology devices do not ship with out-of-band management, so conservative change windows matter.

4 Docker image selection and a compose baseline

Mihomo publishes official release binaries; community-maintained container images wrap those builds for repeatable upgrades. Pick an image tag you trust—ideally one that tracks upstream Mihomo closely—and pin the digest after first pull if you want supply-chain stability. Synology’s registry mirror settings sometimes lag; if pulls stall, switch Docker Hub region or add a mirror in Container Manager registry settings. Always verify image signatures or checksum policies match your personal threat model; this article cannot endorse a single third-party maintainer for every jurisdiction.

The compose snippet below illustrates a host-network deployment suitable for Intel models where Container Manager allows it. It bind-mounts your persistent folder to /root/.config/mihomo, which is the conventional config root inside many Mihomo containers. Adjust the left-hand host path to the shared folder you created. The cap_add stanza grants NET_ADMIN, which TUN mode needs to manipulate routes. If you cannot use host networking on your model, delete network_mode: host, add explicit ports mappings, and prefer mixed-port proxying until you validate advanced bridging.

version: "3.8"
services:
  mihomo:
    image: metacubex/mihomo:latest
    container_name: mihomo
    restart: unless-stopped
    network_mode: host
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - /volume1/docker/mihomo:/root/.config/mihomo
    environment:
      - TZ=Etc/UTC

After docker compose up -d, tail logs from Container Manager or SSH with docker logs -f mihomo. A clean boot prints listener lines without YAML parse errors. If the container instantly restarts, open the log, fix the YAML mistake, and redeploy—Mihomo fails fast on invalid keys just like other Clash-compatible cores.

5 Volume mounts, permissions, and where DSM hides files

Synology maps shared folders to /volume1/… paths on the btrfs array. Container bind mounts reference those absolute paths even though File Station shows friendly names. Keep config.yaml, rule snippets, and downloaded geoip.dat / geosite.dat files together so upgrades never orphan assets. If you import large rule providers, monitor free space; spinning disks can bottleneck writes during provider refresh storms. Schedule provider intervals sanely—hourly pulls of multi-megabyte lists are rarely necessary in a home deployment.

Permissions are simpler than multi-user Linux servers because the container usually runs as root inside its namespace. Still, avoid world-readable files for secrets: restrict File Station shares so guest accounts cannot read your subscription URLs. When you edit YAML from a Windows workstation via SMB, mind line endings; CRLF files occasionally confuse parsers if a bad editor strips UTF-8 BOM incorrectly. Use VS Code remote editing or SSH plus vim when possible.

For geodata updates, you can reuse the same HTTPS sources described in our geoip and geosite update article—point geox-url keys at mirrors you trust, then restart Mihomo after major jumps so rule evaluation stays coherent.

6 Clash-compatible YAML tuned for LAN gateway duty

The skeleton below is intentionally similar to our Linux guide so you can diff changes quickly. allow-lan: true is mandatory when phones and PCs will connect from private RFC1918 addresses. Bind listeners to 0.0.0.0 inside the container (or rely on host mode) so traffic arriving at the NAS IP actually reaches Mihomo. Mixed port 7890 serves both HTTP and SOCKS clients; add DNS listeners if you want the NAS to answer DNS from LAN. Replace placeholder proxies with your real subscription or static nodes; until you do, keep proxy-groups pointed at DIRECT so you do not create a black hole during first boot.

mixed-port: 7890
allow-lan: true
mode: rule
log-level: info
external-controller: 0.0.0.0:9090
secret: "replace-with-long-random"

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
  fallback:
    - https://dns.google/dns-query

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

proxies: []

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - MATCH,Proxy

TUN stanza values vary by Mihomo version; consult upstream release notes when upgrading across major versions. If you temporarily disable TUN for debugging, remember to revert after you finish—otherwise LAN clients that pointed their default gateway at the NAS will forward packets without interception, which looks like “the proxy died” even though the process is healthy.

7 Synology firewall rules that actually help

DSM ships a host firewall separate from Mihomo’s internal rule engine. After publishing ports, open Control Panel → Security → Firewall, create a limited rule that allows LAN subnet sources (for example 192.168.1.0/24) to reach TCP 7890 and 9090 on the NAS, and UDP/TCP 1053 if you expose DNS. Deny the same ports from the guest VLAN or untrusted Wi-Fi SSIDs unless you intentionally want roaming guests to use your policy stack. Many admins also add a deny-all for 9090 from WAN interfaces if the NAS is accidentally exposed through port forwarding—double NAT does not excuse sloppy management plane exposure.

If you run QuickConnect or reverse proxies, audit whether they overlap with Mihomo management ports. Defense in depth beats assuming “obscurity through random high ports.” Combine firewall rules with strong secret tokens and, where feasible, bind the external controller to localhost only, then reach it through an SSH tunnel when you need the dashboard remotely.

Synology also offers Threat Prevention packages on certain models; aggressive IDS signatures occasionally flag long-lived TLS flows from proxy cores. If you see bizarre resets, temporarily correlate timestamps with Mihomo logs before you blame the upstream airline Wi-Fi.

8 DHCP option 3 versus manual gateway on each device

Pushing the NAS as default gateway through DHCP is convenient: every new phone inherits policy automatically. In DSM you can run DHCP Server on the NAS if it owns a subnet, but most homes already run DHCP on the Wi-Fi router. Router firmware varies wildly; look for “DHCP option,” “static route,” or “gateway override” menus. Some routers let you set per-MAC DHCP options; that is the sweet spot for piloting one laptop without touching the rest of the family. If the router cannot express option 3 per client, fall back to static IP configuration on each test device—Android and iOS both allow static IPv4 with custom gateway and DNS fields buried two screens deep.

When you push gateway via DHCP, also decide where DNS lives. If Mihomo answers on 1053, advertise that IP in DHCP option 6 so clients do not bypass your FakeIP setup with hard-coded DoH from Chrome. If you leave DNS on the router, align Mihomo’s upstream resolvers with what you expect—split-brain DNS is the primary reason “some apps work, some hang” after a gateway migration. Our DNS leak prevention article remains the deep dive; here the operational takeaway is single-resolver ownership per device during testing.

Remember the NAS itself still needs DNS to pull Docker images and geodata. DSM resolver settings are independent from what DHCP advertises to clients; verify both paths after changes.

9 Verification checklist from the LAN perspective

On a laptop configured to use the NAS gateway, run traceroute 1.1.1.1 and confirm the first hop is the NAS IPv4 address, the second hop is your main router, and subsequent hops continue outward. Then open a browser and visit an IP-check site; the reported country should match the outbound node you selected in Mihomo unless you intentionally route that domain direct. For DNS-specific validation, query a unique test hostname and watch Mihomo’s query log—if nothing appears, packets never reached the DNS listener and you still have a path issue.

Throughput testing matters on ARM Synology models: a single-core container might saturate below your ISP line rate. That is acceptable for browsing but disappointing if you aimed for 4K remuxes plus proxy simultaneously. If CPU pegs, consider moving Mihomo to a small x86 low-power box and keep the NAS for storage—honest capacity planning saves weekend rework.

When you finish validation, document the working combination: Docker compose revision, DSM firewall rule IDs, DHCP scope, and the YAML commit hash. Future you will upgrade DSM at 11 p.m. and need that map instantly.

10 Troubleshooting the usual NAS gateway failures

Clients lose all internet after changing gateway: Check that IPv4 forwarding is enabled on the NAS, that Mihomo is running with TUN if you expect interception, and that the main router still allows the NAS to NAT outbound. A quick fix is reverting DHCP or static settings to automatic, then fixing YAML offline.

Only browser traffic works: You are probably using mixed-port mode without TUN, while some apps ignore system HTTP proxies. Either enable TUN for full capture or accept per-app limitations—games and UDP voice chat often need explicit routing rules.

DSM web UI becomes unreachable: You likely collided management ports or broke host routing. Stop the container from SSH (docker stop mihomo), verify DSM listens on 5000/5001 again, then adjust compose networking before restart.

Logs show repeated restarts: Parse errors in YAML, missing /dev/net/tun, or insufficient capabilities. Remove TUN temporarily to confirm the baseline mixed-port profile loads, then add privileges incrementally.

Everything works except one streaming app: Capture the domain from Mihomo logs and add a precise rule instead of widening generic GEOIP shortcuts. The same discipline applies on routers; see our OpenClash transparent proxy piece for parallel inspiration even though this deployment stays on DSM.

11 Wrap-up

Running Mihomo on Synology DSM 7 inside Docker gives you a maintainable Clash-compatible control plane without sacrificing the stock router firmware your household already understands. Pair a pinned container image with bind-mounted YAML, open only the ports you need in the Synology firewall, then roll out default gateway changes carefully—DHCP-wide when you are confident, per-device while you learn. Treat the NAS as a deliberate side gateway with observability: logs, traceroutes, and DNS traces beat guessing when something drifts after a DSM update.

Compared with all-or-nothing VPN clients on every gadget, centralizing policy on the NAS keeps phones and laptops consistent while still letting you fall back to desktop GUIs when you travel. For day-to-day personal machines, a polished Clash app often delivers faster iteration on rules than editing remote YAML through SSH—but the NAS remains the steady house-wide backstop.

When you want installers and release notes in one place, start from our download hub; upstream GitHub remains the right venue for source and issues, not the first hop for tired family members who only need routing to behave.

→ Download Clash for free and experience the difference