V2Ray 使用手册

核心概念：区分接入、匹配与出站

客户端、内核与服务端

V2Ray 通常指 Project V 相关的代理技术与工具生态，不是单一图形软件。客户端负责保存服务器资料、导入订阅、切换设置和展示日志；内核负责建立连接、识别流量、执行路由与协议处理。服务端则运行在远端，接收协议连接并继续访问目标。三者职责不同，界面能打开只说明客户端可以运行，不代表内核启动成功，更不代表远端连接已经可用。

V2Fly 与 Xray 是相关生态中的不同内核项目。它们共享部分配置概念，但功能范围、协议扩展和参数细节并不完全一致。v2rayN 可以提供不同内核的管理入口，实际选项取决于所用发行包；v2rayNG 主要使用 Xray，v2flyNG 使用 V2Fly。遇到某个字段不被识别时，先确认当前启动的是哪个内核，再查对应配置说明，不能仅凭客户端名称判断支持范围。

一条连接经过哪些环节

把一次访问拆成四段更容易定位问题：应用先把连接交给本地接入点，内核再按规则选择出站，代理出站连接远端服务器，远端最后访问目标地址。HTTP 代理、SOCKS 代理、TUN 都属于不同的接入方式；direct、proxy 等标签属于出站选择。接入失败时调整远端协议没有意义，规则走错时反复更换本地监听端口也不能解决根因。

服务器资料通常包含地址、端口、协议、身份信息、传输方式与安全层。这里的协议用于约定客户端和服务端如何通信，传输方式描述数据如何承载，TLS 或 REALITY 等设置属于连接安全机制。VLESS 不是传输方式，WebSocket 也不是加密协议。导入后应按层核对，不能看到地址相同就认定两份配置等价，路径、服务名称和服务器名称等字段都可能影响连接建立。

域名解析与路由之间的关系

DNS 将域名解析为地址，但域名并不一定在进入客户端前就消失。有的应用向代理提交完整域名，有的应用先在本地解析再提交地址。内核拿到的信息不同，能匹配的规则也不同。因此域名规则没有命中时，应检查接入方式和日志中的目标类型，而不是立即认定规则库损坏。访问同一个站点的不同应用，也可能因为解析位置不同而走不同出站。

路由匹配与 DNS 查询不是同一个动作。设置域名解析策略可能让内核为了匹配地址规则而发起查询，但这不等于应用的全部 DNS 请求都改走了指定通道。进入 TUN 场景后，还要考虑系统解析器、客户端 DNS 接管、浏览器自身解析功能等路径。先画出实际请求经过的组件，再检查设置，通常比同时打开多个 DNS 选项更有效。

建立可验证的起点

首次配置只需要一条来源明确的服务器资料、一种接入方式和一套容易解释的路由。先让浏览器通过系统代理访问，再观察连接日志是否出现目标与预期出站。不要同时启用 TUN、自定义 DNS、分应用代理和复杂分流，否则失败后无法判断是哪一项造成。运行基线的价值不在于设置少，而在于每一步都能与上一状态对照。

本手册中的配置块用于解释局部字段，不包含完整服务器连接资料。实际使用应优先在图形设置中修改，再检查客户端生成的结果。直接编辑运行时配置可能在重启、切换服务器或更新订阅后被覆盖。完成本章后，应能用“流量从哪里进入、匹配哪条规则、交给哪个出站”描述一次访问；术语仍不清楚时，可对照术语手册继续查阅。

选择客户端：平台、内核与资料兼容

桌面先选 v2rayN

Windows、macOS 与 Linux 桌面环境优先从 v2rayN 开始。它将服务器、订阅分组、路由和运行日志集中在图形界面中，适合建立可重复的操作流程。Windows 提供桌面版与经典 WPF 版入口：桌面版采用跨平台界面路线，WPF 版保留经典桌面交互。应按系统环境和使用习惯选择，不需要为同一个连接同时运行两版客户端。

macOS 选择安装包时先查看“关于本机”中的芯片信息，Apple Silicon 对应 arm64，Intel 对应 x64。Linux 除了架构，还要看发行版的软件包体系：使用 deb 软件包的环境选择 deb，使用 rpm 软件包的环境选择 rpm。架构决定程序能否在处理器上运行，包格式决定安装工具如何管理文件，两项都要匹配，不能只根据文件扩展名判断。

安卓区分主选与备选

Android 首选 v2rayNG，主要使用 Xray 内核；需要 V2Fly 配置兼容性时再评估 v2flyNG。两者都属于图形客户端，但协议支持不能简单视为完全相同。服务器资料依赖某个内核扩展时，应先确认该客户端对应内核是否支持，再考虑导入方式。不要把导入成功当作兼容性证明，解析链接和建立实际连接是两个不同阶段。

安卓包架构优先根据设备系统与处理器支持判断。多数较新的设备适合 arm64，但仍可能遇到处理器支持而系统环境不匹配的情况。无法确认时可以考虑通用包，代价通常是包体更大。安装器若报告不兼容，应返回设备信息与包选择检查，不要连续重复安装同一文件。具体入口集中在Android 下载面板，不必从不同来源拼凑安装文件。

按需求核对，不按名称猜测

选择前整理三项需求：服务器使用的协议与传输、需要覆盖的应用、是否必须使用 TUN。浏览器为主的桌面使用通常可以从系统代理开始；不遵循系统代理的应用需要单独设置或评估 TUN；安卓则需要理解系统 VPN 接入与分应用名单。功能更多并不自动意味着配置更合适，选择能覆盖当前需求且容易维护的组合即可。

订阅兼容也应单独判断。同样被称为订阅地址，返回内容可能是协议链接集合、编码后的列表，或某种专用配置文件。客户端支持某个协议，不代表支持所有订阅格式。下载前如果已经持有资料，应确认提供方给出的客户端类型和导入说明。格式不匹配优先获取正确的原始入口，不要把私人订阅地址提交给来源不明的在线转换页面。

迁移时保留一条回退路径

从另一台设备迁移时，先在新客户端建立一个独立订阅分组，只验证一条服务器，不立即复制全部路由、DNS 和接入设置。不同平台的系统代理、权限管理和网卡行为存在差异，原设备能用的设置未必可以原样迁移。连接基线成立后，再逐项迁移业务规则，并记录每次迁移对应用访问的影响。

多个客户端同时运行容易争用代理端口、修改系统代理或占用 VPN 接入。评估替代方案时，应先停止旧客户端的接入功能，再启动新客户端。保留旧配置用于回退，但不要让两者同时管理系统流量。三款客户端的进一步差异见客户端内核与平台对照笔记；完成选型后，下一章再处理安装与首次启动。

安装与初始化：权限、目录与监听

安装前确定文件与数据的位置

从获取客户端页面按平台和架构选择入口。安装前先退出已有实例，确认下载的是准备使用的客户端，而不是另一平台的软件包。使用安装器时按向导完成安装；发行包要求解压运行时，先完整解压到独立目录再启动。不要在压缩包预览窗口中直接运行程序，否则关联文件可能无法找到，后续更新和数据保存也容易出现异常。

程序目录与配置数据目录不一定相同。有的发行形态在用户目录保存数据，有的允许使用独立数据目录。首次启动后先查看设置中的数据位置或备份入口，确认订阅和路由会保存在哪里。计划迁移设备时，应备份客户端提供的数据范围，而不是只复制桌面快捷方式。也不建议把运行目录放入多人可写或频繁清理的临时位置。

桌面系统完成首次启动

Windows 安装后先以普通用户启动，观察界面和日志能否正常显示。若 WPF 版提示缺少运行组件，应按该发行包要求补齐对应环境，或重新选择适合当前系统的安装入口。不要看到启动失败就长期使用管理员权限运行。普通代理与需要管理虚拟网卡的操作权限不同，后者在启用对应功能时再按提示授权。

macOS 将应用放入计划使用的位置后再打开，避免在临时挂载位置反复运行。系统出现安全提示时，应先确认文件来源、包类型与系统支持范围，再按系统提供的应用安全流程处理。Linux 使用对应包管理工具安装后，从应用菜单启动并检查日志；若桌面组件或权限不足，应处理具体提示，不要通过宽泛修改系统目录权限来绕过问题。

安卓安装后的系统授权

Android 安装时只为实际使用的安装来源授予必要权限，完成后可按需要收回。首次启动先导入一条资料，再启动连接；系统弹出的 VPN 连接请求用于允许客户端建立本地流量接入。授权不等于远端连接成功，是否可用仍需检查服务器配置和访问结果。已有其他 VPN 类应用运行时，应先停止其连接，避免接入资源冲突。

为了区分安装问题与后台问题，首次测试保持应用在前台，屏幕亮起，先确认连接本身成立。随后再进行锁屏和后台测试。若只有锁屏后断开，重点检查电池优化、后台运行限制和厂商系统的任务清理设置，而不是重新安装。相关操作可继续阅读安卓授权、省电与分应用设置。

检查内核与本地监听

桌面客户端打开后，在日志或状态区域确认内核确实启动。找不到可执行文件、配置解析失败和端口被占用属于不同故障：第一类检查安装内容是否完整，第二类撤回最近改动，第三类检查是否有旧实例或其他程序使用相同端口。不要在尚未启动监听时测试浏览器代理，否则浏览器只会报告本地连接被拒绝。

确认监听地址、端口和代理协议后，再决定如何让应用接入。系统代理应指向客户端实际监听的位置；手动配置应用时也要区分 HTTP 与 SOCKS 入口。端口没有统一必须使用的数字，以当前设置为准。修改端口后应同步更新应用配置，不能让应用继续连接旧端口，也不要把服务器的远端端口误填为本地代理端口。

初始化阶段暂不启用开机启动和自动接管。先完成一次“启动内核、接入应用、停止接入、退出程序”的完整循环，确认退出后系统网络恢复正常，再开启自动化选项。这样可以明确客户端实际修改了哪些系统设置。若退出后仍无法访问，先查看系统代理是否残留，而不是立即重置整个网络环境；常见分支可查FAQ 故障排查。

订阅导入：分组、更新与字段核对

先确认资料类型和访问范围

订阅地址是一种更新入口，不等于某一条服务器连接。它可能返回多条服务器资料，并在后续更新时增删内容。单条协议链接则描述一条连接，二维码只是承载链接的方式。导入前先判断拿到的是订阅入口、单条分享链接还是完整配置文件，选择对应操作。把订阅地址粘贴到单服务器地址栏，通常只会得到无法连接的错误配置。

订阅地址可能包含能够访问私人资料的标识，应像连接凭据一样保存。需要别人协助排查时，不要发送完整地址，也不要把二维码直接发布在公开页面。说明返回格式、错误类型与客户端名称通常已足够开展初步检查。若地址曾意外公开，应使用资料提供方的管理方式更换入口，而不是仅删除聊天记录或浏览器历史。

在分组中建立更新关系

v2rayN 可从订阅分组管理入口新增分组，填写便于识别的备注和实际订阅地址，再保存并执行更新。一个来源对应一个分组，方便判断更新影响范围。备注只用于本地识别，不会改变连接能力。首次更新后，检查是否生成服务器条目、条目是否属于正确分组，以及日志是否报告格式解析错误，不要只看界面是否出现成功提示。

v2rayNG 和 v2flyNG 中选择订阅相关管理入口，新增地址并更新；菜单文字以实际界面为准。若持有单条分享链接，则使用剪贴板导入或二维码扫描等相应入口。导入前确认剪贴板没有前后说明文字，扫描后核对协议、地址和备注。多个二维码连续导入时尤其要检查是否重复添加，避免在列表中选到旧条目。

更新失败按网络与格式分开处理

更新失败先检查地址是否完整，包括协议前缀、路径和查询参数；某些复制方式会漏掉末尾字符。随后判断是连接超时、访问被拒绝、证书错误，还是内容解析失败。前两类优先检查网络路径和入口权限，证书错误还需检查系统时间与证书环境，解析失败则要确认返回内容是否为客户端支持的订阅格式，而不是网页登录页或错误说明。

客户端可能提供经代理更新订阅的选项。当直连无法取得内容时，可以在已有可用连接的前提下尝试；如果当前没有任何可用连接，就不能把“通过代理更新”当成自动修复手段。先建立一条可用的初始连接，或向资料提供方确认可访问的更新方式。不要同时切换更新路径、DNS 与内核，否则很难识别哪一项真正改变了结果。

核对导入结果，而非只看备注

从列表选择一条服务器，逐层核对协议、地址、端口、身份字段、传输方式与安全层。WebSocket 配置重点看路径与 Host，gRPC 配置重点看服务名称，TLS 配置重点看服务器名称和证书验证条件。不同协议的字段不能相互替代；某个字段为空可能是允许的，也可能意味着资料不完整，应根据服务端要求判断。

更新前记录当前选中的服务器和分组，更新后重新确认选中状态。有些客户端会保留匹配项，有些情况下原条目被替换或删除，界面仍停留在相似备注也不能证明底层参数未变。若只有更新后出现故障，应比较具体字段与内核错误，而不是立即删除全部数据。保留一条经过验证的独立测试项，有助于区分订阅变化和本地环境变化。

订阅管理完成的标准是：来源明确、分组可识别、更新行为可解释、至少一条条目能够建立连接。服务器列表里的测试结果只能作为当时的观察，不能替代实际业务验证。下一步先让目标应用通过确定的接入方式访问，再考虑路由优化。若只需要完成首次操作，可返回快速上手主线；涉及协议字段的疑问则查阅协议与传输术语。

代理模式：接入范围与流量方向

系统代理解决应用如何接入

系统代理是操作系统提供给应用参考的代理设置。桌面客户端启用后，通常把 HTTP 等代理入口写入系统配置，愿意遵循该设置的应用才会把连接交给客户端。浏览器往往能够使用它，但部分游戏、命令行工具和自带网络组件的程序不一定遵循。系统代理已开启却只有部分应用生效，是接入范围问题，不应直接归因于远端服务器。

在 v2rayN 中先启动可用服务器，再设置系统代理，随后重新发起浏览器连接。测试前关闭或检查浏览器中的独立代理扩展，避免扩展覆盖系统设置。已经建立的长连接可能继续使用原路径，因此改变代理设置后要重新加载页面，必要时重新打开应用。仅观察开关颜色，无法证明新连接确实已经进入客户端。

全局与绕过模式解决接入后怎么走

全局代理通常意味着将进入客户端、且未被必要例外规则处理的流量交给代理出站，并不意味着系统里每个应用都自动接入。绕过大陆等模式则依据域名与地址规则，让部分目标使用直连，其他目标走代理。两者都是路由选择，与系统代理属于不同层。可以开启系统代理并使用绕过规则，也可以通过 TUN 接入后使用同一套路由思路。

使用全局模式排查时，目的是暂时减少目标分流带来的变量，而不是永久忽略所有本地需求。局域网设备、回环地址和远端服务器自身的连接仍需要合理处理。不同客户端预设对这些例外的安排可能不同，因此“全局”不能被理解为删除全部规则。想知道某个目标实际走向，应检查当前预设内容和运行日志，而不是只根据模式名称推断。

按单一应用验证路径

先选一个容易重复测试的应用，确认它使用系统设置还是独立代理设置。若手动填写代理，要使用本地监听地址和相应协议端口，而不是远端服务器地址。SOCKS 入口是否把域名交给代理解析，还取决于应用支持的选项；本地解析与远端解析可能导致不同规则命中。操作前记录原设置，测试结束后恢复，避免留下难以察觉的覆盖项。

验证时同时观察应用结果与客户端日志：应用连接失败且日志完全没有目标记录，优先检查接入；有记录但使用错误出站，检查路由；使用预期代理出站但建立连接失败，再检查协议和远端。日志级别过低可能看不到足够细节，可临时提高后复现一次。不要仅凭页面打开或打不开就判断是哪一层，也不要把缓存页面当成新的联网结果。

安卓分应用与桌面例外

Android 的 VPN 接入可以结合分应用名单使用。名单可能表示“只代理所选应用”，也可能表示“绕过所选应用”，两种含义相反，配置前必须阅读当前选项说明。加入名单后重新建立连接，并重新启动待测应用的新连接。被名单排除的应用不会因为切换全局路由而自动纳入，因为它根本没有进入客户端的处理路径。

桌面环境也存在系统代理例外列表、浏览器独立设置和应用自身网络选项。访问本地管理页面失败时，应先检查是否被送入了不合适的代理路径；某个应用始终直连时，则检查其是否绕过系统设置。不要用不断切换全局与绕过模式替代接入分析。完整概念对照见系统代理与路由模式笔记，确认接入后再进入下一章编排规则。

路由分流：顺序、条件与出站标签

先确定规则实际由谁执行

路由规则由正在运行的内核执行，图形界面负责生成或管理配置。修改前确认当前使用的内核、启用的路由预设和服务器配置类型。某些自定义配置会自行定义路由，不一定使用客户端的常规规则页面。若修改后完全没有变化，应先确认编辑对象确实进入运行配置，而不是反复调整一套未被使用的预设。

一般按规则顺序匹配，先命中的规则决定出站。把精确业务域名放在宽泛分类前，把局域网例外放在通用代理规则前，可以减少覆盖冲突。同一条规则里不同条件的组合关系也要确认：以常见 field 规则为例，多个不同类型条件通常共同限制匹配，而同类列表提供候选值。不要把包含域名和端口的规则误读为两个独立规则。

读懂 domainStrategy 与标签

domainStrategy 影响为路由匹配进行的域名解析行为。AsIs 不为地址匹配主动解析域名；IPIfNonMatch 在域名未匹配后尝试解析以继续匹配地址条件；IPOnDemand 则可能在遇到相关地址规则时提前解析。它不是代理协议开关，也不直接等于客户端全部 DNS 的转发策略，选择时要考虑规则内容与解析成本。

outboundTag 引用实际存在的出站标签。direct、proxy、block 只是常见名称，必须有相应出站定义才具备意义。下例仅展示路由片段，假定运行配置中已定义 direct 与 proxy，并且具备相应规则数据文件。不要把片段单独保存为完整配置，也不要在未核对标签时直接覆盖客户端生成内容。

{
  "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"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

规则数据与精确域名

geosite 用于引用域名集合，geoip 用于引用地址集合，集合名及可用内容取决于实际安装的数据文件。它们并不是联网实时查询得到的绝对结论，更新后分类也可能变化。某个站点使用多个关联域名时，只匹配主页面域名可能不足以覆盖登录、资源与接口请求，应根据日志逐个确认，避免直接放大到整个无关分类。

编写精确例外时，要区分完整域名与后缀匹配。例如 full:example.com 只针对该完整名称，domain:example.com 通常还会覆盖其子域名。示例域名仅用于解释语法，实际规则填写目标业务域名。不要依靠模糊关键词匹配替代明确边界，否则域名中恰好含有同一词段的其他服务也可能被纳入，排查时很难察觉。

用日志解释一次命中

验证规则时只修改一项，保存并按客户端要求重新加载，然后发起新的连接。记录目标是域名还是地址、匹配了哪条条件、最终用了哪个出站。如果目标只剩地址，域名规则可能没有足够信息；如果较早的宽泛规则已经命中，后面的精确条件就没有机会执行。排查时临时移动规则需要记录原位置，测试完成再恢复。

遇到分流后部分资源失败，先将该业务临时放到单一可用出站验证，再缩小关联域名范围。这样能区分规则覆盖不足与远端本身不可用。不要一开始就加入大量下载来的规则集；每多一层集合，解释路径都会变长。稳定的路由应能说明每条规则的用途、顺序和撤销方法，无法说明用途的条目应先停用观察，而不是长期保留为未知依赖。

TUN 模式：虚拟网卡、DNS 与回环

先证明普通接入可用

TUN 通过虚拟网络接口承接系统流量，适合不能直接设置代理或不遵循系统代理的应用。它改变的是接入路径，后面仍然需要路由和可用出站。启用前先用普通代理证明同一服务器可以访问目标，否则启用后出现故障时，无法区分远端连接与本地网卡问题。TUN 不是修复错误服务器资料的工具，也不保证所有应用的网络行为完全一致。

图形客户端的 TUN 实现可能依赖不同内核、辅助组件与权限机制，具体字段不一定与普通 Xray 路由配置相同。不要把其他实现的整段配置粘贴进当前客户端。先阅读当前 TUN 设置页，识别自动路由、DNS 接管、绕过网段和协议栈等选项的职责；没有明确需求时保留合理默认值，避免同时改变所有选项。

权限与系统路由

首次启用可能需要管理员授权或安装虚拟网卡相关组件。授权后检查内核日志、网卡是否创建以及系统路由是否按预期生效。仅出现虚拟网卡名称不代表流量已经进入内核；同样，开关显示开启也不代表创建过程成功。若启用失败，保留错误信息，先检查权限和组件状态，再决定是否重试，不要连续创建多个不明用途的接口。

自动路由会影响系统如何选择网络出口，因此要特别处理客户端连接远端服务器的流量。若这部分流量再次被捕获并送回同一代理入口，可能形成回环，表现为反复重连或网络整体不可用。客户端通常有相应绕过机制，应优先使用其设计好的处理方式。手工增加网段或进程例外前，先确认实际出口网卡和远端地址，避免把过大的范围全部绕开。

DNS 接管需要独立验证

TUN 下常见的失败是地址直连可用但域名访问失败。此时重点查看 DNS 请求到达哪里、客户端能否访问上游解析服务，以及解析结果是否能用于后续路由。应用可能使用系统 DNS，也可能自行建立加密解析连接；客户端设置某个 DNS 上游，不代表自动接管应用的全部解析行为。应以实际请求路径为准，不能仅根据设置页中出现了服务器地址就判断完成。

部分实现提供 FakeDNS，将域名映射到保留地址范围，再在后续连接中恢复域名关系。这需要 DNS 与流量接管配合，并不适合直接当作所有场景的默认方案。应用缓存旧结果、绕过接管路径或使用独立解析时，都可能造成映射信息不一致。没有清晰需求时先使用较简单的解析方案，普通链路稳定后再单独测试这类功能。

局域网、双栈与应用边界

测试应覆盖网页、局域网服务、休眠唤醒和网络切换。打印机、文件共享或路由器管理页无法访问时，先检查本地网段是否被错误送入代理。企业网络可能使用非典型内部网段或专用 DNS，不能只依据家庭网络经验设置绕过。需要保留内部解析时，应把解析路径与访问路径一起考虑，单独放行地址不一定能解决域名问题。

IPv4 与 IPv6 也要分别确认。若只接管一种地址族，应用可能优先使用另一种，造成路径与预期不同；若解析返回了不可达的地址族，也可能表现为等待很久后才连接成功。排查时观察实际目标地址和系统连接结果，不要把关闭整个地址族作为第一步。安卓还应检查 VPN 常开、阻止未经过 VPN 的连接等系统选项，它们会改变停止客户端后的行为。

只有特定应用在 TUN 下异常时，先回到该应用的连接特点：是否使用 UDP、是否绑定网卡、是否存在独立代理，以及是否需要局域网发现。逐项验证比盲目调低 MTU 更有依据。涉及路由器与旁路由时，网关和回程路径会进一步影响接管范围，可阅读路由器部署笔记；不要把桌面 TUN 设置直接照搬到网关环境。

日常维护：更新、备份与分层排错

把更新对象拆开管理

客户端程序、代理内核、路由数据与订阅内容属于不同更新对象。客户端更新可能改变界面和配置生成方式，内核更新可能改变功能与参数支持，规则数据更新会影响分类结果，订阅更新则改变服务器资料。遇到更新后异常，首先识别刚刚更新了哪一层。一次性更新所有内容虽然省操作，但会让回归问题缺少可比较的边界。

更新前通过客户端备份功能保存必要数据，记录当前接入方式、路由预设、DNS 设置和已验证的服务器。备份可能包含敏感连接信息，应放在受控位置，避免直接进入公开同步目录。升级后先用原来的最小场景验证，再测试 TUN 和特殊规则。不要仅检查程序能否打开，就删除旧备份或立即继续调整配置。

故障按接入、内核、远端分层

完全无法访问时，先暂停接管功能确认基础网络是否正常。基础网络也失败，就检查无线连接、网关和系统网络状态；基础网络正常而代理失败，再确认本地监听与内核日志。浏览器报告本地连接被拒绝，多数应从监听地址、端口和进程状态开始，而不是先修改远端协议。日志出现配置解析错误时，撤回最近一次配置变更更直接。

有目标记录但远端连接失败时，区分名称解析失败、连接超时、连接被拒绝和安全握手失败。解析失败检查解析路径；超时检查地址、端口与可达性；拒绝通常意味着目标端口没有接受连接；握手问题则继续核对系统时间、服务器名称、传输和身份参数。不要通过关闭证书验证来掩盖错误，应查清为什么验证没有通过。

速度问题保持测试条件一致

速度慢不一定是协议问题。先固定同一设备、同一网络、同一目标与同一时间段内的测试方式，再比较不同服务器。下载目标本身、无线信号、运营线路和本地后台任务都会影响结果。单次连接测试只能提供有限观察，不能证明持续吞吐能力。使用多个不同性质的业务验证，比在列表中反复点击同一种测试更接近实际使用。

如果浏览网页正常而大文件传输异常，检查目标服务限制、连接复用以及链路稳定性；如果只有一个应用慢，检查独立代理和解析路径；如果所有应用都慢，再比较基础网络与代理路径。TUN 场景还要观察是否存在其他 VPN 或安全软件接管。完整分层方法见速度慢排查笔记，不要在缺少证据时反复更换全部配置。

日志只保留解决问题所需的信息

常规运行使用适度日志级别，复现问题时临时提高详细程度。记录发生时间、操作步骤、接入模式和错误原文，通常比截取整屏服务器列表更有帮助。分享前检查地址、身份字段、订阅入口和个人业务域名等内容。处理结束后恢复日常级别，避免持续产生大量文件，也避免把长期访问记录作为普通备份随意流转。

退出与迁移也属于维护

退出客户端前，按使用方式停止系统代理或 TUN，并确认网络恢复。异常退出后若浏览器无法连接，检查系统是否仍指向已经停止的本地监听；TUN 环境则查看路由和 DNS 是否恢复。避免在多个应用之间来回切换接管而不清理旧状态。需要重新安装时先备份，只有确认数据损坏才考虑重建配置，不把重装作为所有问题的统一处理办法。

迁移到新设备后先恢复必要资料，不立即恢复所有自动启动和后台选项。订阅更新、内核启动、应用接入、路由命中与退出恢复应逐项测试，最后再开启自动化。长期维护的目标是保持一条已知可用的回退路径，而不是让设置数量不断增加。常见问题可从FAQ 分类页进入，复杂问题则携带最小复现步骤继续定位。

进阶路线：最小实验与可维护配置

从一个明确问题开始扩展

进阶配置不以启用更多功能为目标，而是解决已经观察到的问题。先写出需求，例如“某个业务域名固定直连”“某个应用需要进入代理”“网络切换后自动恢复”。再确定它属于接入、路由、解析还是运行管理层。需求能够明确归类，就能缩小改动范围；如果需求只是“整体更快”，应先补充可重复的测量和故障现象，再决定改哪里。

为每项实验保留基线，复制路由预设或创建独立服务器测试项，不直接覆盖日常配置。记录输入条件、预期结果、观察方法和撤回步骤。例如添加一条完整域名规则后，用新连接验证其出站，并检查其他域名没有被扩大匹配。实验成功不代表适合长期启用，还需要确认在重启、订阅更新和网络变化后行为是否仍然一致。

协议、安全层与传输分别评估

研究 VLESS、VMess 或 Trojan 时，重点看它们与当前服务器和内核的兼容条件，而不是依据名称判断性能高低。协议负责通信约定，TLS 或其他安全机制提供相应连接保护，传输方式又受服务端部署与中间网络条件影响。某个组合在一个环境可用，不能证明换到另一条线路也有相同表现；只有服务端提供支持，客户端参数才有意义。

调整传输字段时遵循两端一致原则。路径、服务名称、服务器名称和身份参数各有用途，不能随意用同一个字符串替代。分享链接缺少字段时，应向资料来源确认，而不是从其他节点复制。连接问题若发生在安全握手之前和之后，排查方向也不同。理解日志所处阶段，比收集一份不解释含义的“通用参数大全”更有实际价值。

让 DNS 与路由形成闭环

进阶 DNS 应先回答三件事：谁提出查询、谁执行查询、结果交给哪个连接使用。域名规则可能在无需解析时直接决定出站，地址规则可能需要先取得结果，应用自身解析又可能绕过客户端。将这几种路径分别记录，才知道某个上游解析设置影响哪一段。不要为了追求单一设置页的整齐，把所有查询强行指向一个并不适合内部网络的上游。

需要分流 DNS 时，应同时验证解析服务自身的访问路径与返回地址的后续可达性。解析请求成功并不证明返回结果适用于当前网络，地址能够连接也不证明域名分类符合预期。实验中选择少量明确目标，分别记录域名、返回地址和出站，避免刚开始就引入大量规则集、多个上游与复杂缓存策略，导致每次复现都受不同缓存状态影响。

读懂生成配置，保持来源清楚

熟悉图形操作后，可以查看客户端生成的配置，追踪入站标签、路由条件和出站定义的引用关系。重点不是记住所有字段，而是识别哪些内容来自服务器资料、哪些来自全局设置、哪些来自路由预设。运行时文件可能被重新生成，因此持久修改应回到对应管理入口。确需使用自定义配置时，应明确它接管了哪些职责，以及哪些图形选项不再生效。

按阶段验收，而不是一次完成

建议先完成稳定连接，再完成可解释分流，然后处理特殊应用与 TUN，最后研究多内核和复杂解析。每阶段都有退出条件：连接阶段要能复现成功与失败；分流阶段要能解释目标出站；接管阶段要能正常恢复系统网络；维护阶段要能从备份重建最小环境。没有通过上一阶段的验收，就不应继续堆叠下一层设置。

多内核切换尤其需要重新验证协议、路由数据和 DNS 行为，不能把启动成功当成配置等价。保留一套日常内核与预设，另一套仅用于明确功能测试，能减少切换造成的不确定性。需要重新走操作主线时回到使用文档；需要安装入口时前往获取客户端；术语与异常分别从术语手册和FAQ查阅。最终留下的应是一套能够解释、验证和回退的配置。