群晖 DSM 7 Docker 部署 Mihomo：局域网网关指到 NAS

1 适用场景与能力边界

当你已经有一台长期在线的群晖，并且主路由仍是运营商或厂商原装固件、不方便刷 OpenWrt 时，把代理核心挪到 NAS 上，用旁路网关思路承接部分或全部局域网流量，是成本可控、可回滚的方案。核心软件选用 Mihomo，是因为它与常见 Clash 订阅、规则写法高度兼容，便于沿用机场提供的 YAML 或自行维护的 Rule Provider。

需要提前对齐预期：「把默认网关改成 NAS」并不等于「只填 HTTP 代理地址」。网关变更后，终端会把跨网段访问的 IP 报文先交给 NAS，NAS 必须具备转发能力，并且代理栈要能接管这些流量——常见实现要么走 TUN 栈配合系统路由，要么在宿主机上做透明重定向到 Mihomo 的 redir-port 一类端口。群晖内核与 Docker 的权限模型和家用路由器不同，一键开箱程度通常弱于《OpenClash 与 OpenWrt 透明代理》那类专用插件，但换来的是不刷机与 DSM 生态内的可维护性。

合规与责任边界 请仅在有权使用的网络环境中操作；遵守当地法律与运营商条款。本文仅作技术说明，不提供任何绕过监管或访问非法内容的指引。

2 网络拓扑：主路由仍是 DHCP 服务器

典型家庭拓扑是：光猫或主路由在 192.168.x.1，DHCP 仍由主路由发放；NAS 拿到固定局域网地址，例如 192.168.1.50。旁路模式下，不要让 NAS 与主路由同时争抢 DHCP（除非你非常清楚双 DHCP 的隔离与优先级）。更稳妥的做法是：主路由继续下发网关为自身，仅对需要代理的设备手动把网关改为 NAS；或在主路由的 DHCP「高级选项」里为特定 MAC 绑定网关为 NAS。

当终端网关指向 NAS 时，NAS 必须能把「去往互联网」的流量再送回到主路由（同一二层下的默认下一跳仍是主路由），否则会出现单臂旁路常见的回程或环路问题。简言之：NAS 要知道「去外网仍走 192.168.1.1」，而「哪些会话进 Mihomo」由内核与 Mihomo 的路由或 iptables 规则决定。若你对 Linux 上 systemd 部署更熟，可先对照《Linux 安装 Mihomo 并开机自启》理解 YAML 与进程关系，再回到 DSM 的 Docker 封装里对照端口与权限。

3 DSM 7 与 Docker 准备

在 DSM 7 中通过 Container Manager（或套件中心的 Docker）拉镜像前，建议先完成三件事。第一，在控制面板 → 网络 → 网络界面里为 NAS 绑定静态 IP，避免 DHCP 租约变化后全家设备网关指向失效地址。第二，在控制面板 → 终端机和 SNMP中按需开启 SSH，便于后续用 sysctl 或排障命令确认IP 转发是否生效。第三，记录 NAS 在局域网中的地址与主路由地址，后面写 Mihomo 的 default-interface、静态路由或防火墙规则时都会用到。

套件与权限方面，确保运行 Docker 的存储空间充足；为 Mihomo 单独建共享文件夹（例如 /volume1/docker/mihomo），其中至少包含 config.yaml 以及后续可能下载的 geoip、geosite 等资源。这样配置与日志都在卷挂载目录内，容器重建不会丢订阅与自定义规则。

4 镜像、数据卷与 Compose 示例

Mihomo 官方容器镜像通常以 metacubex/mihomo 为仓库名（具体 tag 以镜像页为准）。在群晖上既可用图形界面创建容器，也可在某一共享目录放置 docker-compose.yml 后用任务计划或 SSH 执行 docker compose up -d。若你希望局域网设备直接连到 Mihomo 的 混合端口或启用 TUN，常见做法是使用 network_mode: host，让容器与宿主机共用网络命名空间，减少端口映射断层；代价是端口冲突排查要在 NAS 全局视角下进行。

docker-compose.yml (example)

services:
  mihomo:
    image: metacubex/mihomo:latest
    container_name: mihomo
    restart: unless-stopped
    network_mode: host
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    volumes:
      # host path: map to Mihomo config dir inside container
      - /volume1/docker/mihomo:/root/.config/mihomo

若你的环境无法使用 host 网络（例如与其他服务端口冲突），可退回桥接模式并显式映射 7890（HTTP/SOCKS 混合）、9090（REST API）等端口，但透明接管「改网关后的全部 IP 流量」往往仍需要 host 或额外的 iptables 在宿主机上配合，这一点与仅在本机开系统代理完全不同。

端口规划小结

混合端口（如 7890）：终端手动配置 HTTP/HTTPS 代理时常用；与「改网关」组合时，多用于验证阶段。
外部控制器（如 9090）：给 Web 面板或脚本用；安全要求见《Mihomo 外部控制器与 Yacd》。
透明代理端口（如 redir-port）：与网关方案更贴近，但需在 NAS 上维护转发规则，升级 DSM 后要复查是否被重置。

5 Mihomo 配置要点：Clash 兼容与局域网访问

在 config.yaml 根级，至少需要关注与「全屋设备连得上」直接相关的几项。mixed-port 提供 HTTP 与 SOCKS 在同一端口上的混合入口；allow-lan: true 允许非本机地址访问这些端口，否则即使防火墙放行，连接也会在应用层被拒绝。bind-address 若设为 * 或具体局域网 IP，决定监听范围；若仅监听 127.0.0.1，则其他设备无法把 NAS 当作代理入口。

YAML (excerpt)

mixed-port: 7890
allow-lan: true
bind-address: '*'
external-controller: 0.0.0.0:9090
secret: "replace-with-a-long-random-secret"

# TUN example (paths and stack depend on your build; verify upstream docs)
tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

TUN 段落是否启用、字段名与取值请以当前 Mihomo 版本文档为准；群晖内核版本与模块能力会影响启动是否报错。若 TUN 暂时无法工作，可退而求其次：保持主路由为网关，仅在需要代理的设备上使用自动代理脚本或分应用代理，但这已偏离「改默认网关」主线，适合作为阶段性过渡。

不要把 external-controller 裸暴露在公网 0.0.0.0:9090 仅建议在受信任的家庭局域网使用，并配合强 secret 与 DSM 防火墙限制源地址；远程管理优先 VPN 或 SSH 隧道。

6 内核转发、TUN 与 DSM 防火墙

当网关指向 NAS 后，IPv4 转发几乎是必查项。可通过 SSH 在宿主机执行 sysctl net.ipv4.ip_forward 查看是否为 1；若为 0，需要在可持久化的配置中开启（不同 DSM 小版本存放位置可能不同，升级后务必复查）。没有转发时，常见现象是终端拿不到外网或仅能 ping 通 NAS 而不能访问公网。

DSM 防火墙规则需要在「允许 Docker 与局域网互访」与「缩小攻击面」之间折中。至少放行来自内网网段到 Mihomo 监听端口的入站连接；若你使用 Container Manager 的桥接网络，还要留意 Docker 子网与 DSM 防火墙规则的交互。修改规则后，用手机流量断开再连 Wi-Fi，确认新规则已生效。

透明重定向若依赖 iptables，要意识到 DSM 更新或套件重启可能改变链路顺序；建议把自定义规则写入你可追踪的启动脚本，并在每次大版本升级后做一次连通性回归。这与路由器上 OpenClash 一键维护的体感不同，却是消费级 NAS方案的常态成本。

7 把默认网关指到 NAS：手动与 DHCP

手动网关适合先在一台电脑上验证：在 Windows「以太网属性 → IPv4」或 macOS 网络详情里，把默认网关改为 NAS IP，DNS 可先填主路由或公共 DNS，再观察浏览器与外网应用是否正常。Android 与 iOS 对静态 IP 与网关的入口因厂商而异，部分机型仅允许在已连接的 Wi-Fi 上逐项填写。

DHCP 高级选项适合「希望某一类设备自动走 NAS」：若主路由支持为特定 MAC 下发选项 3（路由器/网关），可将网关改为 NAS 而 DNS 仍由路由下发或由 Mihomo 接管。务必避免同一网段内两台 DHCP 服务器不知情地并存，否则终端可能拿到错误网关或重复地址。

若家中还有访客网络或 AP 隔离，确认隔离策略不会阻止终端访问 NAS 上的代理端口；否则表现为「网关已改但始终超时」。

8 验证步骤与常见问题

分步验证：先在终端上仅设置系统代理指向 NAS_IP:7890，确认订阅与规则无误，再进入「改网关」阶段，避免两个问题叠在一起难查。
DNS 异常：若网页打不开但 ping IP 正常，多为 DNS 未走代理或Fake-IP与本地解析冲突；可对照站内 DNS 专题调整 dns 段与分流。
仅 NAS 本机正常：检查 allow-lan、监听地址与 DSM 防火墙；再用局域网另一台设备 curl 探测混合端口。
性能与温度：全屋流量经 NAS 时，CPU 与磁盘唤醒频率会上升；注意散热与节能策略，避免硬盘频繁启停影响体验。

排错时建议打开 Mihomo 日志级别为 info 或 debug 的短期窗口，观察连接建立阶段是卡在入站还是出站；同时用主路由管理界面确认 NAS 仍持有正确 ARP 表项。若你希望图形客户端与 NAS 方案互为备份，个人电脑与手机仍可从本站下载页安装各平台 Clash 系客户端，在 NAS 维护或升级期间快速切回本机代理。

9 总结

在 群晖 DSM 7 上用 Docker 跑 Mihomo，本质是把与 Clash 兼容的核心搬到长期在线的 NAS 上；要让手机、电脑通过默认网关获得接近「全屋透明」的体验，需要同时搞定卷挂载与配置、旁路网关下的转发与防火墙，以及 DHCP 或手动网关的一致策略。相比专业软路由方案，你在 DSM 上付出的是更细的手动维护，换来的是不刷机与对现有拓扑的尊重。

相比仅依赖桌面客户端，NAS 方案更适合「多设备、希望入口统一」的家庭；而相比路由器插件，DSM 上的权限与内核约束更多，更强调分步验证与可回滚。若你还需要在浏览器里远程切换节点，可把外部控制器与 Yacd 一并纳入同一套安全边界。

个人终端上，图形化 Clash 客户端在稳定性与易用性上往往更省心：订阅更新、系统代理切换与 TUN 开关都集成在界面里，与 NAS 网关方案形成互补而非替代。若你主要在电脑与手机上上网，不妨在 NAS 稳定运行后，仍保留一套本机客户端作备用。

→ 立即免费下载 Clash，开启流畅上网新体验

群晖 DSM 7 Docker 部署 Mihomo：
局域网设备把网关指到 NAS 的实操步骤