54 lines
6.5 KiB
Markdown
54 lines
6.5 KiB
Markdown
# Surge Mac 与独立 Tailscale 客户端共存
|
||
|
||
Surge 使用增强模式与原有公网代理、AI DNS 分流；Tailscale 负责 tailnet 路由。独立客户端保持原有登录，不需要在 Proxy Station 保存 auth key。
|
||
|
||
## 已验证的配置
|
||
|
||
本机 Tailscale 禁用系统 DNS 接管：`tailscale set --accept-dns=false`。tailnet 管理端仍启用 MagicDNS，本机 Quad100 仍回答显式发给它的查询。不要选 Exit Node。
|
||
|
||
这是逐设备的本机设置，不随 Tailscale 账号或 Surge 订阅同步。每台新 Mac 都需检查 accept-dns=false、Exit Node 未选择、实际网络扩展进程匹配直连例外。2026-10-06 MacBook Air 虽已载入相同 Surge 配置，accept-dns 仍为 true，随后单独关闭。未安装 CLI launcher 时使用 `TAILSCALE_BE_CLI=1 /Applications/Tailscale.app/Contents/MacOS/Tailscale set --accept-dns=false`。
|
||
|
||
生产 settings 的 General 在现有 skip-proxy 中追加 tailnet 域名、子域和 `fd7a:115c:a1e0::/48`；always-real-ip 追加 tailnet 域名、子域以及 Tailscale 控制服务域名。保留原有公共 DNS、DoH、AI DNS、include-all-networks=false。
|
||
|
||
Host 的具体值只写入生产设置，仓库示例使用占位符：
|
||
|
||
```ini
|
||
[Host]
|
||
tailXXXXX.ts.net = server:100.100.100.100
|
||
*.tailXXXXX.ts.net = server:100.100.100.100
|
||
```
|
||
|
||
删除持久 Host 设置中同域名旧的公共 DNS 映射，并检查最终生成配置的优先级。线上生成器还可能在后面追加同域名的公共 DNS 映射；Surge Host 首条匹配生效，因此显式 MagicDNS 映射必须在它们之前，实际 DNS 日志必须显示 Quad100。诊断优先使用完整 MagicDNS 名称；短名称依赖系统搜索域，禁用系统 DNS 接管后不保证可用。
|
||
|
||
将以下 DIRECT 规则置于 STUN 阻断之前：实际 Tailscale 网络扩展进程、`/Applications/Tailscale.app/`（包含 CLI）、tailnet 域名、`100.64.0.0/10` 和 `fd7a:115c:a1e0::/48`（IP 规则带 no-resolve）。其他应用的 STUN 阻断保持开启。
|
||
|
||
**不要在这台 Mac 上将整个 100.64.0.0/10 写入 tun-excluded-routes。** 实测 Surge 为该范围创建指向物理网关的路由，覆盖 Tailscale 的 /10 路由，造成内部 tailscale ping 可通但普通 TCP 服务不可达。移除额外排除项、禁用 Tailscale 系统 DNS 接管后，普通应用访问恢复。其他系统、版本和子网路由应重新检查实际路由表，不可照搬排除项。
|
||
|
||
模板用于新库初始化，现有订阅从数据库实时生成；通过 update-db 技能备份并更新 settings/rules，不修改客户端的托管文件，不重置规则。
|
||
|
||
## 验证与恢复
|
||
|
||
检查 Surge 增强模式开启、Tailscale Running；确认公网请求仍命中原代理，DNS 日志显示 tailnet 名称使用 100.100.100.100 并返回真实 IP。使用普通 curl/SSH 访问 peer 服务；tailscale ping 是附加检查，不能替代普通应用验证。检查 IPv4 和 IPv6 路由，不能仅看客户端显示已连接。
|
||
|
||
检查 tailscale netcheck 的 UDP 状态和 tailscale ping 的 direct/DERP/peer-relay 路径。中继可正常工作，是否直连还取决于两端 NAT 和防火墙。
|
||
|
||
2026-10-06 本机验证：增强模式开启，tailnet 普通 HTTP 服务经 IPv4、IPv6 均返回 200；MagicDNS 使用 Quad100，ChatGPT DNS 继续使用 AI 策略下的 Cloudflare DoH；公网代理请求返回 200。netcheck UDP=true，peer-relay 约 5 ms。两种启动顺序均通过真实服务访问。Tailscale 应用的 STUN 匹配 DIRECT，其他应用仍匹配 STUN REJECT。用户确认 iPhone 经蜂窝网络成功 SSH 到 Mac Studio；本机查看该 iPhone 的活动 peer 路径为 NJCQ-Relay 的 peer-relay，探测 RTT 为 53–69 ms。睡眠唤醒尚未验证。
|
||
|
||
本次变更前的生产在线备份为 `data/backups/before-tailscale-coexist-20261006-145847.db`；节点、策略组、订阅数量不变，新增 5 条直连规则。系统 DNS 接管原值为 true，现值为 false；恢复旧配置时需一并考虑该本机设置。
|
||
|
||
如果重载 Surge 后 Tailscale 已断开，等 Surge 稳定后重新连接 Tailscale。公网中断时先 tailscale down 恢复网络，再检查 DNS 与路由。未来增加子网路由、Exit Node 或更换客户端时重新验证。
|
||
|
||
## 排查过程中的教训
|
||
|
||
- 初始方案只依据通用路由排除说明，未考虑本机 Network Extension 的实际路由冲突。必须以 `route -n get <peer-IP>`、路由表和普通 TCP 服务为准；不能把官方通用机制当作本机已验证方案。
|
||
- Tailscale 系统 DNS 接管与 Surge 的 DNS 管理在本次环境中发生干扰。最终同时撤掉额外排除路由并禁用 Tailscale 系统 DNS 接管后恢复，不应将所有整机断网现象归因于单一因素。
|
||
- tailscale up 返回或接口就绪时，控制连接与 peer 路径仍可能在恢复。使用 `tailscale wait --timeout=25s`，并对真实服务做有限重试；保留公网失败时自动关闭 Tailscale 的恢复措施。
|
||
- CLI netcheck 的 STUN 不一定来自网络扩展进程。仅豁免网络扩展时 netcheck 曾显示 UDP=false；增加 Tailscale 应用路径例外后显示 UDP=true。测试其他应用的 STUN 阻断时避开已有特殊 IP 规则（如 AI DNS 的 1.1.1.1），否则命中的可能是更靠前的规则。
|
||
- 用户手动关闭 Tailscale 曾造成状态变化；日志的 userInitiated 不能直接解释成软件故障。先与用户协调测试窗口，不反复擅自重连导致用户再次断网。
|
||
- 判断是否经过自建 relay，应检查目标 peer 的 Active、PeerRelay、CurAddr 和探测输出，再用网络映射确认 relay 身份。访问 relay 节点本身可通，不能证明 iPhone 到 Mac 的连接经过它；显示 DERP 区域也不能覆盖当前 PeerRelay 的实际路径。经过 relay 不等于已测得相对 DERP 的性能提升。
|
||
- 入站 SSH 失败先检查 SSH 服务是否监听。此次 Mac 的 22 端口起初拒绝连接；用户开启远程登录后，蜂窝网络 SSH 成功，并在 Mac 看到来自 iPhone tailnet IP 的 ESTABLISHED 会话。
|
||
|
||
本次环境：Surge Mac 6.9.1、独立安装版 Tailscale 1.102.4、Mac Studio 的 macOS 27.0.1。睡眠唤醒、长期运行及网络切换恢复尚未覆盖；升级后应重新验证，不能据此承诺所有版本永久兼容。
|
||
|
||
参考：[Surge 虚拟网卡配置](https://manual.nssurge.com/profile/general.html)、[Surge 进程规则](https://manual.nssurge.com/rules/process.html)、[Tailscale Quad100](https://tailscale.com/docs/reference/quad100)、[Tailscale 手动 DNS 配置](https://tailscale.com/s/resolvconf-overwrite/)、[多 VPN 共存限制](https://tailscale.com/docs/reference/faq/other-vpns)。
|