V2RayN的PAC模式如何实现自动分流功能？

一、从一个运营者的真实痛点说起：为什么“全走代理”一定会出问题

如果你同时管着一台挂着下载任务、又开着海外 SaaS 后台、还要刷国内视频的桌面设备，那么“全局代理”和“完全直连”这两个极端都会让人难受：前者让国内站点的响应变慢、部分服务还可能触发风控校验；后者则让真正需要代理的请求直接失败。追根究底，问题并不在于哪个选项更“正确”，而在于两类性质完全不同的流量被塞进了同一条出口。V2RayN 的 PAC 模式正是为这种“既要又要”的场景准备的——它把“哪些域名走代理、哪些域名直连”的判断权交给一份脚本，由浏览器与系统按域名自行决定出口。

但必须先把预期放正：PAC 不是万能分流器。它只能影响“愿意读取系统代理设置、并且支持 PAC”的程序，绝大多数情况下就是浏览器以及少数使用系统代理的桌面软件。命令行工具、游戏客户端、走独立 SOCKS 端口的应用，往往完全不理会 PAC。这也是为什么很多人在配好 PAC 之后仍然觉得“没生效”——不是脚本写错了，而是那部分流量从一开始就不在 PAC 的管辖范围内。把这一点想清楚，后面的配置动作才不会走偏。

本文按“问题 → 定位 → 对策 → 操作 → 验证 → 取舍”的顺序展开：先讲清楚 PAC 模式在 V2RayN 中到底承担什么角色，再给桌面端的最短配置路径，最后说明什么时候应该直接放弃 PAC、改用核心路由规则。

二、PAC 模式在 V2RayN 中的定位与边界

PAC 是 Proxy Auto-Config 的缩写，直译就是“代理自动配置”。它的载体是一个 JavaScript 文件，里面必须定义一个名为 FindProxyForURL(url, host) 的函数。浏览器或操作系统在发起请求前调用这个函数，函数返回 DIRECT（直连）或 PROXY 127.0.0.1:端口（走本地代理）之类的指令，请求据此决定出口。这是 PAC 的通用规范，与具体客户端无关；换句话说，你在别的工具里见过的 PAC 配置，底层逻辑与这里是同一套。

放到 V2RayN 的语境里，PAC 模式的角色是“系统代理层的一道前置过滤器”：它让一部分域名在第一跳就被标记为直连，从而绕开本地代理进程。需要特别说明的是，PAC 相关入口（例如本地 pac.txt 文件、GFWList 订阅、更新 PAC 之类的按钮）在不同历史版本中的位置与保留情况并不一致，截至当前的最新版本，其界面组织已多次调整。因此下文凡是涉及具体入口的描述，请以你实际安装版本的界面为准；如果你在设置里找不到对应项，直接跳到第七节的路由方案即可，它实现的分流效果更彻底。

PAC 与核心路由的分工：一个在门外，一个在门内

理解两者区别的最直观方式，是想象一栋楼。PAC 相当于楼门口的一张告示，告诉访客“你去哪个门”；只有愿意抬头看告示的访客（支持系统代理的程序）才会遵守。核心路由则是楼内的一条内部通道规则，凡是进了楼的流量（通过本地代理端口进来的 TCP/UDP 请求）都由它统一调度，哪怕访客完全没看门口的告示。PAC 管的是“要不要进代理进程”，路由管的是“进了代理进程之后往哪走”。

这个分工决定了两者的适用边界：PAC 适合“只有浏览器需要分流”的轻量场景，配置简单、改动面小；核心路由适合“机器上还有一堆不走系统代理的程序”的场景，覆盖面广，但需要理解规则的匹配顺序与优先级。经验性观察是，随着桌面端应用越来越多地自带网络栈（Electron 应用、独立下载器、开发工具链），单靠 PAC 能覆盖的流量比例在下降。所以选哪条路线，本质上是在“改动面大小”与“覆盖范围大小”之间做一次权衡。

三、两条分流路线对比：PAC 与核心路由该选哪个

在下手之前，先做一次选择，可以省掉后面大量返工。下表列出两条路线在几个关键维度上的差异，供你对照自己的实际情况判断。

如果你的机器上只有浏览器需要区分国内外，PAC 的投入产出比更高；如果你还要兼顾下载器、即时通讯、开发工具，直接上路由规则会更省心。两者并不互斥，可以同时开启：PAC 先把一部分域名挡在代理进程之外，剩下的流量再由路由规则二次分类。注意，同时启用并不意味着“双重保险”，它只是把两道筛选串联起来，规则越简单，出问题时越容易定位。

四、桌面端最短配置路径：让 PAC 接管系统代理

下面以 Windows 桌面端为主要参照。macOS 与 Linux 的整体思路一致，差异集中在系统代理的设置入口，第八节会单独说明。

前置检查（建议先做，能避免大半无效操作）：

• 确认 V2RayN 已经正常运行，并且本地代理端口处于监听状态；默认配置下 HTTP 端口常见为 10809、SOCKS 端口常见为 10808，但端口可被修改，请以你本地实际配置为准。
• 确认主界面底部的系统代理选项当前处于可切换状态，而不是被其他代理工具占用。
• 确认你有可用的 PAC 文件或订阅地址（见第五节）。

这三项之所以要提前确认，是因为它们各自对应一类常见失败：程序没起来、代理开关被占用、以及无规则可用。把排查顺序前置，比事后逐个试错要快得多。

操作步骤（以实际界面文案为准）：

1. 打开 V2RayN 主界面，底部状态栏切换系统代理模式，选择与“自动配置/PAC”语义对应的那一项。不同版本的下拉文案可能是“自动配置系统代理”“PAC 模式”或类似表述。
2. 若界面提供 PAC 路径或 PAC 文件设置项，指向本地已有的 pac.txt；若提供订阅更新入口，填入 GFWList 一类的规则源地址后执行更新。
3. 保存后建议重启浏览器，使新的代理配置生效——浏览器会缓存 PAC 解析结果。
4. 打开一个国内域名和一个境外域名，用第九节的方法分别验证出口。

失败分支与回退方案

如果切换后浏览器出现“无法连接代理服务器”，第一步是把系统代理模式切回“不改变系统代理”或“清除系统代理”，恢复可用状态，再检查 PAC 文件路径是否含有中文或空格、端口是否与实际监听一致。若更新 PAC 后反而全部直连，通常是规则源内容被替换成了空列表或格式损坏，回退到上一份备份文件即可。建议在改动前先复制一份当前 pac.txt 作为备份，这个习惯能省掉很多重配时间。

五、PAC 文件从哪里来：本地文件与规则订阅

PAC 文件的来源大体有三类。第一类是客户端自带的模板文件，通常位于安装目录或用户配置目录下，名字可能叫 pac.txt；第二类是社区维护的规则源，例如以 GFWList 为基础的订阅，其内容本质是一批需要走代理的域名后缀；第三类是你自己手写的精简脚本，只覆盖自己实际用到的几十个域名。第三类的可维护性最好，因为你能完全掌握命中逻辑，出问题时也只需回看自己写的那几十行。

需要提醒的是，社区规则源的内容会随时间变化，订阅地址也可能失效或被迁移。不要在配置完成后就不再过问：环境说明里建议每季度至少检查一次订阅是否还能正常更新，同时留意本地 pac.txt 的行数与最后修改时间是否发生变化。若更新后行数骤降，往往意味着源已异常，此时及时切回备份比继续排查更划算。

提示：PAC 文件本质是纯文本配置，不是可执行程序，但函数体是 JavaScript。不要从来源不明的地址下载 PAC 文件，因为脚本可以读取你访问的 URL 与主机名。

六、手写一份可用的最小 PAC 脚本

如果你只想覆盖少数几个常见域名，手写脚本比引入庞大的规则源更清晰。下面是一份最小可运行示例，逻辑是“命中直连列表则直连，否则走本地代理，代理不通时回退直连”。

function FindProxyForURL(url, host) {
  // 需要直连的域名后缀，按需增删
  var directList = [
    ".cn",
    "example.cn",
    "localhost"
  ];
  for (var i = 0; i < directList.length; i++) {
    var rule = directList[i];
    if (host === rule || dnsDomainIs(host, rule)) {
      return "DIRECT";
    }
  }
  // 其余流量交给本地 HTTP 代理，端口请替换为你的实际值
  return "PROXY 127.0.0.1:10809; DIRECT";
}

这份脚本有几个必须知道的边界。其一，dnsDomainIs 是纯字符串匹配，不做 DNS 解析，所以写 “.com” 会把所有 .com 域名都判为直连，颗粒度很粗。其二，PAC 的返回值支持多级回退，用分号分开，浏览器会按顺序尝试，最后一项建议保留 DIRECT，避免代理进程退出后整台机器的浏览器直接断网。其三，脚本越短越容易排错，不要一上来就塞进上千条规则——先让最小版本跑通，再按实际访问中暴露的缺口逐条补充，是这个环节最省时间的做法。

七、路由规则方案：更彻底的自动分流

当你发现 PAC 覆盖不到目标程序时，就应该转向核心路由。V2RayN 的路由规则最终会转化为代理核心的 routing 配置，结构是“规则数组 + 出口标签”，匹配从上到下、命中即停，因此顺序比内容更重要。下面的片段展示了最常见的三分法：国内域名直连、国内 IP 直连、其余流量走代理。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      { "type": "field", "outboundTag": "direct", "domain": ["geosite:cn"] },
      { "type": "field", "outboundTag": "direct", "ip": ["geoip:cn"] },
      { "type": "field", "outboundTag": "proxy", "network": "tcp,udp" }
    ]
  }
}

这里出现的 geosite:cn 与 geoip:cn 是代理核心内置的分类数据标识，含义是“部分地区常见域名集合”与“部分地区 IP 段集合”，具体内容由数据文件决定，会随版本更新。domainStrategy 设为 IPIfNonMatch 的含义是：域名规则没命中时，再解析出 IP 去匹配 IP 规则——这一步会引入一次额外解析，延迟略有增加，但能覆盖那些没有被域名列表收录的站点。也正因如此，它适合作为“兜底”而不是“主力”。

什么时候不该用这套规则？如果你身处对 DNS 解析路径有严格审计要求的内网环境，额外的解析请求本身可能就是不合规的；此外，当你的主要诉求只是“浏览器分流”时，引入路由规则会同时改变其他应用的出口，反而扩大了变更面。这种情况下，PAC 的局部性反而是优点。

八、跨平台差异：Windows、macOS、Linux 与移动端

V2RayN 长期以 Windows 桌面端为主要形态，较新版本基于跨平台的运行时构建，在 macOS 与 Linux 上有可运行的分发形式，但界面与系统集成的成熟度并不一致，请以官方发布说明为准。下表给出各平台“最短可达路径”的差异概览。

移动端需要单独说明：V2RayN 目前并不提供官方的 Android 或 iOS 客户端，移动设备上常见的做法是使用其他支持分流的第三方客户端，它们通常直接内置规则列表，而不是走 PAC 这条路。因此不要把桌面端的 PAC 配置经验直接套用到手机上，两者的分流实现机制并不相同。

Linux 下还有一点容易被忽略：很多命令行程序只认 http_proxy / https_proxy 环境变量，而这两个变量并不支持 PAC 脚本。也就是说，即便你在图形界面里配好了 PAC，终端里的 curl、git、包管理器依然会直连。这类场景必须靠路由规则或 TUN 模式来兜底。

九、验证与观测：如何确认分流真的生效

配置完成后不做验证，等于把问题留给未来某个紧急时刻。下面给出一组可复现的验证步骤，按从粗到细的顺序排列。

1. 出口比对。在浏览器中分别访问“我的 IP 地址查询”类页面，一次访问国内站点、一次访问境外站点，对比两次显示的出口 IP 是否不同。若国内站点也显示境外出口，说明 PAC 未生效或规则未命中。
2. 开发者工具确认。在浏览器开发者工具的“网络”面板中查看任一请求，观察其是否经由本地代理端口。这一步能区分“真的直连”和“走了代理但被规则放行”。
3. 系统层确认（Windows）。在命令行执行 netsh winhttp show proxy，可查看 WinHTTP 层面的代理设置。需要注意浏览器通常使用 WinINET 而非 WinHTTP，两者结果不一致属于正常现象，不能据此判断 PAC 是否失败。
4. 命令行对照。用 curl 分别带 --proxy 参数和不带参数访问同一地址，观察返回内容或响应时间差异，可确认代理端口本身是否可用。

这四步的顺序有讲究：先从最直观的出口 IP 看结论，再往下逐层定位到具体环节。建议把第 1 步固化成习惯：每次调整规则后跑一次，花不了半分钟，却能立刻发现“改了等于没改”的情况。如果你在维护多台设备，可以记录每台设备的规则版本与验证结果，便于横向对比。

十、故障排查：现象 → 可能原因 → 验证 → 处置

下面按现象归类整理排查路径，尽量按照“可观测”的顺序排列，避免盲目改配置。每一类都遵循同样的四步：先看现象，再列可能原因，然后验证，最后处置。

现象一：所有站点都无法访问。可能原因是 PAC 文件路径无效、脚本语法错误，或代理端口写错。验证方式是临时把系统代理切回“不改变系统代理”，若恢复正常即可确认问题出在代理配置层。处置方法是检查路径中是否含中文或空格、确认返回值中的端口与本地监听端口一致。

现象二：国内站点变慢，但境外站点正常。通常是 PAC 规则没有命中国内域名，导致国内流量绕道境外。验证方式是对比“直连时”与“代理时”访问同一国内站点的响应时间。处置方法是在直连列表中加入该域名后缀，或改用第七节的路由方案统一处理。

现象三：改完脚本后没反应。绝大多数情况是缓存。浏览器与系统会缓存已下载的 PAC 内容，部分系统还要求重启网络服务。验证方式是查看脚本文件的最后修改时间是否已更新，再重启浏览器确认。处置方法是重启浏览器，必要时重启系统代理开关。

现象四：浏览器生效，其他程序不生效。这不是故障，而是 PAC 的固有边界。验证方式是对比浏览器与命令行工具的出口 IP，若两者不同即可确认。处置方法是转用路由规则，或对该程序单独设置代理。

十一、例外与取舍：什么时候不该用 PAC

PAC 的价值在于“局部、低侵入”，它的局限也正源于此。以下几类场景建议直接排除 PAC 方案。

• 目标程序自带网络栈、不读系统代理。例如部分独立下载器、游戏客户端、基于 Electron 且自行管理代理的应用。这类程序对 PAC 完全免疫。
• 需要覆盖 UDP 流量。PAC 的返回值机制面向 HTTP 语义，无法对 UDP 流量做分流。
• 需要按 IP 而非域名分流。PAC 的匹配依据是 URL 与 host，无法根据目标 IP 归属做判断。
• 团队协作场景。把 PAC 文件分发给多人维护时，版本一致性极难保证，一份错误的脚本可能导致全员断网，且排查成本高于集中式的规则配置。

这四类的共同点是：问题不在脚本写得对不对，而在 PAC 这个机制本身管不到。反过来，如果你只是想在个人设备上给浏览器做一个轻量分流，又不想理解规则匹配顺序，PAC 仍然是成本最低的路径。这里没有绝对优劣，只有是否匹配你的变更承受能力。

十二、适用与不适用场景清单

把判断标准写成清单，方便你在动手前先做一次自我筛查。

适合使用 PAC 的情况：设备上只有浏览器需要区分国内外；你希望改动范围可控、随时可以一键关闭；你不打算长期维护大规模规则；你对排错时间不敏感，能接受手动重启浏览器。

不适合使用 PAC 的情况：机器上运行着大量不读系统代理的程序；需要处理 UDP 或非 HTTP 协议；需要按目标 IP 决策；多人共用一套配置且要求可审计；你的合规环境要求所有出站流量路径可追溯。

第三种情况值得多说一句。在需要审计的环境里，PAC 的“部分流量完全不经过代理进程”这一特性，反而可能使流量记录出现缺口。如果你的工作假设是“所有出站必须可追溯”，那么 PAC 会带来额外的解释成本，此时集中式的路由规则更合适。

十三、最佳实践检查表

最后给出一份可以直接照做的落地清单，按顺序执行即可完成一次相对稳妥的部署。

• 改动前备份现有的 pac.txt 与路由配置，保留至少一份可用回退版本。
• 先确认本地代理端口，再写 PAC 返回值，不要凭记忆填端口。
• PAC 脚本保持精简，直连列表从实际访问的域名开始积累，而不是一次性引入大而全的列表。
• 返回值末尾保留 DIRECT 作为兜底，避免代理进程异常时浏览器完全不可用。
• 每次调整后按第九节做一次出口比对，确认改动方向正确。
• 当发现覆盖不到的程序越来越多时，及时切换到路由方案，不要在同一套 PAC 上反复打补丁。
• 定期检查规则源的可用性，关注本地文件行数的异常波动。

这份清单的核心思路只有一句：先用最小改动跑通，再按实际暴露出的缺口逐步补规则。一次性追求“完美分流”，往往会在排错阶段消耗掉比收益更多的时间。

十四、常见问题 FAQ

十五、结语与下一步动作

回到最初的问题：V2RayN 的 PAC 模式实现自动分流的方式，是借助 PAC 脚本在系统代理层完成第一道筛选，让命中的域名直连、其余域名交给本地代理。它的优势是局部、轻量、易回退；它的边界同样明确——只对支持系统代理的程序生效，主要覆盖 HTTP/HTTPS，无法处理按 IP 判断或 UDP 分流的需求。

如果你的场景正好落在 PAC 的能力圈内，建议按第四节的路径配置、第九节的方法验证，把改动控制在可回退的范围内。如果你发现自己不断给 PAC 打补丁、且总有程序覆盖不到，那就说明问题是结构性的，应该转向第七节的路由方案，用一套统一的规则来管理出口。判断标准很简单：当你需要修改配置的频率超过了每月一次，就该换方案了。

下一步的具体动作可以这样安排：先备份当前配置，再按检查表完成一次验证，记录下国内与境外域名的出口 IP 结果作为基线；之后再有任何调整，都用同一套比对方法确认效果。这样即使规则来源发生变化，或者客户端界面在后续版本中再次调整，你也能在几分钟内定位到问题出在哪一层。