V2Ray 从零到精通：v2rayN 完整配置

核心概念与流量路径

先区分客户端、内核与服务器

V2Ray 使用过程中最容易混淆的三个对象是图形客户端、代理内核和远端服务器。v2rayN、v2rayNG、v2flyNG 属于图形客户端，负责保存订阅、展示服务器列表、生成运行配置、切换代理模式，并把用户操作转换成内核能够理解的参数。Xray 与 V2Fly 属于内核家族，主要负责监听本机端口、建立出站连接、执行路由匹配和处理不同传输方式。订阅提供方配置的远端服务器则位于连接链路另一端，接收客户端发出的协议连接。图形界面显示“已启动”，只代表本机内核进程已经运行，不等于远端服务器一定可达；订阅更新成功，也只代表地址返回了可解析内容，不等于其中每个节点都能建立连接。

理解这三层后，排错可以按边界展开：程序打不开，优先检查客户端安装与系统依赖；内核启动失败，查看本机日志和端口占用；服务器测试失败，检查节点参数、网络可达性与系统时间；浏览器仍走原网络，检查系统代理或 TUN 是否真正接管了对应应用。把所有问题统称为“节点不能用”会掩盖关键线索，也容易造成反复重装。

一条请求如何离开应用

以 v2rayN 的系统代理模式为例，浏览器首先读取操作系统的代理设置，然后把请求交给 v2rayN 在本机监听的 HTTP 或 SOCKS 入站端口。内核拿到请求后，按照 routing 中从上到下排列的规则检查域名、IP、端口、协议或入站标签。规则命中后，请求被送往指定出站：可以是当前选中的代理服务器，也可以是 direct 直连出口，或 block 阻断出口。若没有规则命中，则进入配置中的默认出站。DNS 查询可能在应用、系统或内核中发生，因此“域名命中了直连规则但最终仍走代理”一类现象，往往与域名解析结果和匹配阶段有关。

协议、传输层与安全层不是同一参数

VMess、VLESS、Trojan 等名称通常描述节点使用的代理协议；TCP、WebSocket、gRPC 等描述传输承载方式；TLS、REALITY 等用于连接认证或安全层。导入节点后，这些字段必须与服务器端配置逐项对应，不能只保留地址与端口后自由组合。比如一个节点使用 VLESS、TCP 与 REALITY，那么 flow、serverName、publicKey、shortId 等字段可能共同决定连接是否成立。更改其中任意一项，都可能让握手在到达业务请求前终止。对于初学者，最稳妥的原则是完整导入分享链接或订阅，不在尚未理解字段含义时手工改动传输参数。

延迟、连通性与实际速度

客户端中的延迟测试通常用于判断目标是否可连接以及握手大致耗时，不代表持续传输速度。不同测试方式可能走 TCP 握手、真实协议请求或指定网址，因此同一个节点在不同客户端里出现不同结果并不异常。延迟较低的节点可能在长连接中不稳定，延迟稍高的节点也可能拥有更充足的可用带宽。选择节点时应同时观察连续连接是否成功、网页首包是否稳定、长时间使用是否频繁断开，而不是只按单次数字排序。建立这种分层认识，是后续订阅管理、分流与 TUN 配置的基础。

选择客户端并完成安装

按系统平台选择客户端

桌面环境首推 v2rayN。它覆盖 Windows、macOS 与 Linux，能够管理订阅、切换系统代理、配置路由和启用 TUN，适合将多台桌面设备的操作方式统一起来。Android 环境首推 v2rayNG，它使用 Xray 内核，界面围绕移动端连接流程组织；需要使用 V2Fly 内核时，可选择 v2flyNG。三款客户端的定位不同，不需要在同一设备上同时运行。多个客户端同时监听相同本机端口，或同时尝试接管系统代理，会制造难以判断的端口冲突和状态覆盖。

架构、安装形式与目录权限

安装前先确认操作系统架构。Windows 常见桌面设备使用 x64；macOS 应在“关于本机”中确认芯片类型；Android 近年的主流设备通常使用 arm64，但无法确认时可选择通用版；Linux 可执行 uname -m 查看架构，输出 x86_64 对应 x64，输出 aarch64 对应 arm64。架构不匹配时，常见现象是安装程序拒绝运行、系统提示格式错误，或程序启动后立即退出。

Windows 的 v2rayN 桌面版与经典 WPF 版应选择其中一种作为日常入口。使用压缩包形式时，应先完整解压到具备写入权限的固定目录，再启动主程序；不要直接在压缩软件的临时预览窗口中运行，否则配置文件、日志和内核文件可能无法稳定保存。macOS 安装完成后从应用目录启动。Linux 使用 deb 或 rpm 安装时，包管理器会按系统规则放置文件；出现依赖提示时，应先让对应发行版的包管理器完成依赖处理，而不是手工复制库文件。

第一次启动应检查什么

首次启动后先不要立即启用 TUN。检查主窗口是否能正常显示，设置页面是否能识别内核，日志窗口是否出现持续报错，并确认本机监听端口没有被其他代理客户端占用。随后导入一个配置，选中该服务器并执行客户端提供的连接测试。只有普通系统代理路径可以稳定工作后，再进入路由和 TUN 章节。这样能够把安装问题与高级接管问题分开。

系统权限与安全提示的处理原则

TUN 驱动安装、系统代理修改和防火墙规则写入可能触发系统权限确认。应先核对正在运行的程序名称和操作来源，再完成授权。普通系统代理通常不需要长期使用管理员权限；TUN 因为需要创建虚拟网络接口，权限要求会更高。企业设备若存在统一网络策略，应先确认本机是否允许修改代理和网络适配器。若启动后只有特定账户无法保存配置，重点检查程序目录写入权限与账户配置目录，而不是直接修改协议参数。

完成安装后，可在客户端下载页核对当前平台对应的客户端类型和安装形式。安装阶段的目标不是一次配置全部功能，而是得到一个能够稳定启动、能够保存设置、能够读取日志的基础环境。后续每增加一个功能，都应保留可回到这一基础状态的路径。

订阅导入与节点管理

订阅地址与单节点分享链接

订阅地址通常指向一份可更新的服务器清单，客户端请求该地址后解析出多个节点，并把它们放入对应订阅分组。vmess、vless 等分享链接则描述单个节点的完整参数，适合临时导入或单独保存。二者不能通过外观简单区分：订阅地址可能是普通 HTTPS 链接，也可能带有访问参数；单节点链接则通常以协议名称开头。不要把分享链接粘贴到订阅地址输入框，也不要把订阅网址当成单节点扫描内容处理。

在 v2rayN 中，先进入订阅分组管理，新建分组并填写订阅地址，然后执行“更新当前订阅”或对应的订阅更新菜单。分组名称应描述用途或来源，避免使用“订阅一”“订阅二”这类后续无法辨认的名称。v2rayNG 与 v2flyNG 的入口名称可能略有不同，但操作关系相同：保存订阅地址、执行更新、回到配置列表、选中目标节点。更新前后的节点由客户端按订阅内容管理，手工修改订阅节点的字段可能在下一次更新时被覆盖。

订阅更新失败的分层检查

更新后列表为空时，先查看日志中是“请求失败”还是“解析失败”。请求失败表示客户端没有取得订阅内容，应检查地址是否完整、系统时间是否准确、当前网络是否能访问订阅地址，以及订阅更新是否被设置为通过某个当前不可用的代理出口。解析失败表示服务端返回了内容，但格式不是客户端预期的数据，常见情况包括地址过期、返回登录页面、访问参数缺失或客户端版本无法识别新增字段。可以在不修改原分组的前提下新建测试分组，重新粘贴完整地址，以排除旧字段残留。

若旧节点仍然存在但更新持续失败，不要立即删除整个配置。先保留现有可用节点，复制日志中的首个明确错误，再检查订阅链接。排查顺序应是地址、网络请求、返回内容、解析过程、节点连接，不能从更新失败直接跳到重装客户端。更完整的检查路径可参阅订阅解析失败的常见原因与自查清单。

节点测试应该如何使用

批量测试适合清除明显无法连接的条目，但不应把单次测试结果当作永久排序。先更新订阅，再选择统一的测试方式，完成后观察失败是否集中在同一种协议、同一组域名或同一服务器区域。如果同一订阅内全部节点同时失败，优先检查本机网络、系统时间、内核状态和订阅参数；如果只有少量节点失败，再考虑节点自身状态。连续快速执行多轮测试可能触发连接拥塞，也会让日志混入大量并行错误，不利于定位。

分组、备注与更新策略

当订阅数量增加时，应让分组承担边界管理。不同来源放入不同分组；手工节点放入独立分组；用于测试的临时节点设置明确备注。自动更新周期不宜短到频繁打断正常使用，日常可按实际变化频率设置，并保留手动更新入口。更新任务执行时如果需要经过代理，应确保其依赖的当前节点可用，否则会出现“需要更新才能恢复节点，但更新又依赖失效节点”的循环。

订阅地址本身可能包含访问凭据，不应粘贴到公开截图、日志分享或公共文档中。排错时可以保留域名和错误类型，但应遮去查询参数及路径中的识别信息。节点分享链接同样包含完整连接参数，只应在受控设备间传递。合理的节点管理目标不是保留尽可能多的条目，而是让来源、更新时间、常用节点和失败原因都可以被快速辨认。

系统代理与代理模式

系统代理解决什么问题

系统代理是桌面端最适合先掌握的接管方式。v2rayN 启用系统代理后，会把操作系统的代理地址指向本机监听端口。遵循系统代理设置的浏览器和桌面应用随后把请求交给内核处理。它的优点是边界清楚、启停直接、排错成本低；限制是部分程序不读取系统代理，某些游戏、命令行工具或自带网络栈的应用仍会直接连接。遇到单个程序未被接管时，应先确认该程序是否支持系统代理，再决定是否需要 TUN，而不是立即修改节点协议。

系统代理状态与内核运行状态是两件事。可以出现内核已经启动但系统代理未开启，也可以出现系统代理仍指向旧端口而内核已经退出。正常关闭客户端时应让程序恢复系统代理；若程序异常退出后浏览器无法访问网络，可进入操作系统代理设置，检查是否仍保留指向本机的地址。重新打开 v2rayN 并关闭系统代理也能在许多情况下完成恢复。

全局、规则与直连的区别

“全局”通常表示被客户端接管的流量统一发送到代理出站；“规则”表示流量先经过路由匹配，再按规则进入代理、直连或阻断出口；“直连”表示被接管的流量直接从本地网络发出。这里的关键限定是“被接管的流量”：如果应用根本没有进入系统代理，那么切换全局或规则不会影响它。反过来，全局模式也不是让设备上所有数据自动进入客户端，它只改变内核内部的出站选择。

用对照测试确认接管链路

验证代理模式时，不要只观察托盘图标颜色。先选中一个已确认可连接的节点，开启系统代理，使用遵循系统代理的浏览器访问测试页面；随后切换为直连模式，再访问同一页面；最后关闭系统代理。若三个状态没有任何差异，应检查浏览器是否使用独立代理设置、系统代理地址是否指向当前端口、客户端日志中是否出现对应请求。若日志有请求但连接失败，问题位于路由或节点侧；若日志完全没有请求，问题位于应用到本机入站之间。

命令行工具的行为需要单独判断。部分工具读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 环境变量，而不读取桌面系统代理。临时测试时可按工具文档设置代理地址，但不要把端口号照搬自其他设备，应以当前客户端的本地监听设置为准。修改监听端口后，所有手工环境变量和应用内代理也要同步更新。

局域网访问与本机监听

允许局域网连接会让客户端监听地址从仅本机可用扩展到局域网接口。只有在确实需要让同一网络中的其他设备使用这台电脑作为代理入口时才应启用，并同时确认防火墙范围、监听地址与访问控制。普通单机使用保持仅本机监听即可。若启用后其他设备仍无法连接，按监听地址、系统防火墙、路由器设备隔离和端口填写顺序检查。不要为了排除问题而长期开放所有接口，因为这会改变原本清晰的本机边界。

路由分流规则

规则按顺序匹配

路由分流的核心不是规则数量，而是匹配顺序。内核通常从上到下检查规则，流量命中一条后便进入该规则指定的出站，后面的规则不再处理。因此更具体的例外规则应放在更宽泛的规则之前。例如，某个域名必须走代理，而它所属的域名集合默认直连，那么单域名代理规则要排在集合直连规则前。若先放宽泛规则，后面的例外永远不会生效。

常见匹配条件包括域名、IP、端口、网络类型、协议和入站标签。domain 条件适合按完整域名、后缀或规则集匹配；ip 条件处理解析后的目标地址；port 适合限定服务端口；inboundTag 可以区分来自不同本机入口的流量。outboundTag 则决定命中后使用哪个出口。规则中的标签必须与 outbounds 中实际定义的标签一致，拼写差异会导致配置检查失败或路由结果不符合预期。

一份精简的 routing 示例

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com",
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

示例先让私有地址走 direct，避免访问路由器、打印机或局域网服务时绕到远端；第二条将示例域名及指定集合送到 block；最后一条作为兜底，把剩余 TCP 与 UDP 流量送到 proxy。实际客户端可能通过图形界面生成等价配置，出站标签名称也可能不同，因此复制规则前要先查看当前配置中的标签。示例中的最后一条非常宽泛，如果放在第一条，局域网直连规则便不会获得匹配机会。

domainStrategy 如何影响判断

domainStrategy 决定路由阶段在什么情况下把域名解析为 IP。使用 AsIs 时，路由优先保留原始域名，不主动为了 IP 规则解析；IPIfNonMatch 表示域名规则未命中时再解析 IP，以便继续检查 IP 规则；IPOnDemand 会在规则需要 IP 时更积极地解析。选择并非越积极越好，因为额外解析会引入 DNS 路径、缓存与解析结果差异。日常分流通常可以从 IPIfNonMatch 开始，再根据日志判断是否需要调整。

从最小规则集开始

建立分流时先保留三类基础行为：局域网直连、明确需要代理的目标、剩余流量的默认处理。验证稳定后再加入广告阻断、应用专用端口或复杂域名集合。每次只增加一组规则，并记录它位于规则列表中的位置。出现异常时，先把模式切换为全局进行对照；若全局正常而规则模式失败，说明节点本身大概率可用，问题应集中在路由条件、DNS 或出站标签。

复杂配置可结合V2Ray 配置文件结构逐段解读理解 inbounds、outbounds 与 routing 的关系。排查分流时应记录“原始域名、解析地址、命中规则、目标出站”四项信息，而不是只记录网页是否打开。只要这四项能够对应，路由行为通常就可以被解释和复现。

TUN 模式配置

TUN 与系统代理的接管差异

TUN 模式通过虚拟网络接口接收系统流量，能够覆盖更多不读取系统代理的应用。系统把符合路由条件的数据包交给虚拟接口，客户端再将其转换并送入内核。由于它工作在比应用代理更低的网络层，DNS、UDP、局域网访问、默认路由和防火墙都会参与结果。TUN 不是“更强的全局开关”，而是一种接管边界更广、配置变量也更多的运行方式。

启用前应先完成三个确认：普通系统代理能够通过当前节点稳定连接；路由规则在系统代理模式下结果正确；客户端能够以所需权限创建虚拟接口。若基础链路尚未验证，TUN 启动失败时就无法区分是节点、规则、驱动还是系统网络问题。建议保存一份关闭 TUN 的可用配置，出现异常时先回退到该状态。

启用过程与必要检查

在 v2rayN 的设置中启用 TUN 后，系统可能请求提升权限并创建虚拟网络适配器。完成授权后查看日志，确认适配器创建、地址分配、路由写入和内核启动均未报错。随后先访问普通网页，再测试需要 UDP 的应用，最后检查局域网设备。不要一开始同时开启自定义 DNS、严格路由、复杂规则集和多个网络过滤工具，否则任何一步异常都会产生多个可能原因。

如果 TUN 显示已启动但所有网络都中断，先关闭 TUN，确认基础网络恢复；再检查默认路由是否被正确写入、DNS 是否有可用出口、虚拟适配器是否获得地址，以及其他安全软件是否阻止新接口。若只有浏览器正常而特定应用失败，查看该应用使用 TCP 还是 UDP，以及路由规则是否阻断了对应协议。若只有域名失败而直接访问测试地址有响应，问题通常集中在 DNS。

DNS 与回环问题

TUN 场景下必须避免客户端自身发出的连接再次被 TUN 捕获并送回客户端，形成路由回环。成熟客户端会为内核进程、服务器地址或特定出站设置绕行，但自定义规则可能破坏这一关系。典型表现是日志反复出现对同一服务器地址的连接、CPU 占用上升、连接快速失败。此时应恢复默认 TUN 规则，确保代理服务器地址通过真实网络接口直连，并确认内核出站没有再次进入虚拟接口。

DNS 处理要保持单一、可解释的主路径。系统 DNS、客户端内置 DNS、浏览器自带解析和其他网络工具若同时生效，域名可能在不同位置获得不同结果。排查时可暂时关闭额外的应用级 DNS 功能，使用客户端推荐的默认解析设置，观察日志中域名查询从哪个入站进入、经哪个出站返回。确认稳定后，再逐项恢复自定义策略。

休眠、切网与退出后的恢复

笔记本从休眠恢复、在有线与无线网络间切换、或从一个网络切换到另一个网络后，虚拟接口和默认路由可能仍引用旧状态。出现连接中断时，可先停止 TUN，等待真实网络获得有效地址，再重新启用。若客户端异常退出后网络未恢复，检查系统代理、虚拟适配器和默认路由，不必立即删除全部配置。Windows 可先关闭残留系统代理并重启客户端；Linux 可用 ip route 查看默认路由；macOS 可在网络设置中确认当前服务顺序。

TUN 配置完成的标准不是图标显示“就绪”，而是普通网页、UDP 应用、局域网资源、休眠恢复和客户端退出这五个场景都能得到可预期结果。完成测试后记录当前 DNS 方式、私有网段规则和权限设置，后续升级或换网时可以快速对照。

故障排查与日常维护

先读取第一条有效错误

内核启动失败时，日志中靠后的大量错误可能只是首个问题引发的连锁结果。应从本次启动时间点开始向下阅读，找到第一条包含字段名、端口、文件路径或配置段的明确错误。常见类型包括本机端口已占用、JSON 字段格式错误、出站标签不存在、传输参数缺失、内核文件无法执行和配置目录无写入权限。记录原始错误后再修改配置，每次只处理一个原因并重新启动，避免同时更换节点、端口、内核和路由规则。

端口占用时，先确认是否有另一个客户端仍在后台运行。Windows 可使用以下命令查看占用本机端口的进程编号，再到任务管理器核对程序；Linux 可使用 ss 查看监听进程。端口号应替换为客户端设置中实际显示的本地监听端口。

netstat -ano | findstr LISTENING
ss -lntup

不要看到端口占用就随机改成任意数字。若浏览器、环境变量或其他应用已经手工填写了旧端口，修改后必须同步更新。更详细的日志阅读方法可参考从日志窗口定位内核启动错误的排查路径。

按链路建立排错清单

当程序能启动但无法访问目标时，依次检查：订阅是否能更新、目标节点是否能完成连接测试、内核是否处于运行状态、应用请求是否进入本地入站、路由是否选择了正确出站、DNS 是否返回可用结果。每一步都需要一个可观察证据，例如订阅日志、内核启动日志、请求记录或模式对照结果。若全局模式可用而规则模式不可用，重点查路由；若系统代理可用而 TUN 不可用，重点查虚拟接口、DNS 与系统路由；若所有模式都无法建立连接，回到节点参数、系统时间和基础网络。

日常更新与回退

客户端、内核、订阅和规则集是四类不同更新对象，不应在同一次维护中全部更换。较稳妥的顺序是先记录当前可用状态，更新其中一项，重启并验证常用场景，再继续下一项。客户端升级后重点检查配置迁移和菜单变化；内核更新后重点查看协议参数与启动日志；订阅更新后关注节点增删和名称变化；规则集更新后对照常用网站与局域网访问。只要每一步都有验证点，异常就能被限定在最近一次变化中。

回退需要保留可识别的基线。至少记录当前使用的客户端类型、订阅分组、常用节点、系统代理模式、TUN 状态和自定义路由规则。配置导出文件应存放在受控位置，订阅地址与节点信息不应进入公开同步目录。若升级后出现问题，先回退最近变更项，不要删除全部配置重新开始。重建环境虽然有时能暂时恢复，但会同时清除能够解释原因的日志和差异。

分享日志前的处理

日志适合保留错误时间、错误类型、字段名、目标端口和客户端操作步骤，但其中可能出现订阅路径、服务器地址、用户标识或本机目录。向他人提供日志前，应删除订阅查询参数、节点识别信息和个人目录名，同时保留错误上下文。只截取最后一行通常缺少启动阶段信息；完整公开整个配置又会暴露不必要的数据。推荐提供“发生前执行了什么、预期结果、实际结果、首条错误及其前后若干行”。

稳定维护依赖可复现步骤，而不是频繁清空配置。只要保留基线、一次修改一个变量、从第一条错误开始阅读，大多数问题都可以定位到明确层级。主窗口各区域的作用可继续参阅v2rayN 主界面功能分区详解。

配置文件与进阶路线

从图形设置映射到配置结构

进阶学习的重点不是脱离图形客户端手写全部配置，而是理解界面操作最终改变了哪一段结构。V2Ray 系配置通常由 log、dns、inbounds、outbounds、routing 等部分组成。inbounds 定义流量如何进入内核，例如本机 SOCKS、HTTP 或 TUN 入口；outbounds 定义代理、直连与阻断出口；routing 决定入站流量送往哪个出站；dns 影响域名如何解析及解析请求经何种路径发送；log 决定记录级别与输出位置。

当 v2rayN 中切换服务器时，通常会改变主代理出站的参数；切换全局或规则模式会改变路由选择；修改本地端口会影响入站监听；启用 TUN 会新增或调整对应入站以及系统网络配置。理解映射后，日志中的 inboundTag、outboundTag、域名策略等词就不再是孤立字段。阅读配置时应先画出“入口—规则—出口”三段关系，再查看协议细节。

配置修改的最小变更法

手工调整配置前先复制当前可用版本，并给副本写明用途。每次只改一个逻辑目标，例如新增一个直连域名、改变 DNS 出站或增加一个测试入站。保存后先执行客户端或内核提供的配置检查，再启动并观察首段日志，最后验证与修改目标直接相关的请求。不要在同一次编辑中重排所有路由、替换 DNS、修改监听端口和更换节点，因为即使最终连接成功，也无法判断哪项修改真正产生了作用。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

这段示例展示本机 SOCKS 入站、直连与阻断两个基础出站。监听地址使用 127.0.0.1，表示仅本机访问；开启 UDP 允许该入站接收相应请求。它不是完整的远端代理配置，因为代理出站必须使用订阅或服务器提供的真实协议参数。学习时可以用这种精简片段理解结构，但日常连接应让客户端生成与订阅相匹配的完整配置。

日志级别与观察范围

日常运行使用 warning 等较克制的日志级别即可；排查复杂路由或连接过程时可临时提高详细程度，问题确认后再恢复。详细日志会快速增加内容量，也可能记录更多目标信息，不适合长期启用。观察日志时应围绕一个测试请求记录时间点，然后从该时间附近查找入站、目标域名、路由决定和出站错误。没有明确测试动作的长日志通常难以区分后台请求与目标请求。

推荐的进阶学习顺序

第一阶段掌握系统代理、节点选择和日志入口；第二阶段理解域名、IP、端口与规则顺序；第三阶段学习 DNS 请求发生的位置以及 domainStrategy 的影响；第四阶段再研究 TUN 的虚拟接口、默认路由和 UDP；第五阶段才进入协议字段与传输参数。这个顺序从本机可观察行为逐步进入协议细节，遇到问题时仍能回到已经验证的基础层。

协议学习应围绕字段关系展开。VLESS 等协议字段负责身份与流控，TCP、WebSocket、gRPC 等传输方式负责承载，TLS 或 REALITY 负责相应的安全与认证参数。任何分享链接都应作为一组完整参数处理，不能根据名称相近就互换字段。需要比较单节点链接与订阅的结构时，可阅读vmess 与 vless 分享链接怎么用。

形成自己的运行基线

完成本手册后，建议建立一份设备基线：记录客户端名称、系统平台、监听端口、系统代理模式、TUN 状态、DNS 路径、路由规则来源和常用订阅分组。基线不需要保存节点敏感参数，只需要描述配置关系。每次升级或修改后，用同一组场景验证：客户端启动、订阅更新、普通网页、规则分流、局域网访问、UDP 应用和休眠恢复。结果与基线一致，才能认为变更完成。

从零到精通并不意味着记住每个字段，而是具备稳定的分析顺序：先确定问题层级，再收集日志证据，随后做最小修改，最后用对照测试确认。需要重新走一遍最短配置流程时返回快速上手；需要更换平台安装包时前往客户端下载页。二者负责操作入口，本手册负责解释配置之间的因果关系。