V2Ray 从零到进阶配置手册

核心概念：客户端、内核、协议与路由

先分清图形客户端与代理内核

v2rayN、v2rayNG 与 v2flyNG 首先是图形客户端。它们负责保存订阅、展示节点、生成配置、启动内核，并把系统代理或虚拟网卡切换到正确状态。真正执行协议握手、加密传输、DNS 查询和路由匹配的是客户端调用的内核。v2rayN 可在桌面平台使用 Xray 或 V2Fly 相关内核；v2rayNG 以 Xray 内核路线为主；v2flyNG 则面向 V2Fly 内核配置。遇到“客户端已打开但网页无法访问”时，不能只看窗口是否存在，应继续查看内核是否启动、监听端口是否建立、系统流量是否进入该端口。

客户端配置和节点配置也不是同一层。节点配置描述远端地址、端口、用户标识、协议、传输方式与安全参数；客户端配置还包含本地监听、系统代理、DNS、路由和日志。订阅通常只提供节点及分组信息，不会替用户决定所有本地网络策略。导入订阅后仍需选择代理模式，必要时设置绕过局域网、国内域名直连、远程 DNS 或 TUN。把这两层分开理解，能够解释为什么同一条订阅在不同设备上可以连接，但分流效果并不完全一致。

协议、传输与安全参数需要成组匹配

VMess、VLESS 和 Trojan 属于节点协议层；TCP、WebSocket、gRPC 等属于传输层；TLS 与 REALITY 属于连接安全及身份校验相关配置。客户端建立连接时，这些参数必须与服务端逐项一致。以 VLESS 配置为例，地址和端口正确并不代表连接一定成功，用户标识、流控、传输类型、服务名、服务器名称、公钥与短标识中的任一项不匹配，都可能表现为握手失败、连接后立即断开或测试延迟超时。

REALITY 节点常见字段包括服务器名称、指纹、公钥、短标识和流控。服务器名称不是随意填写的备注，它参与握手；公钥必须来自节点提供方；短标识按提供内容填写；使用 Vision 流控时，协议、传输与安全组合也要保持一致。导入标准分享链接或订阅时，客户端通常会自动解析这些字段。手动录入只适合确认字段来源的情况，不要把其他节点的参数拼接到当前节点。

入站、出站和路由构成数据路径

入站表示客户端在本机接收流量的位置，例如本地 SOCKS 端口、HTTP 端口或 TUN 虚拟接口；出站表示流量离开客户端后的处理方式，常见标签是代理、直连和阻断；路由规则则决定每个请求交给哪个出站。浏览器使用系统代理时，请求先进入本地 HTTP 或 SOCKS 入站，再由路由判断直连还是代理。开启 TUN 后，更多应用流量从虚拟网卡进入内核，但后面的路由与出站逻辑仍然存在。

路由通常按域名、IP、端口、网络类型或进程信息匹配。规则有顺序，先命中的规则先执行，因此“规则内容正确”还不够，还要确认它位于合适的位置。局域网地址和保留地址通常优先直连，明确需要阻断的目标放在直连规则之前，地域域名和 IP 规则放在兜底代理之前。最后保留一个可预期的默认出站，避免未命中流量落入不明确状态。

用可观察结果判断当前层级

连接测试显示成功，只能说明客户端在特定测试条件下能够访问目标，并不能覆盖所有应用。浏览器可用而命令行不可用，通常要检查程序是否读取系统代理；域名打不开但直接访问已知 IP 有响应，优先检查 DNS；局域网设备突然不可达，优先检查路由与 TUN 绕过项；所有节点同时失败，则先看本地网络、系统时间、内核启动和订阅参数，不要逐个删除节点。

日志是确认层级的主要依据。启动日志用于确认配置是否被接受、端口是否被占用、虚拟网卡是否创建；连接日志用于观察域名、目标地址、匹配规则和出站标签；错误日志用于定位解析失败、握手失败、超时和权限问题。日志等级日常可设为 warning，排查时临时切换为 info；完成排查后恢复，避免长期积累大量文件。日志中可能包含访问域名和节点地址，复制前先删除与问题无关的连接信息。

选择客户端并完成安装

按平台和内核需求选择客户端

Windows、macOS 与 Linux 桌面环境优先选择 v2rayN。它把订阅、节点、系统代理、路由、DNS、TUN 与日志集中在同一套界面中，适合从基础连接逐步进入分流和虚拟网卡配置。Windows 用户可在桌面版与经典 WPF 版之间选择：桌面版采用跨平台界面，适合希望在不同桌面系统保持相近操作路径的用户；经典 WPF 版保留传统 Windows 操作结构，适合已经熟悉原有菜单和托盘行为的用户。

Android 设备优先使用 v2rayNG，节点字段与 Xray 路线匹配较完整；需要 V2Fly 内核配置时选择 v2flyNG。两者都能够导入订阅、选择节点、建立本地 VPN 接管并查看日志，但部分设置名称和入口位置不同。迁移时不要只复制截图中的开关状态，应先导出标准节点链接或重新添加订阅，再逐项重建路由、DNS 和按应用策略。

安装前先确认架构和旧配置

下载前在客户端页面选择对应平台。macOS 需要区分 Apple Silicon 与 Intel；Android 近年的主流设备通常选择 arm64，无法确认时使用通用版；Linux 需要同时确认发行版包格式与处理器架构。文件名中的 x64、arm64、deb、rpm 都是选择依据，不能只看应用名称。系统架构不匹配时，常见表现是安装程序拒绝运行、系统提示格式不受支持，或启动后立即退出。

已有旧版客户端时，先记录当前订阅地址、订阅分组、路由规则、DNS 设置和本地端口。若客户端提供配置备份功能，使用它保存到个人文档目录；若采用便携配置目录，则在完全退出客户端后复制整个配置目录。升级时不要同时更换客户端分支、内核类型和主要配置，否则出现问题后难以判断变化来源。稳妥顺序是先保留配置完成客户端更新，确认基础连接，再更新内核或调整路由。

桌面平台完成首次启动

Windows 安装后启动 v2rayN，先检查窗口底部或设置页面中的内核状态。若程序只显示在通知区域，应从托盘图标打开主界面。系统安全提示出现时，仅为实际需要的网络范围授予访问权限。端口冲突通常发生在旧实例未退出或其他代理程序占用相同监听端口，此时先退出重复程序，再到 v2rayN 的本地监听设置中确认 SOCKS 与 HTTP 端口没有被其他进程使用。

macOS 首次启动可能要求确认应用运行、网络访问或系统代理变更。完成授权后先使用普通系统代理模式验证，不要立刻开启 TUN。Linux 安装后若主窗口可以打开但托盘不显示，先确认桌面环境是否提供状态图标支持；即使托盘暂时不可见，也可从主窗口完成订阅与连接。Linux 上还应确认当前用户对配置目录具有读写权限，避免每次退出后设置无法保存。

移动端完成基础权限设置

Android 安装 v2rayNG 或 v2flyNG 后，首次连接会请求建立 VPN 连接，这是系统将应用流量交给客户端处理所需的权限。授权只需要在系统弹窗中确认。若系统启用了严格的后台限制，应把客户端设置为允许后台运行，否则锁屏后内核可能被系统停止。双卡、热点共享和工作资料环境会改变网络接口，切换网络后如连接中断，可先停止再重新启动连接。

首次安装阶段只做三项验证：客户端能够正常打开、订阅或单节点能够保存、连接后日志没有持续重复的启动错误。此时不要导入大量自定义规则，也不要修改所有 DNS 选项。先用默认路由建立一条可复现的基础连接，后续章节再逐步添加系统代理、分流和 TUN。若只需要尽快完成第一次连接，可转到快速上手主线按精简步骤操作。

导入订阅并管理节点

订阅链接与单节点链接的区别

订阅链接用于持续获取一组节点及其更新结果，单节点链接只表示一个具体连接配置。长期使用时优先创建订阅分组，而不是把订阅内容逐条转换为手工节点。分组能够保存更新入口、备注、筛选条件和独立更新策略；节点地址、端口或安全参数变化后，只需更新订阅。手工节点适合临时测试或验证字段，不适合作为大量节点的主要维护方式。

在 v2rayN 中打开“订阅分组”，新增分组名称与订阅地址，保存后执行“更新全部订阅”或更新当前分组。分组名称应表达来源或用途，不要依赖节点原始备注区分。v2rayNG 与 v2flyNG 的入口通常位于订阅设置或侧边菜单，添加后先执行更新，再回到节点列表选择目标。复制订阅地址时注意不要附带前后空格、换行或聊天软件生成的说明文字。

更新失败时按请求链路检查

订阅更新失败与节点连接失败是两类问题。更新订阅时，客户端需要先访问订阅地址并解析返回内容；节点连接则使用解析后的服务器参数。订阅更新失败但旧节点仍可连接，说明现有配置尚可使用，应检查订阅地址是否完整、系统时间是否准确、当前网络能否访问订阅入口，以及订阅分组是否设置了错误的前置代理。不要先删除旧分组，否则会失去可用配置与对照样本。

如果订阅更新必须经过当前代理，应先连接一个已保存且可用的节点，再为订阅分组启用前置代理；如果订阅入口在本地网络可直接访问，则保持直连更新更容易排查。返回内容无法解析时，查看日志中是 HTTP 请求失败、内容格式不支持，还是某个节点字段异常。单个节点解析失败不一定意味着整个订阅不可用，可保留成功项目并向订阅提供方确认异常字段。

用分组、备注和筛选控制列表规模

多个订阅同时存在时，为每个分组设置稳定的短名称，并给节点备注保留可搜索结构，例如“地区｜线路｜协议”。筛选只作用于显示或更新结果，不应修改节点协议字段。v2rayN 可按关键词包含或排除节点，适合隐藏重复条目或只保留某类协议。规则应尽量简单，使用一两个稳定关键词即可；过度依赖节点名称中的临时文字，会导致订阅改名后列表突然为空。

自动更新间隔不需要设置得很短。订阅内容通常不会按分钟变化，频繁请求只会增加失败提示和列表刷新。日常可在启动时更新，或按实际变化频率设置周期。更新后先观察当前选中节点是否仍存在，节点被移除时再手动选择新的项目。需要更完整的分组策略，可继续阅读v2rayN 多订阅分组管理。

节点选择不要只依赖一次测试

延迟测试用于快速判断客户端能否完成指定探测，但它不等同于实际应用质量。不同测试方式可能测量 TCP 建连、HTTP 响应或真实连接过程，结果不能直接互相比较。选择节点时先确认协议字段完整，再执行客户端提供的连通测试，然后用实际需要访问的网页或应用验证。一次超时可能来自本地网络抖动、DNS、远端限流或测试目标暂时不可达，应复测并对比日志。

节点全部超时时，先选择一个配置明确的节点作为样本。检查服务器地址是否能解析、端口是否被本地网络拦截、系统时间是否偏差过大、内核是否支持节点所用参数。单个节点失败而同分组其他节点正常，重点比较协议、传输、安全和备注之外的真实字段；所有订阅同时失败，则重点检查本机网络、内核启动和代理回环，不要逐个修改用户标识。

{
  "protocol": "vless",
  "settings": {
    "vnext": [
      {
        "address": "example.com",
        "port": 443,
        "users": [
          {
            "id": "11111111-1111-4111-8111-111111111111",
            "encryption": "none",
            "flow": "xtls-rprx-vision"
          }
        ]
      }
    ]
  }
}

上面的片段用于说明 VLESS 出站字段层级，域名与用户标识是示例值。实际使用订阅时，应由客户端根据订阅内容生成完整配置，不要把示例字段覆盖到现有节点。查看生成配置的主要目的，是确认界面中的地址、端口、用户标识和流控是否进入了正确层级，而不是把整份生成文件改成长期手工维护。

选择系统代理与代理模式

系统代理负责接入支持代理的程序

v2rayN 启动内核后会在本机监听 SOCKS 和 HTTP 端口，但仅有监听端口并不会自动接管所有程序。启用“自动配置系统代理”后，读取操作系统代理设置的浏览器和桌面应用会把请求发送到 v2rayN。关闭系统代理时，内核可以继续运行，手工指定本地代理端口的程序仍可使用。这个区别适合排查“客户端显示运行，但只有部分应用可连接”的情况。

系统代理模式适合浏览器、办公软件和多数遵循系统设置的应用，影响范围清楚，退出客户端后也容易恢复。对不读取系统代理的命令行工具，可在该工具自身设置 HTTP 或 SOCKS 代理，而不是立刻切换 TUN。设置本地代理时，地址一般使用回环地址，端口必须与客户端当前监听一致。不要把远端节点端口误填为本地代理端口。

全局、规则和直连模式对应不同路由策略

“全局”通常表示进入客户端的流量统一使用当前代理出站，适合判断路由规则是否导致访问异常，也适合短时间验证节点本身。它不是日常使用的必选项，因为局域网、打印机、本地开发服务或境内资源也可能被交给代理。“规则”模式按照域名、IP 和其他条件选择直连或代理，是长期使用时更常见的设置。“直连”则让进入客户端的请求直接访问目标，可用于确认问题是否由代理路径引起。

排错时可以形成固定顺序：先切到全局模式测试目标；全局可用而规则模式不可用，检查路由匹配；全局也不可用，检查节点、DNS 和内核。直连模式可用并不能证明节点正常，只说明本地网络到目标的直接路径可达。完成测试后应恢复原模式，并在日志里确认目标域名最终使用了预期的出站标签。

PAC 与系统代理例外项需要明确边界

部分桌面环境允许使用 PAC 脚本决定哪些请求进入本地代理。PAC 在请求到达内核之前进行一次选择，而客户端路由在请求进入内核之后再次决定出站，两者叠加会增加理解成本。需要精细路由时，通常保持系统代理统一指向客户端，再由内核路由处理直连与代理更清楚。只有必须让某些程序或域名完全不进入客户端时，才考虑使用系统代理例外或 PAC。

局域网地址应加入绕过范围，常见范围包括回环地址、私有地址和本地域名。这样访问路由器管理页、局域网文件服务或开发环境时不会绕行代理。注意域名形式的局域网服务仍可能先经过 DNS，若解析结果不正确，仅添加 IP 绕过并不能解决。此时应在 DNS hosts、系统 hosts 或本地域名解析服务中保持一致记录。

验证流量是否真的进入客户端

不要只根据网页能否打开判断系统代理状态。打开客户端连接日志，访问一个此前没有缓存的域名，观察是否出现新的连接记录以及对应出站。如果浏览器访问正常但日志没有变化，可能使用了浏览器内独立代理、其他网络扩展或缓存连接。若日志出现请求但出站为 direct，则应检查路由；若日志显示 proxy 但随后握手失败，则应回到节点参数与远端连接层。

命令行环境可分别验证直连解析、系统代理读取情况和显式代理。不同工具对系统代理变量的支持并不一致，因此测试命令必须知道自己使用的是哪条路径。完成验证后清除临时环境变量，避免后续终端会话继续把软件更新或包管理请求发往已经关闭的本地端口。日常配置的目标不是让所有程序采用同一种入口，而是让每类应用的入口清楚、可查看、可恢复。

配置路由分流与 DNS

从最小路由规则集开始

常用路由目标是局域网和私有地址直连、明确的境内域名与 IP 直连，其余流量使用代理。v2rayN 中可先选择“绕过大陆”等预置规则，再根据实际应用补充自定义域名。预置规则依赖 GeoSite 与 GeoIP 数据，前者按域名集合匹配，后者按目标 IP 所属地址段匹配。域名规则能够在解析前决定策略，IP 规则通常需要先得到解析结果，两者应配合而不是互相替代。

最小规则集应先处理私有地址，防止局域网请求进入远端出站；再处理明确阻断项；然后处理需要直连的域名与 IP；最后设置代理兜底。规则越多不一定越准确。大量重复域名、过期规则和相互覆盖的表达式会让日志难以解释。新增规则时先写一个精确域名进行验证，确认匹配后再扩展为后缀或分类标签。

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

domainStrategy 决定域名规则未命中时是否继续解析并尝试 IP 规则。IPIfNonMatch 表示域名规则没有结果时再解析 IP，适合同时使用 GeoSite 与 GeoIP 的常见场景。若设置为仅按已有 IP 处理，部分域名流量可能不会进入预期的 IP 规则；若对所有域名都提前解析，则会增加 DNS 参与程度。修改策略后要同时观察解析日志与路由日志。

理解域名规则的匹配范围

精确域名只匹配指定主机；域名后缀可覆盖其子域名；关键字匹配范围更宽，容易把名称相似但用途不同的域名一起纳入。优先使用精确域名或明确的分类标签，只有目标域名结构稳定且确实需要覆盖多个子域时才使用后缀。对于内容分发网络，同一服务可能调用多个域名，不能只根据地址栏中的主域名建立规则，应从连接日志确认实际请求集合。

路由判断依赖客户端看到的域名。应用如果直接连接 IP，域名规则不会命中，只能使用 IP、端口或进程规则。启用某些 DNS 映射机制后，内核可以恢复域名与连接之间的对应关系，但这需要 DNS 请求也由客户端管理。出现“同一网站有时直连、有时代理”时，检查是否存在不同子域、IPv4 与 IPv6 结果差异、缓存解析结果或应用自带解析通道。

把 DNS 与路由作为同一条链路配置

DNS 的任务不只是把域名转换为 IP，它还会影响后续路由是否命中、请求是否受到本地缓存或解析路径影响。常见配置是境内域名使用本地或境内解析服务，其他域名使用远程解析，并让远程 DNS 请求经过代理出站。这样可以减少域名解析结果与实际访问路径不一致的情况。具体规则应根据当前内核支持的 DNS 结构配置，不要同时在系统、浏览器、客户端和多个网络工具中设置互相冲突的解析策略。

排查 DNS 时先清理变量：关闭浏览器中的独立安全 DNS 设置，保留客户端 DNS；或暂时关闭客户端自定义 DNS，只测试系统解析。一次只保留一条主要解析路径。域名无法访问时，先确认日志中是否出现查询、返回了哪个地址、该地址随后匹配了哪条路由。解析成功但连接失败，问题已经进入传输层；没有查询记录，则应用可能绕过了客户端 DNS。

处理 DNS 泄漏、缓存与 IPv6 分支

使用系统代理时，部分应用可能仍直接调用系统 DNS，这取决于应用如何解析域名。需要让解析请求统一由客户端处理时，可使用客户端的远程 DNS、DNS 出站或 TUN DNS 接管。验证方法包括浏览器检测、系统命令查询和客户端日志对照，具体步骤可查看v2rayN DNS 泄漏检测与修复。判断时应关注解析服务器与请求路径，不要只看最终返回 IP。

缓存会让修改看起来没有生效。客户端、操作系统、浏览器和应用都可能保存 DNS 结果。修改规则后先重启相关应用或清除对应缓存，再用新域名建立连接。IPv6 可用时，域名可能同时返回 A 与 AAAA 记录；若本地 IPv6 路径不稳定，应用可能优先选择失败的地址。应先确认系统是否具备正常 IPv6 连通性，再决定保留、限制或为 IPv6 单独建立路由，不能只通过删除一条 DNS 记录长期掩盖网络问题。

维护 GeoIP 与 GeoSite 数据

GeoIP 与 GeoSite 数据会随地址分配和域名变化而更新。规则本身没有修改但分流结果逐渐偏离预期时，应检查数据文件是否能够被当前内核读取、更新过程是否完成，以及自定义文件是否覆盖了客户端管理的版本。数据文件和内核应保持兼容，更新后先重启内核，再从日志确认分类标签能够加载。

手动替换数据文件前先退出客户端并备份原文件，避免文件仍被占用。替换后若启动日志报告标签不存在或文件格式错误，应立即恢复备份，不要继续添加补偿规则。完整的检查位置、更新入口和恢复方法见GeoIP 与 GeoSite 数据更新指南。路由数据库只是分类依据，最终仍需通过访问日志确认目标是否命中预期出站。

启用并校准 TUN 模式

明确什么时候需要 TUN

TUN 模式通过虚拟网络接口接收操作系统中的 IP 流量，适合不读取系统代理的应用、部分命令行程序以及需要统一接管的场景。它覆盖范围通常大于系统代理，因此也会把局域网、软件更新、后台服务和其他原本不经过代理的流量带入路由判断。只使用浏览器和常规桌面应用时，系统代理通常已经足够；确认存在无法单独配置代理的应用后，再开启 TUN 更容易维护。

TUN 不是提升节点连接能力的开关。节点本身握手失败、订阅字段错误或远端不可达时，开启 TUN 不会修复连接，反而会增加路由表、DNS 与权限变量。正确顺序是先在系统代理模式验证当前节点，再开启 TUN，并保持相同节点与基础路由。开启后如果所有访问都失败，可以直接对比开关前后的日志与系统路由，而不必重新怀疑订阅内容。

开启前检查权限、接口和地址范围

创建虚拟网卡和修改路由通常需要系统权限。v2rayN 提示权限不足时，按客户端与操作系统提供的方式完成授权，不要反复点击启动。系统中已有其他虚拟网络工具时，可能出现接口路由竞争、DNS 被重复接管或默认路由来回切换。排查阶段先退出其他会修改系统网络的程序，只保留 v2rayN，再重新创建 TUN 接口。

TUN 使用的虚拟地址段不能与当前局域网、企业网络或其他虚拟接口重叠。重叠时可能表现为某些地址无法访问、局域网设备失联或请求循环。可先查看本机现有路由，再选择客户端默认且不冲突的地址段。Windows 可使用系统网络界面查看适配器和路由；macOS 与 Linux 可通过系统网络工具查看接口。重点是确认默认路由、局域网网段和 TUN 网段各自指向正确接口。

ip route
ip route get 1.1.1.1
resolvectl status

这些 Linux 命令分别用于查看路由表、确认指定目标经过的接口，以及查看当前 DNS 状态。其他桌面系统应使用对应的系统网络查看工具。命令结果主要用于比较开启 TUN 前后的变化：默认流量是否进入虚拟接口、局域网网段是否仍由物理接口直连、DNS 服务器是否切换到预期入口。

设置自动路由、严格路由与绕过项

自动路由让客户端创建将流量导向 TUN 的系统路由，通常应先使用默认值。严格路由会加强对旁路流量的限制，适合已经确认基础 TUN 正常后再测试。开启严格策略后，本地服务、虚拟机、容器或局域网发现可能受到影响，因此要先建立私有地址与本地接口绕过。不要把所有私有地址交给代理出站，否则路由器、打印机和本地开发服务会变得不可达。

按进程绕过或包含可以缩小 TUN 的作用范围，但进程名、子进程和系统服务关系需要实际验证。某个应用可能由启动器拉起独立进程，也可能把网络请求交给系统组件。只添加主程序名称不一定覆盖完整请求链。开始时使用普通路由规则验证，确实需要按应用控制时，再结合日志逐个添加进程，并保留默认出站作为兜底。

处理 TUN 下的 DNS 和 MTU

TUN 场景中 DNS 最好由客户端统一处理，使域名、映射地址和实际连接保持关联。常见做法是让系统 DNS 指向客户端提供的本地入口，再由内核根据域名规则选择本地或远程解析。若系统仍同时使用其他 DNS，可能出现解析结果未进入内核、域名规则无法关联或检测结果不一致。切换 TUN 后先查看 DNS 状态，再进行网页测试。

部分网络下会出现网页开始加载但大文件或特定请求停住，这可能与 MTU 有关。TUN 封装会增加额外开销，路径中某些设备又可能无法正确处理分片。排查时可以在客户端支持范围内逐步降低 MTU，每次只调整一个档位，并用相同目标复测。不要直接设置极低值，过小的 MTU 会增加分片与处理开销。若只有单一网络环境异常，还应与其他 Wi-Fi 或有线网络对比。

建立可恢复的关闭流程

正常退出客户端前先关闭 TUN，让客户端撤销虚拟接口、路由和 DNS 修改。系统异常关机或客户端崩溃后，如果出现网络仍不可用，先重新启动客户端并正常开关一次 TUN，使清理逻辑执行；仍未恢复时，再检查系统代理、默认路由和 DNS。不要在不清楚残留状态时连续安装多个网络工具，这会让路由来源更难判断。

稳定的 TUN 配置应满足四项：开启后基础访问正常，局域网仍可达，DNS 请求进入预期路径，关闭后系统网络完整恢复。完成这四项后再添加严格路由、进程规则或复杂 DNS。TUN 使用中的常见问题也可回到快速上手页查看基础连接检查顺序，再结合本章定位系统接管层。

日常维护、备份与故障排查

把客户端、内核、订阅和规则分开更新

v2rayN 的图形客户端、代理内核、订阅内容与 GeoIP、GeoSite 数据属于四个独立更新对象。一次只更新一个对象，完成后验证基础连接与分流，再继续下一项。这样遇到配置不兼容时能够快速回退。客户端更新主要改变界面和配置生成方式；内核更新可能改变协议实现或参数支持；订阅更新改变节点；路由数据库更新改变分类结果，它们造成的问题表现不同。

更新前记录当前可用节点、内核类型、系统代理模式、TUN 状态和自定义路由。对重要配置进行备份，并保留最近一次确认可用的配置副本。更新后先使用原节点和原模式测试，不要立即清理旧配置。确认启动日志没有解析错误、连接日志正常，再删除过期备份。自动更新适合订阅和常规数据，涉及客户端分支切换或大范围规则变更时应手动安排。

按照“入口—解析—路由—传输”排错

第一步检查入口：程序是否读取系统代理，或流量是否进入 TUN；第二步检查解析：域名是否得到地址，DNS 请求是否走预期路径；第三步检查路由：目标命中 direct、proxy 还是 block；第四步检查传输：节点协议、端口、安全参数和远端响应。固定顺序可以避免在 DNS 问题上反复更换节点，也避免在节点握手失败时盲目修改路由。

浏览器可用而其他应用不可用，优先检查应用入口；所有域名失败而已知 IP 可连接，优先检查 DNS；规则模式失败而全局模式正常，优先检查路由；所有节点突然失败，先检查本地网络、系统时间、内核进程和订阅变化；单节点失败，则比较该节点字段与同分组正常节点。排查时保留一个已知可用样本，它比同时测试大量节点更有价值。

正确使用日志等级和时间线

日常将日志等级保持在 warning 可以突出启动失败、解析异常与连接错误。需要确认路由命中时临时切换到 info，复现一次目标访问后立即保存相关时间段。日志过多时，先停止连接、清空当前视图，再重新启动并只执行一个测试动作。这样能够把启动、DNS、路由和连接记录按时间串起来，避免从大量后台请求中寻找目标。

错误信息要结合上下文解释。timeout 表示在规定时间内未得到预期响应，可能发生在 DNS、TCP 建连或协议握手；connection refused 表示目标明确拒绝当前端口；name resolution failed 指向解析层；配置解析错误通常会给出字段路径或类型。复制日志用于讨论问题时，只保留错误前后的必要行，并移除订阅地址、节点凭据和与问题无关的访问记录。

维护系统时间、端口与后台状态

TLS 与 REALITY 等连接依赖合理的系统时间。设备时间偏差明显时，证书有效期判断和握手都可能失败，因此应让系统自动同步时间。端口方面，本地 SOCKS、HTTP 和 API 监听不能与其他程序冲突；更改端口后，应用内手工代理也要同步修改。客户端重复启动时可能产生两个界面实例，但只有一个成功占用端口，应通过进程列表和日志确认。

移动设备需要注意后台限制，桌面系统需要注意睡眠唤醒、网络切换和托盘退出。网络从有线切到 Wi-Fi、从家庭网络切到移动热点后，旧连接与 DNS 缓存可能仍然存在。遇到异常先停止当前连接，等待旧会话释放，再重新连接。长期使用 TUN 时，每次系统大版本更新后都应重新验证虚拟接口权限和关闭恢复流程。

建立简单、可回退的备份结构

备份至少包含订阅分组、手工节点、自定义路由、DNS 配置和客户端首选项。文件名可使用日期与用途，例如“桌面基础规则”“TUN 稳定配置”，但不要把订阅地址或节点标识写进文件名。备份后应实际验证能够导入或恢复，只复制一个不完整的数据库文件并不能保证有效。跨平台迁移时优先迁移标准订阅和规则思路，不要假定所有界面配置文件可以直接通用。

遇到复杂故障时，恢复到最小配置通常比继续叠加修补规则更快：关闭 TUN，使用系统代理；暂时使用默认 DNS；选择单个已知配置；启用全局模式；确认连接后依次恢复规则、DNS 与 TUN。每恢复一步都复测同一目标。DNS 专项问题可参考境内外分流解析配置，Linux 安装与自启动问题可参考v2rayN Linux 安装教程。

从可用配置走向可维护配置

先固定一份最小基线

进阶配置的起点不是增加更多规则，而是保存一份能够稳定复现的最小基线。基线应包含一个可用订阅分组、一个已验证节点、系统代理入口、简单的私有地址直连规则、明确的默认出站和可观察日志。它不需要覆盖所有应用，但必须能够回答请求从哪里进入、怎样解析、命中哪条路由以及使用哪个出站。

在基线上增加功能时，使用小步变更：先加入 GeoSite 与 GeoIP 分流，验证后加入远程 DNS，再验证 TUN，最后才考虑进程规则、严格路由或复杂域名覆盖。每一步保留配置快照和测试目标。测试目标应覆盖普通网页、局域网服务、需要代理的域名、直连域名和一个不读取系统代理的应用，确保变化没有只解决单一场景。

理解生成配置，再决定是否自定义

v2rayN 等客户端会把界面设置转换为内核配置。进阶用户应学会查看生成结果中的 inbounds、outbounds、routing、dns 与 log，但不要绕过客户端长期直接修改临时生成文件，因为客户端重启或切换节点时可能重新生成。正确方式是在客户端提供的自定义配置、路由规则或预设入口中修改，并通过生成结果确认修改落到了预期字段。

查看配置时先追踪标签关系：路由规则中的 outboundTag 必须对应实际出站标签；DNS 服务器如指定出站，也必须存在对应标签；入站标签可以用于限制规则适用范围。字段名称正确但标签拼写不一致时，内核可能拒绝启动或采用非预期路径。数组顺序也很重要，尤其是路由规则、DNS 服务器选择与域名匹配列表。

{
  "dns": {
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      {
        "address": "https://resolver.example/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      }
    ],
    "queryStrategy": "UseIP"
  }
}

该片段展示按域名集合选择 DNS 服务器的结构，示例域名仅用于说明字段。实际配置时要确认当前内核支持对应写法，并为解析服务安排正确出站。skipFallback 会影响匹配服务器失败后的回退行为，不应在不了解结果时批量启用。DNS 配置完成后仍需结合路由检查解析请求和目标连接是否采用一致路径。

为不同网络环境建立配置边界

家庭网络、办公网络、公共网络和移动热点的 DNS、IPv6、局域网网段与端口可达性可能不同。不要用一组强假设规则覆盖全部环境。经常切换网络时，可准备“系统代理基础”“TUN 接管”“局域网保留”几套配置，名称表达接管范围而不是地点。切换后先检查当前默认路由与 DNS，再启动客户端，能够减少旧接口残留带来的问题。

办公网络可能使用内部域名和私有 DNS，这些请求应保持在本地解析路径，并让内部地址直连。家庭网络中的存储、打印和媒体设备同样需要私有网段绕过。公共网络可能存在登录认证页，连接网络后应先完成本地认证，再启动代理或 TUN。认证页无法打开时，临时关闭系统代理和 TUN，完成认证后恢复原设置。

用测试矩阵代替主观判断

可维护配置需要固定测试矩阵。每次变更后依次测试：客户端能否启动；订阅能否更新；已知节点能否连接；直连域名是否使用 direct；代理域名是否使用 proxy；局域网地址是否可达；DNS 是否使用预期服务器；TUN 关闭后网络是否恢复。测试结果记录为“通过、失败、未测试”，不要只写“网络正常”。

出现回归时，根据首次失败项回到对应层。客户端无法启动就不要测试网页；DNS 未确认时不要评价路由；局域网失败时检查私有地址规则和接口；关闭 TUN 后未恢复时先处理系统网络。把测试顺序固定后，升级客户端、内核或数据文件都可以用同一套流程复核，避免依赖记忆。

形成长期学习路线

完成本手册后，下一步应先读懂连接日志与生成配置，再深入域名策略、DNS 出站、TUN 路由和协议参数。协议学习以字段关系为主：VLESS 的用户标识与流控、REALITY 的服务器名称与公钥、传输层的服务名与路径，都要结合实际节点配置理解。不要从收集大量配置片段开始，脱离客户端版本、内核能力和服务端条件的片段很难直接复用。

日常维护重点放在可解释性：知道当前节点来自哪个分组，知道系统代理或 TUN 是否开启，知道主要 DNS 路径，知道路由默认出站，知道怎样恢复基线。配置越复杂，越需要减少隐含状态。遇到具体问题时先回到对应章节，再查看站内相关文章和快速上手页的常见问题说明，按层级收集日志和复现步骤。