Windows VPN分流规则怎么设？一次配好应用代理

在 Windows 上使用 VPN 或代理客户端时，最实用的配置通常不是让所有程序都走同一条线路，而是根据应用、域名和网络请求类型进行分流。浏览器、终端、开发工具、办公软件和本地服务的访问目标不同，如果全部连接都经过代理，可能带来不必要的延迟、登录异常、局域网访问失败或 DNS 判断混乱。

分流的核心不是简单地勾选“代理”或“直连”，而是先确定规则匹配什么，再确定规则从哪里读取，最后验证请求是否真的按照预期离开电脑。Windows 官方客户端、Clash Verge、sing-box 以及其他兼容客户端，在界面和规则格式上有所区别，但基本逻辑一致：请求进入客户端后，按照规则顺序匹配目标，匹配成功后选择代理、直连或拒绝。

先理解 Windows 分流的三层逻辑

Windows 上常说的“按应用分流”，实际可能对应不同层级。第一层是客户端是否接管系统代理；第二层是客户端根据域名、IP、端口或进程名称选择路径；第三层是应用自身是否拥有独立的代理设置。只有这几层没有互相冲突，规则才会表现得稳定。

系统代理与虚拟网卡不是一回事

许多代理客户端会在 Windows 中写入系统代理设置，让支持系统代理的应用自动使用 HTTP 或 SOCKS 代理。浏览器、部分办公软件和常见开发工具通常能够识别这类设置，但某些游戏、后台服务、命令行程序或使用独立网络栈的应用可能完全不读取系统代理。

另一种方式是虚拟网卡或 TUN 模式。客户端通过创建虚拟网络接口接管更广泛的连接，再由内核根据规则决定走代理还是直连。TUN 模式覆盖范围通常比单纯系统代理更大，但也更容易影响局域网、虚拟机、远程桌面、打印机和安全软件。因此，启用 TUN 后必须重新检查本地网络访问，不应把它简单理解成“更强所以一定更好”。

应用规则、域名规则与 IP 规则

应用规则根据进程名称或程序路径匹配，例如让某个浏览器或终端使用代理。域名规则根据请求目标匹配，例如把特定网站、后缀域名或域名集合交给代理。IP 规则则适合处理已经解析出的地址、局域网网段或明确的出口范围。

三类规则并不总能互相替代。应用规则可以覆盖一个程序发出的多个目标，但也可能把该程序访问的本地服务一并送入代理；域名规则更细致，却依赖域名识别是否准确；IP 规则适合处理网络范围，但 CDN 地址变化、共享 IP 和 IPv6 可能让规则维护变得复杂。

实际配置时，建议优先使用域名规则处理网站访问，使用应用规则处理不方便识别域名的程序，再用 IP 或网段规则补充局域网和特殊服务。这样比把所有请求都绑定到某个应用更容易维护。

配置前先设计规则顺序和默认策略

分流最容易出错的地方是规则顺序。多数客户端按照从上到下或从高优先级到低优先级进行匹配，第一条符合条件的规则可能直接决定请求路径。如果把宽泛规则放在前面，后面更精确的规则就可能永远没有机会生效。

例如，你希望公司内网直连、某个外部服务走代理，通常应先放置局域网和内网域名的直连规则，再放置特定域名的代理规则，最后设置兜底策略。如果先写“所有域名代理”，后面的内网例外就可能被提前截获。不同客户端对规则语法和优先级的实现并不完全相同，导入配置后仍要结合客户端文档检查。

一套容易维护的顺序

1. 先处理本机、局域网、家庭路由器和需要直连的内网地址。
2. 再处理明确需要代理的域名、应用或目标地址。
3. 随后处理广告、追踪或不需要访问的请求；是否使用拒绝动作要谨慎。
4. 最后设置未匹配请求的默认行为，选择直连或代理。
5. 保存配置后，重新加载规则并清理受影响应用的旧连接。

默认策略没有绝对正确的答案。以直连为默认值，风险范围较小，也更容易保留本地服务和国内网站的正常访问；以代理为默认值，规则覆盖不完整时不容易漏掉目标，但可能增加流量消耗、影响本地服务，甚至让登录验证或企业安全策略出现异常。日常办公和开发通常适合“明确目标走代理，其余直连”；需要临时检查整体出口时，才考虑短时间切换到全局模式。

• ✅ 先写出必须直连的局域网、内网和本地服务。
• ✅ 再添加明确需要代理的应用或域名。
• ✅ 规则名称使用容易理解的描述，避免只保留一串缩写。
• ❌ 不要把“全局模式”当作长期替代分流规则。
• ❌ 不要同时开启多个会接管系统代理或虚拟网卡的客户端。

在 Windows 上完成一次应用与域名分流

下面以兼容 Windows 的图形化客户端为例说明操作思路。不同软件的菜单名称可能是“规则”“Profiles”“Routing”“分流”或“模式”，但配置步骤可以对应起来。使用 Clash Verge、sing-box 客户端或服务商提供的官方客户端时，先确认软件是否支持规则模式、系统代理和 TUN 模式，再决定采用哪一种接管方式。

第一步：导入并确认配置来源

如果使用订阅链接，先在客户端的配置或订阅页面添加链接并完成更新。导入成功的标准不是页面出现一个配置名称，而是能够看到规则、代理组或可选择的线路。订阅链接属于配置凭据，不要复制到公开聊天、截图或来源不明的在线转换工具中。

如果使用本地配置文件，应先确认文件格式与客户端内核兼容。Clash 系配置、sing-box 配置以及其他客户端的 JSON 或 YAML 文件不能随意互换。导入后如果出现空白规则、字段错误或代理组缺失，优先检查格式和内核支持，不要立即修改 Windows 的网络设置。

第二步：启用规则模式和必要的接管方式

在客户端中选择规则模式，而不是全局模式。随后根据应用范围决定是否开启系统代理。只需要让浏览器和支持系统代理的软件工作时，可以先使用系统代理；如果终端、独立程序或不读取系统代理的应用也需要参与分流，再评估是否启用 TUN。

启用 TUN 前，记录当前的局域网访问情况，例如路由器管理页、局域网文件共享、远程桌面和打印服务。部分客户端提供“绕过局域网”“允许局域网访问”或类似选项，应根据实际需求开启。若启用后本地服务失效，先关闭 TUN 或恢复原设置进行对照，不要连续修改多项参数。

第三步：添加应用与域名规则

应用规则通常需要填写进程名或程序路径。进程名必须与任务管理器中实际运行的名称一致；有些软件的启动器、主程序和后台更新程序是不同进程，因此只添加启动器并不代表所有请求都会被匹配。对于桌面软件，建议先观察实际进程，再决定是否使用应用规则。

域名规则可以使用完整域名、子域名或域名后缀。添加网站时，不要只凭浏览器地址栏里的主域名判断全部请求。登录、图片、接口、字体和静态资源可能来自不同域名。可以先通过客户端连接日志观察请求目标，再补充必要规则。规则不宜无限扩张，否则网站改版或第三方服务变化后，维护成本会持续增加。

第四步：重新加载并逐项测试

保存规则后，执行客户端提供的“应用”“重新加载配置”或“更新规则”操作。仅修改文件并不一定会让正在运行的内核立即读取新内容。对于已经建立连接的浏览器标签页、终端会话和后台程序，最好关闭连接后重新启动，以免旧连接继续沿用之前的路径。

测试时不要只看客户端显示“已连接”。先测试一个应当直连的目标，再测试一个应当代理的目标，最后测试没有写入规则的普通网站。观察日志中的匹配规则、动作和代理组名称，结合 IP 检测页面确认出口变化。若应用规则与域名规则同时存在，应特别检查究竟是哪一条规则先被命中。

用日志和分层方法检查规则是否生效

分流问题需要分层排查。网页打不开并不一定是规则错误，也可能是订阅失效、线路握手失败、DNS 返回异常、应用缓存连接或 Windows 防火墙阻止了流量。一次只改变一个变量，才能知道修复动作是否真正有效。

先看客户端是否命中规则

打开客户端的连接日志或请求日志，重新访问目标网站，观察是否出现请求记录。若完全没有记录，说明应用可能没有经过客户端接管，或者该应用没有使用系统代理。若有记录但动作错误，重点检查规则顺序、域名写法和默认策略。若动作正确但连接失败，再转向线路、协议或 DNS 层排查。

再检查 DNS 与解析结果

域名分流依赖客户端识别目标域名。如果应用先通过本地 DNS 解析，再直接连接 IP，客户端可能无法按照预期匹配域名规则。某些软件还会使用自己的 DNS、DoH 或缓存机制，导致系统设置与应用实际解析路径不同。

在 Windows 中可以使用系统工具查看基础解析结果，例如在终端中运行 nslookup example.com，但这只能反映该命令使用的解析路径，不能完全代表浏览器或 TUN 内核的行为。更可靠的方式是结合客户端日志、应用开发者工具和实际出口结果判断。不要因为一次解析结果不同，就直接认定代理线路失效。

最后检查本地服务与 IPv6

如果开启 TUN 后无法访问路由器、局域网共享或本地开发服务，先检查是否启用了绕过局域网选项，以及内网网段是否被错误地送入代理。使用 localhost、局域网主机名和局域网 IP 的应用，匹配方式可能不同。

IPv6 也可能造成“浏览器看似走代理，某些请求仍然直连”的现象。如果客户端或当前线路对 IPv6 支持不完整，而系统或应用优先使用 IPv6，就可能出现连接超时、地区判断不一致或规则日志不完整。应先确认客户端对 IPv6 的处理方式，再决定是为 IPv6 添加明确规则，还是在可控范围内关闭相关优先级。不要在不了解网络环境的情况下修改系统注册表或批量禁用网卡协议。

正确的验证顺序是：请求是否进入客户端、是否命中预期规则、规则动作是否正确、线路是否建立连接、DNS 是否符合预期、应用是否复用旧连接。跳过前面的层级，直接更换节点，往往只能暂时掩盖问题。

常见误配与长期维护方法

最常见的误配是同时运行两个代理客户端。两个程序可能争抢系统代理端口、重复创建虚拟网卡，或者分别写入不同的 DNS 设置。结果可能表现为网页偶尔打开、部分应用完全无法连接，甚至关闭其中一个客户端后网络仍未恢复。排查时应只保留一个负责接管网络的客户端，并恢复系统代理设置后重新启用。

第二种误配是把应用名称写错。Windows 程序可能由启动器拉起另一个真正处理网络请求的进程，规则看起来已经添加，实际请求却没有命中。可以使用任务管理器确认进程名称，也可以通过客户端日志观察请求来源。对于浏览器多进程架构，不建议仅凭猜测添加一长串进程；优先使用域名规则，必要时再补充应用规则。

第三种误配是把规则写得过于宽泛。例如将整个顶级域名、所有未知请求或所有 IP 都交给代理，短期内可能感觉“什么都能访问”，但本地服务、企业系统和部分支付页面也会受到影响。规则应尽量接近实际目标，使用明确的域名后缀、应用路径或内网网段，并定期删除已经不再需要的例外。

第四种误配是更新订阅后覆盖本地规则。部分客户端把订阅配置视为完整配置文件，更新后可能替换手动添加的规则；另一些客户端则支持本地覆写或规则附加。修改前先确认客户端的配置合并方式，并保留一份可恢复的本地设置。不要直接编辑每次更新都会被覆盖的远程内容。

• ✅ 每次只修改一项设置，并在修改后重新测试。
• ✅ 为规则保留清楚的名称，记录它解决的具体问题。
• ✅ 更新订阅后检查规则模式、系统代理和 TUN 状态。
• ❌ 不要把日志中的一次连接成功当成所有应用都已分流。
• ❌ 不要把 DNS 异常、线路故障和应用权限问题混为同一类故障。

如果只是让少量网站或一个应用经过代理，可以先从系统代理和域名规则开始；如果需要覆盖不读取系统代理的程序，再评估 TUN 或虚拟网卡。无论使用官方客户端、Clash Verge 还是 sing-box 兼容客户端，都应优先确认客户端内核支持的规则格式、匹配优先级和配置更新方式。把配置逻辑保留下来，比临时复制一份别人无法解释的规则更有价值。