系统代理、全局模式与绕过大陆模式的区别:三种代理方式怎么选

v2rayN 中的“系统代理”“全局”“绕过大陆”并不是同一层级的三个互斥开关。系统代理决定哪些应用会把连接交给本地客户端，全局与绕过大陆则决定连接进入 Xray 或 V2Ray 内核后应该选择哪个出站。先区分入口接管和内核路由，才能解释浏览器能访问而某个程序仍然直连、切换全局后国内网站变慢、游戏流量没有经过节点等常见现象。

本文速览

本文适合正在使用 v2rayN 7.x、v2rayNG 或 v2flyNG，却不确定代理模式含义的用户。阅读后可以判断应用流量是否被接管、理解全局与规则分流的差异，并根据网页浏览、境外服务和游戏连接选择可验证、可回退的配置。

系统代理、全局与绕过大陆分别控制什么

系统代理属于操作系统入口层。以 v2rayN 7.13.2 的常见默认设置为例，客户端在本机监听 SOCKS 端口 127.0.0.1:10808 和 HTTP 端口 127.0.0.1:10809。托盘菜单选择“系统代理”→“自动配置系统代理”后，Windows 的代理设置会指向本地 HTTP 入口。浏览器、部分办公软件和遵循系统网络设置的程序会将请求交给 v2rayN。

全局模式属于内核路由层。连接已经进入本地代理端口后，内核通常把可代理的流量统一发送到当前选中的 VMess、VLESS 或其他节点出站。这里的“全局”不代表系统中每一个进程都会自动进入代理；未读取系统代理设置、直接建立套接字或使用独立网络栈的程序，仍可能绕过本地监听端口。

绕过大陆模式同样属于路由层，但它会根据域名和目标 IP 分类。常见规则让 geosite:cn、geoip:cn 与局域网地址走直连，其余匹配项走代理。其效果依赖 GeoSite、GeoIP 数据是否及时更新，也依赖域名解析结果、规则顺序和最终兜底规则，不应理解成对每个网站地理位置的实时识别。

仅开启系统代理

负责把遵循系统设置的应用流量送入本地端口，实际出口仍由当前路由规则决定。

适合:先验证浏览器和常规桌面软件

系统代理加全局路由

进入内核的连接优先使用代理出站，排查节点、订阅和协议连通性时变量最少。

适合:短时诊断、单节点连通测试

系统代理加绕过大陆

为什么开启系统代理后仍有程序直连

系统代理不是操作系统级的全流量重定向。浏览器通常会读取 Windows 代理设置，但游戏启动器、更新器、命令行工具和部分基于 UDP 的程序可能忽略该设置。有些应用只读取启动时的代理状态，v2rayN 切换模式后需要完全退出并重新启动应用；另一些应用提供自己的代理选项，应在软件内部填写 127.0.0.1 与对应端口。

DNS 也会影响观察结果。应用可能先通过系统 DNS 获得 IP，再把连接送入 SOCKS 或 HTTP 入口；启用远程 DNS、FakeDNS 或 TUN 后，解析路径又会变化。只看到网页打开，并不能证明域名解析与数据连接采用同一出口。排查时应查看 v2rayN 实时日志中的目标地址、入站标签和出站标签，而不是只依靠浏览器显示结果。

7.13.2

本文 v2rayN 示例版本

10808

常见本地 SOCKS 端口

10809

常见本地 HTTP 端口

127.0.0.1

仅本机可访问的监听地址

流量来源	系统代理能否接管	更合适的入口	验证位置
常规浏览器网页	通常可以	HTTP 系统代理	v2rayN 实时日志
手动配置代理的软件	取决于软件设置	HTTP 或 SOCKS	软件网络设置与客户端日志
不读取系统代理的进程	通常不能	TUN 或程序自身代理	连接目标与进程流量
UDP 实时连接	通常不完整	TUN、透明代理或专用网络方案	UDP 会话与延迟记录

结论:先确认流量有没有进入内核

切换全局或绕过大陆只会改变已进入内核的连接。日志里完全没有目标连接时，应检查系统代理、应用内代理或 TUN 接管，而不是继续修改路由规则。

v2rayN 中三种模式的设置与验证顺序

开始调整前先更新订阅并选择一个已验证可用的节点。订阅只是服务器配置列表，不会自动决定系统代理状态；更换 VMess 或 VLESS 节点后，也不会自动把所有程序流量接管。建议一次只改变一个变量，并记录原来的系统代理与路由模式。

在 v2rayN 7.x 中，可先进入“设置”→“参数设置”→“基础设置”，确认本地监听端口没有与其他程序冲突。随后从托盘菜单选择“系统代理”→“自动配置系统代理”，再打开路由菜单选择“全局”或“绕过大陆”。不同小版本的菜单文字可能略有变化，但入口层与路由层仍应分别设置。

选择节点后运行一次延迟测试。延迟只能反映探测结果，不能替代实际网页或下载连接测试。
开启系统代理，重新启动待测试浏览器，访问一个常用国内站点和一个需要代理出口的服务。
打开 v2rayN 的实时日志，确认请求从本地 HTTP 或 SOCKS 入站进入，并观察使用了 direct 还是 proxy 出站。
先切换全局模式验证节点本身。如果全局可用而绕过大陆异常，重点检查路由顺序、GeoSite、GeoIP 与 DNS。
测试结束后恢复原模式。若曾手动填写应用代理，也要同步恢复，避免形成重复代理链。

推荐方案:先用全局诊断，再切规则分流

诊断阶段

系统代理设为自动配置
路由暂时选择全局
固定一个可用节点
记录实时日志与连接耗时

日常阶段

保留系统代理入口
路由切换绕过大陆
更新 GeoSite 与 GeoIP
为特殊域名单独加规则

全局正常而规则模式异常，通常说明节点与订阅可用，问题范围可收敛到路由数据、规则顺序或 DNS。

日常浏览、境外服务与游戏连接怎么选

日常网页与办公软件

优先选择“系统代理加绕过大陆”。国内网页、软件更新与本地服务通常走直连，境外服务按规则进入代理，节点流量和连接延迟更可控。若某个域名被误判，可以添加一条更靠前的域名规则，而不是长期改成全局。

临时排查境外服务

先使用全局模式缩小问题范围。假设绕过大陆下页面无法加载，而全局模式立即恢复，应查看该域名是否命中了直连规则、DNS 是否返回了与预期不同的地址，以及规则集中是否存在更靠前的匹配项。确认原因后应修正规则，再恢复分流。

游戏与实时 UDP

仅开启系统代理通常不足以接管游戏流量。需要接管不读取系统代理的进程时，可评估 v2rayN 的 TUN 模式。TUN 会创建虚拟网络接口并扩大接管范围，同时也会增加 DNS、路由表、管理员权限和局域网访问方面的排查项目。

网页浏览：优先系统代理加绕过大陆，重点验证域名规则与浏览器出口。
境外服务：短时全局用于诊断，确认后使用域名规则精确分流。
实时游戏：先确认服务器区域、基础延迟和丢包，再评估 TUN；代理路径不会自动改善物理距离造成的延迟。
局域网设备：打印机、路由器管理页和文件共享地址应保留直连，常见私有地址段不应送往远端节点。

绕过大陆模式失准时检查哪些规则

规则系统通常按顺序匹配，命中后便使用指定出站。一个域名既可能匹配自定义域名规则，也可能在 GeoSite 分类中出现；解析后的 IP 又可能命中 GeoIP。排查时应从最具体的自定义规则开始，再检查数据集规则与最终兜底，不要同时批量修改多个规则组。

域名策略也会改变 IP 规则是否参与判断。若内核只按域名匹配，某些连接不会继续解析并匹配 GeoIP；若启用需要解析的策略，则 DNS 返回结果可能影响出站。配置概念可用下面的简化结构理解，实际字段应以当前内核和客户端生成的配置为准。

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

全局模式可用，绕过大陆模式打不开部分网站怎么办？

先在实时日志中确认目标域名命中的出站，再更新 GeoSite 与 GeoIP 数据。若域名被错误归入直连，可添加优先级更高的代理规则，并检查 DNS 返回地址是否命中现有 IP 规则。

开启系统代理后命令行下载仍然直连怎么办？

确认该工具是否读取系统代理。若需要显式配置，可在工具支持的代理参数中填写本地 HTTP 地址 http://127.0.0.1:10809，或按其文档使用 SOCKS 入口。修改后通过 v2rayN 日志确认连接已经进入内核。

v2rayNG 与 v2flyNG 的模式逻辑是否相同？

两者在安卓系统上通过本地虚拟网络接口接管流量，入口机制与桌面系统代理不同，但全局和按规则分流仍然用于选择出站。v2rayNG 通常使用 Xray 内核，v2flyNG 使用 v2fly 内核，具体可用字段应以客户端当前内核支持范围为准。

三种模式的最终选择规则

对多数桌面用户，稳定的起点是“自动配置系统代理加绕过大陆”。它覆盖常规浏览器与遵循系统设置的软件，同时保留国内和局域网流量直连。全局模式更适合短时诊断或明确需要所有已接管连接统一走节点的场景，不宜把它当作解决所有网络问题的固定开关。

当目标程序不读取系统代理时，应先选择应用内 HTTP/SOCKS 配置；只有需要接管更多进程、UDP 或无法单独设置代理的流量时，再评估 TUN。每次调整后都要用实时日志验证入站和出站，避免仅凭网页是否打开判断配置是否正确。

浏览器和常规桌面软件：系统代理加绕过大陆。
节点或协议连通排查：系统代理加全局，确认后恢复分流。
单个应用误分流：添加精确域名或 IP 规则，不整体切换全局。
不读取系统代理或依赖 UDP：检查应用内代理，必要时评估 TUN。
模式频繁失准：更新地理数据，检查 DNS、规则顺序与最终兜底。

结论:模式选择应按“入口、路由、节点”三层排查

日志没有连接就检查入口，连接走错出口就检查路由，已经命中代理但握手失败才检查节点、协议与服务端参数。按层定位比反复切换全局更快，也更容易恢复原配置。