订阅分组与服务器过滤
订阅分组是 v2rayN 管理多个机场或自建订阅的基础手段。很多用户一开始只添加一个订阅，把所有节点混在一起；等节点数量超过几十个，再想找到某个特定地区的节点就变得很费劲。订阅分组解决的就是这个问题：把不同来源的节点放进独立的分组，分组之间互不干扰，更新、筛选、延迟测试都按组进行。
在 v2rayN 主界面中，打开“订阅分组”菜单，进入“订阅分组设置”。在这里可以新建分组，并为分组命名，比如“主力机场”“备用自建”“工作专用”。每个分组可以绑定一个或多个订阅地址。绑定完成后，v2rayN 会把该订阅拉取到的节点归入这个分组，主界面的服务器列表会按分组显示为树状结构，展开某个分组就能看到该分组下的全部节点。
分组的另一个实用功能是独立的自动更新间隔。在订阅分组设置里，可以给每个分组分别配置更新间隔，例如主力机场每 12 小时更新一次，备用自建每 24 小时更新一次。v2rayN 会在后台按照这个间隔自动拉取订阅，不需要手动点击刷新。这样即使某个订阅临时失效，也不会影响其他分组的正常更新。
服务器过滤是订阅分组的自然延伸。当节点数量很多时，服务器列表上方的筛选框可以按协议类型（VMess / VLESS / Trojan / Shadowsocks）过滤，也可以按延迟、地区、分组排序。过滤后的视图可以一键全选，然后批量测试延迟。延迟测试时，建议在“设置—参数设置”里把测试 URL 改成自己平时访问的地址，比如一个常用的网页或生成式 204 页面，这样测出来的延迟更接近实际使用体验。部分节点对默认测试 URL 有特殊处理，换一个目标地址能避免误判。
订阅分组与服务器过滤结合起来，能形成一套很实用的工作流：先按订阅来源分组，再在组内按协议或延迟筛选，最后把筛选结果通过“设置”里的“服务器排序”固定下来。日常使用时只需要展开对应分组，选择延迟最低的节点即可。
如果希望从配置文件层面理解订阅分组，v2rayN 的 guiConfig.json 中有一个 subItem 数组，每个元素代表一个订阅项。下面是一个简化的示例，展示了订阅项的基本字段：
{
"subItem": [
{
"id": "a1b2c3d4",
"remarks": "主力机场",
"url": "https://example.com/subscribe?token=xxxx",
"enabled": true,
"autoUpdateInterval": 12
},
{
"id": "e5f6g7h8",
"remarks": "备用自建",
"url": "https://home.example.net/sub",
"enabled": true,
"autoUpdateInterval": 24
}
]
}url 字段是订阅链接，remarks 是显示名称，enabled 控制该订阅是否参与更新，autoUpdateInterval 是以小时为单位的自动更新间隔。手动编辑这个文件前，建议先关闭 v2rayN，编辑完成后再重新打开，避免 GUI 覆盖修改。
路由规则实战
路由规则决定流量往哪里走：是直连、走代理，还是直接阻断。对于大多数用户来说，默认的“绕过大陆”规则已经足够；但如果需要更精细的分流——比如某些域名强制走代理、某些 IP 段强制直连——就需要手动编辑路由规则。
路由规则依赖两个数据集合：geosite 是域名集合，geoip 是 IP 集合。例如 geosite:cn 包含国内常见域名，geoip:cn 包含国内 IP 段。v2rayN 内置的规则模板就是基于这两个集合拼装出来的。在“设置—路由设置”里，可以直接选用内置模板，比如“全局代理”“绕过局域网”“绕过大陆”等。
如果内置模板不满足需求，可以编辑 config.json 的 routing 部分。路由规则是一个数组，按照从上到下的顺序逐条匹配，第一条命中的规则生效，后面的规则不再执行。因此规则的排列顺序非常重要：通常把直连规则放在最前面，代理规则放最后，作为兜底。
下面是一份典型的“国内直连、国外走代理”的规则组：
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{ "type": "field", "domain": ["geosite:cn"], "outboundTag": "direct" },
{ "type": "field", "ip": ["geoip:cn"], "outboundTag": "direct" },
{ "type": "field", "domain": ["geolocation-!cn"], "outboundTag": "proxy" }
]
}
}domainStrategy 控制域名匹配的顺序。默认值是 AsIs，即只按域名匹配；改成 IPIfNonMatch 后，如果一个域名没有命中任何域名规则，v2ray 会先解析该域名的 IP，再拿 IP 去匹配 geoip 规则。这样能覆盖那些没有收录在 geosite 里的域名，代价是首次访问时多一次 DNS 解析。
三个规则的逻辑是：先匹配国内域名，直接出站；再匹配国内 IP，直接出站；最后匹配“非国内地理位置的域名”，走代理。这里 geolocation-!cn 是 v2ray 内置的一个特殊域名集合，等价于“除中国以外的地理位置所覆盖的域名”。
规则不生效时，按以下顺序排查：第一，确认 outboundTag 的值是否存在。v2rayN 默认代理出站的标签是 proxy，直连出站是 direct，如果自定义出站时改了标签，路由规则里也要同步修改。第二，检查规则顺序。如果某条规则写在了更宽泛的规则后面，可能永远匹配不到。第三，检查 domainStrategy。如果域名没有命中任何域名规则，又没启用 IPIfNonMatch，该域名就不会走 geoip 匹配，可能漏掉。第四，确认域名是否真的在 geosite 里。某些冷门域名没有收录，需要手动把域名加进规则，比如 "domain": ["example.com", "geosite:cn"]。
路由规则与订阅分组配合使用，可以实现很精细的流量调度：把某个分组的节点作为“工作专用”，在路由规则里把办公相关域名指向这个分组的代理出站。这比手动切换节点更稳定。
关于国内外分流的更完整配置示例，可参考本站博客文章《v2rayN 路由规则配置实战：国内直连、国外走代理的完整分流方案》。
DNS 配置优化
DNS 解析是网络访问的第一步。在代理场景下，DNS 解析的结果可能影响流量走向：如果 DNS 被污染，即使代理节点正常，也可能出现“连上了但打不开网页”的情况。因此，DNS 配置优化是进阶配置里非常关键的一环。
v2rayN 的 DNS 设置位于“设置—参数设置”中。界面上通常有“远程 DNS”和“本地 DNS”两个输入框。远程 DNS 走代理网络，用于解析国外域名；本地 DNS 走直连网络，用于解析国内域名。常见的远程 DNS 有 1.1.1.1 和 8.8.8.8，常见的本地 DNS 有 223.5.5.5（阿里）和 119.29.29.29（腾讯）。
如果希望更精细地控制 DNS 查询，可以编辑 config.json 的 dns 部分。下面是一个按域名分流 DNS 查询的示例：
{
"dns": {
"servers": [
{ "address": "1.1.1.1", "domains": ["geosite:geolocation-!cn"] },
{ "address": "223.5.5.5", "domains": ["geosite:cn"] },
{ "address": "8.8.8.8" }
]
}
}这段配置的意思是：非中国地理位置的域名（geosite:geolocation-!cn）使用 1.1.1.1 解析；中国域名（geosite:cn）使用 223.5.5.5 解析；其他未匹配的域名使用 8.8.8.8 作为兜底。这里 domains 字段是可选的，不写就表示该服务器作为默认兜底。
DNS 防泄漏是另一个重要话题。如果系统代理没有接管所有流量，某些浏览器扩展或后台应用可能绕过代理，直接向系统 DNS 发起查询，导致解析结果被污染。解决方式有两种：一是使用 TUN 模式（下一章介绍）接管全部流量；二是在 v2rayN 的 DNS 设置里勾选“防止 DNS 泄漏”相关选项，把 DNS 查询也纳入代理通道。
配置 DNS 时需要注意：远程 DNS 本身也要走代理，否则它自己就被污染了。v2rayN 默认会把远程 DNS 的流量交给代理出站，这依赖于路由规则中的 DNS 分流逻辑。如果你手动编辑了路由规则，务必保留一条把 DNS 流量导向代理的规则，否则远程 DNS 可能无法解析国外域名。
TUN 模式
TUN 模式是 v2ray 客户端的一项高级功能：它创建一个虚拟网卡，把整个系统的网络流量都接管过来，包括那些不遵守系统代理设置的应用、UDP 流量以及命令行工具。对普通用户来说，TUN 模式意味着“开了之后，所有程序都走代理”，不需要逐个应用配置代理。
适用场景主要包括三类：一是需要全局代理的场合，比如某些应用只认系统代理但系统代理又照顾不到；二是 UDP 流量，比如游戏、语音通话，系统代理通常不转发 UDP；三是命令行工具，比如 git、curl，它们默认不读取 Windows 的系统代理设置。
在 v2rayN 中开启 TUN 模式很简单：打开“设置—参数设置”，找到“启用 TUN 模式”开关并勾选。首次开启时，Windows 会弹出 UAC 用户账户控制提示，因为虚拟网卡需要管理员权限才能创建。macOS 上则需要输入管理员密码或授权内核扩展。开启后，v2rayN 会创建一个虚拟网卡，并自动把系统默认路由指向这个网卡。
TUN 模式与系统代理的区别需要说清楚。系统代理只对“主动读取代理设置”的应用生效，浏览器、部分下载工具会读取，但很多应用不会；TUN 模式是在网卡层面接管，所有流量都会经过虚拟网卡，因此覆盖面更广。但 TUN 模式也有代价：性能开销比系统代理略高，因为所有流量都要经过一次虚拟网卡；而且如果配置不当，可能影响局域网访问。
开启 TUN 模式后，路由规则仍然生效。也就是说，你可以在 TUN 模式里继续做分流：国内流量直连，国外流量走代理。TUN 模式只是提供了“流量入口”，具体的走向仍由路由规则决定。
下面是 v2rayN 的 config.json 中 TUN 部分的示例：
{
"tun": {
"enable": true,
"stack": "system",
"dns": "1.1.1.1"
}
}stack 是网络栈的实现方式。Windows 上推荐 system，它使用系统自带的网络栈，兼容性最好；macOS 上推荐 gvisor，能避免一些内核扩展冲突。如果 TUN 模式开启后网络不稳定，可以尝试切换 stack 参数。 dns 字段指定 TUN 模式下使用的 DNS 服务器，这里写 1.1.1.1 是走代理的远程 DNS，也可以写成 223.5.5.5 走直连，取决于你的分流需求。
使用 TUN 模式时有一个常见误区：开启 TUN 后，如果 DNS 配置不当，所有域名解析都会失败，表现为“连上了但什么都打不开”。此时先关闭 TUN 模式，检查 DNS 配置，再重新开启。另外，TUN 模式与某些 VPN 软件、游戏加速器可能冲突，如果同时使用，会出现路由表互相覆盖的情况。建议只保留一个全局接管工具。
TUN 模式与下一章要讲的 FakeDNS 是黄金搭档：TUN 接管全部流量，FakeDNS 接管 DNS 解析，两者配合可以做到真正的“无泄漏代理”。
FakeDNS
FakeDNS 是 v2ray 内核的 DNS 模块功能：它拦截所有 DNS 查询，不向真实 DNS 服务器请求，而是直接返回一个伪造的内部 IP（通常在一个保留网段内）。真正的域名解析被推迟到流量真正要连接的时候，由 v2ray 根据路由规则决定走代理还是直连。
FakeDNS 的核心价值有三个：第一，DNS 查询不会泄漏到外部。因为所有查询都在本地被拦截，外部网络根本看不到你查询了哪些域名。第二，域名解析速度更快。不需要等待 DNS 服务器响应，本地直接返回一个假 IP，后续的连接由 v2ray 的代理通道处理。第三，可以避免 DNS 污染。既然不向真实 DNS 服务器查询，污染也就无从谈起。
在 v2rayN 中启用 FakeDNS，通常需要手动编辑 config.json 的 dns 部分。v2rayN 的 GUI 不一定暴露所有 FakeDNS 选项，所以高级用户更倾向于直接编辑配置文件。下面是一个启用 FakeDNS 的示例：
{
"dns": {
"servers": ["1.1.1.1"],
"queryStrategy": "UseIP",
"fakeDns": {
"enabled": true
}
}
}fakeDns.enabled 设为 true 后，v2ray 会拦截所有 DNS 查询。 queryStrategy 控制查询策略，UseIP 表示只查询 IP 记录，避免不必要的 AAAA 查询。需要注意的是，FakeDNS 与某些需要真实 IP 的应用不兼容，比如 P2P 下载软件、局域网设备发现。如果这些应用出现异常，需要在 FakeDNS 配置里排除相关域名，或者关闭 FakeDNS。
FakeDNS 与 TUN 模式配合使用时，效果最好。TUN 模式接管所有流量，FakeDNS 接管所有 DNS 查询，两者结合形成一个完整的“透明代理”环境。在这种组合下，系统里的任何应用都不需要单独配置代理，浏览器、聊天工具、游戏都会自动走代理，同时 DNS 查询不会泄漏。
不过，FakeDNS 也有一个需要注意的地方：由于它返回的是假 IP，某些应用会把假 IP 缓存下来，导致后续连接失败。比如一个应用先解析域名得到假 IP，然后 v2ray 退出，应用再用假 IP 连接就会失败。因此，在切换配置或关闭 v2ray 时，最好重启一下相关应用，清除其 DNS 缓存。
如果你只是轻度使用代理，不追求“无泄漏”，可以不用 FakeDNS。它更适合对隐私有要求、或者经常遇到 DNS 污染问题的用户。
多订阅管理
多订阅管理是 v2rayN 的一项基础却容易被低估的能力。一个 v2rayN 实例可以配置多个订阅分组，每个分组独立更新、独立启用、独立命名。这为“多机场”和“自建 + 机场”混合使用提供了极大的便利。
最常见的场景是“主力机场 + 备用机场”。主力机场的订阅负责日常使用，备用机场只在主力节点全部失效时切换。如果只用一个订阅，主力机场出问题时只能干等；配置多个订阅分组后，备用机场的节点始终在列表里，切换只是点一下的事。
另一种场景是“自建节点 + 付费机场”。自建节点稳定但数量少，付费机场节点多但质量参差不齐。把两者放进不同分组，路由规则里可以让自建节点优先，机场节点作为兜底。这样即使自建节点临时不可用，也能自动切到机场节点。
在订阅分组设置里，可以给每个分组设置“启用”状态。未启用的分组不会自动更新，但已经拉取到的节点仍然保留在服务器列表中。如果某段时间不想用某个分组，但也不想删除，可以暂时关闭其更新开关。
订阅更新失败是常见问题。排查顺序如下：第一，确认网络能访问订阅链接。有些机场的订阅域名被运营商屏蔽，需要先走代理才能拉取订阅。第二，确认订阅链接是否过期。很多机场的订阅链接是限时的，过期后需要重新生成。第三，确认是否需要自定义 User-Agent。部分机场对订阅请求的 User-Agent 有要求，v2rayN 支持在订阅分组设置里为每个订阅单独指定 User-Agent。第四，确认订阅格式是否兼容。有些订阅是 Clash 格式，v2rayN 内置了转换器，能在拉取时自动转换；但如果转换失败，需要检查订阅内容是否完整。
订阅去重也是多订阅管理的一个实用点。多个订阅之间经常出现重复节点，v2rayN 可以根据节点 ID 或地址去重。在订阅分组设置中勾选“去重”相关选项后，重复的节点只会保留一个，避免服务器列表被刷成一大片。
如果订阅链接里的节点太多，可以结合“服务器过滤”功能，按协议、地区、延迟筛选，把不常用的节点隐藏起来。这样既保留了多订阅的灵活性，又不会让列表变得难以管理。
多订阅管理与路由规则结合，还能实现更高级的用法：比如把“工作分组”的节点作为默认代理，把“家庭分组”的节点作为备用，然后在路由规则里按域名或 IP 指定不同的出站。这种配置适合对网络环境有清晰规划的用户。
自定义出站
出站（outbound）是 v2ray 客户端发起连接的目标。v2rayN 默认内置两个出站：一个是“代理”，指向当前选中的节点；另一个是“直连”，即 freedom 协议，不经过任何代理。这两个出站已经覆盖了绝大多数使用场景。
但在某些高级场景下，需要自定义出站。比如，你希望某个应用走 Shadowsocks 出口，另一个应用走 SOCKS 出口，或者你想把一个特定协议（如 HTTP）的流量转发到另一个代理。这些都可以通过编辑 config.json 的 outbounds 数组来实现。
下面是一个添加 Shadowsocks 出站的示例：
{
"outbounds": [
{
"tag": "proxy",
"protocol": "shadowsocks",
"settings": {
"servers": [
{
"address": "1.2.3.4",
"port": 8388,
"method": "aes-256-gcm",
"password": "your-password"
}
]
}
},
{
"tag": "direct",
"protocol": "freedom"
}
]
}这段配置定义了两个出站：proxy 使用 Shadowsocks 协议，连接到一个地址为 1.2.3.4、端口 8388 的服务器；direct 使用 freedom 协议，表示直连。注意 tag 字段非常重要，路由规则里的 outboundTag 就是引用这个标签。如果把 tag 改成了别的名字，路由规则也要同步修改。
自定义出站与路由规则的配合是核心玩法。比如，你可以在路由规则里写一条规则：
{
"type": "field",
"domain": ["example.com"],
"outboundTag": "proxy"
}这样，访问 example.com 的流量就会走 proxy 出站。如果你有多个自定义出站，比如一个 Shadowsocks 出站和一个 HTTP 出站，就可以按域名把流量分到不同的出口，实现“多线路”效果。
在 v2rayN 中，手动编辑 config.json 是唯一能添加自定义出站的方式。编辑前建议先关闭 v2rayN，备份原配置文件，再编辑。编辑完成后重新打开，如果配置有语法错误，v2rayN 会提示加载失败，此时用备份恢复即可。注意，v2rayN 的 GUI 在保存其他设置时可能会覆盖 config.json，所以如果手动编辑了配置，最好把 v2rayN 的“自动保存”相关选项关掉，或者编辑后立即重启，避免 GUI 覆盖。
关于 VMess 与 VLESS 的协议差异，以及如何选择适合自己节点的协议，可以参考本站博客文章《VMess 和 VLESS 有什么区别：一分钟看懂两种协议的适用场景》。
进阶调优与故障排查
配置完成后，连接不稳定或无法上网是常见问题。这一章把常见的故障场景和调优方向集中整理，方便按图索骥。
连接不稳定的排查步骤
第一，检查节点延迟。在服务器列表中选择节点，右键“测试服务器真连接延迟”。如果延迟很高或超时，先换一个节点试试。第二，检查本地端口冲突。v2rayN 默认使用 10808 和 10809 作为本地 SOCKS/HTTP 端口，如果被其他程序占用，连接会失败。可以用命令 netstat -ano | findstr 10808 查看占用进程，然后在“设置—参数设置”里修改本地端口。更详细的步骤可参考博客《10808 端口被占用怎么办：定位冲突进程与修改 v2rayN 本地端口》。第三，检查系统代理设置。如果系统代理指向的端口与 v2rayN 实际监听的端口不一致，浏览器会连不上。第四，检查路由规则。如果路由规则把所有流量都导去了直连，代理自然不生效。
启动崩溃与闪退
v2rayN 启动即退，通常与运行库缺失或安全软件拦截有关。Windows 上先确认 .NET 运行时是否安装完整；如果安装过但仍崩溃，检查安全软件（如 Windows Defender、第三方杀毒）是否把 v2rayN 或 v2ray 内核文件当作威胁隔离了。把 v2rayN 安装目录加入白名单，或者重新解压到一个非系统盘路径。更详细的排查步骤可参考博客《v2rayN 打不开怎么办：启动崩溃与闪退的运行库、权限排查步骤》。
已连接却无法上网
这是最令人困惑的问题：客户端显示已连接，但网页打不开。按以下顺序逐项排查：第一，先确认节点是否真的可用——测试延迟并尝试访问一个不需要代理的国内网站，如果能访问，说明网络基本通。第二，检查系统时间。代理协议对时间同步敏感，时间偏差超过 90 秒会导致连接被拒绝。第三，检查 DNS。如果 DNS 配置不当，域名解析会失败，表现为“能 ping 通 IP 但打不开域名”。第四，检查系统代理设置。有些应用会强制使用系统代理，如果系统代理指向了错误的端口，就会断网。第五，检查路由规则。如果规则里把访问的域名导去了直连，而直连网络本身访问不了该域名，也会出现“连上了但打不开”。完整的排查清单可参考博客《V2Ray 已连接却无法上网？按这份清单逐项排查节点、DNS 与系统代理》。
性能调优方向
如果连接稳定但速度不理想，可以尝试以下调优：启用 Mux（多路复用），Mux 把多个 TCP 连接复用到一条连接上，能减少握手次数，降低延迟，但会增加一点 CPU 占用。对于移动网络或高延迟线路，Mux 通常有帮助。传输层协议的选择也很重要：WebSocket 兼容性好但开销略大，gRPC 在长连接场景下表现更好。这些都可以在 v2rayN 的节点配置里调整。
日志排查
v2rayN 的日志窗口（“查看日志”）记录了连接过程中的错误信息。如果连接失败，日志里通常会有明确的错误原因，比如“connection refused”“timeout”“certificate verify failed”等。学会读日志能大幅缩短排查时间。日志级别可以在“设置—参数设置”里调整，调成“调试”能看到更详细的信息，排查完成后记得调回“信息”或“警告”，避免日志文件过大。
以上调优与排查方法适用于 v2rayN 桌面端和 v2rayNG 安卓端。安卓端遇到问题时，优先检查订阅是否更新、节点是否可用，以及是否被系统省电策略限制。
如果对基础操作还不熟悉，建议先回到快速上手教程，把订阅导入和节点选择流程走一遍，再回来阅读本页的各章节。本页的每一章都是独立主题，可以按需查阅。