V2Ray 新手到进阶
客户端配置完整手册

核心概念：先分清配置的层次

客户端、内核与服务端分别做什么

先把图形客户端理解成配置入口。v2rayN 负责管理订阅、选择节点、生成运行配置，并调用相应内核；真正处理协议连接和流量转发的是内核。服务端则位于连接的另一端，需要与客户端使用一致的协议与认证参数。客户端可以免费下载，但安装客户端本身不会自动获得可用的服务端配置。开始操作前，应准备来源明确、仍然有效的节点信息或订阅地址。

Project V 是相关代理技术生态的起点，V2Fly 延续 V2Ray 的社区开发，Xray 则是另一条相关的内核发展路线。sing-box 也是部分客户端可以调用的代理内核，但它不是 V2Ray 的另一个名称。不同内核的配置结构、功能支持和参数解释不完全相同。图形界面能够统一展示部分选项，并不代表任意配置都能原样交给任意内核执行。

协议、传输与安全参数需要成组理解

VMess、VLESS、Trojan、Shadowsocks 描述的是代理协议层面的选择；TCP、WebSocket、gRPC 等描述连接采用的传输方式。TLS 或 REALITY 涉及连接安全相关机制，不能与协议名混为一谈。一个节点即使地址和端口正确，也可能因为传输路径、服务名称或安全参数不匹配而失败。导入后优先保留完整参数，不要凭名称相似就手动替换其中一项。

以 VLESS 为例，识别节点通常要同时查看服务器地址、端口、用户标识、传输方式以及安全设置。使用 TLS 时还可能涉及服务器名称；使用 REALITY 时则需要匹配相应公钥、短标识等参数。VLESS 本身不等于一套完整的加密连接方案，是否启用安全层以及采用什么组合，必须依据服务端配置。不要把其他节点的参数拼接进来试错。

沿着流量路径定位设置

一次访问通常经历应用发起请求、流量进入客户端、路由规则选择出口、内核连接服务端、服务端访问目标这几个环节。系统代理和 TUN 主要决定流量怎样进入；路由规则决定进入后走直连、代理还是阻断；节点参数决定代理连接能否建立。DNS 又参与域名解析，可能影响规则匹配和实际连接地址。把这几层分开，排错时就不会只盯着节点列表。

本章的完成标准不是记住所有术语，而是能描述当前方案：使用哪个客户端、调用哪个内核、节点是什么协议、应用通过什么入口接入、默认采用哪种路由。把这几项写成简短记录，后续每次变更只修改其中一层。对陌生名称可查术语表；遇到错误提示时，先判断它属于启动、解析、握手还是目标访问阶段，再决定下一步检查对象。

选择客户端：按系统与配置需求决定

桌面端优先从 v2rayN 开始

Windows、macOS、Linux 桌面用户优先选择 v2rayN，便于沿用本手册的订阅分组、系统代理与路由操作逻辑。下载前先查看系统类型和处理器架构，再选择对应发行包。系统名称相同不代表安装包通用，例如 x64 和 arm64 面向不同处理器指令集。无法运行时应先核对包的适用范围，而不是连续更换节点，因为此时网络配置尚未进入执行阶段。

Windows 下载区提供 Desktop 与经典 WPF 两种入口。Desktop 使用跨平台界面，适合希望在不同桌面系统间保持相近操作习惯的用户；WPF 保留经典 Windows 界面，适合已有对应使用习惯的用户。两者首先是界面与发行方式的差异，不能据此推断某个节点一定更快。运行时依赖、界面入口和配置保存方式，应以实际发行包说明为准，不要混用两个目录里的程序文件。

Android 区分首选与兼容备选

Android 首选 v2rayNG，使用 Xray 内核；v2flyNG 使用 V2Fly 内核，作为有相应兼容需求时的备选。两款客户端都可以承担节点导入与连接管理，但不能假设所有分享链接、传输参数和高级功能完全一致。已有配置明确依赖某项内核能力时，应先确认目标客户端支持该组合，再导入测试。只因名称相似就切换应用，可能把协议支持问题误认为订阅失效。

Android 安装包通常需要在 arm64 与通用版之间选择。主流较新的手机可优先核对 arm64，不能确定架构或遇到兼容问题时再检查通用版的适用说明。通用版并不意味着连接质量更高，主要区别在包含的架构范围。安装之前也要确认系统允许当前文件来源发起安装；安装完成后，权限授权仍属于独立步骤，不能把安装成功等同于代理已经启动。

比较功能时先列出实际任务

把需求写成具体任务，比比较功能数量更有效。例如只让浏览器使用代理，通常先检查系统代理或应用自身的代理设置；需要接管不读取系统代理的程序，再研究 TUN；需要按应用划分流量，则核对目标平台的分应用能力。这些任务依赖不同的系统机制。客户端能显示某个开关，也不表示当前系统权限、网络环境和内核组合已经满足启用条件。

选型阶段还要考虑维护成本。若一台设备已经稳定使用某套配置，迁移前先记录订阅来源、路由策略及特殊参数，确认新客户端能表达同样的设置。导出文件未必能跨客户端直接恢复，优先使用原始订阅或标准分享链接重建。完整对照可查客户端选型指南，实际安装入口集中在下载页。本章完成后只保留一个明确的首选方案，先建立可用基线，再评估替换需求。

安装与启动：先建立可运行的基线

确认架构、安装位置与权限

打开客户端下载页，按操作系统选择发行包。Windows 可在系统信息中查看系统类型；macOS 可在设备信息中确认芯片；Linux 同时核对架构和包管理格式。不要仅凭文件扩展名判断是否适合当前设备。下载结束后先完成安装或解压，再启动主程序；如果发行包要求解压运行，不要直接在压缩文件预览窗口里打开程序，否则相对路径、资源文件和配置写入都可能出现问题。

Windows 建议为客户端保留独立目录，避免把不同发行包反复覆盖在同一位置。目录需要允许当前用户保存设置，首次配置时尤其要确认退出后修改仍被保留。一般使用不应为了省事而长期提升所有权限；只有启用需要额外权限的功能时，再按客户端提示处理。出现运行时缺失提示，应根据错误信息安装对应依赖，而不是随意复制其他电脑上的运行库文件。

macOS 选择与芯片匹配的安装入口，按系统流程放入合适位置并启动。若系统阻止打开，先确认文件来源和系统提示内容，再按安全设置中的正常授权流程处理。Linux 应选用发行版适合的 deb 或 rpm 包，并通过系统包管理流程解决依赖。图形桌面、权限授权方式和虚拟网卡支持可能随发行版不同，启动失败与网络连接失败需要分别记录，不能合并成一个笼统的连接问题。

首次运行只检查必要项目

进入主界面后，先确认客户端能正常保存设置、内核能启动，以及本地监听地址和端口没有冲突。监听端口是应用接入客户端的入口，不是服务端端口，两者用途不同。若日志提示地址已被占用，先退出其他代理实例或调整本地监听设置，再重启验证。不要删除不认识的系统进程，也不要同时启动多个客户端争用相同端口，让后续测试失去确定性。

首次启动时保持系统代理关闭、TUN 关闭，先导入一条配置，再使用客户端提供的连接测试或明确配置代理的应用进行验证。这样可以把内核是否工作与系统流量是否接入分开。若界面正常但内核反复退出，应读取启动日志中的首个错误，重点检查配置不兼容、资源文件缺失、权限不足或端口占用。仅看窗口仍然存在，无法判断后台代理服务是否已成功运行。

完成一次启动与退出检查

Android 安装后，首次连接会出现系统 VPN 授权请求。这是应用通过系统网络接口接管流量所需的许可，不表示已经连接到服务端。先确认授权对象，再观察客户端的运行状态；若设备已有其他 VPN 会话，通常需要在两者之间选择。桌面端也可能存在其他网络工具的残留代理设置，首次排查时应暂停这些工具，避免新客户端正常运行却仍被旧入口影响。

最后主动退出并重新打开一次客户端，检查订阅分组和偏好设置是否保留。再核对退出后系统代理是否恢复，确认基本网络访问不依赖已经关闭的本地监听。安装阶段的完成标准是程序可启动、设置可保存、内核没有启动错误，以及能够明确区分运行与停止状态。Windows 界面与依赖细节可继续阅读Windows 安装流程与常见问题，不要在安装尚未稳定时提前叠加复杂分流。

订阅与节点：建立可持续更新的配置来源

先判断拿到的是哪一种链接

订阅地址用于获取一组配置，后续更新仍然访问同一个来源；分享链接通常描述单个节点，例如以相应协议名称开头的链接。两者应走不同导入入口：订阅放入订阅分组，单节点链接使用剪贴板或分享链接导入。网页能打开的地址也不一定是订阅地址，可能只是账户页面或说明页面。导入之前先确认来源说明，不要把登录页地址当成客户端可以直接解析的配置内容。

在 v2rayN 中创建订阅分组，填写一个能识别来源的名称，再粘贴完整地址。复制时注意开头协议、路径和查询参数是否齐全，尤其不要遗漏问号之后的内容，也不要混入空格、换行或中文标点。保存后执行该分组的订阅更新，观察结果是否出现节点。分组名称是本地管理标签，不参与服务端认证；修改名称通常不能修复地址过期或认证信息失效的问题。

更新方式取决于地址当前能否访问

订阅更新是否通过代理，应根据当前网络和地址可达性决定。尚未建立任何可用代理时，优先尝试不通过代理更新；如果直连访问受网络路径影响，而已有节点可以正常工作，再尝试通过代理更新。两种方式是获取订阅内容的不同路径，不是订阅格式的修复开关。若服务端返回登录页面、错误页面或空内容，切换路径也未必有效，需要检查地址权限与来源状态。

更新失败后先保留现有节点，不要立即清空全部分组。查看日志中是连接超时、名称解析失败、认证拒绝，还是内容解析错误。前两类偏向获取路径，后两类更可能涉及来源权限或内容格式。可以联系配置提供方确认地址状态，但不要把完整订阅地址贴入公开讨论。订阅中的查询参数常承担访问凭据作用，泄露后应按提供方流程更换，而不只是删除聊天记录。

更新成功之后还要检查实际可用性

成功获取节点列表只说明内容能够被读取和解析，不代表每个节点都能完成连接。先选一个参数完整、当前需求适用的节点，设为活动节点，再做真实请求测试。列表中的名称只是标签，不能可靠反映协议、安全方式或可用区域。对于长时间保留的单节点，应记录其来源和用途；如果原始来源已停止提供服务，修改显示名称或重复导入同一链接不会恢复连接。

订阅节点与手动节点最好分别管理。某些客户端更新分组时会重建该分组中的条目，因此直接编辑订阅生成节点的特殊参数，可能在下次更新后被覆盖。如果确实需要本地改动，应确认客户端提供的保留机制，或复制为独立配置并标注来源。不要默认订阅更新会替换所有本地路由设置，也不要默认完全不会影响活动节点；更新后应核对当前选择和关键参数。

建立稳定来源后再考虑自动更新。频率应符合提供方的使用约定，更新过于频繁不一定更及时，反而可能触发访问限制。每次较大更新后检查节点数量是否异常、活动节点是否变化，以及真实请求是否仍能完成。单节点和订阅的结构区别可查分享链接与订阅地址说明；更新异常则沿着订阅更新失败自查清单继续定位，先查获取结果，再查内容兼容性。

代理模式：先确认应用怎样接入

系统代理控制入口，不直接定义分流

系统代理是一组供应用读取的系统网络设置。开启后，遵循这些设置的应用会把请求交给本地代理监听；没有读取系统代理的程序，可能继续自行连接。因而系统代理开启不等于整台设备的所有流量都被接管，也不等于所有请求都使用远端节点。进入客户端之后是否直连，仍由路由决定。把入口和出口分开理解，可以避免用全局路由去修复应用根本没有接入的问题。

v2rayN 常见选项包括清除系统代理、自动配置系统代理、不改变系统代理和 PAC 模式。自动配置用于把相应系统设置指向客户端的本地入口；清除用于移除相应代理设置；不改变表示保持系统现状，并不是强制直连。PAC 则让支持该机制的应用按脚本结果选择入口。具体影响哪些系统字段，以当前系统和客户端实现为准，切换前最好记录已有的工作网络设置。

用一个应用验证入口是否生效

先保持 TUN 关闭，选定可用节点并启动内核，然后启用自动配置系统代理。使用一个明确遵循系统代理的浏览器发起新请求，观察客户端访问日志是否出现对应目标。必要时关闭旧连接或重新打开浏览器，避免连接复用干扰判断。若完全没有相关请求记录，应先检查应用自身代理选项、系统设置和本地监听，而不是继续切换远端节点或修改传输参数。

如果应用允许手动填写 HTTP 或 SOCKS 代理，应根据客户端当前显示的监听类型、地址和端口填写，不要凭教程中的示例数字猜测。HTTP 监听不能任意当作 SOCKS 监听使用；允许混合入口的客户端也需要确认该功能确实启用。应用里设置了独立代理时，系统代理开关可能不再决定它的行为。记录应用级设置，排错时才能解释为何同一设备上只有部分程序受影响。

PAC、全局与绕过大陆不在同一层

PAC 在应用接入之前进行一部分选择，客户端内的全局、绕过大陆等路由预设则在流量进入后决定出口。两套规则叠加时，某些直连请求可能根本不会出现在内核日志里，这是入口层已经作出选择的结果。入门阶段建议先使用单一、容易观察的入口，再使用内核路由分流；需要 PAC 时再明确脚本来源、更新方式和实际支持范围，不要同时叠加多套自动判断。

验证代理应使用真实业务请求，而不仅是查看客户端图标颜色。一个目标可以访问，也只能说明相应目标和当前请求路径可用；另一个应用可能使用不同协议、不同 DNS 路径或独立代理设置。遇到浏览器可用而其他程序失败，先比较入口差异。遇到页面部分资源失败，则检查不同资源域名的路由与解析，不要仅凭主页面出现就认定所有连接均已正常。

工作网络可能通过管理策略规定代理配置，切换前应了解本机权限和组织要求。不要把个人代理设置直接覆盖到不允许修改的环境。退出、休眠和网络切换后，也要检查系统入口是否保持预期。本章的完成标准是能解释哪些应用会接入、入口地址从哪里读取、关闭客户端后怎样恢复。需要更广泛的流量接管时再进入 TUN 章节，而不是把系统代理失效一概归结为节点故障。

路由分流：用最少规则表达实际需求

从一个预设建立可解释的默认行为

先选择一个适合当前用途的路由预设，再增加少量自定义规则。全局通常把进入客户端的流量交给代理出口，但不改变应用是否进入客户端这一事实；绕过大陆通常依靠域名和地址规则将部分目标直连，其实际范围取决于预设内容及规则资源。不要把预设名称当成完整技术定义。选择后应查看具体规则和默认出口，尤其确认未匹配任何规则的流量最终怎样处理。

路由一般按顺序匹配，较早命中的规则决定后续处理。一个范围过大的规则放在前面，可能遮住后面的精细规则。调整时先写下目标：哪个域名直连、哪个目标代理、哪些连接阻断，再判断匹配维度是否正确。域名、目标地址、端口和应用信息并非总能同时获得；如果当前入口只能提供地址，单纯增加域名规则未必生效，还需要检查域名信息来自哪里。

理解配置片段，不直接拼接完整运行文件

下面是 Xray 风格的路由片段，展示回环与私有地址直连、指定域名走代理的基本写法。它不是完整客户端配置，引用的出口标签必须在实际配置中存在，图形客户端也可能使用不同标签。应先在界面中表达相同意图，确需使用自定义配置时再核对当前内核文档。sing-box 的规则结构不同，不能把这段内容直接粘贴到另一种内核的配置字段。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "::1/128", "fc00::/7"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      }
    ]
  }
}

在这段示例中，域名后缀匹配覆盖目标域名及其子域名，不应把它理解成任意包含相同字母的地址。地址规则只在能够获得并匹配目标地址时起作用；使用按原域名处理的策略，并不会为了每条地址规则主动解析全部域名。因此，局域网服务最好优先使用明确的本地域名或地址规则，并结合实际访问形式测试，避免以为写了私有地址范围就一定覆盖所有入口情况。

DNS 与嗅探影响规则能看到什么

DNS 决定域名怎样得到地址，路由决定连接采用哪个出口，两者互相影响但不是同一个设置。解析得到的地址可能随网络、解析器和时间变化，所以使用某个临时地址替代完整域名规则往往不稳定。嗅探可从部分协议数据中尝试识别目标名称，但并非所有流量都能识别，也不应把它当作万能修复。启用前要理解其用途，并关注兼容性，而不是同时开启全部相关选项。

测试一条新规则时，先选一个明确目标，记录修改前出口，再添加规则并重新建立连接。日志能显示规则或出口时，查看实际命中结果；界面只显示连接信息时，则结合可控目标和请求结果判断。若测试仍走旧路径，先排除连接复用、应用缓存和规则顺序，再考虑解析差异。每次只改一项，确认有效后才继续，否则很难区分是哪条变化产生作用。

分流维护的重点是少而明确。定期删除失去用途的临时规则，记录例外规则为何存在；更新规则资源后重新测试常用目标和局域网访问。出现问题先恢复最近一次可用预设，再逐条加回自定义项。不要为了追求复杂规则而牺牲可解释性。学习阶段的合格结果是能说明默认出口、例外条件与匹配顺序，并能用真实请求证明规则生效，而不只是看到保存成功的提示。

TUN 模式：在稳定配置上扩大接管范围

先理解虚拟网络接口的作用

TUN 通过虚拟网络接口接收系统交给它的网络数据，使部分不读取系统代理的应用也有机会进入代理处理流程。它解决的是流量接入范围问题，不会自动修复过期订阅、错误认证或不可达服务端。启用之前应确保同一节点已经能在基础代理路径中工作，否则入口、路由和远端连接三种问题会叠在一起。对只使用浏览器的简单场景，未必需要额外引入这一层。

桌面系统可能要求管理员权限、服务支持或额外的网络授权，具体方式取决于系统和发行包。按客户端提示处理即可，不要从不明来源下载所谓通用驱动。启用后应确认虚拟接口已经建立、内核持续运行，并且路由设置没有立即触发错误。Android 客户端通常通过系统 VpnService 接管流量，授权界面和桌面端 TUN 开关不是同一种操作形式，不能逐项照搬。

避免代理连接再次被自身接管

TUN 需要正确处理代理服务端本身的连接，否则可能发生流量再次进入虚拟接口的回环。图形客户端通常提供相应自动处理，但多客户端并行、手动修改路由或其他 VPN 同时运行，都可能破坏预期。首次启用时暂停其他网络接管工具，保持单一入口；如果日志出现重复连接、请求堆积或启动后立即失去网络，应先关闭 TUN 恢复基线，再检查出口和系统路由。

系统代理是否同时开启，应遵循当前客户端的推荐组合。两者并用不必然错误，但会增加路径解释难度。测试阶段可以关闭系统代理，选一个原本不遵循系统代理的应用，观察启用 TUN 前后的访问日志变化。若客户端提供自动路由、严格路由或接口选择等选项，应先保留默认值，理解作用后再调整；不同内核的同名选项可能存在行为差异，不能只凭名称迁移设置。

把 DNS、局域网与休眠恢复纳入验证

TUN 往往涉及 DNS 接管或专用解析路径。启用后如果地址能访问而域名失败，优先检查解析链路；如果域名可解析但连接超时，再检查出口选择和服务端连通。采用合成地址机制时，还需要相应的映射与路由流程配合，不能把这些地址当作目标真实地址写进永久规则。企业内部域名、局域网设备名称和需要特定解析器的服务，应分别测试是否仍可正确解析。

验证清单应包含普通网页、原本需要单独设置代理的应用、局域网设备访问，以及休眠唤醒后的恢复。切换无线网络或有线网络后，也要检查出口接口是否变化。若只有特定网络失败，可能涉及该网络的 DNS、门户认证或管理策略；先完成网络本身要求的登录，再开启接管。不要在系统尚未正常获取网络配置时持续重启内核，把接入网络的问题误判成客户端故障。

Android 还要检查后台限制。系统省电策略可能在息屏后停止应用，使连接表现为间歇失效；应按设备设置允许必要的后台运行，而不是无限放宽全部权限。分应用设置中也要分清列表代表包含还是排除，避免把目标应用放进相反范围。详细操作可参考VPN 权限、省电与分应用代理说明。本章完成标准是接管范围可解释、常用场景可验证，而且关闭后能回到正常网络状态。

日常维护：保留基线，按层处理异常

更新之前先记录可恢复状态

日常维护不只是点击更新。先记录当前客户端类型、使用的内核、订阅分组、活动节点与路由预设，再备份必要的本地设置。订阅地址和导出配置可能包含访问凭据，应放在受控位置，不要上传到公开网盘或讨论区。备份是否可恢复也要验证：至少知道导入入口、哪些内容包含在文件里，以及恢复会不会覆盖当前设置，避免故障时才发现只保存了一个空目录。

更新客户端、内核、订阅和规则资源属于不同操作。客户端更新可能改变界面与配置管理；内核更新涉及协议实现与运行行为；订阅更新刷新来源提供的节点；规则资源更新影响分流匹配。一次只进行一种更新，启动后检查日志和常用目标，再继续下一项。若全部同时更换，出现问题时很难判断应该退回程序、节点还是规则，也容易把暂时的网络波动误认为更新缺陷。

无法连接时从入口开始逐层缩小

先判断基础网络是否正常，再确认客户端和内核是否运行，然后检查应用流量有没有进入，最后检查路由与远端连接。完全没有访问记录，优先看入口；有记录但连接服务端超时，优先看地址、端口和网络路径；握手被拒绝则检查认证、传输和安全参数。时间相关认证或证书验证异常时，还应核对系统时间。不要把所有错误都处理成重新安装，安装过程本身未必涉及故障层。

如果同一节点在不同应用中表现不同，先比较系统代理、应用独立代理、DNS 和协议需求。若所有节点都失败，重点检查共同依赖，例如本地监听、内核启动、网络接入和统一解析设置。若只有一个节点失败，再核对该节点的服务端状态与专属参数。若同一设备换网络后恢复，说明路径差异值得调查，但仍不能单凭一次测试就确定问题归属，应记录可复现的条件。

读懂测速结果与日志证据

TCPing 通常只反映到目标端口的一部分连接情况，不能证明完整代理握手和目标请求成功。真连接延迟更接近一次经代理完成的请求，但也依赖测试目标；下载测速涉及带宽、服务端负载、目标站点和本地网络，且会消耗流量。不要把单个数字作为唯一选点标准。优先判断业务请求能否稳定完成，再结合多次、同条件的测试比较差异，避免混合不同测试方法的结果。

阅读日志时优先截取一次失败对应的时间范围，寻找首个具体错误，而不是最后一条汇总提示。常见的超时、连接拒绝、名称解析失败、认证失败指向不同阶段。分享日志前移除订阅地址、用户标识、完整服务端信息和本地敏感路径；只保留定位所需的错误类型与操作顺序。过长日志可能隐藏关键上下文，短小且能复现的记录通常比整屏截图更有用。

维护结束后应再次检查退出恢复、系统代理状态和常用应用。保留一个已验证可用的基础配置，但不要无限累积失效节点和临时规则。测速原理可查TCPing、真连接与下载测速的区别；高频现象可查常见问题。维护的完成标准是变更有记录、异常能定位到层次、恢复步骤可执行，而不是让设置页面的开关尽可能多地处于开启状态。

进阶路线：从能连接到能解释配置

第一阶段：用可重复测试替代反复试错

进阶不意味着立刻编写完整配置文件。先为常用场景建立重复测试方法：固定一个应用、一个目标和一种入口，记录节点、路由与解析设置，再观察一次请求的结果。改变配置时只修改一个变量，确认结果后继续。这样得到的知识可以迁移到其他节点和网络，而不是依赖某个偶然可用的组合。若无法解释为什么有效，暂时保留记录，不要把猜测写成通用结论。

逐步学习 DNS 的作用范围，分清系统解析、应用自带解析和内核解析。观察域名是否在进入客户端前已变成地址，规则是否需要原始域名，以及解析请求本身怎样选择出口。不要一开始就追求复杂解析链，先确认每一层的负责人。对于同时存在不同地址类型的目标，还应检查系统网络是否具备相应连接能力，避免把地址可解析误认为地址必然可达。

第二阶段：围绕真实需求理解内核差异

Xray、V2Fly 与 sing-box 之间的选择，应由节点协议、传输组合、路由能力和客户端支持情况共同决定。切换内核之前先列出必须保留的功能，再确认客户端能否正确生成相应配置。界面中的可选项可能只是部分能力映射，自定义配置也可能绕开某些图形设置。不要以为切换后所有选项都会自动保持等价，应重新验证连接、解析和路由，而不是只看进程能否启动。

学习参数时围绕一个已知可用节点逐项核对：地址和端口用于找到服务端，认证信息用于确认身份，传输参数用于匹配承载方式，安全参数用于建立预期的保护机制。TLS 的服务器名称不是任意备注，REALITY 的公钥也不是可自行生成后替换的显示字段。任何一项变化都需要对应的服务端条件。理解这些边界后，才能判断错误来自客户端表达能力还是配置本身不完整。

第三阶段：学习配置结构与验证流程

阅读完整配置时，先识别日志、入站、出站、路由与 DNS 这些功能区，再追踪标签引用关系。入站描述接收什么流量，出站描述怎样连接或处理流量，路由把匹配条件连接到某个出站。标签只是配置内部的引用名称，不能仅凭名字认定行为；需要查看它实际对应的协议与设置。遇到不同内核时重新识别结构，不要把一种配置格式的字段名套到另一种格式上。

编写自定义配置之前先复制一份工作配置，在独立测试环境中进行。确认 JSON 语法、字段适用范围和引用关系，再由对应内核完成语义验证。语法合法只说明格式可解析，并不证明字段被支持，更不证明服务端参数正确。图形客户端可能在启动时重新生成运行配置，因此不要直接修改会被覆盖的临时文件；应使用它明确提供的自定义入口，并记录图形设置还有哪些仍然生效。

形成自己的最小操作手册

把稳定流程整理为简短文档：如何安装和导入、默认使用什么模式、遇到故障先检查哪一层、怎样关闭接管并恢复网络、哪些设置需要备份。对每条例外规则标注用途，对每次变更保留退回方法。设备迁移时先重建最小连接，再恢复订阅分组和常用路由，最后启用 TUN。顺序与本页主线一致，能够避免把旧环境的隐含依赖一次性带到新系统里。

最终应能回答四个问题：流量从哪里进入，为什么选择这个出口，域名在哪里解析，失败后怎样退回基线。能够回答并通过日志与真实请求验证，才算建立了可维护的配置。之后按需求查术语表、常见问题和专题博客，不必一次开启所有高级功能。需要重新梳理最短操作流程时，回到快速上手教程，先恢复可用，再逐层增加能力。