路由和PAC模式性能

[ttc0419]

如果我理解的没错的话，路由模式是将所有代理流量发给v2ray客户端，然后客户端根据dat文件选择是否让服务器代理，或者自己直连？如果是这样的话，就算是直连，也需要客户端进行转发，网络性能会不会下降？相比之下，PAC对于直连是如何工作的？也是类似逻辑么？性能哪个更好？

[CrazyBoyFeng]

PAC 的工作逻辑是：

1. 访问网址前查看 PAC 脚本缓存是否过期
2. 没有缓存或者缓存过期那么就会去 PAC HTTP 服务器下载 JS 脚本文件
3. 运行 JS 脚本判断直连或代理

路由模式确实比 PAC 模式要浪费一些资源。PAC 模式那些直连的网站，在路由模式里也要耗费额外的资源进行代理。
不过一般来说，这点差异应该也感觉不出来。除非你的代理是放在性能较低的机器上，比如路由器，那么这个感受就会比较明显。

[ttc0419]

感谢解答。所以PAC是被浏览器调用的嘛，如果匹配到直连，浏览器会选择不发送请求给代理？

[CrazyBoyFeng]

所以PAC是被浏览器调用的嘛，如果匹配到直连，浏览器会选择不发送请求给代理？

我所知的系统里，Windows 和 Android 系统会存在一个缓存 PAC 的服务，然后提供接口供第三方调用。当开发者使用系统 SDK 提供的 HTTP 客户端时，默认就会调用系统提供的 PAC 解析。解析后如果是直连就不发送请求给代理。

第三方语言平台则需要看该语言是如何实现代理机制：

• .Net 自带的 HTTP 客户端内置了代理机制。但我不清楚它是 app 解析 PAC 还是调用系统 SDK。
• Python 自带的以及常用的第三方 HTTP 客户端会内置代理机制。它们是 app 解析 PAC。
• Java 自带的 HTTP 客户端虽然支持代理机制，但是不会主动去读取 Windows 的代理配置。它是 app 解析 PAC。

目前，大部分语言里都只有 HTTP 客户端实现了 PAC 机制。其它 TCP 和 UDP 连接虽然有的也实现了代理机制，但通常都并未实现 PAC 机制。所以 PAC 与路由分流的另一大区别就是：是否能够识别 HTTP 和 HTTPS 以外的流量。

[1265578519]

pac是系统代理，性能是最好的，99%的软件产生的http流量都会支持pac，除非软件代码中没有使用http或者强制设置了不允许代理，例如Steam登录

[RAINighty]

而且根据issues#2535的回答，网速还会受制于核心的性能本人的亲身经历：epic下载不开代理能70-80MBps，开了代理2MBps。pac从我个人的感觉上综合来说是比路由要好的