决定使用 meta 核心

2023/11/3 J10c
LINUX DEPLOY RASPBERRY PI

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

契机

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

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

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

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

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

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

选择 meta

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

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

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

Meta 官方维护的 GUI

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 内核服务。

总结

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