v2rayN 配置手册

第一阶段：核心概念

区分界面、内核与远端服务

先把连接拆成三部分。v2rayN 是图形客户端，负责保存节点、管理订阅、生成配置并启动内核；内核负责监听本地端口、处理协议、查询域名和选择出站；远端服务接收连接并转发请求。安装客户端不会自动获得可用节点，填写订阅也不代表远端服务已经可用。排错时分别确认这三层，能避免把远端故障误判成界面设置问题。

理解 Project V、V2Fly 与 Xray 的关系。Project V 是相关工具和协议的生态背景，V2Fly 延续 V2Ray 的开发，Xray 是相关内核分支。客户端可以通过不同内核实现连接，但“支持某个协议”不等于支持它的全部传输与安全组合。导入成功只说明配置能够被识别，还要检查实际内核能否解析生成的字段，并与服务端协商成功。

沿着一次请求理解参数

从应用发起请求开始看路径。读取系统代理的浏览器先连接本机监听端口，内核收到目标域名或地址后，根据规则选择直连、代理或阻止。代理出站再连接节点服务器，完成相应握手。使用 TUN 时，入口变成虚拟网络接口，但后续仍然需要路由判断与可用出站。因此，更换接管方式不能修复错误的节点地址、凭据或传输参数。

把节点参数分成几组阅读。服务器地址与端口确定连接目的地；用户标识或密码用于身份验证；传输类型决定数据如何承载；TLS、REALITY 等设置决定相应的安全握手。VMess、VLESS、Trojan、Shadowsocks 是不同协议，REALITY 不是与它们并列的订阅格式。参数必须按服务方提供的完整组合填写，不能凭名称相近就交换字段。

建立可观察的判断标准

区分域名解析、传输连接与应用响应。解析失败时，请求可能尚未到达节点；连接被拒绝通常需要检查监听或远端端口；握手错误则要核对安全参数和系统时间；页面返回错误状态还可能来自目标服务。不要把所有现象统称为“代理没开”。先记录出现问题的应用、目标、时间与模式，再查看同一时刻的内核日志。

理解测试结果的边界。列表中的连接测试只覆盖客户端所采用的测试方法，不代表所有网站、所有应用与所有网络都可用。某个探测目标被限制，可能让测试失败而实际业务仍能访问；反过来，测试成功也不能证明域名解析、长连接和文件传输都正常。应同时保留一个实际网页和一个实际应用作为验证样本。

完成本阶段时，尝试不用界面名称描述路径：哪个应用通过哪个入口，把什么目标交给哪个内核，再由哪条出站发送。能回答这些问题后，再查阅概念速查补齐术语。后续章节都围绕这条路径展开，不需要一次记住所有协议字段，更不需要在尚未连接成功时提前叠加复杂规则。

第二阶段：选择客户端

先按系统与处理器筛选

桌面端首选 v2rayN，再按操作系统和处理器架构进入客户端下载页。Windows 用户先查看“设置 → 系统 → 系统信息”中的系统类型；macOS 用户查看“关于本机”中的芯片或处理器；Linux 用户同时确认发行版包格式与机器架构。不要仅凭电脑品牌判断安装包，也不要把界面相似理解成不同平台的包可以互换。

在 Windows 下载区区分桌面版与经典 WPF 版。桌面版使用跨平台界面，适合希望在多种桌面系统保持相近操作方式的用户；WPF 版面向 Windows，保留经典界面与操作习惯。两者都要按实际包说明检查运行条件。不要仅凭“新”或“经典”判断某项功能必然存在，菜单位置、设置覆盖和运行环境可能随发行分支变化。

让内核能力与现有配置对应

Android 优先使用基于 Xray 内核的 v2rayNG，使用 V2Fly 内核的 v2flyNG 作为备选。选择依据应是已有节点使用的协议与功能，而不是安装更多客户端后反复切换。两款应用的设置不能假定完全一致，导入方式相似也不意味着配置数据库可以直接复制。首次使用可先读Android 上手步骤，只保留一个正在工作的网络接管入口。

区分客户端能力与订阅内容。更换客户端不会自动把普通节点变成另一种安全组合，也不会补齐服务端未提供的参数。遇到导入后字段缺失，先确认订阅面向哪类客户端、是否提供完整链接，以及该节点要求的内核。不要为通过导入而随意删除参数；能够保存的简化配置，可能在实际握手时才暴露不兼容。

迁移前保留可回退的工作环境

准备更换桌面界面时，先在旧环境记录订阅分组、当前节点、监听端口、路由模式和 DNS 设置，再导出客户端支持的备份。把新环境视为独立安装，先用一个节点验证基础访问。不要同时运行两套客户端争用相同监听端口，也不要让两边轮流写入系统代理，否则当前显示的模式可能与系统里实际生效的地址不同。

评估运行条件时，把界面启动与流量接管分开。能够打开主窗口，并不保证内核已成功启动；能够启动内核，也不保证当前账户能够创建虚拟网络接口。普通系统代理通常不需要整套程序长期以管理员权限运行，TUN 则可能需要提升权限或使用对应服务机制。应根据目标功能授权，不要把提高权限作为所有错误的统一处理方式。

完成选择后，写下一条明确结论：系统是什么、处理器是什么、使用哪款客户端、准备采用哪个入口模式。再查看下载页对应平台的要求，避免在安装途中临时更换方案。需要比较两套桌面界面时，可阅读v2rayN 桌面版与 WPF 版区别，重点核对系统支持和功能差异，而非仅比较外观。

本阶段的验收是“选对包”，不是“功能全开”。先满足当前设备与现有节点的要求，保留一个简单、可重复的连接方案。后续需要接管更多应用或调整规则时，再增加相应能力，能明显缩小故障出现后的检查范围。

第三阶段：安装与首次启动

准备固定目录与运行条件

从Windows 客户端入口选择已确认的版本类型，再根据安装包实际形式操作。安装程序按向导完成安装；压缩形式先解压到固定目录，再运行程序，不要直接在压缩窗口里启动。避免把持续使用的数据目录放在临时清理位置。程序需要保存配置、日志与内核文件，目录可写性比路径名称是否简短更重要。

首次启动若提示缺少运行组件，按当前发行包说明补齐对应组件，不要根据旧教程随意安装不匹配的架构。记录提示的完整名称，区分缺少运行环境、文件被阻止和内核无法启动。若系统显示安全提示，先核实来源与文件属性，再决定后续操作；不应为了让界面打开而整体关闭系统防护或允许所有未知程序。

确认界面与内核分别启动

打开主窗口后，先寻找日志或信息区域。此时还没有节点，连接未建立是正常现象；重点检查是否存在配置读取失败、路径不可写或监听失败。界面能响应只代表图形程序正常，不代表内核已经监听。添加节点后再次检查启动信息，确认没有立即退出或反复重启，再继续设置系统代理，避免浏览器被指向尚未工作的端口。

查看“设置”中的本地监听相关项目，记录地址、端口与支持的入口协议。不同版本可能提供混合入口或分别提供 HTTP、SOCKS 入口，不要从旧文章推断当前默认端口。通常只需要让本机应用访问回环地址。开启允许局域网连接会扩大可访问范围，只有明确需要共享给其他设备时才启用，并同时评估防火墙与访问限制。

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess

以上命令用于列出当前 TCP 监听端口与进程编号，不会修改网络设置。把结果中的端口与界面记录对照，再到任务管理器“详细信息”查看对应进程。若端口已被其他程序占用，优先退出重复运行的客户端；确实需要并行运行时，再修改其中一个监听端口，并同步更新依赖它的应用。不要看到陌生进程就直接结束任务。

保存启动基线与退出路径

暂时关闭开机启动、自动更新订阅和 TUN 等附加行为，先完成一次手动启动与退出。退出前清除系统代理，退出后确认浏览器仍可按原网络方式访问。这个动作能验证恢复路径：即使后续节点失败，也知道如何让系统脱离本地代理入口。仅关闭主窗口可能只是缩小到托盘，应使用托盘菜单确认程序是否真正退出。

其他桌面系统也沿用同一验收顺序：程序能够启动，数据能够保存，内核能够加载，监听没有冲突，退出能够恢复。macOS 按芯片选择安装入口，Linux 按发行版包格式安装；遇到权限问题时，检查当前安装位置与系统提示，不要把所有文件权限放宽。需要进一步定位监听冲突，可阅读本地端口被占用的处理方法。

完成本阶段后，保留安装位置、数据备份方式和监听设置的简短记录。重启一次客户端，确认设置仍然存在。只有这条基线稳定，后续导入订阅、调整规则时得到的现象才具有可比性，不会把安装层面的不稳定误当成网络变化。

第四阶段：订阅与节点管理

添加分组，再执行更新

打开“订阅分组设置”，添加一个容易辨认的分组名称，再把服务方提供的订阅地址粘贴到对应地址栏。检查首尾空格、换行和复制时附带的标点。订阅链接可能携带访问凭据，应按敏感信息保存，不要放进公开截图、笔记或问题反馈。保存分组后返回主界面，选中相应分组，再执行“更新当前订阅(不通过代理)”。

理解更新方式的区别。“不通过代理”通常用于本机尚未建立代理或订阅地址可以直接访问的情况；通过代理更新则依赖当前已有可用路径。若直连更新失败，先确认订阅地址在当前网络中的可达性，再判断是否需要改用已有代理。不要在完全没有可用节点时，指望通过代理更新自动解决首次获取问题，这会形成相互依赖。

区分获取失败与解析失败

观察更新反馈时，先判断是否拿到了内容。域名无法解析、连接超时与服务返回拒绝属于获取阶段；已经返回内容却没有节点，则可能是格式不适用、响应实际是登录页面，或节点参数无法识别。网页能够打开不代表返回的是订阅正文。需要联系服务方时，只提交错误类型和脱敏后的响应说明，不提交完整订阅地址与身份参数。

更新成功后，在节点列表核对名称、协议、地址与分组归属。相同名称不代表同一条配置，名称也不代表真实网络质量。选中一个节点，将其设为活动服务器，再观察内核是否成功加载。不要一次给大量节点并发测试，避免测试本身占用带宽、触发服务限制，或让短时结果掩盖实际使用中的稳定性。

处理手动节点与订阅覆盖

使用单条分享链接时，通过客户端提供的剪贴板导入入口添加，再核对导入字段。手动节点适合临时验证或少量配置，订阅分组适合由服务方集中更新。不要直接编辑订阅节点并假定修改永久保留，下一次更新可能重建记录。需要长期自定义时，先复制到独立的手动分组，并清楚标记它不再随原订阅同步。

删除分组前，确认操作影响的是分组记录、订阅节点还是全部服务器，避免把测试分组与日常分组混在一起。订阅更新后节点数量减少，不一定是导入损坏，也可能是服务方调整了可用条目。先看更新结果和分组筛选条件，再检查是否误选其他分组。恢复旧备份只能恢复本地记录，不能保证已失效的远端服务重新可用。

核对安全相关参数时，保持服务器地址、端口、用户标识、传输类型、服务器名称及对应密钥参数成组一致。不要为消除握手错误随意关闭证书验证，也不要把一个节点的安全字段复制给另一个节点。系统时间明显不准同样可能影响握手，应先修正设备时间，再复测。只有掌握服务端要求后，才进行手动字段调整。

安排更新频率时，以服务方的配置变化节奏为依据。频繁更新不会自动提升速度，反而可能覆盖正在排查的状态。重要调整前先保存本地备份，并记录当前活动节点；更新后用相同目标验证一次。这样能区分“内容发生变化”与“连接暂时失败”，也方便在保留现场的情况下继续定位。

完成本阶段的标准是：能解释订阅来自哪里、节点属于哪个分组、当前激活哪条记录，以及下一次更新会覆盖什么。基础导入失败可回到快速上手的订阅步骤按顺序重做；参数名称不清楚时，再查术语表，而不是反复删除整个客户端数据目录。

第五阶段：系统代理与代理模式

把接管入口与出站规则分开

先区分两个问题：应用怎样把请求交给客户端，以及客户端收到请求后怎样发送。“自动配置系统代理”负责前一个问题，路由中的全局或绕过规则负责后一个问题。开启系统代理不代表所有程序都会使用它；选择全局代理，也只影响已经进入内核的流量。理解这两个层次，才能解释为什么浏览器可用而某些桌面程序没有变化。

在 v2rayN 中选择“自动配置系统代理”，再到 Windows“设置 → 网络和 Internet → 代理”核对实际地址与端口。这里应与客户端当前用于系统代理的监听入口一致，不要仅看托盘图标判断。通常应指向本机回环地址，而不是节点服务器地址。远端节点端口用于内核连接服务端，不是给浏览器填写的本地代理端口。

按应用行为选择接管方式

先用一个确认读取系统代理的浏览器访问实际目标。浏览器如果配置了独立代理、扩展代理或特定配置文件，可能不会跟随系统设置。排查时暂时只保留一种代理来源，记录原设置后再关闭冲突项。命令行工具、游戏和后台服务也可能使用自己的网络栈，应查看各自设置，不能把浏览器成功直接推广到所有应用。

需要手动设置应用代理时，按应用支持的协议填写 HTTP 或 SOCKS 入口，使用客户端实际监听的地址和端口。两种入口的字段不能机械对调。若客户端提供混合入口，也要确认该入口确实支持所选协议。应用中存在单独的域名解析选项时，继续核对解析是否交给代理端处理，避免请求虽然走代理，域名却仍按另一条路径查询。

理解清除、保留与自动配置

“清除系统代理”用于移除系统当前的手动代理设置，但不会自动关闭每个应用内部配置。“不改变系统代理”表示客户端不主动改写系统项，并不等于系统目前没有代理。遇到退出客户端后网页全部失败，先查看系统是否仍指向本地端口，再查看浏览器是否保留独立配置。不要在客户端已经关闭时继续使用一个无人监听的入口。

切换模式前记录现状，切换后对照系统设置，再测试新建连接。已有长连接可能沿用旧路径，浏览器连接池也可能让结果延后体现。可以关闭测试页面并重新打开，必要时完全退出测试应用再试。不要在每次测试间同时更换节点、DNS 和路由，否则即使现象变化，也无法确定是哪项调整产生了作用。

完成本阶段后，至少做一次正向与反向验证：开启自动配置，确认浏览器通过本地入口工作；清除系统代理，确认恢复原网络行为。保留这组操作作为故障时的恢复步骤。只有在明确某应用不读取系统代理、又确实需要接管时，才进入后面的 TUN 阶段，而不是为了显示更多开关而全部启用。

第六阶段：路由分流与 DNS

从内置模式建立规则基线

先在路由相关菜单选择适合当前需求的内置规则，例如“绕过大陆”对应的模式，再观察实际访问。不同规则集可能包含私有地址、域名分类和默认出站的不同组合，不要只根据模式名称推断全部细节。使用前查看规则内容与顺序，确认本地网络资源是否直连、未命中的目标去哪里，以及规则所引用的数据文件是否能够正常加载。

理解匹配顺序。常见路由按规则从前到后查找，前面的宽泛匹配可能让后面的细分规则永远没有机会生效。为某个服务添加例外时，应先确定它与现有规则的关系，再放到适当位置。不要把“所有流量代理”放在顶部后，又期待末尾的私有地址直连规则起作用。调整后对照日志验证命中情况，而不是仅凭页面能否打开判断规则正确。

区分域名规则与地址规则

域名规则根据请求中可用的域名信息匹配，地址规则根据目标地址匹配。一个服务可能使用多个域名与分布式地址，仅添加首页域名未必覆盖登录、静态资源和下载请求。反过来，按某个解析地址添加规则，也可能误伤共享同一地址的其他服务。优先描述明确的业务域名范围，避免用一次解析结果代替长期稳定的规则。

{
  "type": "field",
  "domain": ["geosite:cn"],
  "outboundTag": "direct"
}

这是一条规则对象，不是完整配置。它需要放入相应内核配置的规则数组中，且环境中必须有可用的域名分类数据，实际出站标签也必须名为 direct。客户端生成的标签可能不同，应先查看生成配置再对应。不要把片段覆盖到整个配置文件，也不要直接粘贴到只接受分享链接的导入框；优先使用客户端支持的规则编辑入口。

让解析路径与流量路径一致

DNS 负责把域名转换成地址，但客户端内核、系统和应用可能分别进行解析。远程 DNS 与直连 DNS 是不同用途的配置角色，不是把某个地址填两遍就完成分流。若远程解析服务本身需要代理才能访问，还要确保访问该服务的连接有明确出站，避免解析依赖代理、代理连接又依赖尚未完成的解析，形成启动环路。

检查时先确认域名是谁解析的，再确认解析请求走哪条路。浏览器启用加密 DNS 后，可能绕过预期的系统解析链；应用直接请求地址时，内核也可能拿不到原始域名。嗅探可以在特定条件下提取协议信息，但并非能够识别所有连接，也不能代替完整的 DNS 设计。遇到分流异常，先简化路径，再逐层恢复功能。

排查错误命中时，记录完整目标域名、实际解析地址、规则顺序与当前出站。规则数据更新后，同一域名的分类也可能改变，应把数据更新视为一次配置变化。若临时例外规则解决了问题，继续确认根因再保留，不要长期堆积彼此覆盖的补丁。相关检测步骤见DNS 泄漏检测与防泄漏设置，重点核对预期解析路径。

完成本阶段后，应能说清三种结果：明确直连、明确代理、没有匹配时的默认行为。再检查重启后规则是否保留，内核是否报告不认识的字段或缺失数据。只有路由与解析在系统代理下稳定，再启用 TUN；否则更大的接管范围会把原来的局部问题扩展到更多应用。

第七阶段：TUN 模式与接管范围

先判断是否确实需要虚拟接口

TUN 通过虚拟网络接口接入符合路由条件的系统流量，适合处理不读取系统代理、又需要纳入统一分流的应用。它改变的是流量入口，不会赋予节点额外协议能力，也不会让错误凭据自动恢复。开启前先确认同一节点在普通系统代理下已经可用，把工作基线保留好；如果基础连接都不稳定，应先回到订阅、监听和路由章节排查。

评估接管范围时，把本机、局域网和远端分别列出。打印机、共享目录、开发服务、远程桌面与其他虚拟网络可能需要特定直连路径。TUN 并不天然等于所有地址都应进入代理，应在启用前确认私有地址与必要网段的处理方式。不要等到远程管理连接中断后，才第一次考虑如何恢复网络；远程操作设备时尤其要准备本地恢复手段。

按权限、接口与路由顺序启动

保存配置后，按当前客户端要求使用管理员权限或相应服务机制，再打开“启用 Tun 模式”。不同界面与内核的启动方式可能不同，应查看实际提示。打开开关后不要立即以访问失败下结论，先确认内核没有退出、虚拟接口已经创建、系统路由完成设置。日志中出现权限不足、接口创建失败和路由写入失败时，应分别处理。

若提示接口或驱动相关问题，先退出重复运行的客户端，确认其他虚拟网络软件是否正在占用相近资源。不要直接删除系统里所有虚拟网卡，也不要批量卸载驱动。某些接口来自虚拟机、容器或企业网络，删除会影响原有环境。先关闭 TUN 并重启客户端，再依据明确错误处理对应组件，保留每一步操作记录。

验证 TCP、UDP 与 DNS 的实际行为

先测试原本通过系统代理可用的网页，再测试此前未被接管的目标应用。两者都成功，才能说明入口变化达到了目的。应用包含 UDP、语音或实时通信时，还要确认远端与相应协议组合支持需要的流量。网页访问正常不能代表 UDP 一定正常；应用启动正常也不能代表后续媒体连接沿用相同路径，应验证实际业务操作。

DNS 是 TUN 排错中的单独一层。启用后可能出现系统解析、应用加密解析与虚拟接口接管共同作用的情况。若地址连接看似正常而域名访问失败，优先检查解析链、远程解析服务的可达性和路由循环。不要通过永久固定目标地址掩盖解析问题，也不要直接清空所有 DNS 设置；先保留当前值，再逐项对照内核支持的配置方式。

遇到局域网设备无法访问，先确认目标地址、子网掩码和当前路由，而不是只增加一个域名例外。使用地址直连的共享服务不会匹配域名规则。若同时运行其他网络隧道，路由优先级和默认出口可能竞争，应逐个关闭非必要入口做对照。测试完成后再恢复组合环境，确认是哪一项组合触发冲突，避免把所有问题归因于节点。

睡眠唤醒、切换无线网络或插拔有线网后，应重新验证虚拟接口与解析路径。恢复失败时，先尝试关闭再开启 TUN，让客户端重建对应状态；仍然失败则查看新日志，不要反复提升权限。正常退出后确认网络能够恢复，异常结束后也检查系统代理与路由现状。详细原理与步骤可继续读v2rayN TUN 模式配置笔记。

本阶段的验收不是“开关保持开启”，而是新增应用被正确接管、直连资源仍然可用、退出恢复路径明确。满足实际需求后再保留 TUN；如果普通系统代理已经覆盖全部使用场景，可以继续采用更简单的入口，减少权限、接口与路由之间的相互影响。

第八阶段：日常维护与故障定位

把备份与更新拆成独立操作

在连接稳定时建立备份，包含订阅分组、手动节点、路由、DNS 与必要的自定义设置。使用客户端提供的导出方式，并记录哪些内容没有包含在备份中。备份可能携带订阅凭据和节点身份信息，应保存在受控位置，分享前必须脱敏。仅保存主程序文件不足以恢复使用状态，仅截取节点名称也无法还原完整参数。

区分客户端更新、内核更新、订阅更新与规则数据更新。它们改变的对象不同，应分开执行并逐次验证。更新客户端前先正常退出，避免文件仍被占用；更新后检查菜单、监听与配置迁移结果。若当前包对内核组件有统一管理，应按对应机制处理，不要随意把其他来源的内核文件覆盖进去，防止界面生成字段与内核能力不匹配。

按入口到出口定位故障

出现问题时先停止继续改设置，记录故障发生前最后一次变化。按“应用是否使用入口、本地是否监听、内核是否启动、域名是否解析、节点是否握手、目标是否响应”的顺序检查。每通过一层再进入下一层。这样能把现象缩小为具体边界，而不是同时切换多个节点、刷新订阅并重置系统网络，导致现场无法复现。

浏览器失败而其他应用正常，先检查浏览器独立代理、扩展、加密 DNS 与缓存连接。所有应用都失败，先检查监听与内核日志。只有某个目标失败，先判断目标本身、域名规则和分布式资源是否存在差异。换网络后才失败，则比较 DNS、接入认证和路由环境。分类比重复点击连接测试更有价值，也能减少不必要的配置重建。

Get-Date
Resolve-DnsName example.com

上面的命令查看当前系统时间和系统解析结果，不代表已经测试了客户端内部远程 DNS。用它建立对照：系统解析失败但内核解析正常，说明两条链路不同；系统解析正常也不能证明代理出站正常。握手错误时顺便核对系统时间，记录时区与时间同步状态。不要把一次命令成功当作整条代理链路通过，仍需用实际应用验证。

记录最小复现与恢复动作

阅读日志时优先寻找第一条相关错误，而不是只看后续连锁超时。记录错误所属模块、目标类型和发生时间，再与操作顺序对应。反馈时移除完整订阅地址、用户标识、密码与其他敏感字段；需要展示规则时，只保留相关片段及出站关系。日志级别提高后可能产生更多访问记录，定位完成就恢复合适等级并清理不再需要的副本。

备份恢复也要验证，不应假设导入成功就等于环境完全还原。先确认分组存在，再确认活动节点、监听端口、路由和 DNS，最后检查系统代理或 TUN。旧环境中的接口、权限与安装路径可能不适用于新设备，应按新系统重新建立。恢复时保留当前备份，避免用一个来源不明的旧配置覆盖唯一可用状态。

移动端维护另需检查电池优化、自启动和后台限制。连接在锁屏后中断，与桌面监听端口冲突不是同一类问题，不应复制桌面排错步骤。可参考v2rayNG 后台与电池设置建立设备侧检查表。无论使用哪款客户端，都先保留能恢复的配置，再安排更新，把网络可用性与软件变更分开验证。

完成本阶段后，准备一份简短恢复清单：清除系统代理、关闭 TUN、确认原网络、启动客户端、加载基线节点、恢复分流。真正发生故障时按清单执行，比临时搜索零散建议更容易保持判断一致，也能避免把原本局部的问题扩大到整个系统。

第九阶段：进阶配置与学习路线

从读取生成配置开始

进阶的第一步不是编写一整份配置，而是阅读客户端实际生成的内容。找到当前配置的查看入口，区分入站、出站、路由、DNS 与日志模块，观察它们怎样对应界面设置。注意生成文件可能随启动或切换节点被重建，直接编辑后未必长期保留。先了解客户端支持的自定义入口和合并规则，再决定哪些内容适合交给界面管理。

练习追踪一个出站标签。先找到代理出站和直连出站的实际标签，再查看规则引用是否对应，最后确认未匹配时的默认行为。标签是配置内部的引用关系，不是固定中文名称，也不是节点备注。复制其他资料中的规则前，必须完成这一层映射。字段合法但标签不存在的配置，可能在启动阶段就失败，也可能无法按预期选择出口。

为每项实验定义预期结果

每次实验写下目标、改动和回退方式。例如让某个明确域名直连，预期应是该域名命中指定规则，其他目标路径不变；为某个应用启用 TUN，预期应是该应用新增流量进入内核，本地资源仍可访问。把预期写得足够具体，才知道测试应该观察什么。仅以“似乎更快”判断复杂配置，无法排除缓存、节点和网络波动的影响。

保留一个专门用于实验的配置副本，避免在日常工作环境反复叠加参数。先完成单个例外规则，再尝试多规则组合；先理解基础解析，再研究更复杂的域名处理方式。出现新问题立即回到最近一次可用状态，对比改动，而不是继续添加补丁。实验记录应能让隔天重新打开设备后，仍然理解每个自定义字段的用途。

按问题类型选择下一条路线

协议路线适合经常遇到导入或握手问题的用户。依次学习服务器地址、认证、传输、安全层和服务端名称，理解哪些参数必须由远端提供。不要把协议名称当作性能排行，也不要根据单次测试就判断一种组合普遍优于另一种。协议选择首先受服务端支持与实际网络环境约束，客户端只能在兼容范围内执行已有配置。

路由路线适合需要访问局域网资源、区分服务去向或处理复杂应用的用户。先掌握规则顺序、域名与地址的区别，再学习分类数据和默认出站。DNS 路线则继续追踪解析由谁发起、经哪个出口发送、结果怎样参与匹配。两条路线需要相互验证，但初次调整时仍应分开实验，否则一次访问变化可能同时涉及解析结果和规则命中。

系统网络路线适合需要长期使用 TUN 的用户。学习接口、路由表、地址范围和权限边界，理解网络切换、虚拟机与其他隧道为何可能产生冲突。不要仅为获取更多功能而开放局域网监听，也不要在不了解访问范围时共享本地端口。把服务暴露给其他设备后，需要额外评估认证、设备可信度与防火墙，已不再只是本机代理设置。

形成自己的可维护配置

整理最终配置时，删除已失去用途的临时例外，给保留规则记录简短原因，并写清它依赖的内核能力和数据文件。规则越多不代表覆盖越完整，互相重叠反而增加阅读成本。不要保存无法解释的整段参数；确实需要保留时，先在实验副本中证明它解决了什么问题，再合并到长期配置，并确认重启后仍然生效。

建立固定阅读顺序：操作遗忘时回到快速上手，术语不清时查概念速查，出现具体错误时读技术笔记，需要更换平台时进入客户端下载页。系统手册负责连接这些知识，不要求一次全部启用。保持一个能够说明、验证和恢复的工作方案，再按实际问题逐步扩展，就是这条学习路线的终点。