家里的群晖 NAS 上运行着 DSM、Docker、影音和其他自建服务。在局域网中访问很方便，但外出后如何继续用同一个 HTTPS 域名访问这些服务，而且不暴露公网端口？
我最终采用的方案是：群晖通过 Tailscale 发布家庭子网路由；FlClash 使用 Mihomo 内置的 type: tailscale 节点，按规则把家庭内网请求送进 Tailscale。 实际部署中还踩到了「IP 能访问、域名却报 SERVFAIL」的坑，最后通过 Mihomo 内核 Hosts 解决。
一、方案与网络拓扑
本文的示例环境如下（均为演示地址，按自己的环境替换）：
| 项目 | 示例值 |
|---|---|
| 家庭局域网网段 | 192.168.123.0/24 |
| 群晖 NAS 局域网 IP | 192.168.123.163 |
| NAS 访问域名 | nas.example.com |
| 群晖 HTTPS 反向代理端口 | 443 |
| FlClash 家庭网络策略组 | Home |
最终实现的链路：
1 | Android / Mac |
与普通的「通过公网 IP + DDNS + 端口映射」方案相比，这套方案不需要把 NAS 的业务端口暴露在公网，也不要求家里有可入站的公网 IP。
两者分工很明确：Tailscale 负责组网和访问家庭子网，Mihomo 负责流量分流。
二、群晖配置 Tailscale 子网路由
1. 安装 Tailscale
从 Tailscale 官方 Synology SPK 下载页 下载适合群晖 CPU 架构与 DSM 版本的安装包。
进入 DSM「套件中心 → 手动安装」，安装后登录自己的 Tailnet。
2. 启用 SSH 并发布子网
在 DSM「控制面板 → 终端机和 SNMP」中启用 SSH，在电脑终端连接群晖：
1 | ssh 管理员用户名@192.168.123.163 |
发布家庭局域网网段：
1 | sudo tailscale set --advertise-routes=192.168.123.0/24 |
这表示其他授权的 Tailscale 设备可以通过群晖访问 192.168.123.0/24 中的设备，包括没有单独安装 Tailscale 的路由器、摄像头以及 Docker 服务。
3. 在后台批准路由
打开 Tailscale Machines，找到群晖，进入子网路由设置并批准：
1 | 192.168.123.0/24 |
还需要确认 Tailnet 的 ACL/Grants、群晖防火墙和目标设备防火墙允许相应流量。
提示： 在 DSM 7 环境下，某些 Ping 测试不一定能代表实际 TCP/UDP 可达性。优先使用 Web、SSH 等实际服务测试。
三、配置群晖 HTTPS 反向代理
理想的访问方式是：
1 | https://nas.example.com |
而不是记住：
1 | https://192.168.123.163:5001 |
进入 DSM「控制面板 → 登录门户 → 高级 → 反向代理」，添加一条规则。以代理到 DSM 登录页为例：
| 配置项 | 示例 |
|---|---|
| 来源协议 | HTTPS |
| 来源主机名 | nas.example.com |
| 来源端口 | 443 |
| 目标协议 | HTTPS |
| 目标主机名 | 127.0.0.1 |
| 目标端口 | 5001 |
不同服务需换成其对应的后端地址及端口。如果使用了 HTTPS 后端自签证书，还要考虑反向代理的证书验证设置。
为 nas.example.com 绑定有效的 TLS 证书；不开放公网 80/443 的情况下，可使用 DNS-01 验证签发或续期证书。
为什么 IP 直连 443 可能不工作？ 因为浏览器使用域名访问时，会在 TLS 握手中提供 SNI，并在 HTTP 中发送 Host；反向代理可能依靠这些信息选择服务。因此，https://192.168.123.163 和 https://nas.example.com 不一定等价。
四、FlClash 配置内置 Tailscale 出站
1. 生成 Auth Key
登录 Tailscale Keys，生成用于首次注册的 Auth Key。
单台设备通常选择一次性 Key；要注册多台独立设备时，可以按需使用 Reusable，但必须妥善保管，避免泄露。Reusable Auth Key 并不意味着多台设备可以共用同一份已注册节点状态。
2. 添加 type: tailscale 节点
在已有 Mihomo YAML 的 proxies 列表内追加节点（不要覆盖原有 proxies）：
1 | - name: TS-HOME |
核心参数：
| 参数 | 含义 |
|---|---|
type: tailscale |
Mihomo 内置 Tailscale 出站 |
hostname |
在 Tailnet 中显示的设备名 |
auth-key |
首次注册使用的密钥 |
state-dir |
节点身份及状态目录 |
accept-routes: true |
接受群晖发布的家庭子网路由 |
udp: true |
启用 UDP 支持 |
特别注意：Mac 和 Android 使用不同的状态目录和节点名称，例如 flclash-mac、flclash-phone。不要跨设备复制已注册的 Tailscale 状态数据，否则可能出现 Duplicate node key。
3. 添加 Home 策略组
在已有的 proxy-groups 列表中追加：
1 | - name: Home |
在 FlClash 中，将 Home 选择为 TS-HOME。
4. 添加家庭域名与网段规则
将下面的条目插入已有 rules 列表中，并放在通用 MATCH、私有地址直连等规则之前：
1 | - DOMAIN,nas.example.com,Home |
这样实现：
nas.example.com→ Tailscale；192.168.123.x→ Tailscale；- 其他
192.168.x.x→ 本地直连。
no-resolve 的意思是：为匹配这条 IP-CIDR 规则，不主动触发额外的 DNS 解析；它不是「禁止 DNS」开关。
注意系统代理和 TUN 有不同的接管范围。Mac 系统代理模式下，如果系统已经把 192.168.0.0/16 列入代理绕过列表，流量可能在进入 Mihomo 之前就被绕过，因此单靠分流规则无法挽回。
五、排障：IP 能访问，域名却打不开
实际配置时，我遇到了一种很奇怪的现象：
- FlClash 内置 Tailscale 访问
192.168.123.163正常； - 独立 Tailscale 客户端访问域名正常；
- FlClash 的 SSH 出站访问同一个域名正常；
- 但 FlClash 内置
type: tailscale访问该域名时，会出现超时、TLS 握手中断或SERVFAIL。
1. 查看 FlClash 连接记录
连接页面显示目标类似：
1 | tcp://nas.example.com/192.168.123.163:443 |
说明域名规则命中了预期的出站，但不代表底层连接已经成功。
2. 对比正常解析与强制指定 IP
在手机 Termux 中运行：
1 | curl -4 -Iv https://nas.example.com/ |
当时可以看到 Mihomo 分配的 Fake-IP，例如：
1 | IPv4: 198.18.0.7 |
198.18.0.7 是 Mihomo 的 Fake-IP 虚拟地址，出现这个地址本身不等于故障。
再强制指定真实局域网 IP，同时保留 HTTPS 域名：
1 | curl -Iv \ |
这次连接正常，出现了：
1 | SSL certificate verify ok. |
这说明该次测试中，设备能够到达目标 IP，TLS 证书匹配，反向代理也正常。需要继续排查的是普通域名请求的 DNS 或出站拨号路径。
3. SERVFAIL 的线索
FlClash 曾出现：
1 | all DNS requests failed, first error: server failure: SERVFAIL |
Mihomo 有一个与此现象类似的报告：Issue #3375：Tailscale 出站重新解析域名。在部分实现/版本中，Tailscale 出站可能再次解析域名；如果其解析器没有可用上游，就可能连接失败。
注意： 这个 Issue 提供了很有价值的解释线索，但不能仅靠一次 SERVFAIL 日志就认定所有失败均由同一个 Bug 引起。
六、最终有效的修复：Mihomo 内核 Hosts
对我的环境来说，最简单、最稳定的办法，是在 FlClash 的 Mihomo 内核 Hosts 中直接写入域名和 NAS 私有 IP 的映射：
1 | hosts: |
有多个家庭域名时也可以继续添加：
1 | hosts: |
如果已有顶层 dns: 配置，请确保没有禁用 Hosts：
1 | dns: |
这是配置片段：如果原文件已有 dns:、hosts:，应当合并相应字段，不能复制出重复的顶层 YAML 键。
为什么内核 Hosts 能修复？
排障时曾经出现的失败链路：
1 | 访问 nas.example.com |
设置 Hosts 后，在相关解析路径中可以直接获得：
1 | nas.example.com → 192.168.123.163 |
从而避免这条查询再依赖失败的 DNS 上游。与此同时，浏览器访问的依然是 https://nas.example.com，所以 SNI、证书匹配和反向代理的 Host 路由不受影响。
这次实测验证有效的改动，是 Mihomo 内核 Hosts，而不是简单增加 DOMAIN 规则，也不是关闭全局 Fake-IP。
备选方案：Tailscale Split DNS
Tailscale 管理后台也支持配置域名专用 DNS：
https://login.tailscale.com/admin/dns
可以在 Nameservers 中添加 Custom DNS，并限定到 example.com，前提是该 DNS 服务器确实能够解析出正确的家庭私有 IP。
不过，Tailscale 的 DNS 设置属于 Tailnet 级别，可能影响其他启用了「Use Tailscale DNS settings」的客户端；在同时运行独立 Tailscale 和其他 TUN 代理时还可能遇到 DNS/路由冲突。
因此，对于仅访问少量家庭域名的场景，我更推荐在 FlClash 的内核 Hosts 中管理映射。
七、Mac 和 Android 的使用区别
Android：主要使用 FlClash 内置 Tailscale
Android 端的 FlClash 通常通过系统 VPN 接口接管流量。配置 TS-HOME 后，直接让相应规则选择 Home 即可，无须再同时运行另一套独立 Tailscale VPN。
Mac：两种方式任选其一
方案 A：FlClash TUN 开启，独立 Tailscale 关闭。
这是本文实际采用的整合方式：
- FlClash 接管目标应用的网络流量；
- 访问家庭内网的请求走
TS-HOME； - 普通互联网继续按原有规则分流。
方案 B：独立 Tailscale 开启，FlClash TUN 关闭，使用系统代理。
此时独立 Tailscale 负责系统路由。对已经可以通过 macOS 路由到达的家庭 IP，FlClash 规则可以视情况选择 DIRECT，由系统送入独立 Tailscale。但这种方式可能受到 macOS 的代理绕过列表影响。
不建议在没有规划的情况下，让两套 TUN/VPN 同时修改重叠网段的路由和 DNS。
八、常见问题速查
| 现象 | 排查方向 |
|---|---|
| Tailscale 节点无法登录 | Auth Key、节点状态、Tailnet 设备列表 |
Duplicate node key |
是否跨设备复制了已注册的状态目录 |
| 家庭内网 IP 不通 | accept-routes、子网路由批准、ACL、防火墙 |
| IP 通但域名不通 | 内核 Hosts、DNS、出站拨号错误日志 |
DNS 返回 198.18.x.x |
可能是正常 Fake-IP，结合实际连接判断 |
出现 SERVFAIL |
区分 Mihomo DNS 和 Tailscale 内部解析器 |
| HTTPS 报证书错误或返回错误站点 | 检查 SNI、Host、反向代理和证书 |
| Mac 访问内网不正常 | TUN、系统代理绕过列表和策略组选择 |
| 换设备后无法连接 | 重新注册节点，避免共用状态目录 |
额外建议：为群晖在路由器上设置 DHCP 地址保留，避免 IP 变化导致内核 Hosts 失效；为 Tailnet 设置适当的访问权限；不要在公开仓库提交真实 Auth Key、节点认证信息或完整代理配置。
九、总结
最初以为，只要能从外网访问家庭内网 IP，就能自然地通过域名访问群晖。实际部署后才发现，组网、分流、DNS 和 HTTPS 反向代理是不同层次的问题。
这套方案最终只需要四个关键步骤：
- 群晖通过 Tailscale 发布
192.168.123.0/24子网路由； - FlClash 添加
type: tailscale节点并开启accept-routes； - 使用
DOMAIN和IP-CIDR将家庭内网流量指向 Home； - 用 Mihomo 内核 Hosts 让 NAS 域名稳定解析到私有 IP。
最终，无论在 Android 还是 Mac 上，都可以通过统一的 HTTPS 域名访问家里的 NAS，而不必在路由器上对公网开放 NAS 的业务端口，也不必为了访问家庭网络频繁切换独立 VPN。
参考资料
- Tailscale：Synology 集成指南
- Tailscale：子网路由配置
- Tailscale：DNS 设置
- Mihomo：Tailscale 出站
- Mihomo：Hosts
- Mihomo Issue #3375
本文根据 2026 年 10 月底的实际部署及故障排查整理。不同 FlClash/Mihomo 版本的行为可能存在差异，具体以正在使用的内核及官方文档为准。
