V2Ray 完整手册

一、核心概念与连接链路

客户端、内核与服务器各做什么

V2Ray 通常指 Project V 相关的代理技术生态，不是一个包含线路的单独账号服务。图形客户端负责保存服务器、管理订阅、生成配置和启动内核；内核处理入站连接、协议通信与路由规则；远端服务器接收符合约定的连接并转发请求。安装客户端只是准备本地工具，仍需取得有权使用的服务器参数，才能建立完整的数据通路。

V2Fly 与 Xray 是相关生态中的不同内核项目，支持的协议扩展和配置细节并不完全相同。v2rayN 为桌面操作提供界面，v2rayNG 常用于安卓上的 Xray 配置，v2flyNG 则提供 V2Fly 路线的选择。看到客户端能导入一个名称，并不能直接证明当前内核支持其中全部选项；判断兼容性要继续检查传输、安全层和扩展参数。

把服务器参数拆成三层

第一层是代理协议，例如 VMess、VLESS、Trojan、Shadowsocks，决定双方如何识别连接及表达请求。第二层是传输方式，例如 TCP、WebSocket、gRPC，决定协议数据怎样承载。第三层是安全相关设置，例如 TLS、REALITY 及服务器名称。三层组合必须与服务器配置相符，不能因为地址和端口正确，就随意替换其他字段。

服务器名称、连接地址和请求目标是三个不同概念。连接地址用于找到远端服务；TLS 的服务器名称参与握手中的身份验证；请求目标则是应用真正访问的域名。它们有时相同，有时不同。修改分享链接中的服务器名称来“修复域名”，可能反而破坏握手。参数存在疑问时，先与提供方给出的原始说明逐项核对。

沿数据方向定位问题

一次常见请求依次经过应用、本地监听端口、内核路由、远端服务器，最后到达目标服务。系统代理只影响愿意读取该设置的应用；已经进入本地代理的请求，还要经过内核规则选择出口。DNS 则负责把域名解析成地址，可能由应用、操作系统或内核参与。把这些环节混成一个“代理开关”，容易在错误的位置反复改动。

排错时应先确定失败发生在哪一段。客户端启动失败，要看运行环境与端口；浏览器没有进入客户端，要看应用代理；日志出现握手错误，要看协议参数和时间；只有部分域名异常，要看规则与解析结果。日志中的一条报错需要结合触发时间理解，后台应用的失败请求不一定与当前页面有关。

建立可以复现的最小基线

开始配置时，只使用一个已确认可用的服务器、一种应用入口和一套简单路由。暂时关闭不必要的自动切换，不同时启用多种网络接管方式。这样一次测试只改变一个条件，结果才有解释价值。连接成功后记录客户端名称、内核选择、监听端口及路由模式，这些信息比“昨天还能用”的描述更容易帮助恢复现场。

继续阅读前，应能说明当前服务器参数从哪里取得、哪个程序启动内核、测试应用连接哪个本地端口。若这三个问题仍不明确，先整理来源与设置，不要提前配置复杂分流。概念清楚后，下一章按平台选择客户端；后续章节再逐步加入订阅管理、域名规则和虚拟网卡，每个阶段都保留一次可回退的测试结果。

二、客户端选择与平台准备

桌面优先选择 v2rayN

Windows、macOS、Linux 桌面环境优先从 v2rayN 开始，便于用同一种界面理解服务器、订阅分组、系统代理与路由。先到客户端下载页选择平台，再确认处理器架构和安装格式。平台名称相同不代表安装包可以互换，架构选择错误可能表现为程序无法启动，也可能需要额外的兼容运行环境。

Windows 的桌面版采用跨平台界面，经典 WPF 版保留传统操作方式。首次使用可先选择桌面版；已有经典界面的操作习惯时，也可按需求选择 WPF 版。两种界面的布局不同，不应仅凭教程截图找按钮。迁移之前先导出需要保留的设置，测试新界面能够导入服务器后，再决定是否替换原有使用环境。

按芯片和发行版选择安装格式

macOS 应先在系统的设备信息中查看芯片类型，Apple Silicon 对应 arm64，Intel 对应 x64。不要依据电脑外观或购买年份猜测。安装后还需确认程序获得正常运行所需的权限；TUN 使用的权限与普通启动不同，因此不能把“界面能打开”当作所有网络功能都准备完成。第一次测试应先使用系统代理建立基线。

Linux 需要同时核对处理器架构、发行版的包管理方式和桌面会话。deb 与 rpm 对应不同的软件包体系，arm64 与 x64 则对应不同指令架构。软件包安装成功后，如果托盘图标或系统代理表现不同，应继续检查桌面环境的支持情况。应用自行配置本地代理通常更容易验证，不能仅凭托盘是否出现判断内核状态。

安卓围绕内核需求取舍

Android 首先考虑 v2rayNG，使用 V2Fly 相关配置时再评估 v2flyNG。多数较新的主流设备可选择 arm64；不确定设备架构时，可查看系统信息，或按下载页说明考虑通用版。不要把两个客户端同时启动作为连通性测试方法，它们可能争用系统的 VPN 接口，使后启动的连接替换先前连接，导致结果难以解释。

安卓客户端通过系统 VPN 接口接管网络时，会出现系统授权提示。这是在创建本地网络入口，不等于系统已经验证远端服务器可用。还要考虑省电策略、后台运行权限以及按应用代理名单。若前台可用、锁屏后失效，应先查看后台限制，而不是马上更换协议。不同设备厂商的设置入口有差异，应按权限名称查找。

选择前整理需求，不追逐参数数量

客户端是否合适，取决于实际需要的协议、订阅格式、规则能力及网络入口。只使用浏览器时，普通本地代理往往足够；需要覆盖更多应用时，再研究 TUN。使用 REALITY 等特定配置前，应确认所选内核能够处理完整参数。客户端界面中的功能多，并不意味着每项功能都必须开启，额外开关会增加排查范围。

换客户端不能直接解决服务器本身不可用的问题。先保留同一组参数和同一网络环境，再比较两个客户端的日志与行为，才有参考意义。需要进一步比较管理方式，可阅读三款客户端功能对比。完成选择后，固定一款客户端继续安装，避免在尚未建立基线时频繁迁移配置。

三、安装与首次运行基线

安装到可以持续写入的位置

先根据下载页说明完成安装或解压，再启动客户端。需要解压的程序应先完整解压到独立目录，不要直接在压缩包预览中运行。目录应允许当前用户写入配置和日志，也应方便后续备份。不要在同步工具正在频繁改写的目录里测试，以免配置文件被旧副本覆盖，或者多个设备同时写入同一份运行状态。

首次启动如果出现运行环境提示，应按提示补齐对应组件，再重新打开客户端。界面能显示但内核无法启动时，查看核心程序路径、执行权限和安全软件的拦截记录。不要直接关闭整个系统防护；先确认被阻止的具体文件及原因。涉及系统权限的操作应尽量缩小范围，普通代理测试不需要一开始就启用 TUN。

检查内核与本地监听端口

进入参数设置，确认当前内核与服务器配置兼容，再查看本地监听地址和端口。手册以 10808 作为端口示例，实际使用应以客户端界面为准。某些界面将 HTTP、SOCKS 或混合入口分开显示，另一些界面提供统一入口；应用填入的代理类型必须与对应监听方式一致，不能只复制一个端口数字。

本机应用通常连接 127.0.0.1。这个地址表示当前设备自身，在另一台设备上填写同样地址，只会连接那台设备本身。首次配置保持仅本机监听，暂不开启局域网连接。若以后需要供其他设备使用，再确认监听范围、访问控制及防火墙规则，并理解开放端口会扩大可访问范围，而不只是增加一个方便入口。

用最少变量完成首次测试

导入一个已授权的服务器并设为活动项，先保持 TUN 关闭。选择自动配置系统代理后，用遵循系统代理的浏览器发起一次新请求，同时观察客户端日志。浏览器缓存和已经建立的长连接可能保留旧路径，必要时关闭测试标签页再重新打开。测试时应记住访问时间，方便从日志中找到同一批请求，而不是阅读所有历史输出。

“内核已启动”只说明程序进程进入运行状态，不代表远端握手成功。若页面不能打开，先检查日志里是否出现该请求；没有记录时优先排查应用入口，有记录但连接失败时再看服务器地址、端口和安全层。程序日志若含有配置加载错误，应先修复该错误，继续切换节点通常不会改变同一份错误配置的结果。

区分网络权限与程序权限

系统防火墙允许程序联网，与允许局域网设备访问本地端口，是两个方向的权限。首次使用只需满足当前测试路径，不应为了排错一次性放开所有入站规则。macOS 的安全提示、Linux 的执行权限以及 Windows 的运行环境问题，也应分别处理。具体安装边界可查阅首次安装设置笔记。

成功建立连接后，记录程序所在目录、配置保存位置、当前内核、监听端口以及测试应用。随后正常退出客户端，观察系统代理是否按预期清理，再重新启动确认配置能够保留。若退出后浏览器仍连接本地端口，应检查系统代理残留。把这一轮启动、连接、退出测试做完，才算得到可重复的安装基线，之后再加入订阅和规则。

四、订阅导入与服务器管理

分清订阅地址和分享链接

订阅地址用于下载并更新一组服务器，分享链接则通常描述一个服务器。以 vmess://、vless://、trojan://、ss:// 开头的内容，应使用分享链接导入入口；订阅地址应放入订阅分组的地址字段。把两者填反，可能出现解析失败，也可能只导入文本而没有生成可用服务器。

订阅地址经常包含用户专属凭据，应按敏感信息保存，不发到公开截图或聊天记录中。复制时检查开头、结尾和换行，避免把说明文字、标点或空格一起复制。地址来自二维码时，也应先核对客户端识别出的内容类型。不要把订阅交给来源不明的转换服务，转换过程可能让地址和服务器参数被第三方读取。

建立分组，再执行更新

在 v2rayN 的订阅分组管理中新增分组，填写容易辨认的名称和订阅地址，保存后对该分组执行更新。第一次更新应观察结果提示，并确认服务器列表确实发生变化。分组名称只用于本地管理，不会改变远端线路。不同来源分开保存，便于日后定位某一来源的更新失败，也可避免手工服务器混在订阅条目中被覆盖。

更新失败时，先区分下载失败和解析失败。下载失败要看当前网络能否访问地址、是否需要经过已经可用的代理、证书及系统时间是否正常；解析失败则要看返回内容是否真的是客户端支持的订阅格式。账号页面、错误提示页和过期响应都可能被当成普通文本返回，看到“下载完成”并不代表导入成功。

理解更新方式与覆盖范围

部分客户端提供直接更新和通过代理更新两种路径。首次配置尚无可用服务器时，依赖代理的更新可能形成循环；已有可用连接后，才有条件使用代理访问订阅地址。选择前先确认更新流量究竟走哪条路径，不要在同一个错误入口上反复点击。若提供方要求特定格式，应使用其明确适配的客户端订阅入口。

订阅更新可能替换该分组的条目，因此不宜直接修改订阅节点并期待修改长期保留。确有本地调整需求时，可复制到独立的手工分组，并注明修改原因。更新前后检查活动服务器是否仍存在，特别是条目名称或标识变化时。客户端显示旧名称，不足以证明当前连接仍使用同一个地址，需要打开详情核对。

核对导入后的关键字段

分享链接成功解析后，依次查看协议、地址、端口、用户标识或密码、传输方式及安全层。WebSocket 还可能涉及路径和 Host，gRPC 涉及服务名称，REALITY 涉及公钥、短标识和服务器名称等参数。这些字段应与来源一致，不要根据其他节点的配置批量套用。别名可以自由整理，连接参数则必须保留其原本含义。

更新完成后先测试当前服务器，再安排自动更新。自动更新频率应与来源说明相符，过于频繁并不能提高稳定性。对于长期不用的分组，可停用自动更新并保留必要记录。若仅某个分组异常，而其他分组正常，应先定位该订阅来源；常见失败分支可在帮助中心继续查阅，避免把局部问题扩展成全局重装。

五、系统代理与流量入口

系统代理不是全设备接管

系统代理负责向应用提供本地代理地址，是否采用该地址由应用自身决定。浏览器通常能够读取系统设置，部分工具则有独立代理项，还有应用可能完全忽略系统代理。因此，切换“自动配置系统代理”后，不能仅凭一个应用的结果推断所有流量已经进入内核。验证入口时，应使用已知遵循该设置的测试应用。

“清除系统代理”通常用于移除当前系统的代理配置，“不改变系统代理”则保留既有系统状态，两者并不等价。若系统中原本已有其他代理设置，使用前先记录，防止切换后无法恢复。客户端结束运行而本地代理地址仍被系统保留时，应用可能持续连接一个已经关闭的端口，表现为客户端退出后网络反而异常。

路由模式发生在入口之后

全局、绕过大陆、直连等路由模式，决定已经进入内核的请求采用什么出口。它们与系统代理属于不同层级。把路由改为全局，不会自动接管忽略系统代理的应用；把系统代理设为自动，也不会自动保证所有请求走远端。先确认请求进入客户端，再分析出口选择，才能准确理解模式切换带来的变化。

全局代理适合临时验证远端连接是否工作，但仍应检查当前预设是否保留私有网络等例外。绕过大陆通常依赖域名和 IP 数据集，让相应目标使用直连出口；直连模式则让进入内核的流量优先直接访问。各客户端预设可能不同，模式名称只是入口，应打开规则内容确认实际含义，不能仅凭名称推断完整行为。

为独立应用配置代理

应用有独立代理选项时，按客户端实际监听方式选择 HTTP 或 SOCKS，地址填写本机回环地址，端口填写对应本地端口。不要把远端服务器地址直接填入普通代理框，远端协议通常需要由内核处理。应用还可能提供“代理时解析域名”之类选项，其取值会影响域名由哪一端解析，需要与后续路由策略一起理解。

一次测试只保留一个明确的应用代理来源。浏览器扩展、系统代理和应用内部设置同时存在时，要先查清优先级，避免以为改动了系统代理，实际请求仍走扩展保存的旧端口。切换后关闭旧连接再重试，并记录哪一种设置生效。长期使用时也应减少重复入口，配置来源越少，恢复和迁移越容易。

按应用场景选择组合

普通浏览使用可从自动配置系统代理加清晰的分流规则开始；单个开发工具可使用应用独立代理；需要接入更多不遵循系统代理的程序时，再考虑 TUN。局域网设备访问另有监听范围与防火墙要求，不属于系统代理开关本身的能力。每增加一种入口，都应补一次独立测试，确认新入口没有改变已有流量的预期出口。

若浏览器正常而其他应用失败，先判断失败应用是否进入客户端，不要立刻调整域名规则。若应用均进入客户端但只有某类目标失败，再检查路由、解析与远端访问情况。更详细的组合示例见系统代理与路由模式区别。下一章在入口已经明确的前提下，进一步说明规则顺序与域名策略。

六、路由分流与 DNS 策略

从上到下理解规则匹配

路由规则描述哪些请求应交给哪个出站。常见条件包括域名、目标 IP、端口和网络类型等；同一规则中不同条件通常需要共同满足，规则中的同类候选则按对应语义判断。内核按顺序查找匹配规则，命中后选择相应出站，因此特定例外通常应放在宽泛规则之前。没有匹配时如何处理，要继续检查默认出站与客户端生成配置。

先写出目标行为，再决定匹配条件。例如需要让某个内部域名直连，就应先确认客户端获得的是域名还是只有 IP，再选择域名规则或地址规则。只给一个公开域名添加直连，不一定覆盖它加载的全部资源，因为页面还可能请求其他域名。应按实际日志逐步补充，不要看到一处失败就把大范围目标全部改到同一出口。

域名策略决定何时尝试解析

AsIs 侧重按现有目标信息匹配，不为路由主动追加域名解析；IPIfNonMatch 在域名未匹配相应规则时，尝试解析地址并继续匹配 IP 条件；IPOnDemand 则在匹配需要 IP 的规则时尝试解析。具体行为应按所选内核实现理解。修改域名策略主要改变路由判断过程，不等于替换系统所有应用使用的 DNS。

geosite:cn 是域名数据集选择方式，geoip:cn 是地址数据集选择方式，两者不能相互替代。数据文件是否存在、内容是否适合当前需求，都影响匹配结果。域名解析得到的地址可能随网络与时间变化，不能仅凭一次地址归属断言路由永久正确。更新数据后也应验证关键域名，而不是假定规则行为完全不变。

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

上例是路由片段，不是完整运行配置。它依赖可用的数据文件和名为 direct 的直连出站，也没有定义其他请求的最终出口。图形客户端可能生成不同的标签名称，应在对应规则界面映射，不要整段覆盖客户端配置。第一条处理私有地址，第二条处理域名集合；其他流量的行为仍由剩余规则与默认出站决定。

把 DNS 故障与连接故障分开

域名无法解析时，连接通常还没有进入目标服务的握手阶段；解析成功后连接超时，则可能涉及地址可达性、路由出口或远端状态。先查看日志中的错误阶段，再决定修改哪一项。某些应用自行解析域名，进入代理时只携带地址，此时单纯增加域名规则未必生效。开启流量探测有时能补充目标信息，但并非所有协议都能识别。

流量探测会尝试从连接信息中识别域名，其识别结果是否用于路由、是否改变目标地址，取决于具体配置。不要把它当作自动修复全部 DNS 问题的开关。需要访问局域网名称时，还应确认本地解析路径没有被不合适的远端解析覆盖。公司网络或校园网络可能有内部域名，修改前应记录原有解析方式与访问需求。

小范围变更与回归验证

每次只新增一条规则，测试一个应命中的目标和一个不应命中的目标，再观察出口是否符合预期。验证通过后才扩大范围，并记录规则用途。出现异常时先撤回最近的变更，恢复最小规则集，再逐条加入。不要同时切换 DNS、域名策略与服务器，否则即使恢复连接，也无法确认究竟是哪项改动起作用，后续维护仍会失去依据。

七、TUN 模式与系统网络接管

虚拟网卡解决入口问题

TUN 通过虚拟网络接口接收系统按路由送来的 IP 数据包，再交给相应组件处理。它主要扩展流量进入代理处理链路的方式，不会自动修复服务器参数、订阅或远端网络。启用前应先用普通代理验证同一个服务器可用。若基础连接没有建立，加入虚拟网卡只会同时增加权限、系统路由和 DNS 等变量，使故障定位更困难。

TUN 不等于所有请求必定经过远端代理。进入接管范围的流量仍可能根据规则选择直连、代理或其他动作；部分流量也可能因系统路由、应用绑定网卡等原因不进入接管范围。界面显示已启用，只是状态的一部分，还需要检查虚拟接口是否创建成功、相关路由是否生效，以及测试应用的请求是否出现在日志中。

启用前先消除接口冲突

先关闭其他正在接管网络的 VPN 连接或重复的 TUN 实例，确认普通网络可用，然后保存当前设置。按客户端提示授予必要权限，启动后查看日志是否存在驱动、接口创建、路由写入或权限错误。不要只反复点击开关等待恢复。若启动失败，应先处理最早出现的明确错误，后续连接超时可能只是接口未建立的连带结果。

远端服务器连接本身必须保留可到达的出口，不能被路由再次送回同一个接管入口而形成回环。客户端通常会处理必要的路由安排，但多网卡、其他网络工具或手工路由可能改变结果。启用后立即全面断网时，先关闭 TUN 恢复基线，再检查默认路由和冲突工具，不要在断网状态下继续批量更新规则与订阅。

分开验证 DNS、UDP 与局域网

启用 TUN 后先测试普通网页，再检查依赖 UDP 的实际应用，并验证路由器管理页、打印设备和内部服务。网页可用只证明一部分路径工作，不能推断所有协议都正常。UDP 是否能够完成转发，涉及客户端接管方式、内核、远端协议及服务器设置。测试失败时应沿同一条链路检查，而不是把所有问题归为系统权限。

DNS 接管可能改变原有的解析路径，因此应比较启用前后的域名表现。若公开域名正常但内部名称失效，优先检查本地 DNS 与局域网例外；若只有某些地址段不可达，再看私有地址规则及路由。MTU 调整应有分片或特定传输异常的依据，随意套用一个较小数值，可能掩盖真正问题，也可能影响其他连接效率。

桌面与安卓分别建立恢复方法

桌面客户端的 TUN 可能调用额外网络组件，具体能力取决于客户端打包与实现，不能把它等同于所有内核都有相同的原生接口。Android 客户端使用系统 VPN 接口时，也要检查按应用名单和后台限制。某个应用被排除在名单之外，或者客户端被系统暂停，都会表现为局部失效，处理方式与远端服务器故障不同。

睡眠唤醒、无线网络切换、连接有线网卡后，应重新验证接管状态。旧接口或旧解析状态可能暂时保留，正常停止再启动客户端有助于重新建立环境，但应先记录异常，避免丢失证据。若每次网络切换都出现同一问题，整理网络类型、触发顺序、接口状态和相关日志，再到帮助中心按症状查找，不宜长期依赖强制结束进程。

八、日常维护与故障排查

分别维护程序、配置与订阅

日常维护包含三个相互独立的对象：客户端及其网络组件、用户保存的设置、远端订阅内容。客户端更新不一定更新订阅，订阅刷新也不会自动改变本地路由规则。开始维护前先确认这次要解决什么问题，只更新相关部分。若一次同时替换客户端、内核和规则，即使出现异常，也难以判断是哪一层引入了变化。

更新程序前导出必要配置，并确认备份包含哪些内容。部分导出只保存服务器，未必包含路由、订阅分组和界面设置；复制整个运行目录也不一定适合跨平台恢复。备份后应检查文件能否被对应导入功能识别。备份中可能包含账号信息和订阅凭据，保存位置应具备适当访问限制，不宜直接放入公开共享目录。

建立固定的检查顺序

完全无法连接时，先关闭接管并验证基础网络，再确认客户端进程和内核状态，然后检查应用入口、活动服务器、握手及目标访问。只有部分应用异常时，先对比是否进入相同入口；只有部分域名异常时，再重点检查路由和 DNS。这个顺序按依赖关系向后推进，避免上游尚未正常就修改下游规则，形成更多无法解释的变化。

日志应围绕一次明确操作采集。记录测试时间、应用、目标类型和当时模式，清理无关旧输出后再复现。遇到配置解析错误，先检查对应字段与内核兼容性；遇到认证或握手错误，核对参数及系统时间；遇到超时，再检查连接地址、出口与网络环境。仅凭“超时”两个字，不能判断服务器永久失效或某个协议不适用。

测试指标需要对应实际任务

延迟通常反映某种探测往返时间，速度测试反映特定连接条件下的数据传输情况，两者不能相互替代。某个服务器探测结果较好，也可能因目标服务、并发或时段变化而不适合当前任务。日常验证应包含真正需要使用的应用，并控制测试次数。批量测试本身会产生连接和流量，还可能干扰正在进行的下载或会议。

系统时间错误可能影响安全握手，睡眠唤醒后也应检查时间与网络状态。若换到另一网络后立即恢复，说明原网络路径值得进一步排查，但仍不能直接定位到某一个具体设备。可以保留同一客户端、同一参数，仅改变网络进行对照；也可以保持网络不变，仅更换一个已确认可用的服务器，每次对照都只改变一个主要条件。

分享诊断信息前移除敏感字段

请求协助时，提供客户端名称、系统平台、内核选择、模式和完整错误阶段即可开始定位。截图应遮盖订阅地址、用户标识、密码、公钥关联信息以及不适合公开的服务器详情。不要直接上传整个配置目录。日志中也可能包含目标域名与本地路径，分享前应检查上下文，保留足够的错误信息，同时减少无关个人数据。

长期稳定后，记录一份简短维护笔记：最近修改了什么、为何修改、怎样验证、如何撤回。遇到异常先恢复最近一次已知可用状态，而不是反复导入相同订阅或重装程序。常见短问答可参考新手连接问题速查；若恢复后问题仍可重复，再沿入口、解析、路由和远端连接逐层继续定位。

九、进阶配置与验证路线

先读生成配置，再尝试自定义

熟悉图形界面后，可以从客户端提供的配置查看或导出功能理解生成结果。重点寻找入站、出站、路由、DNS 和日志这几个部分，观察界面中的一个选项怎样映射成配置字段。先阅读，不急于修改。客户端可能在启动时重新生成文件，直接编辑运行配置不一定能够持久保存，也可能被下一次切换服务器或更新订阅覆盖。

自定义配置适合解决界面暂未覆盖的明确需求，不适合替代对基础链路的理解。开始前保存原始配置，确认所选内核接受相应语法，再用一个最小改动验证。出站标签必须与规则引用一致，端口不能与现有入口冲突，配置片段也不能脱离所依赖的数据与组件单独运行。启动失败时先回到最后可用配置，而不是继续叠加字段。

用小实验理解边界

下面是一个仅用于本机 SOCKS 入站与直连出站的基础配置示例，适合在独立测试环境理解入口和出口关系。它不连接远端代理服务器，不能用来代替已经导入的服务器配置。只有当示例端口未被占用，并且当前内核接受对应字段时才可使用；图形客户端用户仍应优先通过界面完成同等设置。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

这个实验先证明应用能否进入指定端口，再观察直连出口是否工作。它把远端认证与安全握手暂时移出测试范围，因此适合解释本地入口故障，却不能证明远端服务器可用。测试结束后恢复原配置，避免把临时直连环境误当成日常代理环境。理解示例的价值在于识别变量，而不是把所有示例复制进一个越来越大的配置文件。

按需求学习协议与传输

协议学习可从“必须一致的字段”开始：用户身份、传输方式、安全层以及可选扩展。随后再理解这些字段参与哪个阶段，最后才研究性能。REALITY 与 XTLS Vision 属于具体技术组合，能否使用取决于客户端内核与服务器配置，不能只改一个下拉框完成迁移。原理说明见REALITY 与 XTLS Vision 笔记。

比较传输方式时，应保持网络、服务器资源、测试目标和时间条件尽量一致。不同目标服务的响应差异，不能直接归因于协议名称。连接复用、UDP 处理和 DNS 策略也可能影响体验，应逐项验证。没有实际需求时保留兼容且稳定的设置，避免为追求某个理论优势同时更换多个环节，最终无法判断性能变化来自哪里。

把进阶结果变成可维护配置

完成一项进阶设置后，为它写下用途、前置条件、预期行为与恢复方法。例如新增应用分流，应记录匹配条件和默认出口；改变域名策略，应记录受影响的解析路径；启用 TUN，应记录局域网访问与网络切换的验证结果。记录应描述实际行为，不只保存界面截图，因为布局调整后，截图可能无法说明设置背后的逻辑。

最终回归测试应覆盖程序重启、订阅更新、网络切换、睡眠唤醒与正常退出，确认配置不依赖偶然保留的连接状态。若某项功能只在特定顺序下工作，应继续检查依赖，而不是把顺序当作永久解决方法。能够解释一次请求的入口、解析、规则匹配和出口，并能在故障时恢复基线，才是这条从入门到进阶路线的实际完成标准。

后续查阅可按问题定位章节：重新安装回第三章，服务器更新回第四章，应用未接入回第五章，目标分流异常回第六章，虚拟网卡问题回第七章。需要重新走一遍最短连接流程时，返回快速使用指南；需要替换平台或安装格式时，再到下载页选择对应客户端，保持下载、配置与诊断各自清晰分工。