PAC 自动代理配置文件怎么写怎么用：FindProxyForURL 语法、系统设置、缓存与失效排查

PAC 是代理自动配置（Proxy Auto-Config）的缩写，本质上是一个只包含 FindProxyForURL 函数的 JavaScript 文件。浏览器或系统每发起一个请求，都会把网址和主机名交给这个函数，函数返回一串字符串，告诉它这个请求该直连、走 HTTP 代理还是走 SOCKS 代理。公司内网常用它来区分内网地址与外网地址，个人用户也会用它把一部分域名交给本地代理、其余直连。

用 PAC 时常见的问题有：设置之后完全没有效果；改了规则但浏览器还在用旧的；部分网站打开特别慢；浏览器正常，命令行工具和部分软件却完全不走代理。这些问题背后分别是设置位置、缓存、DNS 查询和「谁会读 PAC」四件事。下面先对比 PAC 与其他代理方式的差异，再讲语法、设置步骤和排查。

PAC 与其他代理方式的区别

PAC 的优势是灵活，可以用任意逻辑决定每个请求的去向；劣势是只有读它的程序才会遵守，而且规则要自己维护。它和手动系统代理一样，都属于「请程序配合」的方式，不配合的程序照样直连。TUN 模式在网络层接管流量，不依赖程序是否配合。很多 VPN 客户端已经内置了按域名与 IP 的分流规则，普通用户其实不需要自己写 PAC，只有在公司内网或者有特殊分流需求时才值得折腾。

写出并启用 PAC：分步操作步骤

• 第一步：先把网络线路准备好。PAC 只是规则，真正的出口要先就绪：确认刺猬VPN 或你使用的本地代理已经连上、能正常访问外网，再记下本地代理的地址与端口，端口以所用工具里显示的为准。如果客户端本身的智能分流已经能满足需求，就不需要再叠加 PAC；
• 第二步：写出函数骨架。新建一个文本文件，扩展名改为 .pac，写入 function FindProxyForURL(url, host) { … }，函数必须返回字符串，例如 'DIRECT' 表示直连，'PROXY 127.0.0.1:端口' 表示走 HTTP 代理，'SOCKS5 127.0.0.1:端口' 表示走 SOCKS 代理；
• 第三步：写内网与本机规则。第一条规则用 isPlainHostName(host) 判断不带点的主机名，再用 shExpMatch(host, '*.local') 和 shExpMatch(host, '192.168.*') 之类的写法让局域网地址直连，这几条放在最前面；
• 第四步：写需要走代理的域名。用 dnsDomainIs(host, '.example.com') 匹配某个域名及其子域，或用 shExpMatch(host, '*.example.com') 做通配匹配，命中时返回代理字符串；
• 第五步：写兜底规则。函数最后一行返回 'DIRECT'，表示没命中任何规则的请求直连；如果希望代理失效时自动回退直连，可以返回 'PROXY 127.0.0.1:端口; DIRECT'，分号分隔的多个选项会按顺序尝试；
• 第六步：放到能被访问的位置。很多浏览器和新版系统不再支持 file:// 开头的本地 PAC 路径，最稳妥的办法是用一个本地或内网的 HTTP 地址提供这个文件，响应类型设为 application/x-ns-proxy-autoconfig；
• 第七步：在系统里启用。Windows 打开「设置—网络和 Internet—代理」，在「使用设置脚本」里打开开关并填写脚本地址；macOS 打开「系统设置—网络」，选中当前网络点「详细信息—代理」，勾选「自动代理配置」并填写地址；Firefox 有自己的设置，在「设置—网络设置」里选「自动代理配置的 URL」；
• 第八步：验证效果。打开一个规则里要走代理的网站和一个应该直连的网站，分别确认出口地址；Chrome 可以在地址栏打开 chrome://net-internals/#proxy 查看当前生效的 PAC 地址，并点「重新应用设置」。

按现象排查：不生效、慢与不走代理

PAC 的问题大多出在三个地方：文件没被读到、读到了但规则写错、读的程序根本不支持。按现象逐一对应。

• 设置后完全没效果：脚本地址写错或用了 file:// 本地路径，改用 HTTP 地址，并确认浏览器能直接打开这个地址看到文件内容；
• 改了规则但浏览器还在用旧的：PAC 被缓存了，Chrome 在 net-internals 页面重新应用设置，或者在脚本地址后加一个版本参数，如 ?v=2，强制重新下载；
• 所有网站都变慢：规则里用了 isInNet 或 dnsResolve，这两个函数会对每个请求做 DNS 查询，查询慢时整体变慢，能用域名匹配就不要用网段匹配；
• 整个 PAC 失效、全部直连：函数有语法错误，比如漏了括号或者引号不配对，浏览器会直接忽略整个文件，用编辑器的语法检查或在浏览器控制台里运行一遍；
• 某个子域名没有走代理：dnsDomainIs 的第二个参数没带前面的点，或者通配写成了 'example.com' 漏了星号；
• 浏览器正常，命令行工具不走代理：curl、git、包管理器等多数命令行工具不读 PAC，需要单独设置 HTTPS_PROXY 等环境变量，或改用 TUN 模式；
• 部分软件不走代理：软件没有遵循系统代理设置，PAC 对它无效，同样考虑 TUN 模式或软件自身的代理选项。

常用函数与写法对照

写 PAC 的经验是：能用字符串匹配解决的，就不要用涉及 DNS 的函数；规则从最具体到最宽泛排列，内网和本机地址放最前面；兜底规则写在最后。规则多了以后可以把域名放进一个数组，用循环逐个匹配，比写几百个 if 更好维护。

自动发现、公司网络与安全

除了手动填写脚本地址，Windows 和部分浏览器还支持「自动检测设置」，也就是 WPAD：系统会在局域网里按约定的域名去找一个 PAC 文件并自动使用。公司网络常用这种方式统一下发规则，但在家里或者公共网络里，这个功能反而是隐患，有人可以在同一网络里伪造 WPAD 服务，把你的流量引到他的代理上。不需要时，在 Windows 代理设置里关闭「自动检测设置」。

同理，不要使用来历不明的 PAC 地址。PAC 能决定每个请求的去向，等于把流量路由的控制权交给了写规则的人；从网上随手复制的 PAC 地址，规则随时可能被改掉。自己写、自己托管，或者使用客户端内置的分流规则，是更稳妥的选择。

线路与分流方式对比

PAC 只解决「哪些请求走出口」，出口本身的稳定性取决于线路。先用免费节点验证规则写得对不对，长期使用时间段较长的话，时长套餐更稳定，有效期内不限流量、不限速。需要说明的是，刺猬VPN 客户端的分流是按域名与 IP 区分流量，没有分应用代理的功能；它的智能分流已经覆盖了常见的「国内直连、海外走线路」需求，多数用户不需要另写 PAC。实际可用性取决于当前网络环境。

与 TUN 模式和分流方案的分工

PAC 和系统代理一样依赖程序配合，命令行工具、游戏和部分桌面软件都不会读它。想让所有程序都走规则，就要在网络层接管流量，这就是 TUN 模式，两者的原理差异和各自适合的场景见 TUN 模式与系统代理的区别。

如果你写 PAC 的目的只是让国内网站直连、海外网站走线路，那其实是分流的需求，不一定要自己写规则，分流的几种实现方式、按域名与按 IP 的差别见 分流是什么。分工可以这样记：公司内网的复杂规则用 PAC，所有程序都要走规则用 TUN，日常的国内外分流交给客户端内置的智能分流。

常见报错速查表

高频问答

• 问：PAC 文件能放在本地硬盘上吗？答：部分浏览器和新版系统不再支持 file 路径，用 HTTP 地址最稳妥；
• 问：为什么改了 PAC 要等很久才生效？答：浏览器会缓存 PAC，手动重新应用设置或在地址后加版本参数；
• 问：PAC 能让游戏走代理吗？答：不能，游戏一般不读 PAC，需要 TUN 模式或其他方案；
• 问：isInNet 一定不能用吗？答：可以用，但每次都会触发 DNS 查询，规则多时明显拖慢速度，能用域名匹配就用域名；
• 问：用了刺猬VPN 还需要 PAC 吗？答：多数情况不需要，客户端的智能分流已按域名与 IP 区分国内外流量；
• 问：网上分享的 PAC 地址能用吗？答：不建议，PAC 决定流量去向，来历不明的规则存在安全隐患。

把 PAC 用在合适的地方

PAC 自动代理配置文件的问题，拆开看都很清楚：不生效先查地址和 file 路径，改了不更新查缓存，整体变慢查 isInNet 与 dnsResolve，整份失效查语法，命令行与游戏不走代理是因为它们不读 PAC。规则从具体到宽泛排列、内网放最前、兜底写最后，再关掉不需要的自动检测，就能用得安稳。

刺猬VPN 采用 HTTPS+AES 加密传输，支持自定义用户名和密码匿名注册，不需要邮箱和手机号；免费节点永久免费、不限流量、不限速，适合先验证规则是否生效；时长套餐有效期内不限流量、不限速，一个账号支持多设备同时在线。客户端内置按域名与 IP 的智能分流和断线保护（Kill Switch），国内站点保持直连，线路中断时拦住流量，多数用户不必自己维护 PAC。实际可用性取决于当前网络环境。