走近科学之Surge关不掉

平日 Surge 是常驻笔者后台的

然而近日，笔者遭遇了极为申必的灵异事件：Surge 明明已经 Cmd+Q 彻底退出，TUN 模式也关了，系统设置里的代理勾选也全是空的，但浏览器和终端竟然还能复读 127.0.0.1:6152 的 Proxy 配置。

排查

起初笔者以为是 Chrome 的缓存问题，遂 Cmd+Q 强退，无效。还查了 .zshrc 和 env 环境变量，并没有 export http_proxy。

于是不得不使用高雅指令 scutil 来查看系统底层状态。

1
2
3
4
5
6
7
8
9
10
11
12
$ scutil --proxy
<dictionary> {
  ExceptionsList : <array> {
    0 : 127.0.0.1
    ...
    8 : passenger.t3go.cn  <-- ？！这是什么贵物
  }
  HTTPEnable : 1         <-- 悲，原来这里是开着的
  HTTPPort : 6152
  HTTPProxy : 127.0.0.1
  ...
}

尝试解决

笔者尝试了以下方法

  • 使用 networksetup -setwebproxystate "Wi-Fi" off 毫无波动，scutil 依然显示为 1。

  • 新建网络位置。 依然无效。

  • 物理删除 plist 配置文件。还是无效。

破案

此刻笔者不得不把目光转移到机器上是不是有什么申必力量在反复与我人机互搏。

因此把目光转移到了所有与网络配置可能有关的软件上，遂想到 tailscale。

于是尝试把 tailscale 里能 reset 全部 reset了一遍，一直尝试到 reset tailscale vpn。

喜报，问题解决了。

分析

根据结果分析成因，应该是这样：

  1. 污染： 笔者应该是曾在开启 Surge（系统代理生效中）的时候，安装/配置了 Tailscale。

  2. 只读不写： Tailscale 这个屑，在启动时把当时的系统代理状态（127.0.0.1:6152）直接吞了进去，并作为 VPN 配置文件的一部分“固化”了下来。

  3. 层级压制： 由于 Network Extension 的优先级极高，哪怕笔者把物理网卡的代理关了一万次，Tailscale 的虚拟网卡依然在后台默默地执行着那个过期的代理指令。

  4. 死锁： 只要 Tailscale 活着，它就会强行把流量劫持到 6152，根本不管 Surge 死没死。

总结

其实应该先排查机器上的软件冲突的可能性，毕竟 macOS 还是很可靠的。

（逃

评论