安卓VPN分流规则怎么设？指定应用直连一次配好

安卓 VPN 分流的核心，不是让所有应用都走同一条线路，而是先确定哪些应用需要通过 VPN，哪些应用应当保持直连。办公软件、网银、局域网工具、流媒体和浏览器对网络出口的要求可能不同：有的应用需要稳定的远端出口，有的应用依赖本地网络或地区服务。把所有流量一律代理，可能造成局域网设备无法访问、应用定位异常或不必要的流量消耗；把所有流量都直连，又无法满足特定应用的连接需求。

Android 上的分流通常由客户端创建系统 VPN 接口后执行。客户端可能提供“排除应用”“仅代理选定应用”“规则模式”“绕过局域网”或“按域名分流”等选项，不同软件的名称和实现方式并不完全一致。本文以通用排查思路为主，说明应用排除、规则优先级、DNS 检查和故障回退的方法。开始前，建议先完成基础订阅导入与连接验证；如果客户端尚未正常建立隧道，应先参考新手指引完成安装和连接。

先记住一个原则 分流规则只负责决定流量走哪条路径，不能修复协议不兼容、订阅失效、应用自身故障或远端服务限制。先确认全局连接正常，再配置分流，排错会简单很多。

先理解安卓 VPN 分流的几种模式

最常见的分流方式有三类。第一类是全局模式，设备上的网络请求尽可能都交给 VPN 处理，适合排查基础连接，也适合希望统一使用同一出口的场景。第二类是排除应用，也叫“全局代理但绕过指定应用”：除用户选中的应用外，其他应用继续通过 VPN。第三类是仅代理选定应用，只有名单内的应用使用 VPN，其余应用保持直连。

如果你的目标是“指定应用使用 VPN，其他应用直连”，应优先寻找“仅代理选定应用”或“允许列表”一类选项；如果目标是“所有应用默认使用 VPN，但网银、办公或局域网应用直连”，则应使用“排除应用”或“黑名单”模式。两者的名单含义相反，最容易发生的错误就是看到了应用列表，却没有确认列表代表“走 VPN”还是“绕过 VPN”。

应用分流和域名分流也不是一回事。应用分流根据 Android 应用身份决定路由，配置直观，适合处理“某个应用整体走直连或代理”的需求。域名分流则根据请求的域名、IP 或规则集判断路径，能够细分同一应用中的不同服务，但对 DNS、规则格式和客户端实现要求更高。刚开始配置时，建议先用应用分流完成验证，再逐步增加域名规则。

还要注意 Android 的应用身份通常与包名有关，而不是应用桌面上显示的名称。同一家公司可能提供正式版、测试版、国际版和工作资料版，它们在系统中可能被视为不同应用。选择列表中的项目时，应结合图标、开发者和实际启动的版本确认，不能只凭相似名称判断。

配置前先整理应用与网络需求

配置分流之前，先列出需要代理和需要直连的应用，比直接在客户端里逐项点击更可靠。可以按“必须走 VPN”“必须直连”“暂时不确定”三组整理。需要代理的应用可能包括特定浏览器、流媒体客户端、AI 工具或跨地区服务；需要直连的应用则可能包括本地银行、企业内网、校园系统、打印工具、智能家居和依赖局域网发现的应用。

• ✅ 先记录应用的准确名称和版本来源，避免把测试版与正式版混在一起。
• ✅ 把工作资料、个人资料和系统分身中的同名应用分别确认。
• ✅ 对必须直连的应用，先确认它是否依赖本地 IP、局域网发现或运营商服务。
• ✅ 对必须代理的应用，准备好连接前后的出口 IP、DNS 和登录状态检查。
• ❌ 不要一开始同时修改应用名单、DNS、协议和线路，无法判断变化来自哪里。

Android 的“个人资料”和“工作资料”可能拥有独立的应用实例。即使屏幕上看到两个相同图标，客户端也可能只识别其中一个，或者系统策略不允许工作资料应用使用个人 VPN。企业设备还可能由管理员限制 VPN、后台运行或应用网络权限。如果出现个人浏览器可以按规则连接，而工作应用完全不受规则影响，应先检查资料环境和设备管理策略。

应用排除并不总能覆盖应用调用的全部网络请求。部分应用会启动独立的 WebView、外部浏览器、下载组件或系统服务；某些功能还会通过推送服务、媒体服务或第三方登录组件完成。此时主应用命中代理，并不代表所有关联请求都使用相同路径。排查时要观察具体失败环节：是登录页打不开、图片加载失败、视频接口失败，还是后台通知没有到达。

如果客户端支持“绕过局域网”选项，可以根据实际需求开启。家庭路由器管理页、网络打印机、局域网文件共享和投屏设备通常需要访问本地地址。开启后，局域网请求可以保持本地路径，而外部目标仍按应用或域名规则处理。但如果你需要通过远端网络访问某个内网地址，则不应机械开启绕过局域网，应以目标地址和客户端说明为准。

动手设置：让指定应用直连或代理

不同 Android 客户端的菜单名称可能略有差异，但操作顺序通常接近。为了避免误操作，建议在修改前记录当前模式、当前线路和 DNS 设置。这样出现问题时，可以快速恢复到原来的工作状态，而不是删除全部配置重新开始。

1. 打开客户端，确认订阅已经更新，先连接一条能够正常使用的线路。
2. 进入设置、路由、分流或应用管理页面，寻找“应用代理”“应用分流”“排除应用”等选项。
3. 先确认模式是“仅代理选定应用”还是“排除选定应用”，不要直接根据列表标题猜测。
4. 选择需要调整的应用，保存名单后返回主界面。
5. 断开并重新连接 VPN，让新的 Android VPN 接口和路由设置生效。
6. 先测试一个明确需要代理的应用，再测试一个明确需要直连的应用。
7. 确认结果后，再逐个加入其他应用，并为每次变化保留简单记录。

以“指定应用直连、其他应用继续使用 VPN”为例，应使用排除应用模式，把需要直连的应用加入排除名单，而不是把它们加入代理名单。保存后，VPN 状态仍可能显示为已连接，这是正常现象；系统 VPN 连接状态只说明隧道存在，不说明每个应用都一定经过远端线路。真正的判断应放在应用请求的出口 IP、DNS 结果和实际访问行为上。

如果使用“仅代理选定应用”模式，则名单内应用才会进入 VPN。此模式适合只想让某个浏览器、视频应用或 AI 工具使用远端出口的情况，也能减少其他应用的不必要转发。不过，应用更新、重新安装或切换资料环境后，系统识别的应用项可能发生变化，应重新检查名单。应用被卸载后重新安装，也不应假设旧规则一定仍然有效。

配置完成后，建议按照“单应用、单线路、单变量”的方法验证。先保持同一网络和同一线路，只切换一个应用的分流状态；观察完成后，再改变另一个应用。不要在一个步骤里同时切换协议、线路、DNS 和路由模式，否则即使问题消失，也无法知道真正起作用的设置。

检查规则优先级与 DNS 是否一致

当客户端同时提供应用规则、域名规则、IP 规则和全局开关时，优先级就会影响最终结果。不同客户端的排序方式可能不同，有的从上到下匹配，有的把系统开关放在所有规则之前，还有的会把应用排除作为独立层处理。因此不能仅凭其他客户端的经验推断当前软件的规则顺序，应查看客户端说明或在日志中确认实际命中结果。

一个实用的排查顺序是：先看全局模式，再看应用是否被选中，随后看域名或 IP 规则，最后确认是否存在“直连优先”“代理优先”或“绕过局域网”之类的开关。如果同一个应用被设置为代理，但它访问的域名又被域名规则指定直连，最终结果可能由更具体的域名规则决定。相反，某些客户端会让应用规则覆盖域名规则，必须以实际实现为准。

DNS 是分流中经常被忽略的一环。应用请求可能已经按预期进入 VPN，但域名解析仍由本地网络完成；也可能应用被设置为直连，却继续使用 VPN 提供的 DNS。这样会出现网页能打开但地区判断不一致、域名解析到不可达地址、局域网名称无法解析或某个应用反复登录失败等现象。

• 连接全局 VPN 后，检查外部 IP 是否变化，再检查 DNS 解析路径是否符合客户端设置。
• 把目标应用切换为直连，观察它访问本地服务时是否恢复正常。
• 清理应用缓存或重新启动应用，避免旧 DNS 缓存和旧连接复用干扰判断。
• 如果只有域名访问失败而直接 IP 行为不同，应优先检查 DNS、规则集和域名匹配。
• 如果局域网设备无法发现，检查局域网绕过、Multicast、系统权限和应用自身发现机制。

协议也会影响分流表现。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC 和 WireGuard 的客户端实现、DNS 接管方式以及 UDP 支持可能不同。Hysteria2 与 TUIC 常使用 UDP 或 QUIC 传输，在受限网络中可能与基于 TCP 或 TLS 的线路表现不同；WireGuard 是隧道协议，客户端路由和 AllowedIPs 配置会直接影响哪些地址进入隧道。协议名称不能代替实际的路由验证，导入订阅后还要检查客户端是否正确解析传输参数。

DNS 判断提示 如果应用规则看起来正确，但地区识别、域名解析或局域网访问异常，不要只重复切换线路。先确认 DNS 是由谁提供、请求是否被分流，以及应用是否缓存了旧结果。

用可回退的方法验证，出错时快速恢复

分流验证应覆盖“代理应用”和“直连应用”两条路径。代理应用可以检查出口 IP 是否符合预期、目标页面是否能正常加载、登录和媒体请求是否连续；直连应用则应检查本地服务、企业系统、银行页面或局域网设备是否恢复正常。不要只看到 VPN 图标就认为设置成功，也不要只用一个网页代替所有应用测试，因为不同应用可能使用不同的网络接口和请求组件。

可以先关闭分流，使用全局模式建立基准；确认基础连接正常后，再启用应用分流。若启用后代理应用无法访问，先把该应用临时加入全局代理范围，判断问题来自分流还是线路。如果全局代理也失败，应回到协议、订阅、线路和 DNS 方向排查。如果全局代理正常而分流失败，则重点检查应用名单、规则优先级和应用是否绕过系统 VPN。

故障回退时，最安全的做法不是立即清除所有数据，而是按层恢复：先把模式改回全局或关闭自定义分流，再断开并重连；如果仍然异常，再恢复 DNS 设置；最后才考虑更换线路或重新导入订阅。每次只撤销一层配置，便于定位问题，也能避免把已经正确的订阅和节点信息一并删除。

• ✅ 修改前记录当前模式、线路和 DNS 选项。
• ✅ 每次只增加或删除一个应用，完成测试后再继续。
• ✅ 代理应用和直连应用都要验证，不要只测试其中一类。
• ✅ 锁屏、切换 Wi-Fi 与移动网络后，重新检查分流是否仍然生效。
• ❌ 不要同时开启两个使用系统 VPN 接口的客户端。
• ❌ 不要把完整订阅链接、二维码或包含认证字段的日志发到公开空间。

如果锁屏后规则失效，应检查 Android 的电池优化、后台运行、自动启动和后台数据权限。不同厂商的系统菜单名称可能不同，但排查目标一致：允许客户端保持必要的后台活动，并确认系统没有在屏幕关闭后终止 VPN 服务。若切换网络后无法恢复，则可分别测试其他协议或线路；UDP 类传输受限时，基于 TCP 或 TLS 的配置可能更容易建立连接，但仍应以客户端兼容性和服务端配置为准。

当问题需要提交给服务商时，应描述发生阶段和复现条件，例如“全局模式正常，加入某应用后无法访问”“直连应用可以打开本地页面，但外部域名解析失败”。日志提交前要遮盖账号、订阅令牌、服务器认证字段和个人访问记录。清楚的现象描述比一张包含完整隐私信息的截图更有帮助。

完成设置后，建议把分流规则保持简单。能够用应用名单解决的问题，不必马上加入大量域名和 IP 规则；能够通过直连访问的本地服务，也不必强行放进远端隧道。规则越少，后续更新、换机和排错越容易。随着应用版本或客户端功能变化，再根据实际现象补充规则，比一次性复制复杂配置更稳妥。