Surge结合Whistle使用

Surge经是我必不可少的代理工具,灵活的代理规则及开放的API使得我也很容易二次开发来进一步的提升效率,但工作中一直使用公司OA客户端及Whistle等,借着假期考虑下结合使用的可能

当前的使用情况

  1. 非工作机,Surge作为我的个人网络代理利器,非工作机解决科学上网等代理问题
  2. 工作机,
    1. 使用OA即公司代理客户端解决访问公司内网服务,身份验证及科学上网
    2. 使用Whistle+SwitchyOmega,解决开发中的网页代理调试问题

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

已作出的改进

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

  • 基于Surge的API开发了Alfred 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 // 解决开发调试

注意,将该进程代理规则后放,这样的好处是排在之前的比如Google,GitHub等域名代理可以直接先命中走代理。基于此做到部分依然可以走Surge代理,之后的走whistle来解决开发调试问题

效果

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

不足的地方

  • 当前这种模式下,Surge的增强模式无法打开,否则公司服务很多会出现鉴权失败,毕竟已经走的自己的代理服务
  • 这里没有将公司服务的所有域名一个个列出,因此最终的Final规则只能走公司的代理即直连,从而确保可以正常访问
  • 这里配置后会使得Chrome所有请求都会走Whistle代理,whistle没有命中的自然会走系统直连,这样做有利有弊,如果直连无法访问,也只能增加规则在进程代理之前了。

Surge增强模式开启?

其实确实有办法开启,即确保公司的相关服务都正常走公司的相关代理服务即可,但是代价就是需要将所有域名整理,配置规则,并且也会存在一些没有考虑到的情况,不断应对,因此,不建议这么做,太过于费时费力。

写在最后

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