V2Ray 从零到进阶完整手册

一、核心概念：先看清客户端、内核与配置的边界

图形客户端不等于代理内核

学习 V2Ray 时最容易混淆的，是把图形客户端、代理内核、节点配置和系统代理视为同一个东西。实际上它们位于不同层级。v2rayN、v2rayNG 与 v2flyNG 提供窗口、订阅列表、节点选择、日志和开关等交互界面；Xray 或 V2Fly 内核负责解析配置、建立传输连接、匹配路由规则并提供本地代理端口；订阅或单个分享链接负责把服务器地址、端口、用户标识、协议与传输参数交给客户端；系统代理与 TUN 则决定应用流量怎样进入本地内核。只有四层顺序都正确，浏览器或其他程序的请求才会沿预期路径转发。

因此，“客户端已显示运行”只能证明本地进程已经启动，不能单独证明订阅有效、节点可达或应用流量已经进入代理。排错时应按数据流逐层检查：先确认配置能被客户端识别，再确认内核启动成功，然后确认本地监听端口存在，最后确认系统或应用确实使用该端口。把这些阶段拆开，会比反复点击连接按钮更快找到问题。

入站、出站与路由是怎样配合的

内核配置里常见三个关键部分。入站负责接收本机应用交来的请求，例如本地 SOCKS 或 HTTP 代理端口；出站描述请求离开本机后的处理方式，通常包括远端代理、直连和阻断；路由位于两者之间，根据域名、IP、协议类型或进程条件选择某个出站。图形客户端把这些概念包装成“系统代理”“路由模式”“绕过局域网”“阻止特定连接”等选项，但底层仍然遵循接收、判断、转发这一流程。

域名解析也在链路中占有独立位置。应用可能先在系统中解析域名，再把 IP 交给代理；也可能把域名直接交给本地代理，由内核按配置解析。两种路径会影响域名规则能否命中，也会影响分流结果。初学阶段不必立刻改动复杂 DNS 项，只需知道：如果某条域名规则看起来正确却没有生效，应检查请求进入内核时仍是域名，还是已经变成 IP。

协议名称与传输参数要分开理解

VMess、VLESS、Trojan 等名称通常描述代理协议层；TCP、WebSocket、gRPC 等属于传输方式；TLS、REALITY 等涉及连接安全与握手特征。分享链接会把多层参数压缩成一条字符串，导入后客户端再还原成可供内核读取的配置。不能只看到协议名称相同就认为两个节点配置可以互换：传输方式、主机名、路径、安全选项和服务端设置必须彼此匹配。手动编辑节点时尤其要避免凭经验补值，缺少的信息应回到配置提供方确认。

完成本章后，应能用一条清晰链路描述请求：应用发出请求，系统代理或 TUN 接管流量，本地入站接收请求，路由选择出站，内核按节点配置建立连接。后续所有设置都可以放回这条链路中理解。

二、选择客户端：按平台、内核与维护方式做决定

桌面平台优先选择 v2rayN

Windows、macOS 与 Linux 的桌面使用场景，首选 v2rayN。它把订阅分组、服务器列表、系统代理、路由、日志和 TUN 集中在同一个界面中，适合从基础使用逐步过渡到规则管理。Windows 可根据界面技术和使用习惯选择桌面版或经典 WPF 版；macOS 需要根据处理器架构选择对应安装包；Linux 则根据发行版的软件包体系选择 deb 或 rpm。具体入口与当前文件名由下载页统一展示，本手册不记录固定版本号。

同一份订阅在不同桌面系统上的节点内容通常相同，但系统代理、权限管理、证书存储、开机启动和防火墙行为并不相同。迁移配置时可以复用订阅地址与自定义规则思路，不应直接假设所有本机设置都能照搬。特别是 TUN 模式，它依赖各系统提供的虚拟网络接口和权限机制，排错方法需要结合当前平台。

Android 上区分 v2rayNG 与 v2flyNG

Android 平台首选 v2rayNG，它采用 Xray 内核，适合需要较广协议与传输特性支持的配置。v2flyNG 使用 V2Fly 内核，可作为偏向 V2Fly 生态的备选。两者都能完成订阅导入、节点切换和本地 VPN 接管，但内核能力、设置项名称与部分配置兼容性可能不同。如果订阅明确依赖某项内核特性，应先确认客户端所用内核是否支持，而不是只比较界面外观。

安装包架构也需要选择。较新的主流 Android 设备通常使用 arm64，通用版则适合无法确认架构或需要覆盖更多设备类型的情况。架构只决定安装包中的本机代码类型，不会改变订阅内容。若系统提示安装包与设备不兼容，应先换用通用版，不必重新创建订阅。

不要用节点数量代替兼容性判断

客户端选型的核心不是“能导入多少条记录”，而是当前配置能否被内核完整解析，以及系统流量是否能稳定交给内核。订阅列表显示节点，只说明文本格式或分享链接被识别；连接时仍可能因为传输参数缺失、内核不支持、系统时间偏差或网络不可达而失败。更可靠的判断方法是选取一个已确认可用的配置，在目标客户端中观察内核能否启动、日志是否出现配置错误、本地代理是否能够处理请求。

对于同时使用桌面和 Android 的情况，可以让不同设备引用同一个订阅地址，但建议分别维护客户端本地设置。桌面端常用系统代理和细分路由，移动端更常依赖系统提供的 VPN 接口；两者对后台运行、电池策略和局域网访问的处理不同。订阅负责同步远端配置，不负责同步每台设备的流量接管策略。

选型完成后，应固定一个主客户端完成后续学习。频繁在多个客户端之间来回切换，会把界面差异误判成配置故障。桌面从 v2rayN 开始，Android 从 v2rayNG 开始，是更清晰的学习路径。

三、安装准备：系统架构、权限与首次启动检查

下载前确认系统与处理器架构

安装前先确认三个信息：操作系统类型、处理器架构、当前账户是否具备安装或网络配置权限。Windows 用户还需要决定使用新一代桌面界面还是经典 WPF 界面；macOS 用户需要区分 Apple Silicon 与 Intel；Linux 用户应确认发行版使用 deb 还是 rpm 软件包，并区分 x64 与 arm64；Android 用户可在明确设备架构时选择 arm64，否则使用通用版。架构选择错误通常会表现为无法安装或无法启动，而不是节点连接错误。

下载入口应从站内客户端下载页进入。下载页按照四个平台组织安装包，并给出对应架构说明。安装包更新时文件名可能变化，因此不建议把某个旧文件名写进长期笔记。更稳妥的记录方式是保存客户端名称、平台和架构，例如“v2rayN、macOS、arm64”，需要重装时再进入对应平台面板。

首次启动先检查目录和权限

桌面客户端通常需要保存订阅、日志、路由规则与界面偏好。如果把程序放在只读目录，或当前账户无法写入配置目录，可能出现设置无法保存、重启后订阅消失、内核解压失败等问题。首次启动后先修改一个非关键界面选项并重启，确认设置能够保留。若客户端提供日志目录入口，也应确认该目录可以正常创建文件。

系统代理修改、开机启动与 TUN 模式所需权限并不完全相同。普通系统代理通常只修改当前用户的代理设置；TUN 需要创建虚拟网络接口或调整路由表，往往需要更高权限。基础阶段先使用系统代理完成连接，不要在首次启动时同时开启 TUN、复杂路由、局域网共享和自定义 DNS。一次只引入一个变量，遇到错误才容易回退。

1. 安装客户端。选择与操作系统、处理器架构相符的安装包，完成系统要求的安装步骤。
2. 启动并检查写入能力。确认客户端能保存设置、创建日志并正常关闭。
3. 确认内核启动。先不导入大量配置，观察日志中是否存在缺少组件、端口占用或权限错误。
4. 记录默认本地端口。后续设置应用代理或定位冲突时，需要知道 SOCKS、HTTP 或混合端口。

理解本地监听端口

内核启动后通常会在回环地址监听一个或多个本地端口。回环地址只供本机访问，常写作 127.0.0.1。SOCKS 入站适合支持 SOCKS 代理的应用，HTTP 入站适合支持 HTTP 代理的应用，混合端口则可能同时接受两类请求。具体端口以客户端设置页显示为准，不应照抄他人的数字。端口被其他程序占用时，内核通常无法启动，日志会出现监听失败或地址已被使用之类的信息。

可以在桌面系统中用网络状态工具确认端口是否监听。以下命令只用于观察本机监听状态，示例中的端口 10808 需要替换为客户端界面实际显示的值。Windows 可在终端运行第一条，macOS 与 Linux 可运行第二条：

netstat -ano | findstr 10808
lsof -nP -iTCP:10808 -sTCP:LISTEN

如果没有输出，先查看客户端日志，而不是立刻修改订阅。若端口已经被另一个进程占用，可以关闭冲突程序，或在客户端中改用未占用端口，然后同步更新手动设置了代理的应用。系统代理由客户端自动管理时，一般会跟随端口变化；浏览器、开发工具或终端中的手动代理不会自动更新。

安装阶段的目标不是一次打开所有功能，而是建立可复现的最小环境。记录客户端名称、系统架构、本地端口和配置目录位置，后续升级、迁移与排错都会更直接。

四、订阅管理：导入、更新、分组与格式识别

订阅地址与单个分享链接的区别

订阅地址通常返回一组配置，客户端更新时会重新获取并覆盖或合并该分组内容；单个分享链接只表示一条节点记录，导入后不会自动跟随远端列表变化。长期使用应优先把订阅地址放入独立分组，并为分组设置明确名称。临时测试的分享链接可以放在单独分组，避免更新订阅时分不清哪些条目由远端管理、哪些条目是本地手动添加。

常见订阅内容可能是经过 base64 编码的多行分享链接，也可能是客户端可直接解析的原生 JSON 或其他结构。base64 是编码方式，不是加密协议，也不决定节点采用 VMess、VLESS 还是 Trojan。格式识别失败时，不要反复更换代理模式；应先确认返回内容是否完整、客户端是否支持该订阅格式，以及地址在复制时有没有混入空格或换行。关于格式之间的关系，可继续阅读订阅格式详解。

建立可维护的分组结构

分组的价值不只是整理列表，还能把更新策略和本地规则隔离开。建议至少区分“日常订阅”“临时测试”和“手动配置”。日常订阅保留自动更新；临时测试按需更新；手动配置则避免被远端覆盖。若同一个地址被重复添加到多个分组，更新后会出现内容重复，测速、排序和选择当前节点时都更混乱。发现重复记录时，应先检查订阅列表，而不是逐条删除节点。

更新订阅前，客户端需要先访问订阅地址。这个请求可能使用当前网络直接获取，也可能按客户端选项通过已有代理获取。如果当前节点已经失效，而订阅更新又被设置为通过代理进行，就可能形成“需要更新才能获得可用节点，但更新请求又依赖旧节点”的循环。遇到这种情况，可暂时切换为直连更新，或使用一条已确认可用的配置完成更新。更新成功后再恢复原策略。

• 添加订阅地址
• 命名分组
• 执行更新
• 检查节点字段
• 选择当前配置

更新后要检查什么

看到“更新完成”并不代表每条配置都可用。更新后的检查应分三步。第一步看分组是否产生节点，若为空，重点检查返回格式和筛选条件；第二步随机打开一条配置，确认地址、端口、协议、传输和安全选项没有明显缺失；第三步选择一条配置启动内核，观察日志是否出现解析错误。不要只依据节点名称判断内容，因为名称只是备注，不参与实际连接。

订阅自动更新周期不宜短到频繁打断客户端使用。合理做法是根据配置提供方的变更频率设置，并保留手动更新入口。桌面设备长期运行时，可以让客户端在固定间隔检查；移动设备受后台限制，自动任务可能被系统延迟，此时手动刷新更可靠。无论是否自动更新，都应知道最近一次成功更新发生在何时，以便判断故障来自旧配置还是当前网络。

订阅更新失败的分层排查

更新失败通常落在四类原因中：地址本身已经变化；当前网络无法访问订阅服务；返回内容不是客户端支持的格式；客户端的直连或代理更新策略不合适。先在不公开地址的前提下确认链接是否完整，再切换获取策略，随后查看更新日志中的 HTTP 状态、解析提示或超时信息。如果响应成功但解析失败，问题位于格式层；如果连响应都没有，问题位于网络或地址层。完整排查流程可参考订阅更新失败处理步骤。

稳定的订阅管理应做到三件事：来源按分组隔离，更新路径可切换，更新结果可验证。建立这个习惯后，即使远端列表变化，也不会影响本地自定义规则和临时测试配置。

五、代理模式：系统代理、应用代理与全局选择

系统代理控制哪些程序

系统代理的作用，是把代理地址写入操作系统提供的网络设置。遵循系统代理的浏览器和桌面程序会把请求交给客户端本地端口，但并非所有程序都会读取这些设置。部分命令行工具、游戏、虚拟机、容器或自行实现网络栈的软件可能忽略系统代理。出现“浏览器可用但某个应用不可用”时，首先判断该应用是否遵循系统代理，而不是直接认定节点不稳定。

客户端界面中的“清除系统代理”“自动配置系统代理”“保持不变”等选项，控制的是操作系统设置，不等同于内核路由模式。系统代理回答“流量是否进入内核”，路由模式回答“进入后走哪个出站”。这两个开关经常被混在一起。正确顺序是先确认流量进入，再讨论直连、代理或阻断规则。

手动应用代理适合精确测试

支持代理设置的应用可以直接填写 127.0.0.1 和客户端显示的本地端口。这样只影响目标应用，不修改整个系统，适合验证本地入站是否工作，也适合开发工具需要独立代理的情况。选择代理类型时必须与监听端口一致：SOCKS 设置要指向 SOCKS 入站，HTTP 设置要指向 HTTP 或兼容的混合入站。类型填错时，端口虽然可连接，协议握手仍会失败。

终端程序常通过环境变量读取 HTTP 代理。以下示例使用本机地址和示例端口，只在当前终端会话生效；关闭终端后通常需要重新设置。实际使用前应核对客户端端口，并了解目标工具是否支持这些变量。

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export ALL_PROXY=socks5://127.0.0.1:10808

Windows PowerShell 可在当前会话中使用环境变量形式：

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:ALL_PROXY="socks5://127.0.0.1:10808"

全局、规则与直连模式分别解决什么问题

全局代理通常表示进入内核的请求优先交给当前代理出站，适合做短时间连通性验证。规则模式按域名、IP 或其他条件选择代理、直连或阻断，是日常使用的主要方式。直连模式让进入内核的请求直接访问目标，常用于对照测试，判断问题是否由远端节点引起。模式名称在客户端之间可能略有不同，但判断逻辑基本一致。

排错时可以利用三种模式建立对照：全局代理失败且直连正常，优先检查节点和远端传输；全局代理正常但规则模式失败，优先检查路由命中；系统代理关闭后应用仍然走代理，说明应用自身可能设置了手动代理或当前启用了 TUN。对照测试应一次只改一个开关，并在测试后恢复原设置。

代理模式的关键不是“哪个覆盖范围最大”，而是选择与应用行为匹配的接管方式。系统代理适合常规桌面流量，手动代理适合精确控制，TUN 留到确认基础链路稳定后再启用。

六、路由分流：从规则顺序到域名与 IP 匹配

路由规则按顺序匹配

路由分流的基本动作，是根据请求特征选择代理、直连或阻断出站。多数规则系统按既定顺序检查，命中后停止继续匹配，因此规则内容正确但顺序错误，仍会得到意外结果。范围宽的规则放得过早，会吞掉后面更精确的规则；范围窄的例外项通常应位于对应通用规则之前。修改前先记录当前模式与规则顺序，测试失败时才能快速回退。

常见匹配条件包括完整域名、域名后缀、IP 或网段、端口、网络类型和进程名。域名规则可读性较好，适合针对稳定域名组织；IP 规则适合明确地址段，但目标服务使用动态地址时维护成本更高；进程规则依赖客户端与系统支持，程序更新或路径变化后可能失效。初学阶段应先使用域名和保留地址网段，确认逻辑后再引入更复杂条件。

域名匹配为何可能失效

规则能否看到域名，取决于请求进入内核时携带什么信息。如果应用先完成 DNS 解析，只把 IP 交给代理，纯域名规则可能无法直接命中；内核可通过嗅探或其他机制尝试恢复目标域名，但这不是所有流量都适用。反过来，如果应用通过 SOCKS 把域名交给内核，域名规则通常更直接。排查时应查看路由日志中的目标形式，不要只盯着规则文本。

域名后缀规则还要注意边界。例如针对 example.com 的后缀规则通常会覆盖其子域名，但不应把包含相同字符串的其他域名误判为同一站点。客户端若提供“完整域名”“域名后缀”“关键词”多种类型，应优先选择语义最精确的一种。关键词匹配范围较宽，只适合临时验证，不适合作为长期规则基础。

一份最小路由配置怎样阅读

下面的 JSON 展示路由部分的基本结构。第一条让局域网与保留地址直连，第二条让示例域名走代理，其余流量由后续默认出站处理。direct 与 proxy 必须对应完整配置中已经存在的出站标签。该片段用于理解字段关系，不能脱离入站、出站与 DNS 配置单独运行。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com",
          "full:api.example.net"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

AsIs 表示路由阶段优先按请求原始目标进行处理，不主动为了 IP 规则解析所有域名。不同策略会改变域名与 IP 规则的协作方式，不能孤立地说某个值始终更好。若现有客户端规则已经稳定，不必为了追求参数复杂度改动策略。只有在明确发现域名和 IP 匹配关系不符合预期时，才需要结合 DNS 配置与日志调整。

设计规则时从默认行为开始

建立规则集前，先决定“未命中任何规则时怎么处理”。默认代理适合以直连例外为主的规则体系；默认直连适合只让少数明确目标走代理的体系。两种思路都可以工作，但混用后很难阅读。建议在规则说明中写清默认出站，并给每组规则一个目的，例如“局域网直连”“指定域名代理”“特定协议阻断”，不要只使用含义模糊的编号。

规则验证应使用可重复的目标，并观察日志中实际命中的出站标签。仅凭网页是否打开不能确认路由正确，因为目标可能同时允许直连与代理。若客户端提供路由调试日志，可先临时提高日志级别，完成验证后再恢复，避免日常日志被大量请求淹没。修改多个规则时，按组启用并逐组测试，比一次导入完整规则集更容易定位冲突。

可靠的路由体系应具备明确默认行为、从精确到宽泛的匹配顺序、可辨认的出站标签和可重复的验证目标。规则数量不是成熟度指标，可解释、可回退才是。

七、TUN 模式：虚拟网卡接管、权限与 DNS 路径

TUN 与系统代理的根本差异

系统代理要求应用主动读取操作系统代理设置，TUN 则通过虚拟网络接口和路由表接管更广范围的 IP 流量。对于忽略系统代理的程序，TUN 往往更有效；同时，它也引入了系统权限、虚拟接口、路由冲突、DNS 路径和本地网络访问等额外变量。因此 TUN 不是基础连接失败时的万能修复项，而是基础代理已经稳定后，用于扩大接管范围的独立方案。

启用 TUN 后，应用可能仍然不知道代理的存在。操作系统把流量送入虚拟接口，客户端再将其转换为内核可处理的连接并执行路由。由于这一过程发生在更低层，浏览器、命令行工具和部分不支持代理设置的程序可以被统一处理。但虚拟机、容器、其他 VPN 类软件或安全软件也可能调整路由表，多个组件同时工作时容易产生优先级冲突。

启用前建立对照基线

开启 TUN 前，应先用系统代理确认当前节点、订阅和路由规则可用，并记录关闭 TUN 时的表现。然后关闭应用中的手动代理，避免同一请求先进入手动代理又被 TUN 再次接管。启用后依次检查：虚拟接口是否创建成功，客户端日志是否出现权限错误，默认路由是否按预期调整，局域网访问是否正常，域名解析是否能返回结果。每一步都正常后，再测试原先不遵循系统代理的程序。

如果客户端要求提升权限，应通过系统提供的授权流程完成。权限不足常表现为虚拟接口创建失败、路由写入失败或模式开启后立即关闭。此类错误与节点协议无关，更换订阅通常没有作用。桌面端还要检查是否存在其他正在工作的虚拟网络接口；Android 端则应确认系统的 VPN 接管状态和后台运行限制。

1. 关闭重复入口。清理应用内手动代理，只保留一个明确的数据入口。
2. 启用 TUN 并完成系统授权。观察客户端是否成功创建虚拟接口。
3. 检查基础网络。分别测试域名访问、直接 IP 访问与局域网设备访问。
4. 验证规则命中。确认原有直连、代理与阻断规则在 TUN 下仍按预期执行。
5. 测试目标应用。最后检查之前无法通过系统代理接管的程序。

DNS 是 TUN 排错的重点

TUN 开启后出现“能访问 IP，不能访问域名”，通常说明连接路径存在但 DNS 环节异常。可能原因包括 DNS 请求没有进入预期路径、客户端 DNS 配置与系统设置冲突、路由规则阻断了解析请求，或其他网络软件仍在接管 DNS。此时应先查看客户端日志是否记录解析超时，再对比关闭 TUN 后的解析结果。不要同时更换节点、DNS 服务器和路由规则，否则无法判断哪项修改起效。

另一类现象是域名可以解析，但规则按错误目标命中。TUN 环境下，内核可能通过嗅探恢复域名，也可能只看到解析后的 IP。应结合当前路由策略判断规则究竟匹配域名还是 IP。若必须依赖域名分流，需确保 DNS 与流量接管路径能够保留足够信息；若目标地址稳定，也可以使用明确的 IP 或网段规则作为补充，但要考虑地址变化带来的维护成本。

局域网与休眠恢复问题

TUN 修改路由后，本地打印机、存储设备或开发服务可能被错误送入代理。局域网与保留地址通常应优先直连，并位于宽泛代理规则之前。若只能在关闭 TUN 后访问局域网，检查私有网段规则和绕过设置，不要把整个规则体系改为直连。还应分别测试设备名称和局域网 IP，因为前者涉及本地域名解析，后者主要涉及路由。

电脑休眠、网络切换或从有线切到无线后，旧虚拟接口和路由状态可能没有立即刷新。表现为客户端仍显示运行，但新请求超时。可以先在客户端中关闭再开启 TUN，让其重建接口；若仍未恢复，再重启内核并检查系统路由。把重启系统放在最后，因为直接重启会丢失最有价值的错误现场。

TUN 配置成功的标准不是开关保持开启，而是虚拟接口、DNS、路由规则、局域网和目标应用都能给出可解释的结果。基础代理与 TUN 分阶段验证，可以显著缩短排错时间。

八、日常维护：更新、日志、备份与故障分层

把客户端、内核与订阅更新分开

日常维护包含三类更新：图形客户端自身更新、内核组件更新、订阅内容更新。三者解决的问题不同。客户端更新可能改变界面、系统集成和配置管理；内核更新影响协议解析、传输能力与运行行为；订阅更新只改变远端配置列表。遇到问题时先确认最近变化的是哪一层，不要把订阅更新失败等同于客户端需要升级，也不要在节点故障时同时更新所有组件。

更新前应记录当前可用配置、代理模式和关键自定义规则。更新后先用原有配置做基线测试，再检查新增能力。若直接在更新后导入新订阅、修改路由并开启 TUN，一旦出现异常就无法判断来源。对于长期稳定使用的环境，维护目标是可控变化，而不是始终追逐所有设置项。

日志应按时间线阅读

日志通常包含客户端操作、内核启动、配置解析、DNS、路由和连接错误。有效阅读方式是先记下触发操作的准确时间，然后只查看该时间点前后的一小段。启动阶段错误优先关注配置文件路径、字段解析、端口监听和权限；连接阶段错误优先关注域名解析、握手、超时和路由出站；订阅阶段错误则关注请求状态与内容解析。不要从日志中孤立截取最后一行，因为根因往往出现在更早位置。

提高日志级别可以提供更多细节，但也会快速产生大量记录。应在复现问题前临时提高，完成一次明确测试后立即收集，再恢复日常级别。公开讨论日志时，只保留错误类型、时间顺序和必要字段，隐藏订阅地址、节点地址、用户标识与本地目录中的个人名称。日志用于还原过程，不应变成配置备份。

备份重点是可恢复信息

值得备份的内容包括订阅分组结构、自定义路由规则、客户端偏好、本地手动节点以及必要的配置说明。订阅地址本身可以恢复远端节点，但不能恢复所有本地修改。备份文件应放在受控位置，不要直接公开分享。若客户端支持导出配置，应先了解导出范围：有的只导出节点，有的包含路由与界面设置，有的还会引用本机路径。

恢复时不要一次覆盖全部现有配置。更稳妥的流程是先安装并启动客户端，确认内核基线正常，再导入订阅，随后恢复路由，最后处理 TUN 和开机启动。每一步都启动一次并查看日志。这样即使备份来自不同系统或较早环境，也能在出现不兼容时准确停在对应阶段。

建立最小复现配置

复杂故障应缩减到一个客户端、一个订阅分组、一条已知配置、系统代理和默认路由。关闭自动选择、复杂 DNS、进程规则、局域网共享与 TUN，再复现问题。如果最小配置正常，逐项恢复高级设置；如果最小配置仍失败，检查配置字段、网络和内核日志。最小复现不是永久删掉功能，而是暂时减少变量。

节点选择也应使用真实连接结果，而不是只看列表中的延迟值。延迟通常反映某种探测请求的往返时间，不能完整代表目标连接、传输握手和持续流量表现。选择方法可参考节点挑选思路，重点比较实际可用性、协议兼容性与目标场景。

维护的核心是控制变量。更新分层、日志按时间线阅读、备份按阶段恢复、故障缩减到最小配置，这四个习惯可以覆盖多数长期使用问题。

九、进阶路线：从会用客户端到能解释配置

第一阶段：能够复述完整数据流

进阶并不等于立刻手写大型配置。第一阶段应能解释一个请求从应用到远端的完整路径，并能指出每个环节的观察方法：应用是否读取系统代理，本地端口是否监听，内核是否成功启动，路由选择了哪个出站，节点传输参数是否完整，DNS 在哪里解析。能够回答这些问题，就能把模糊的“连不上”拆成具体层级。

练习时可以使用同一个已确认可用的配置，分别测试系统代理、手动应用代理和 TUN，并记录日志差异。再在规则模式中加入一条明确域名规则，观察出站标签变化。练习目标不是制造复杂环境，而是建立操作与日志之间的对应关系。

第二阶段：读懂客户端生成的配置

图形客户端最终需要把界面选项转换成内核配置。导出或查看生成配置时，先找入站、出站、路由和 DNS 四部分，再把它们与界面设置一一对应。下面示例展示一个仅监听本机的 SOCKS 入站。它可用于理解字段，不包含可连接的远端出站，因此不是完整配置。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ]
}

tag 用于在配置内部引用该对象，listen 限定监听地址，port 是本地端口，protocol 指定入站类型。若把监听地址改为所有网络接口，局域网中的其他设备可能访问该端口，这会改变安全边界。没有明确共享需求时，应保持回环地址。学习配置时，先理解已有字段的作用，不要为了“优化”添加来源不明的参数。

第三阶段：比较 Xray 与 V2Fly 内核边界

Xray 与 V2Fly 同属 Project V 相关生态，但维护方向与特性集合并不完全相同。客户端只是载体，真正决定某项协议扩展或传输能力是否可用的是内核及客户端的配置适配。遇到“同一分享链接在不同客户端表现不同”时，应检查链接使用了哪些协议与安全特性，再确认目标内核是否支持，而不是简单归因于平台差异。

比较内核时应围绕实际需求：当前订阅使用哪些协议，是否依赖 VLESS、REALITY 或 XTLS 相关能力，客户端能否正确生成对应配置，日志能否提供足够排错信息。若当前配置只使用两边都支持的常规能力，选择更符合平台和维护习惯的客户端即可。更详细的对照见Xray 与 V2Fly 内核区别。

第四阶段：建立可测试的规则体系

成熟的路由规则不靠数量取胜，而是有清晰默认行为、分组目的和验证方法。可以从三组规则开始：局域网与保留地址直连，一组明确域名按需求选择出站，其余流量进入默认策略。为每组准备一个可重复测试目标，并在修改后查看日志命中。新增规则前先说明它解决什么问题，无法说明目的的规则不应直接加入长期配置。

DNS 调整也应围绕具体问题。只有在确认解析路径导致规则失效、超时或结果不一致时，才修改查询方式与路由关系。把 DNS、嗅探、路由策略和 TUN 同时改成一套复杂方案，短期可能碰巧可用，长期却难以维护。进阶能力体现在能缩小改动范围，并解释为什么需要这项改动。

第五阶段：形成个人运行手册

个人运行手册不需要很长，但应包含客户端与平台、安装包架构、配置目录、本地端口、订阅分组、自定义规则、TUN 是否启用、更新方式和回退步骤。再补充两个最小测试：一个验证系统代理，一个验证路由命中。设备迁移或升级后，沿这份清单逐步恢复，比依赖记忆更可靠。

当环境出现新问题时，先更新运行手册中的现象与处理结果，再决定是否引入额外规则。长期积累后，手册会形成适合自身设备和应用的稳定基线。此时客户端界面变化不会造成太大影响，因为核心判断仍然围绕入站、出站、路由、DNS 和流量接管展开。

从零到进阶的路线可以概括为：先建立最小可用链路，再扩大流量接管范围；先读懂规则命中，再增加规则数量；先形成可恢复基线，再升级客户端和内核。遇到问题时始终回到数据流，而不是随机切换设置。