Surge 配置 Tailscale：从版本确认到连接验证
简答：Surge 配置 Tailscale，优先使用内置的 tailscale 策略：先确认 iOS 5.20.0+ 或 Mac 6.7.0+，再在 [Proxy] 和对应的 [Tailscale] 段中使用同一个 section-name。新版本可用 interactive-login，旧版本通常需要 auth-key，并且子网路由、出口节点必须得到控制端批准。
定义：Surge 的 tailscale 策略是一种按 Surge 规则选择流量的应用级出站策略，不等同于接管设备全部流量的独立系统 VPN。
先看结论：三步完成 Surge 配置 Tailscale
- 确认平台和最低版本：Surge iOS 需要 5.20.0 或更高版本，Surge Mac 需要 6.7.0 或更高版本，才能使用内置
tailscale策略；交互登录、自动 MagicDNS 和节点地址规则还需要 iOS 5.21.0+ 或 Mac 6.8.0+。具体能力边界以Surge Tailscale 官方文档为准。 - 选择登录方式：优先使用交互登录；如果当前版本或使用场景不支持，再使用 Tailscale 控制台生成的 auth-key。auth-key 是敏感凭据，不要放进公开配置或截图。
- 按目标添加规则：只访问 Tailnet 设备时，匹配 MagicDNS 后缀或节点地址；访问家庭局域网时，匹配已批准的子网路由；使用出口节点时，再显式设置
exit-node。
本文是第三方使用指南，不是 Surge 或 Tailscale 官方页面。配置前建议备份当前 Surge 配置，完成后再逐项验证登录状态、DNS 解析、节点地址和实际路由。
版本与功能边界：不要把最低版本当成全部功能
| 平台或功能 | 官方资料可核实的要求 | 配置时的含义 |
|---|---|---|
| 内置 tailscale 策略 | iOS 5.20.0+；Mac 6.7.0+ | 可以把 Tailnet 作为 Surge 的出站策略使用，但早期版本需要显式规则和 auth-key。 |
| 交互登录、自动 MagicDNS 与节点地址规则 | iOS 5.21.0+；Mac 6.8.0+ | 可在 Surge 的策略编辑界面完成登录，并由 Surge 根据控制端下发的信息建立相关规则。 |
| 接收入站连接、发布出口节点或子网路由 | iOS 5.24.0+；Mac 6.11.0+ | 属于更高版本能力，还需要控制端的节点授权、ACL 或路由批准，不能只靠本地配置开启。 |
| 你的当前版本 | 需在 Surge 的关于、设置或版本信息页面核对 | 本文不假定你使用的是上述最低版本；如果低于要求，应先升级或采用该版本支持的配置方式。 |
上表中的版本是官方文档列出的功能要求，不代表用户当前安装版本。尤其要区分“最低支持版本”和“你正在使用的版本”：如果配置字段被忽略或配置加载失败，先检查版本与字段对应关系，再检查规则。
Surge 文档还明确说明，内置 Tailscale 策略只处理被 Surge 规则选中的流量；它不是独立 Tailscale 客户端的系统级替代品。默认情况下，未命中该策略的流量不会自动全部进入 Tailnet。相关行为见Surge 的 Tailscale 策略说明。
最小配置：先让一个 Tailnet 节点可访问
下面是结构示例，不是可直接复制的完整配置。请替换登录凭据、名称和规则条件，并根据当前 Surge 版本核对字段。不要把真实 auth-key 粘贴到公开仓库、工单或文章中。
[Proxy]
Office Tailnet = tailscale, section-name=office-tailnet
[Rule]
DOMAIN-SUFFIX,example-tailnet.ts.net,Office Tailnet
IP-CIDR,100.x.x.x/32,Office Tailnet,no-resolve
[Tailscale office-tailnet]
auth-key = tskey-auth-REPLACE-ME
hostname = surge-device这里最容易出错的是 section-name：[Proxy] 中的值必须与 [Tailscale office-tailnet] 的名称完全一致。官方文档要求该段使用一种登录方法，即 auth-key 或 interactive-login = true，不要同时配置两者。字段和段落格式可对照官方 Tailscale policy 文档。
100.x.x.x/32 只是结构占位符，不应直接照抄。实际 Tailnet 地址、MagicDNS 后缀和可用路由应以当前控制端与 Surge 状态页显示的值为准。若只访问一个设备，使用该设备实际显示的 Tailnet 地址；若访问一组地址，再根据控制端下发的网段设计规则。
交互登录方式
在支持交互登录的版本中，可在 Surge 的策略编辑或相关登录入口选择交互登录，然后完成控制端授权。对应配置结构可写成：
[Proxy]
Office Tailnet = tailscale, section-name=office-login
[Tailscale office-login]
interactive-login = true
hostname = surge-device如果当前版本没有交互登录入口，或配置解析不接受该字段，应改用 auth-key，不能把较新版本的字段强行套到旧版本。Tailscale 官方说明显示，auth-key 可以在控制台 Keys 页面生成，并可设置是否复用、过期时间、设备标签和预批准等属性，具体选项以当前控制台为准。
按使用目标配置：Tailnet、子网路由与出口节点
| 目标 | 需要匹配的流量 | 额外条件 | 排查重点 |
|---|---|---|---|
| 访问 Tailnet 内的一台设备 | 该设备的 MagicDNS 名称或实际 Tailnet 地址 | 设备在线且控制端允许互访 | 先验证名称解析，再用实际地址测试。 |
| 访问家庭或办公局域网 | 已批准的子网网段 | 子网路由器已发布路由，控制端已批准 | 确认路由实际下发，避免只在本地写一个未授权网段。 |
| 让指定流量走出口节点 | 需要出口的目标流量 | 出口节点已发布默认路由且可用 | Surge 的出口节点不会改变设备全局默认路由，只影响选中该策略的连接。 |
| 通过上游策略连接 DERP | Tailnet peer 流量 | 上游策略本身可用 | underlying-proxy 会影响 Tailscale 的中继连接，并可能关闭直连 UDP，不等同于启用出口节点。 |
访问子网路由
子网路由不是“写了一个局域网网段就能访问”。发布路由的设备需要在控制端完成批准，且当前 Surge 节点必须收到该路由。Surge 官方文档将子网路由与节点允许的地址前缀关联，建议先从控制端或运行状态中确认实际网段，再添加规则。
[Rule]
IP-CIDR,10.20.0.0/16,Office Tailnet,no-resolve上面的网段只是结构示例，不代表你的网络一定使用它。若目标是访问一台办公设备，先确认该设备所在网段、子网路由器发布的前缀以及控制端批准状态。
使用出口节点
需要让指定请求通过某个 Tailnet 节点访问外部网络时，可在 Tailscale 段中指定出口节点：
[Proxy]
Tailnet Exit = tailscale, section-name=tailnet-exit
[Tailscale tailnet-exit]
auth-key = tskey-auth-REPLACE-ME
exit-node = exit.example-tailnet.ts.netexit-node 应使用控制端中该节点的可识别名称、地址或稳定标识，并确保该节点确实发布了默认路由且已获得批准。官方文档特别说明，出口节点只作用于分配给该 Surge 策略的连接，不会把设备所有流量自动切换过去。
MagicDNS、规则与 underlying-proxy 怎么选
MagicDNS 的作用是为 Tailnet 设备提供可解析的设备名称。Tailscale 官方文档说明，MagicDNS 会为网络中的设备自动注册 DNS 名称；Surge 内置策略则会根据控制端下发的 DNS 与网络信息处理 MagicDNS 名称。
- 优先自动规则：在满足 iOS 5.21.0+ 或 Mac 6.8.0+ 的情况下，可让 Surge 自动加入发现到的 MagicDNS 后缀和可见节点地址规则，适合节点地址经常变化的场景。
- 优先显式规则：如果你需要严格控制哪些域名或地址进入 Tailnet，可以关闭自动添加规则，再手动写入经过确认的域名或网段。
- 不要把 100.64.0.0/10 当成万能规则：实际可用的节点地址与路由仍受控制端、ACL 和在线状态影响，规则应以当前 Tailnet 信息为准。
underlying-proxy 是代理链参数：Surge 会先通过上游策略建立连接，再连接目标策略。对于 Tailscale，官方说明指出，非 DIRECT 的 underlying-proxy 会让 DERP 连接通过上游策略，并关闭物理直连 UDP，因此通常会增加延迟并依赖中继可用性。它解决的是“通过什么路径连接 Tailscale”，不是“选择哪个出口节点”。
[Proxy]
Tailnet via Upstream = tailscale, section-name=office-tailnet, underlying-proxy=Upstream如果你的目标只是访问 Tailnet 设备，先不要加入 underlying-proxy。先用默认 DIRECT 路径验证功能；只有在当前网络无法建立直连、需要让 DERP 连接经过指定上游时，再单独测试该参数。
配置完成后的可复现验证清单
- 验证配置加载：保存配置后确认 Surge 没有报告段落、字段或规则解析错误。若失败，先删除最近新增的字段，恢复到备份配置，再逐项加回。
- 验证节点注册：在 Tailscale 控制端查看是否出现新的 Surge 节点，并检查是否需要手动批准。节点未出现时，不要先改 MTU 或 DNS，优先检查登录方式、auth-key 是否过期或被撤销。
- 验证 MagicDNS：使用一个已确认存在的设备名称测试解析；如果名称解析失败，再用控制端显示的实际 Tailnet 地址测试，以区分 DNS 问题和路由问题。
- 验证单个设备：先访问 Tailnet 内一台设备的已知服务端口或管理页面。单个地址可达后，再测试网段规则。
- 验证子网路由：确认子网路由器在线、路由已批准、目标网段与规则一致。若节点地址可达但局域网地址不可达，优先检查路由批准和 ACL。
- 验证出口节点：只给一个明确的测试域名或请求选择出口策略，记录访问结果和出口变化。不要把“Tailnet 节点可达”误判为“出口节点已经生效”。
- 验证直连或中继：查看 Surge 的运行状态或请求详情，确认当前 peer path 是 direct 还是 relay。若使用
underlying-proxy或derp-only，应预期路径与默认 DIRECT 不同。
一次请求成功只说明该请求在当时的规则、节点和路径下成功，不等于长期稳定。建议记录测试时间、平台版本、目标地址、是否命中规则、解析结果、路径类型和错误信息，便于复现。
连接失败、速度慢或规则不生效怎么办
| 现象 | 优先检查 | 处理方式 |
|---|---|---|
| 配置无法加载 | 段名、字段拼写、section-name 是否一致 | 恢复备份，保留 [Proxy] 与 [Tailscale] 的最小段落，再逐项增加字段。 |
| 节点没有出现在控制端 | 登录方式、auth-key 状态、设备授权 | 生成新的最小权限或一次性密钥，并按控制端状态确认设备是否待批准。 |
| MagicDNS 不解析 | 版本、MagicDNS 状态、控制端下发 DNS、规则是否命中 | 先用实际 Tailnet 地址测试；地址可达而名称失败时，再处理 DNS。 |
| Tailnet 设备可达，局域网不可达 | 子网路由发布、批准、ACL 与目标网段 | 确认实际下发的路由，不要只凭本地填写的网段判断。 |
| 访问慢或偶发失败 | 直连或 DERP、中继路径、上游策略、MTU | 先移除非必要的 underlying-proxy，再对比默认路径；MTU 仅作为后续排查项，逐步调整并记录结果。 |
| 出口节点没有生效 | exit-node 名称、节点在线状态、默认路由批准 | 先测试一个明确命中 Tailscale 策略的请求，并确认没有把普通直连流量当成出口流量。 |
auth-key 相关问题要单独处理。Tailscale 官方文档说明，auth-key 可在控制台生成和撤销；官方安全建议还提醒，直接把密钥写入命令可能进入 shell 历史记录，复用密钥泄露后可能被用于注册未经授权的设备。因此，发现密钥出现在日志、截图或公开配置中时，应立即在控制台撤销并重新生成。
回滚与安全边界
- 修改前导出或复制当前 Surge 配置，保留一份未加入 Tailscale 的可用版本。
- 优先只添加一个
[Proxy]策略和一个[Tailscale]段，确认节点上线后再添加子网路由、出口节点或上游代理。 - auth-key 不要写入公开仓库、在线配置分享或截图；不用时在控制台撤销。
- 子网路由、出口节点和入站连接会扩大可访问范围，必须结合控制端 ACL、节点批准和实际业务需要启用。
- 如果添加新字段后出现连接异常，先删除该字段并回到最小配置，不要同时修改 DNS、MTU、规则和上游代理。
如果你的目标只是让 Surge 访问几台 Tailnet 设备，最小配置通常比同时启用出口节点、子网路由和 DERP-only 更容易验证。先完成单节点访问，再逐项扩展范围。
常见问题
Surge 配置 Tailscale 一定要安装独立 Tailscale 客户端吗？
使用 Surge 内置的 tailscale 策略时，官方文档描述的是由 Surge 将 Tailnet 作为应用级出站策略接入，不以独立系统 VPN 作为前提。但它只处理被 Surge 规则选中的流量，不等同于独立客户端接管设备全部流量。
为什么写了 100.64.0.0/10 还是访问不了？
这个网段不能代替真实的节点授权、在线状态和规则命中。应先确认目标设备实际 Tailnet 地址、控制端 ACL 和 Surge 运行状态，再用单个地址测试。不要把示例网段直接当成所有 Tailnet 的完整配置。
interactive-login 和 auth-key 应该选哪个？
支持交互登录且配置由本人维护时，可优先使用交互登录；需要无人值守或当前版本不支持交互登录时，再使用 auth-key。auth-key 的可复用、过期、标签和批准选项以当前 Tailscale 控制台为准。
underlying-proxy 是不是出口节点？
不是。underlying-proxy 是让 Tailscale 的控制连接、中继或相关传输经过另一个 Surge 策略；exit-node 才是选择 Tailnet 中发布默认路由的节点。两者解决的问题不同。
为什么 Tailnet 设备能访问，但家庭局域网不能访问？
最常见的排查顺序是：确认子网路由器正在发布目标网段、控制端已经批准该路由、ACL 允许访问、Surge 规则确实匹配该网段。只写本地 IP-CIDR 规则并不会自动创建或批准子网路由。
如何判断问题是 DNS 还是路由？
先用控制端显示的实际 Tailnet IP 测试，再用对应的 MagicDNS 名称测试。IP 可达但名称失败，优先检查 MagicDNS、DNS 服务器和规则；IP 也不可达，则继续检查节点在线、ACL、路由或中继路径。
常见问题
Surge 配置 Tailscale 一定要安装独立 Tailscale 客户端吗？
使用内置 tailscale 策略时，不以独立系统 VPN 为前提，但它只处理被 Surge 规则选中的流量，不等于独立客户端接管全部设备流量。
为什么写了 100.64.0.0/10 还是访问不了？
该网段不能代替实际节点地址、ACL、设备授权和规则命中。应先确认目标设备显示的 Tailnet 地址，再分别测试 IP、MagicDNS 和路由。
interactive-login 和 auth-key 应该选哪个？
支持交互登录时可优先使用 interactive-login；无人值守或旧版本场景再使用 auth-key，并按当前控制台的权限、过期和批准选项配置。
underlying-proxy 是不是出口节点？
不是。underlying-proxy 控制 Tailscale 连接经过哪个上游策略，exit-node 才是选择 Tailnet 中发布默认路由的节点。
为什么 Tailnet 设备能访问，但局域网不能访问？
检查子网路由器是否发布目标网段、控制端是否批准、ACL 是否允许，以及 Surge 规则是否匹配实际下发的网段。
相关阅读
参考资料
- Surge 官方文档：Tailscale 策略（manual.nssurge.com）
- Surge 官方文档：通用策略参数（manual.nssurge.com）
- Tailscale 官方文档：Auth keys（tailscale.com）
- Tailscale 官方文档：安全处理 auth-key（tailscale.com）
- Tailscale 官方文档：MagicDNS（tailscale.com）
- Tailscale 官方文档：Exit nodes（tailscale.com）