详解 PAC (Proxy Auto-Config) 脚本的工作原理与局限性
#PAC脚本#自动代理#系统配置
阅读需 5 分钟||
在更早期的代理工具（如早年的 Shadowsocks Windows 客户端）中，“系统代理”模式通常会提供两个选项：全局代理与PAC 模式。虽然现在我们更倾向于依赖强大的软路由与 TUN 接管，但理解 PAC 对排障仍有历史意义。
1. 什么是 PAC 脚本？
PAC (Proxy Auto-Config) 是一段由 JavaScript 编写的小脚本。
当你在 Windows 或 macOS 系统的网络设置中填入了一个 .pac 文件的本地或远程路径后，操作系统在每次准备发出网络请求前，都会去执行这段脚本里的核心函数 FindProxyForURL(url, host)。
- 如果脚本判断目标
url是谷歌，它会返回一个命令：“使用代理服务器PROXY 127.0.0.1:1080”。 - 如果判断是国内淘宝，它会返回：“
DIRECT(直连)”。 这就是早年最经典的系统级自动分流原理。
2. 为什么 PAC 被逐渐淘汰？
尽管 PAC 非常轻量，但随着网络形态演进，它的致命缺陷暴露无遗：
- 功能极其简陋：PAC 脚本内的 JavaScript 无法调用系统的网络库去主动发起 DNS 测速。如果你想要判断一个复杂的流媒体前缀，你必须在脚本里硬编码成千上万个域名判断，导致脚本极其臃肿，严重拖慢浏览器的启动响应速度。
- 只对 HTTP(S) 有效：PAC 诞生于浏览器时代，它的生效范围极其狭窄。它完全无法接管非标准端口的 P2P 下载、无法接管游戏内的 UDP 联机流量，甚至无法接管终端里的命令行工具。
- 这就解释了为什么“明明开启了 PAC 代理，但游戏依然报错”的老生常谈问题。
3. 现代工具的超越
为了接管所有流量（包含 TCP 与 UDP，不论应用场景），我们需要在更深的内核网络协议栈中进行拦截（例如注入驱动、修改路由表、或者建立透明 TUN 网卡接管），让系统以为发出去的就是普通的网线流量，这也就是为何当今的高阶代理完全抛弃了 PAC。但作为一个纯浏览网页的极简备用手段，PAC 仍旧存在于某些企业网络控制的遗留设施中。