Surge结合Whistle使用

Surge已经是我必不可少的代理工具,灵活的代理规则及开放的API使得我也很容易二次开发来进一步的提升效率,但工作中一直还没很好的接入这个工具,而是使用的Whistle等,借着假期考虑下结合使用的可能

当前的使用情况

  1. Surge作为我的个人网络代理利器,非工作机解决科学上网

  2. 工作中使用OA即公司代理客户端解决访问公司内网服务,身份验证及科学上网

  3. 工作中,使用Whistle+SwitchyOmega,解决开发中的代理调试

Chrome代理设置为走Whistle,whistle没有命中的代理自然继续走系统直接请求

已作出的改进

  • 基于Whistle的API开发了workflow来提升Rule的切换效率

  • 基于Surge的API开发了workflow来提升Surge代理的切换效率

当前存在痛点

  1. SwitchyOmega的代理开关需要手动操作

  2. Whistle代理有时会莫名报错,一部分原因是当前公司网络的不稳定,但一部分我认为是Whistle在大量请求时容易崩

  3. 公司的OA支持访问外网,但是相比较我自己的代理节点,访问外网的速度不算快且有些网站还是会莫名被屏蔽,但是自己的代理访问是OK的

基于此,考虑解决下痛点

最终形态为:OA+Surge+Whistle来解决当前工作中的代理/开发调试问题

好处

  1. 完全废弃SwitchyOmega,采用Surge整体负责代理分发,这样work的不仅仅是Chrome,比如还有Safari

  2. Surge代理使得外网等一些访问请求不必要走Whistle代理,提升速度

  3. 灵活采用自己的代理节点或者OA来访问外网

  4. 灵活关闭Whistle调试代理

解决方案

  1. Chrome下删除SwitchyOmega,OA保持开启的基础上开启Surge,但Surge的增强模式关闭

  2. Surge增加以下配置

  • 增加Whistle代理节点即指向本地的whistle node服务

    1
    Dev-Whistle-local = http, 127.0.0.1, 8899
  • 增加Rule,使得Chrome,Safari等走Whistle代理,如果是不需要whistle时只需要关闭该模块即可

    1
    2
    PROCESS-NAME,Google Chrome*,Dev-Whistle-local // 解决开发调试
    PROCESS-NAME,/Library/Apple/System/Library/StagedFrameworks/Safari/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.Networking.xpc/Contents/MacOS/com.apple.WebKit.Networking,Dev-Whistle-local // 解决开发调试

效果

  • 整个工作流不再需要SwitchyOmega,当需要whistle来开发调试时,GUI操作Surge Rule开启Rule即可,这样Chrome/Safari的请求都会走Whistle代理
  • 公司OA不支持接管所有客户端代理,因此Gmail一直无法正常查收,因为Surge也接管了网络代理,因此也可以增加规则来使mail客户端走代理,因此gmail邮件也终于可以接收了

不足的地方

  • 当前开关Rule仍然走GUI,需要多步操作,如果Surge未来支持模块中Rule指向自定义代理Policy,则可以封装为Module,那么就可以使用Surge Workflow,那样会简便些。
  • 这里配置后会使得Chrome所有请求都会走Whistle代理,不满足的会走系统直连,之所以这样做是因为Whistle本身也是个代理节点,如果明确以站点的形式来区分走不走whistle代理,以后每次当使用Whistle中的rule匹配新域名站点,Surge Rule就需要修改,所以采取上述的一刀切配置,这样较为简单。当然如果是很明确只需要某几个域名服务走whistle那么也可以不使用上述的PROCESS-NAME方式。这点就看诉求

写在最后

  • 经过一番折腾,Surge也可以与Whistle,公司OA代理客户端并存了,同时Safari等其它客户端也可以很方便的走Whistle代理