近期因运营商公网IP不稳定，尝试使用 Tailscale 进行异地组网。但在开启 Subnet Router（子网路由） 功能后，发现部分局域网服务（如文档系统）出现"假死"现象，外网无法访问。本文记录了从故障复现、路由优先级分析到最终解决的全过程，并探讨了 DDNS 与 Tailscale 共存的最佳实践。
一、 故障背景 由于家庭宽带流量较大（NAS同步、视频上传、监控等），运营商频繁主动断网，导致公网IP频繁变动。为了保证远程访问的稳定性，我在 Ubuntu 软路由（作为跳板机）上部署了 Tailscale ，并开启了 Subnet Routes（子网路由） 功能，试图一劳永逸地访问整个家庭内网网段。
二、 问题复现 开启子网路由后，出现了一个奇怪的现象：
-
大部分内网IP能 ping 通。
-
特定服务无法访问：内部部署的一个文档系统，绑定了域名（通过主路由 DNS 或 Hosts 解析到内网 IP）。当通过 Tailscale 远程访问该域名时，浏览器一直转圈，呈现"假死"状态。
- 关闭 Tailscale 客户端或关闭子网路由功能后，服务恢复正常。
三、 深度排查：路由优先级的冲突 经过一整晚的抓包与排查，发现核心原因在于 Tailscale Subnet Router 的接管逻辑 与主路由规则发生了冲突：
-
机制分析 ：当 Tailscale 开启子网路由时，它的路由规则权限通常优于主路由。
-
冲突点：我的文档系统依赖域名解析。当请求发出时，DNS 将域名解析为局域网 IP。此时，Tailscale 的子网路由规则介入，强行接管了指向该网段的流量。但由于我的 Tailscale 部署在 Ubuntu 跳板机上，流量在"客户端 -> Tailscale 虚拟网卡 -> Ubuntu 跳板机 -> 真实局域网"的转发过程中，与主路由的静态路由表或 DDNS 映射逻辑产生了环路或阻断，导致请求无法正确到达目标容器。
四、 解决方案与优化建议
-
关闭 Subnet Router（非必要不开启） 这是最直接的解决办法。Tailscale 的子网路由虽然方便（只需配置一台设备即可访问全网段），但"牵一发而动全身"。一旦跳板机服务异常或路由表冲突，整个网络都会受影响。
- 替代方案 ：采用 点对点（Point-to-Point） 模式。在所有需要远程访问的终端（NAS、PC、手机）上独立安装 Tailscale 客户端。这样即使某台设备服务挂了，也不会影响整个网络架构。
-
安全性加固 利用 Tailscale 组建虚拟局域网 后，建议在路由器防火墙上关闭高危端口映射（如 Windows 的 3389、SSH 的 22 端口）。
- 新策略：外网访问一律走 Tailscale 的加密隧道，不再依赖公网 DDNS 直连高危端口，既解决了运营商断网导致的 IP 变动问题，又极大提升了安全性。
- 关于性能与 DERP 中转 目前直连延迟在 45-50ms 左右，属于可接受范围。如果后续遇到跨运营商干扰导致延迟过高（>100ms），计划自建国内 DERP 中转服务器来提速。
五、 避坑总结
-
DDNS 与 Tailscale 可以共存，但要警惕路由规则冲突。
-
如果你的内网服务依赖复杂的域名解析或静态路由，慎用 Subnet Router，推荐使用客户端点对点连接。
-
遇到网络"假死"，优先检查路由表优先级。