2026 年 10 月 19 日，Tailscale 发布 MagicRoute 测试版，为有多个冗余子网路由器、应用连接器或 Service 主机的网络提供新的选择方式。Tailscale MagicRoute 路由选择主要影响符合条件的 Premium 和 Enterprise tailnet；已有 regional routing 用户需要主动选择加入。管理员可以先盘点冗余资源，再决定是否安排切换。发布日期与测试状态见Tailscale 官方发布文章。
这次变化涉及整个 tailnet，不能只按某一台电脑的体验决定上线。建议先确认相同目标有合格的候选资源、权限和审批正确，再保存设置并核验实际路径。若关注出口节点推荐，客户端需为 Tailscale v1.86.0 或更高版本；手动选择的出口节点不会被这一推荐算法覆盖。具体适用范围以MagicRoute 官方文档为准。
先判断：你的网络是否需要新的路由选择方式
MagicRoute 解决的是“同一目标有多个合格入口，客户端选哪个”的问题。只有一个入口、没有冗余资源的部署，建议先完成基础可用性检查。这里的 tailnet 指组织管理的 Tailscale 网络；涉及办公内网时，可先参考远程办公 VPN、内网路由与权限边界说明，明确哪些目标本来就应该允许访问。
- 多个站点为同一子网提供入口：值得评估，但要逐项核对发布的前缀。
- 多个连接器承载同一应用：先确认候选连接器都能完成该应用的实际请求。
- 希望严格按服务器容量分配流量：不能把此功能当作容量调度承诺。
- 目前只有 DNS 故障或权限拒绝：先定位故障，避免同时改变路由选择方式。
以上是编辑建议的决策顺序。判断依据应是自己的网络拓扑与业务需求，而不是看到控制台出现新选项就切换。准备一份目标清单通常比立即调整全网设置更有价值：记录应用域名、目标网段、候选入口和负责人，后续测试才能针对同一对象比较。
MagicRoute 和原有方式有什么区别
官方将 MagicRoute 描述为按客户端给合格候选资源计算优先级，使用的信号包括地理位置信息。它不再按 DERP 区域给候选资源分组，支持自定义 DERP；选择粒度是客户端，而非每一条连接。与之相比，active-passive failover 使用主备方式，regional routing 则按 DERP 区域组织选择。详见Route selection 的模式说明。
因此，编辑建议不要用“连续刷新页面是否轮流命中不同主机”作为验收标准。单个客户端多次访问，不能证明全网的分配情况；两台主机流量不相等，也不能单独证明功能失效。应先写清楚需要验证的是可达性、候选资格，还是故障后的业务恢复。
尤其要区分功能目标和性能保证。官方限制说明明确指出，它不保证流量均等、不提供按容量均衡的保证，也不保证选中地理位置最近或速度最快的资源。本文未对延迟或吞吐进行实测，不提供切换后的性能增益预测。
切换前，先查相同前缀与访问资格
按官方前缀匹配规则，子网路由故障转移要求发布相同前缀。重叠路由按最长前缀匹配；当更具体前缀的所有路由器都离线时，不会自动回退到更宽的前缀。候选资源还必须满足审批和访问控制条件；使用 grants 的 via 时，选择范围也受其约束。
举例说明：假设一台路由器发布 10.20.0.0/16，另一台只发布 10.20.1.0/24。不能仅因两个网段有重叠，就把前者登记为后者的完整故障备份。这个例子是对文档规则的解释，实际配置仍需逐项检查已批准的路由。
建议把每条需要冗余的前缀单独列一行，写出其全部合格入口，再检查“任意一个入口不可用后，是否仍有同前缀入口”。如果访问受阻同时伴随设备姿态告警，应结合Tailscale 设备姿态失败的核验方法检查权限条件，避免把不具备访问资格误判为路径选择错误。
管理员切换与验证清单
官方要求由 Owner、Admin 或 IT admin 修改此选项。进入管理控制台的 General 页面，在 Route selection 中选择可用模式，保存成功后重新加载页面确认。整个 tailnet 都会使用该设置；操作步骤见官方控制台配置说明。以下是便于回溯结果的编辑建议：
- 记录原状。记下当前模式、目标前缀、候选主机、客户端版本与现有访问结果，并确定测试窗口和恢复负责人。
- 核对资格。确认套餐、测试功能入口、管理员角色和资源审批；不要为了让候选资源出现而扩大无关用户的权限。
- 准备观察证据。在自己管理的连接器或业务服务上准备访问记录，选用无敏感内容的测试请求，记录时间和来源客户端。
- 保存并读回。选择 MagicRoute 后重新加载设置页，确认显示的是预期模式。保存成功只是配置证据。
- 检查业务路径。从不同位置的授权客户端访问同一目标，对照连接器或服务端记录。页面打开只说明请求成功，不能单凭这一点断言命中了哪台入口。
- 验证冗余与恢复。仅在获准的维护窗口模拟一个候选入口不可用，记录新请求、已有会话及恢复后的表现，再恢复测试资源。出现业务回归时恢复原模式并复查。
不要为一次测试同时修改 DNS、访问策略和路由模式，否则难以区分变化来源。若系统还搭配 Mihomo 并出现分域解析异常，可先阅读Mihomo 与 Tailscale 分域 DNS 排查说明，将名称解析问题单独记录。测试日志应只保留诊断所需信息，避免把凭证和业务内容复制到故障报告中。
常见问题
所有 Tailscale 用户都能开启吗？
不能。本文核验时，官方要求 Premium 或 Enterprise tailnet，具备 regional routing 资格并获得 MagicRoute 测试功能访问权限。看不到入口时，应先核对这些条件；本文没有确认任何具体账号的开放状态。
必须把全部客户端升级到 v1.86.0 吗？
这个版本门槛针对新的出口节点推荐算法。官方说明，子网路由器、应用连接器和 Service 主机之间的服务端选择适用于所有客户端版本。不要把出口推荐的条件扩展为整个功能统一的最低版本要求。
开启后会更换我手动选择的出口节点吗？
官方文档说明不会覆盖用户手选的出口节点。因此，验收出口推荐时，应先记录客户端使用的是手选节点还是推荐机制；否则观察不到出口变化，可能只是测试对象与功能范围不一致。
保存成功就算迁移完成吗？
不算。官方明确提示，已保存的设置不能单独证明某个请求使用了某个资源。建议至少同时保留设置读回结果、业务请求结果和路径侧观察记录。测试版存在环境差异，本文不承诺固定的故障恢复时长；异常应连同脱敏证据提交给 Tailscale 支持。
官方来源与核验入口
- Tailscale，MagicRoute: Routing without physical routers；发布于 2026-10-19，核验于 2026-10-21：查看 MagicRoute 测试版发布背景。
- Tailscale，MagicRoute；页面标注最近验证日期 2026-10-07，本文核验于 2026-10-21：核对适用资格、客户端条件与功能限制。
- Tailscale，Route selection；页面标注最近验证日期 2026-10-07，本文核验于 2026-10-21：核对选择模式、前缀规则和控制台操作。
关于作者
