V2Ray 使用手册

核心概念与连接路径

客户端、内核和服务端各负责什么

V2Ray 是一套代理技术生态中的常见名称，不等于某一个安装包。v2rayN、v2rayNG 和 v2flyNG 是图形客户端，主要负责保存节点、管理订阅、选择运行模式和生成配置。真正处理连接的是内核。服务端则位于远端，接收符合约定的协议请求。安装客户端只是准备本地工具，并不会自动获得可连接的服务端，也不会自动生成可用订阅。

Project V 提供了相关技术的基础背景，V2Fly 延续 V2Ray 内核生态，Xray 是另一条相关的内核实现路线。不同内核能够识别的协议、传输方式和参数并不完全相同，因此不能只看节点名称判断兼容性。节点写着某种协议，还需要检查传输、安全层以及附加参数。图形界面能够保存某个字段，也不代表当前选用的内核一定支持该组合。

把一次访问拆成四个环节

理解连接时，可以沿着“应用程序、本地入口、路由决策、远端出站”逐段观察。浏览器首先决定是否把请求交给代理；客户端通过本地监听端口或虚拟网络接口接收流量；路由规则再决定使用直连、代理或阻断出站；代理出站最后与远端服务建立连接。任意一段没有接上，都可能表现为网页打不开，但处理方法不同。

例如，浏览器访问正常而另一款应用连接失败，首先应确认后者是否遵循系统代理，不应立即更换节点。客户端日志完全没有出现对应请求，通常说明流量尚未进入本地入口。日志已有请求却显示远端握手失败，应转向检查服务端地址、端口与安全参数。能够建立连接但域名解析报错，则需要单独分析 DNS，不能把所有现象都归结为线路质量。

区分协议、传输与安全层

VMess、VLESS 等名称描述代理协议；TCP、WebSocket 等涉及承载方式；TLS、REALITY 则涉及安全传输相关机制。它们不是同一级别的替代选项。导入时需要整套参数保持一致：协议选对但路径、服务器名称或公钥填错，仍然不能连接。REALITY 的公钥与短标识也不是订阅密码，不应套用其他节点的值，更不能凭客户端提示自行猜测。

节点地址可能是域名，也可能是数字地址；用于连接的地址与安全握手使用的服务器名称可以不同。端口表示远端服务监听位置，本地端口则表示客户端在设备上的入口，两者不能互换。教程中出现的本地回环地址只指当前设备，填入另一台设备时不会指向原来的客户端。涉及局域网共享时，还需要另外处理监听范围、防火墙和访问控制。

本手册后续每个阶段都保留一个验证点：安装阶段看核心是否能启动，订阅阶段看节点是否完整，代理阶段看请求是否进入日志，路由阶段看出站是否符合预期。按这个顺序记录结果，比连续切换多个开关更容易定位问题。对陌生术语可先查阅术语表，再回到对应步骤继续配置。

按平台与内核选择客户端

桌面环境优先选择 v2rayN

Windows、macOS 与 Linux 桌面环境优先从 v2rayN 开始。先确定操作系统，再确认处理器架构，最后选择安装包形态。架构决定程序能否在设备上运行，包格式决定安装方式，两者是不同条件。下载页按平台列出入口，选择时应以系统信息为准，不要依据设备外观或购买年份猜测，也不要把压缩包名称里的平台词当作通用标记。

Windows 提供 Desktop 与 WPF 两种发行形态。Desktop 使用新一代跨平台界面，WPF 保留经典 Windows 界面。两者可能在设置位置、运行环境和功能呈现上存在差别，但节点参数仍需与服务端一致。首次安装可先按下载页说明选择一种并完成连接，避免同时运行两套客户端；同时运行可能造成端口占用或系统代理被反复覆盖。

Android 先看协议需要，再看包架构

Android 首推 v2rayNG，使用 Xray 内核；需要 V2Fly 路线时可考虑 v2flyNG。两款客户端不能仅凭名称相近就认为功能完全等价。包含特定安全传输参数的节点，应先确认目标客户端及其内核是否支持。已有可用订阅时，保留服务方提供的协议说明，比根据节点名称里的缩写判断更可靠。缺少必要字段时应向来源确认，不应手工拼接参数。

下载页提供 arm64 与通用包。主流较新设备通常使用 arm64，但旧设备、特殊设备和模拟环境仍需查看实际架构。通用包适合架构不明确或需要覆盖不同设备的情况，体积一般也更大。若系统提示无法安装，不要反复点击安装按钮；应检查系统兼容性、包是否适合设备，以及是否与已装应用的签名或安装来源存在冲突。

把“内核选择”放在参数兼容之后

内核切换不是通用的提速按钮。某个节点无法连接，可能是参数缺失、订阅解析不完整或网络不可达，换内核未必有效。需要切换时，先记录节点协议、传输、安全层与报错，再核对新内核的支持范围。客户端可能允许为不同节点指定核心类型，也可能采用固定内核；具体以当前设置为准，不要套用其他平台的菜单路径。

macOS 在“关于本机”中确认芯片类型，再选择 Apple Silicon 或 Intel 入口；Linux 同时确认发行版的软件包体系和架构，不能把 deb 与 rpm 当作同一文件的不同名称。桌面环境、权限管理和系统代理实现也会影响使用方式。下载成功只完成了选包，不代表当前桌面应用一定会自动遵循代理，需要在后面的模式验证阶段继续检查。

选择完成后，建议固定一个主客户端进行学习，记录它的数据存储位置、当前运行方式和退出行为。确需迁移时，先备份原配置，再逐个核对订阅、路由与 DNS，不要只复制节点后就假定全部设置已经转移。详细差异可查阅客户端对比；实际安装入口统一位于下载页，本页不直接提供安装包。

安装与首次运行检查

桌面安装先处理目录与权限

在 Windows 上，使用安装程序时按提示完成安装；使用可解压发行包时，应先完整解压到固定目录，再启动主程序。不要直接在压缩文件预览窗口里运行，也不要只拖出可执行文件，核心与相关资源可能仍留在压缩包中。选择便于管理、当前用户可写的目录，避免把需要频繁写入的配置放在受严格保护的位置。遇到权限提示时，先判断它在执行哪一步。

首次运行若提示缺少运行环境，应区分图形界面依赖与核心启动失败。WPF 和 Desktop 的依赖条件可能不同，以当前发行说明和系统提示为准。不要从不明弹窗安装所谓修复工具，也不要把所有启动失败都当作缺少运行库。界面能够打开但核心退出时，应进入日志查看具体原因，常见分支包括文件缺失、配置无法解析、端口被占用或系统限制。

macOS 与 Linux 的安装边界

macOS 选择适合芯片的磁盘映像后，按窗口提示将应用放到应用程序目录，再从正式位置打开。系统安全确认应通过系统设置中的明确入口处理，不建议为了启动一个客户端而全局关闭安全保护。如果提示应用无法打开，先确认文件是否适配设备、安装过程是否完整，以及系统给出的具体原因，再决定下一步，不能直接套用终端命令绕过所有检查。

Linux 按发行版选择 deb 或 rpm，并使用系统的软件安装工具完成依赖处理。若安装器报告依赖冲突，应先解决软件包状态，而不是从其他发行版复制库文件。普通代理模式通常不需要把整个图形客户端长期作为高权限进程运行；涉及虚拟接口或路由调整时才可能需要额外授权。授权范围与方式依赖发行包实现，应优先遵循当前客户端提供的提示。

Android 安装与首次授权

Android 安装前检查包架构，系统要求允许当前来源安装应用时，仅对实际使用的安装来源授权。已装同名应用无法覆盖安装，可能涉及签名不同或降级限制；卸载会删除应用数据，因此应先确认是否能够导出配置。首次启用连接时，系统会要求建立 VPN 连接，这是客户端接管流量所需的系统授权，不表示已经完成远端握手，也不代表节点一定可用。

若设备已有其他使用 VPN 接口的应用，通常需要先停止原连接，再启动当前客户端。电池管理可能影响后台持续运行，但不应在首次安装时一次性放开所有权限。先完成前台连接测试，再根据实际断连情况调整后台活动和电池限制。系统通知、VPN 标记与客户端状态可辅助判断进程是否仍在运行，最终仍应结合请求测试和日志确认。

安装后的检查顺序是：确认界面正常打开，查看核心是否启动，记录本地监听地址和端口，再检查是否存在另一个客户端占用相同入口。此时没有节点也可以检查本地状态。若需更改端口，应同步修改应用中的手动代理设置，否则应用仍会连接旧端口。端口数值以当前客户端界面为准，不把其他教程给出的数字当成固定标准。

最后确认退出行为。有的桌面客户端关闭窗口后仍留在托盘，真正退出需要使用托盘菜单；有的设置会在退出时清除系统代理。首次配置应实际执行一次退出和重新打开，观察代理是否恢复正常。Windows 安装形态的进一步说明见WPF 与 Desktop 安装教程，不要在安装尚未稳定时继续叠加分流和 TUN 设置。

订阅导入、更新与参数检查

先分清订阅地址与单节点链接

订阅地址用于获取一组节点，通常需要保存到订阅分组后执行更新；单节点链接则描述一个具体连接，可通过剪贴板或二维码导入。两类内容的入口不同。把订阅地址粘到单节点参数框，或把节点链接当成订阅源，都可能出现空列表或解析失败。导入前先阅读来源给出的使用说明，确认它提供的是哪种格式，以及是否支持当前客户端。

v2rayN 中可进入订阅分组管理，新增分组、填写便于识别的备注和订阅地址，保存后再执行更新。v2rayNG 与 v2flyNG 可从侧栏的订阅分组设置进入相应管理页面。界面名称可能略有不同，但顺序一致：创建分组、保存地址、获取内容、检查节点。只保存地址没有更新时，列表为空并不说明订阅失效，也不需要立即卸载客户端。

更新失败要区分获取与解析

更新失败主要分为“地址无法访问”和“返回内容无法解析”两类。前者检查设备网络、订阅有效期、地址是否完整以及请求是否需要已有代理；后者检查返回的是不是登录页、网页提示或不受支持的格式。如果客户端提供通过代理更新的选项，只有现有代理已经可用时才适合使用。首次没有可用节点时启用它，可能形成更新依赖尚未建立连接的循环。

订阅更新成功后，先核对协议、服务器地址、远端端口和安全传输字段，不以节点显示名称作为唯一依据。同一地区的多个条目可能具有不同传输组合，名字相似也不代表可互换。导入后若出现明显缺失字段，优先检查订阅格式和客户端兼容性，不要把其他节点的服务器名称、路径或公钥复制过来试错。参数需要成套对应。

手动节点与订阅节点分开管理

订阅节点通常会在下一次更新时被重新生成，直接修改其中的参数可能被覆盖。需要验证某个字段时，先复制到独立的手动分组，并在备注中说明它是测试副本。测试完成后保留原始订阅作为基准，避免多个副本混在一起难以分辨。删除分组前也应确认是否同时删除节点，以及其他设置是否仍引用该分组或选中的条目。

选择节点时，先用客户端提供的连接测试建立粗略判断，再用真实目标应用验证。不同测试可能只测端口连通、握手或一次请求，它们不能直接代表所有业务体验。空白测试结果、测试超时与节点完全不可用不是同一个结论。流量额度、使用状态和地区选择应结合订阅来源的说明，客户端本身不会替服务端补足权限或恢复已停用的服务。

如果列表突然变空，先确认当前选择的分组和筛选条件，再看更新记录。可能只是切到了另一个分组，也可能来源暂时返回空内容。保留最近可用备份，不要连续删除并重建所有分组。若部分节点正常、部分失败，优先按协议与传输分类比较，这通常比重复更新整个订阅更有信息。所有节点同时失败才进一步检查本地环境和订阅状态。

每次更新后重新确认当前选中节点，避免原节点被删除后客户端未自动选到预期条目。节点取舍可参考延迟、倍率、地区与协议的选择说明。完成本章的标志不是列表里出现条目，而是已经拥有一条参数完整、能够用于后续验证的连接，并清楚它来自哪个订阅分组。

系统代理与应用接管范围

系统代理是应用约定，不是全设备接管

桌面系统代理告诉遵循该设置的应用把请求交给本地代理入口。它不会自动接管所有程序，也不会改变每个应用的网络实现。浏览器通常较容易验证，某些游戏、命令行工具或内置网络组件则可能忽略系统代理。因此，“浏览器可访问、其他软件不可访问”首先是接管范围问题，不应直接判断客户端失效。后续可以使用应用自身代理设置或按需要考虑 TUN。

v2rayN 常见系统代理选项包括清除系统代理、自动配置系统代理、不改变系统代理和 PAC 模式。清除通常移除当前系统代理指向，但不等于停止核心；自动配置会把系统指向客户端提供的本地入口；不改变表示保留现有系统设置，并不表示主动建立连接。选择之前先确认当前系统是否已有手动代理或其他软件维护的配置，避免相互覆盖。

PAC 与核心路由不是同一层判断

PAC 通过自动代理脚本让遵循它的应用决定直连还是交给代理。请求如果在这一步被应用直连，就不会进入客户端核心，核心里的路由规则也无法再处理它。核心路由则处理已经进入本地入口的请求。两者可以叠加，但排查时会增加变量。初次验证建议固定使用一种明确的入口方式，确认连接后再决定是否需要 PAC。

应用手动代理需要核对入口协议。HTTP 代理端口与 SOCKS 端口可能不同，也可能由同一个混合入口承接，应以当前监听设置为准。地址写本地回环地址时，只能连接同一设备上的客户端。若浏览器保存了旧端口，即使系统代理已更新，它自己的手动设置仍可能优先生效。浏览器扩展也可能控制代理，测试时应暂时固定由一处管理。

Android 的 VPN 模式与路由选择

Android 客户端通过系统 VPN 接口接收流量，是否覆盖所有应用还取决于分应用规则和路由配置。系统 VPN 标记说明接口已建立，不说明每个请求都通过远端代理。被排除的应用可能保持原网络路径，规则设为直连的目标也仍可由本地网络访问。排查某款应用时，应同时查看应用范围与核心出站，而不是只观察连接开关。

验证时先选一个稳定可访问的测试目标，启用连接后发起新请求，并观察客户端日志是否出现相应连接。浏览器缓存可能让页面在网络未真正发起请求时仍然显示，已有长连接也可能沿用旧路径；可使用新的页面请求并重新建立连接。日志没有请求就检查入口，有请求但失败再检查出站，成功却内容异常则进一步分析目标服务和 DNS。

退出前应清楚当前系统代理由谁维护。客户端已经停止，但系统仍指向其本地端口时，遵循代理的应用可能全部失去连接。恢复方法是清除遗留系统代理，或重新启动对应客户端，不需要立即重置所有网络设置。切换不同客户端时也应先停止原连接并确认系统状态，避免一个程序清除另一个程序刚写入的代理地址。

本阶段以“目标应用请求确实进入客户端”为完成条件，暂时不追求复杂分流。如果需要简洁操作路径，可返回入门指南的连接与验证步骤；遇到模式名称与实际范围不一致时，可查阅帮助中心。下一阶段再讨论进入核心后的流量如何选择出站，避免把接管与分流混成同一个开关。

路由规则、DNS 与匹配顺序

先理解入站、规则与出站的引用

进入核心的请求需要通过路由选择去向。规则通常按配置顺序检查，满足条件后交给指定出站；后面的规则不再接管同一次匹配。因此，宽泛规则放在前面可能遮住后面的精细规则。修改前应先确认客户端生成了哪些出站标签，以及默认未匹配流量如何处理。界面中的“代理”或“直连”名称，不一定就是配置文件里的实际标签。

直连表示由当前设备直接向目标建立连接，代理表示使用配置好的远端出站，阻断表示拒绝对应流量。三者不是网络质量等级。对局域网服务使用代理，可能导致打印机、路由器管理页或本地开发服务无法访问；对需要远端出站的目标使用直连，则可能得到不同的访问结果。规则应服务于明确需求，而不是把所有条目统一改成同一方向。

从一段最小规则理解字段

下面是 Xray 风格的路由片段，表示特定域名集合与私有地址走名为 direct 的出站。它不是可以直接替换整个客户端配置的完整文件；运行时必须存在同名出站，且内核环境中具备相关规则数据。客户端已管理路由时，应优先在路由界面添加同等规则，避免手动配置和界面生成结果互相覆盖。

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

domainStrategy 描述路由匹配过程中如何处理域名与地址的关系。IPIfNonMatch 允许在域名阶段未匹配后解析地址，并继续进行地址规则判断。它不等同于所有 DNS 请求都自动通过代理，也不表示每个应用的解析都受同一设置控制。不同内核与客户端还有独立的 DNS 配置，修改路由策略后应分别验证解析路径和实际连接路径。

域名规则与地址规则各有边界

域名规则需要核心掌握目标域名。如果应用直接连接数字地址，或者请求进入时没有可用域名信息，原先设计的域名规则可能无法命中。嗅探功能在适用条件下可以辅助识别部分协议中的目标信息，但不能保证识别所有流量，也不能代替正确的 DNS 与入口设置。开启嗅探后仍应检查日志，不要仅凭规则名称判断它已经生效。

DNS 故障常表现为域名访问失败而数字地址连通，但这只能作为线索。安全连接还可能依赖服务器名称，直接用数字地址访问不一定具备相同条件。排查时先看解析是否有结果，再看结果对应的连接是否成功，最后检查安全握手。不要同时更换解析服务器、开启嗅探并调整路由，否则即使问题消失，也无法知道真正起作用的是哪一项。

维护规则时遵循“例外在前、范围明确、修改可回退”的原则。先添加一条局部规则，用目标应用发起新请求，再从日志核对匹配结果；确认后才扩展到一组域名。规则数据库也会影响集合匹配结果，因此更新客户端后出现差异，应同时检查规则数据和配置，而非只比较界面选项。配置结构的进一步拆解见inbounds、outbounds 与 routing 逐段说明。

TUN 模式与系统路由边界

什么时候需要虚拟网络接口

TUN 通过虚拟网络接口接收系统流量，再交由客户端或相应内核组件处理，适用于不遵循系统代理、又缺少应用代理选项的场景。它解决的是流量如何进入客户端的问题，不会修复错误节点参数，也不会让已停用的订阅恢复。系统代理已经满足需求时，不必为了“更完整”而开启 TUN；接管层次越多，权限、DNS 和路由排查就越复杂。

启用之前，先确认普通代理方式下已有可用节点，并记录当前系统代理、路由模式和 DNS 设置。若原连接本身失败，直接开启 TUN 会把基础连接故障与系统接管问题混在一起。部分发行形态可能需要额外服务、虚拟接口组件或授权，实际支持取决于当前客户端、系统与所选内核组合。界面存在开关不等于所有系统条件都已经满足。

按一次一项的顺序启用

先停止其他可能修改路由或占用 VPN 接口的程序，再按客户端提示启用 TUN。需要授权时确认来源和操作内容，不要把普通启动失败一概交给高权限运行解决。启动后观察核心与接口日志，确认没有权限不足、设备创建失败或路由写入失败，再测试目标应用。若接口未成功建立，反复切换节点通常没有意义，应先解决本地接管条件。

首次测试时，应避免不明原因地同时叠加系统代理与 TUN。某些客户端能够协调两者，但手动组合可能引入重复路径，使日志难以理解。可以先清楚地固定一种接管方式，再逐项恢复其他设置。访问测试不仅包含远端目标，还应包含局域网服务与普通网络连接，确认接管范围没有破坏本来可用的路径。

理解出口回环与私有网络例外

客户端需要通过真实网络连接远端服务。如果这条自身出站再次被虚拟接口捕获，就可能形成回环。成熟实现通常会处理接口绑定、路由排除或相应保护，但手工改动系统路由、叠加其他网络工具后仍可能破坏这些条件。现象可能是大量重复连接、连接建立后立即超时，或开启 TUN 后所有访问失败。此时应先关闭 TUN 恢复基线，再检查路由冲突。

局域网访问同样需要明确边界。路由器管理地址、打印服务、远程桌面和本地开发环境可能依赖私有地址直连。开启 TUN 后若这些服务失效，先检查私有地址规则、局域网绕过选项和虚拟接口路由，不能只把全部流量改成代理。不同网络环境的地址范围可能不同，企业网络还有自己的策略，应遵守网络管理员给出的要求，不随意覆盖已有路由。

DNS 与 UDP 也是验证重点。TUN 启动成功不代表所有域名查询都会遵循预期路径，应用自己的加密解析设置仍可能改变行为。实时通信或游戏使用的 UDP 能否正常工作，还取决于内核、节点与服务端能力，不能因为网页正常就认定它们也正常。验证时分开记录网页、解析和目标应用的结果，避免用一个测试替代全部场景。

如果关闭 TUN 后网络仍不恢复，先正常停止客户端，查看系统代理和现存 VPN 连接，再检查虚拟接口是否仍在活动。优先使用客户端提供的停止或恢复机制，不要直接批量删除系统网卡。保留启用前的设置记录，必要时重启系统以确认残留状态。完成本章意味着可以解释接管范围、验证目标应用，并能安全回到普通代理方式，而不仅是把开关保持在开启位置。

日常维护与分层故障排查

更新之前先保留可恢复状态

日常维护应区分客户端更新、内核更新、订阅更新和规则数据更新。它们改变的内容不同，不宜在出现故障时一次性全部执行。客户端更新可能调整界面与配置生成逻辑，内核更新影响协议能力，订阅更新改变节点来源，规则数据更新则影响分流匹配。先记录当前可用设置，再按需要更新其中一项，确认正常后再处理下一项，才能知道问题发生在哪个环节。

备份至少应覆盖订阅分组、手动节点、路由与 DNS 设置，以及应用接管范围。客户端提供导出功能时优先使用；复制数据目录时先停止程序，避免保存到一半的文件进入备份。备份文件可能含访问凭据，应存放在受控位置。恢复到另一款客户端或另一种发行形态时，不要假定所有内部配置格式兼容，必要时通过标准节点信息重新导入。

先看错误发生在哪一层

遇到连接失败，第一步检查本地网络是否仍能完成普通访问，第二步确认客户端核心是否运行，第三步确认请求是否进入日志。核心尚未启动就不必测试远端节点；没有请求进入日志则先查代理或 VPN 接管。请求已经进入核心后，再看远端连接、解析与握手结果。这一顺序能够把“本地没有收到请求”和“收到后处理失败”分开，减少无效切换。

日志中的超时只表示某个等待过程未按时完成，不会自动指出原因。连接地址超时可能涉及网络路径或服务状态，握手错误可能涉及服务器名称、密钥、系统时间或协议组合，解析错误则需要检查 DNS。应读取相邻日志行中的目标与操作阶段，而不是只搜索一个错误单词。复制日志求助时保留错误类型和时间顺序，遮住节点凭据与个人网络信息。

使用最小对照缩小范围

对照测试每次只改变一个条件。保持客户端与模式不变，换一个已知可用节点，可以检查问题是否集中在节点；保持节点不变，换到另一种可用网络，可以观察是否与当前接入环境相关；保持网络与节点不变，仅恢复默认路由，可以检查自定义分流。不能把同时换网络、换客户端和重建订阅后的成功，当作某一项设置有效的证据。

系统时间应由可信的系统时间同步机制维护，特别是涉及证书有效期或时间相关认证时。时间明显错误会让看似正确的参数仍然失败。另一个常见问题是残留系统代理：客户端退出后本地端口不再监听，但应用继续向旧入口发送请求。遇到这种情况先恢复系统代理状态，不要为了修复它直接删除全部节点或重装操作系统。

日志级别只在排查时按需提高，完成后恢复常规级别，避免长期保存过多访问细节。若只能提供截图，至少包含错误发生前后的相关行与当前模式说明，单独截取一句“连接失败”信息有限。节点超时的具体检查链可参阅七个检查点，一般使用问题可进入帮助中心。维护的目标是保留稳定基线，让每次调整都有记录和回退路径。

配置阅读与进阶学习路线

先读生成结果，再写自定义配置

完成前面阶段后，进阶的第一步不是堆叠更多规则，而是读懂客户端生成的配置。先找到本地入站、远端出站、直连出站、路由和 DNS 各自的位置，再沿标签引用检查它们的关系。界面显示的是便于操作的抽象，配置文件则反映核心实际收到的指令。两者出现差异时，应确认文件是否为当前运行实例生成，避免阅读旧配置后误判当前行为。

入站决定接收方式与监听范围，出站定义如何连接目标或远端服务，路由通过标签把两者联系起来。标签只是配置中的引用名称，不具有自动绑定能力。把示例里的出站标签改名后，引用它的所有规则都需要同步修改。配置语法正确也不等于逻辑正确，例如规则能被解析，却可能永远被前面的宽泛规则遮住，仍需通过请求测试验证。

用局部规则练习参数约束

下面的规则适合用于学习域名匹配：full: 指定完整域名，domain: 匹配给定域及其子域。示例目标使用文档示例域名，添加时需要放入已有路由规则数组，并确保 direct 出站已存在。它本身不是完整配置，也不包含远端连接信息。练习的重点是核对规则顺序、命中条件与引用标签，而不是直接覆盖原始文件。

{
  "type": "field",
  "domain": [
    "full:example.com",
    "domain:example.org"
  ],
  "outboundTag": "direct"
}

尝试自定义配置前，先确认客户端是否会在启动时重新生成文件。如果会，直接编辑生成结果可能只在短时间内有效，下次保存设置就被覆盖。应使用客户端提供的自定义配置、路由管理或模板入口，并弄清它与界面设置是合并还是替换关系。一个字段由多处同时管理时，最终取值往往不直观；应减少重复来源，让每项设置有明确归属。

协议学习按实际需要推进

协议进阶可从 VMess 与 VLESS 的基本差异开始，再理解安全层和传输组合。不要仅凭协议名称推断速度或稳定性，实际表现还受服务端、网络路径与应用行为影响。REALITY、TLS 或 WebSocket 都有各自的必要参数与适用条件，学习时应结合一条来源明确的节点逐项阅读，不把随机示例中的字段拼成新的连接。基础对比可阅读VMess 与 VLESS 说明。

随后再研究 DNS 策略、规则集合、嗅探和分应用范围。每个主题先提出一个可验证目标，例如让局域网服务保持直连，或让某个应用的请求进入指定出站。写出预期现象后再配置，测试时记录是否命中对应规则以及失败发生在哪一层。若无法说明一个选项预期改变什么，就暂时保持默认，不把复杂选项当成必开功能清单。

长期使用时建立简短的变更记录：修改了哪一项、解决什么问题、使用什么条件验证，以及如何撤销。遇到更新后的行为差异，先比较变更记录和运行配置，不要立刻重建全部环境。跨设备迁移也应重新验证系统代理、权限和接口范围，因为节点参数可以相同，操作系统的接管方式却未必相同。对敏感字段进行脱敏后，才适合把配置片段用于交流。

完整学习路线至此形成闭环：能解释连接路径，能选对安装包，能导入和管理订阅，能区分接管与分流，能验证 TUN 并回退，最后能用日志检查自定义规则。后续查阅不必每次从头开始，可使用顶部目录返回对应阶段；需要重新建立最小可用连接时，回到快速上手主线，再逐步恢复必要设置，避免让历史配置成为新的故障来源。