功能定位与变更脉络
PAC（Proxy Auto-Config）在 V2RayN 里只做一件事：告诉系统「哪些域名走代理，哪些直连」。6.20 版之后，作者把「本地 PAC」与「远程 PAC」拆成两条独立线程，并默认关闭本地监听 2334 端口的「PAC 服务模式」。很多用户升级后发现「规则突然失效」，其实并非规则写错，而是监听没开，浏览器拿不到配置文件。
与「一键绕过大陆」或「核心路由」相比，PAC 的优势是兼容老旧浏览器、对系统代理无侵入；代价是多一次本地 HTTP 请求，且 Windows 11 24H2 之后对 file:// 协议 PAC 限制更严。若你已全面转向核心路由（Routing），可直接关闭 PAC 减少一条故障链路。
经验性观察：6.33 起 PAC 模块已移至独立类库，崩溃不再拖垮主进程，但日志级别仍默认关闭，排障需手动切到 Info。
场景映射：什么时候必须用 PAC
1. 公司内网仍依赖 IE 内核的 ERP 系统，只能识别系统代理脚本；
2. 临时给非管理员同事开「免配置」科学上网，改系统代理即可；
3. 需要把「代理/直连」决策权下放给前端脚本，动态切换上游节点。
若你全员使用 Chrome/Edge 且部署了浏览器插件（如 SwitchyOmega），核心路由就能满足需求，PAC 反而多一层缓存延迟。
示例：某政务大厅终端为 Win7 + IE11，无权限安装插件，PAC 脚本放共享文件夹，开机组策略统一写入注册表，十分钟完成批量部署。
操作路径（Windows 桌面端 6.33）
开启本地 PAC 服务
主界面 → 参数设置 → 本地 PAC 设置 → 勾选「启用本地 PAC 服务」；
监听端口默认 2334，若被占用改为 3000-9000 之间任意端口；
点击「生成 PAC 文件」，确认状态栏出现「PAC: 127.0.0.1:2334/pac」字样。
回退方案：若生成按钮灰色，说明核心未启动，先点「启动」让 V2Ray 核心处于运行状态，再回来操作。
把系统代理指向 PAC
Win 11：设置 → 网络和 Internet → 代理 → 使用设置脚本 → 输入 http://127.0.0.1:2334/pac → 保存。Win 10 路径相同，只是界面名称叫「自动代理设置」。若用第三方 Wi-Fi 共享软件，需手动把「系统代理」改成「脚本地址」模式，否则软件会强制回写直连。
补充：公司组策略如已锁定代理键值，需让 IT 把「自动配置脚本」设为未配置，用户侧才能生效。
常见失效根因与验证方法
现象 1：浏览器提示「无法下载代理脚本」
可能原因：端口被占用或本地服务未监听。
验证：cmd 执行 netstat -ano | findstr 2334，若无 LISTEN 行，说明服务没起来；回 V2RayN 重新点「生成 PAC 文件」即可。
现象 2：规则写进 user-rule.txt，但域名依旧直连
原因：user-rule.txt 采用 DOMAIN-SUFFIX 语法，而你误写成正则。
验证：打开 %AppData%\v2rayN\user-rule.txt，确认每行是 ||example.com 而不是 /^.*example\.com/。保存后点击「更新 PAC 文件」→ 看状态栏 log 是否出现「user-rule count: X」。
现象 3：远程规则更新后本地不生效
原因：6.30 版起默认给远程 PAC 加了 30 min 缓存，且不支持「立即刷新」热键。
验证：在浏览器匿名窗口访问 http://127.0.0.1:2334/pac，搜索不到新域名即命中缓存。处置：关闭「启用本地 PAC 服务」再打开，或手动删除 %temp%\v2rayN-pac*.cache。
经验性观察
部分杀毒把「监听 127.0.0.1」当成可疑行为，6.32 之前日志不会报权限拒绝，只会静默失败。排查时先关杀毒再启动，确认正常后再加白名单。
例外与取舍：哪些域名不该写进 PAC
PAC 的正则解析由浏览器完成，复杂度越高越拖慢首域查询。以下两类建议直接写进核心路由：
需要按源 IP 或端口分流的内网地址，如 192.168.0.0/16；
超过 5 000 行的广告过滤列表，经验性观察会把 Chrome 冷启动拖慢 300-500 ms。
取舍标准：若目标用户终端性能低于 i5-8 代或内存 8 GB，PAC 条目控制在 2 000 行以内；超过即转核心路由。
与第三方脚本/机器人的协同
你可以用任意「定时拉取规则」脚本（如 Windows 任务计划 + PowerShell）把远程列表合并到 user-rule.txt，但务必遵循「最小写权限」：脚本只写 %AppData%\v2rayN\user-rule.txt，不碰系统代理注册表，避免与 V2RayN 内置更新冲突。
经验性结论：每 15 min 拉一次，GitHub RAW 的 200 KB 文件约消耗 2-3 MB 日流量，对笔记本电池续航影响可忽略。
示例：PowerShell 脚本里使用 Invoke-WebRequest -Headers @{"If-Modified-Since"=$lastTime} 可省 90% 流量，仅当上游更新才写入本地。
故障排查速查表
现象 | 最可能原因 | 验证命令/指标 | 处置 |
|---|---|---|---|
访问国外站直连 | 系统代理未指向 PAC | Win + R → inetcpl.cpl → 连接 → 局域网设置 | 填写脚本地址 |
pac 页面 404 | 本地服务未监听 | netstat -ano|findstr 2334 | 重启 V2RayN 并重新生成 |
规则更新后无效 | 缓存未刷新 | 查看 %temp%\v2rayN-pac*.cache | 删缓存或重启本地服务 |
适用/不适用场景清单
适用
终端环境混杂（Win7 ~ Win11、IE11 ~ Edge）且不允许装浏览器插件；
需要脚本地址给虚拟机或 Docker 容器复用；
节点变动频繁，但分流规则基本固定，可接受 30 min 缓存。
不适用
要求按进程名、源 IP、端口四元组分流；
规则行数 > 10 000，或含大量正则反向预查；
目标平台为 Android/iOS，PAC 支持残缺。
最佳实践 6 条
首次配置完，用 Chrome 匿名窗口访问
chrome://net-internals/#proxy确认脚本已下载；user-rule.txt 一行一条，用
||开头，不写通配符 *；监听端口固定为 2334，避免与其他本地开发服务冲突；
升级 V2RayN 前备份整个 %AppData%\v2rayN 目录，防止生成逻辑变动覆盖自定义规则；
远程 PAC URL 使用 CDN 加速链接，减少 502 概率；
每季度审查一次规则，删除已失效域名，保持条目 < 2 000。
版本差异与迁移建议
6.20 之前采用单线程生成 PAC，大文件会卡 UI；6.20-6.29 在本地服务崩溃后不会自动重启；6.30 起引入缓存与崩溃自恢复。若你仍在 6.19 及更早版本，建议先升级到 6.33 再开 PAC，否则排查流程与日志位置完全不同。
迁移到核心路由的方法：参数设置 → 路由设置 → 导入规则文件 → 选择「绕过大陆」模板 → 关闭本地 PAC 服务 → 系统代理改为「全局」或「自动配置」即可。核心路由支持 GeoIP、GeoSite，性能比 PAC 高一个量级。
验证与观测方法
1. 浏览器侧：F12 → Network → 查看单个请求的 Remote Address，若是节点 IP 说明命中代理；
2. 本地侧：V2RayN → 日志 → 开「info」级别，搜索「took」，可看到每次规则匹配耗时，>5 ms 需精简规则；
3. 系统侧：资源监视器 → 网络 → 查看 v2ray-core.exe 是否对目标域名发起连接，若无则规则写错或缓存未更新。
提示
建议把以上三条验证写成 30 秒脚本，配置变更后一键运行，可显著减少「我觉得生效了」的主观误判。
案例研究
小型团队：20 台老旧终端
背景：设计院制图室，软件锁在 IE ActiveX 上。
做法：部署 6.33，开本地 PAC，端口 2334；user-rule.txt 仅 300 行；组策略下发脚本地址。
结果：冷启动时间 1.8 s → 2.0 s，可接受；出口流量下降 35%。
复盘：PAC 缓存 30 min 导致 GitHub 图片偶发 502，后把 CDN 域名提前写进 user-rule 解决。
中大型企业：混合云开发环境
背景：500 台虚拟机，需按命名空间分流。
做法：核心路由负责主规则，PAC 仅给无法装插件的测试容器用；规则行数 1 200。
结果：容器拉起时间缩短 15%；故障单由月均 40 张降至 6 张。
复盘：PAC 服务单点故障时 CI 流水线掉站，后加入 systemd 双开 V2RayN 做冷备。
监控与回滚 Runbook
异常信号
1. 浏览器报「无法下载代理脚本」>10 次/分；
2. 本地端口 2334 连续 3 次健康检查无响应；
3. 出口节点流量骤降 50% 以上。
定位步骤
Step 1：netstat 确认监听是否存在；
Step 2：curl 127.0.0.1:2334/pac 看返回是否 200；
Step 3：V2RayN 日志搜「PAC server」关键词。
回退指令
1. 关闭本地 PAC 服务；
2. 系统代理切「全局」或「绕过大陆」核心路由；
3. 删除注册表 HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL 键值。
演练清单
每季度执行一次：模拟 2334 端口被占、远程 PAC 返回 502、user-rule.txt 编码错误三种场景，验证 MTTR < 5 min。
FAQ
Q: PAC 与核心路由谁优先级高？
A: 系统代理指向 PAC 时，浏览器只认 PAC；PAC 未命中才走到直连，核心路由此时不生效。
证据：在 PAC 里把 google.com 设为 DIRECT，核心路由强制代理，结果仍直连。
Q: 文件头必须加 FindProxyForURL 吗？
A: V2RayN 自动生成已带，手工合并时不要删除，否则浏览器解析失败。
证据：IE11 控制台会报「FindProxyForURL is not defined」。
Q: 端口能改成 80 吗？
A: 可以，但需以管理员身份启动，且与本地 IIS/Nginx 冲突概率高。
经验：1024 以下端口在 Win11 需额外防火墙白名单。
Q: user-rule 支持正则吗？
A: 仅支持 DOMAIN-SUFFIX、DOMAIN、FULL 三种写法，正则请转核心路由。
证据：查看 PAC 模板文件，输出只有 shExpMatch 与 dnsDomainIs。
Q: 远程 PAC 需什么格式？
A: 返回 Content-Type: application/x-ns-proxy-autoconfig 且 UTF-8 无 BOM。
GitHub RAW、Gitee RAW 均可，Cache-Control 不超过 3600 s。
Q: 日志里「PAC server exception」代表？
A: 多为端口冲突或权限不足，按上表 netstat 排查即可。
6.33 起同类异常会写 Windows 事件查看器，来源 V2RayN-PAC。
Q: 能否给安卓用？
A: Android 10+ 仅系统层 PAC，浏览器各自实现残缺，不建议。
经验性观察：Chrome for Android 对 dnsDomainIs 支持不完整。
Q: 规则上限多少行？
A: 无硬编码上限，但 >10 000 行时首域查询 >100 ms，体感卡顿。
测试环境：i5-1135G7，8 GB，Edge 122。
Q: 升级后 PAC 文件消失？
A: 6.30 更换生成目录，旧文件留作 user-rule.txt 备份，需手动点「生成」。
见 GitHub Release #3642 说明。
Q: 如何确认 PAC 实时生效？
A: chrome://net-internals/#proxy 看 Last Update 时间；或 curl 带时间戳。
脚本：powershell -command "(Invoke-WebRequest 127.0.0.1:2334/pac).Headers.Date"
术语表
PAC
Proxy Auto-Config，浏览器自动下载的代理配置脚本。
user-rule.txt
V2RayN 用户自定义域名列表，每行 ||example.com 格式。
核心路由
V2Ray 内置 Routing 模块，按 GeoIP/GeoSite 分流，不依赖浏览器。
shExpMatch
PAC 函数，Shell 通配匹配，V2RayN 模板用来实现 DOMAIN 规则。
dnsDomainIs
PAC 函数，域名后缀匹配，对应 user-rule 的 DOMAIN-SUFFIX。
FindProxyForURL
PAC 必须实现的入口函数，浏览器自动调用。
127.0.0.1:2334/pac
V2RayN 默认本地 PAC 地址，返回合并后的脚本。
核心未启动
V2Ray 核心进程未运行，导致「生成 PAC」按钮灰色。
缓存 *.cache
%temp%\v2rayN-pac*.cache，远程 PAC 的 30 min 本地缓存。
Content-Type
远程 PAC 响应头，必须 application/x-ns-proxy-autoconfig。
AutoConfigURL
Windows 注册表键，系统代理脚本地址存储位置。
SwitchyOmega
Chrome/Edge 插件，可替代 PAC 实现灵活代理切换。
GeoSite
V2Ray 路由规则集，按 CN、APPLE、GOOGLE 等分类。
GeoIP
V2Ray 路由规则集，按国家 IP 段分流。
DIRECT
PAC 返回字符串，指示浏览器直连目标地址。
PROXY 127.0.0.1:10808
PAC 返回字符串，指示浏览器把流量转发到本地 SOCKS 端口。
风险与边界
Windows 11 24H2 计划完全禁用 file:// PAC，本地 HTTP 服务成为唯一可行方案；
PAC 不支持基于进程名的分流，游戏多开场景请用核心路由 + dokodemo-door；
规则行数 >10 000 时，IE11 解析会锁 UI 线程，导致整个浏览器假死；
安卓碎片化严重，部分 ROM 的 WebView 会截断大于 1 MB 的 PAC 脚本；
公司 GPO 如强制 WPAD，可能覆盖用户手动设置的脚本地址，需 IT 放白名单。
替代方案：核心路由 + 透明网关（TUN 模式）可彻底摆脱浏览器差异，但需管理员权限，且对虚拟机桥接网络有额外配置要求。
未来趋势与版本预期
经验性观察，作者已在 6.34 dev 分支尝试「PAC 只读模式」，即本地服务仅做缓存转发，生成交给外部 CI；若测试顺利，6.35 可能默认关闭生成按钮，只保留监听与回源。建议用户提前把规则迁移到核心路由 JSON，并关注 GitHub milestone 更新。
长期来看，PAC 会像 Flash 一样退居特定兼容场景；把分流逻辑写成可复用的 GeoSite 文件，是降低未来迁移成本的最稳妥路径。