决定使用 meta 核心

最近几天 Clash 圈子里面闹的沸沸扬扬，我也是趁着风头给电脑换上了 meta 内核。Meta 我早就听说了，但是一直不知道有什么契机需要用 TUN 模式，这个星期我发现了一个合适的理由，下面来谈谈。

契机

简述一下我现在的上网环境：

• 寝室内：树莓派做代理服务器，所有设备 HTTP 代理连接树莓派
• 寝室外：大部分场景只有 Mac 需要上网条件

对于 IOS 和安卓系统，网络的代理设置是跟随 AP 的，而 Mac 则是跟随系统的，所以在 Mac 上切换网络后就需要手动去切换系统代理。我的场景下是在寝室系统代理连接树莓派，外出启动 ClashX，代理切换到本地端口。

在电脑上不仅是系统代理需要切换，Shell 的代理也需要手动切换。之前配置树莓派代理的时候就考虑到了这点，写了个快捷指令来修改系统代理。

当然，这个快捷指令可以改成根据地理位置，或者连接上某个 AP 自动启动

上述方案解决了我的需求：降低设备连接数量（对于机场），虽然麻烦点，但是一个月多用下来也是可以接受的。直到前几天我遇到了一个问题。

我在寝室配置好 Shell 代理的情况下，在本地启动了一个 Tomcat App，然后在寝室外访问一个接口（这个接口需要连接云服务器上的数据库），结果数据库连接超时。通过重新配置 Shell 代理，并重启 Tomcat 解决问题。究其原因可能是 JDBC 连接数据库的时候继续使用了启动时环境变量中配置的代理（http 代理到寝室内的树莓派）。如果一个程序在启动的时候记录了网络相关的环境变量，并在应用运行过程中一直用这个配置，那当电脑的代理环境变化后是会造成隐晦的网络问题。

选择 meta

一番思考后，确认了问题在环境变量的切换，寝室内和寝室外这套方案必须得要两个代理地址，无法避免切换。如果切换的层级在 Shell 这里，那就会出现上述环境变量的问题。现在有一个解决方案，系统代理和 Shell 代理一律连接 Clash 的端口，然后在 Clash 中切换寝室内和寝室外的配置。

其实一开始我没有想这么透彻，在想到原有的方案不行的时候我第一反应就是换成 TUN 模式，因为虚拟网卡的方案更底层，对所有的应用透明。实践的审核又想到区分寝室网络和寝室外网络可以在 GUI 中选择不同节点来实现。写这篇文章的时候才发觉，单后者就能解决问题了，不需要 TUN 也能实现。

其实 TUN 也没什么不好的，我删掉了 Shell 脚本中一些关于代理地址的声明和配置，Shell 启动脚本的可移植性更强了👍

meta 官方的 GUI 也具备切换后端功能，兼容 Clash 内核。我将 Web 页面以 PWA 的形式模拟成了一个 App，在 Mac 上能同时管理和监控本机的 meta 内核和树莓派上的 clash 内核。

额外的 http 代理配置

添加一个 Proxy，回到寝室的时候开启全局代理，节点选择 dormitory 即可。

proxies:
  - name: "dormitory"
    type: http
    server: 192.168.1.30
    tls: true
    port: 7890

macOS 系统服务 - root

从编译 meta 内核到开机自启，其中在 macOS 添加服务是最让我头疼的，尤其是这个服务得由 Root 启动。

macOS 配置系统服务我就不阐述了，这篇文章 讲的很透彻。但是文章中的例子不适用于 Root 服务。plist 的创建者是当前用户，而不是需要执行该服务的 root 用户，参考了 这个回答 后我才成功配置好 meta 内核服务。

总结

现在这套联网方案，已经实现了较为优雅的代理切换。在设备齐全的工作室和环境灵活外出场景，理论上都能兼顾良好的网络访问性和资源的节约。