V2Ray 完整手册v2rayN 配置与维护

核心概念：客户端、内核与连接链路

图形界面与代理内核的分工

V2Ray 通常用于指代 Project V 相关代理技术与工具生态，并不等于某一个桌面程序。v2rayN 是图形客户端，负责保存服务器资料、组织订阅、生成运行配置和调用内核。内核负责监听本地端口、处理协议、匹配路由并建立出站连接。界面可以正常打开，并不代表内核已经成功运行；服务器列表存在，也不代表当前已选中可用服务器。

V2Fly 延续 V2Ray 相关开发，Xray 是同一生态中的另一条内核发展路线。两者在协议能力与配置细节上存在差异，不能仅凭名称相近就互换全部参数。v2rayNG 主要采用 Xray 内核，v2flyNG 使用 V2Fly 内核。遇到某个节点不能导入，先判断客户端和内核是否支持它使用的协议及传输组合，而不是反复修改连接地址。

从应用到服务器的实际路径

普通系统代理场景下，应用先读取系统代理设置，再把请求交给本机监听端口；内核接收请求后匹配路由，决定直接连接目标还是经过远端服务器。远端服务器随后访问目标服务并返回数据。这个过程至少涉及应用、本地监听、规则判断、远端连接四层。排错时逐层确认，才能区分应用没有使用代理、内核未启动、规则走错与服务器不可达。

节点是一组连接参数，常见字段包括服务器地址、端口、用户标识、协议、传输方式与安全设置。订阅则是用于批量取得这些参数的地址，可能同时附带分组信息或服务端说明。订阅地址本身不是本地代理地址，也不能填进浏览器的代理端口栏。客户端提供的是连接工具；实际连接仍需要经过授权、处于有效状态的服务器配置。

协议、传输与安全层

VMess、VLESS、Trojan 等名称描述的主要是代理协议；WebSocket、gRPC 等描述的是传输方式；TLS、REALITY 等涉及连接安全机制。一个节点可能同时包含这些层次，任何一层填错都可能导致失败。服务器地址与 TLS 使用的服务器名称也不一定相同，路径和服务名通常需要精确匹配。应按配置提供方给出的字段导入，不要把不同示例中的参数拼成一条节点。

DNS 是把域名解析为地址的过程，可能由系统、应用、客户端或远端侧完成。解析位置会影响连接结果，尤其是基于地址的规则判断。域名能够解析，只说明拿到了地址；端口能够连接，也只说明传输链路建立到某个阶段。浏览器最终能否取得内容，还取决于握手参数、证书、目标服务和应用自身设置，不能用单项测试代替完整访问。

开始配置前，先画一条自己的链路：哪个应用发起请求，使用什么入口，命中什么规则，选择哪个服务器。记录这四项即可，不需要一开始就阅读全部内核选项。后文每章都围绕这条链路增加一层能力。遇到陌生术语时，先判断它属于入口、规则还是出站，再决定应该在哪一处修改，能够减少同时改动多个位置造成的混乱。

选择客户端：平台、架构与界面版本

桌面优先选择 v2rayN

桌面设备优先选择 v2rayN，再根据操作系统、处理器架构与发行形式选择安装入口。跨平台桌面界面适用于 Windows、macOS 与 Linux；WPF 界面面向 Windows。两种界面都围绕服务器、订阅与路由管理展开，但入口位置、窗口布局与运行依赖可能不同。不要为了与某张旧截图完全一致而更换整个安装方案，先找功能名称和设置用途。

Windows 用户在桌面版与经典 WPF 版之间选择时，可以先考虑现有使用习惯。准备跨设备保持接近的操作方式，可优先尝试桌面版；已有稳定的 WPF 工作目录和配置，则先备份，再评估迁移。两者不要共用同一个可写配置目录，也不要同时接管系统代理。界面差异可继续阅读桌面版与 WPF 版区别。

处理器架构与安装格式

架构描述程序面向哪类处理器，不是网络模式。macOS 可在“关于本机”查看芯片信息，再选择对应安装入口；Linux 可使用下方命令查看机器架构，常见的 x86_64 对应 x64，aarch64 对应 arm64。发行版包管理格式也要匹配，不能把用于一种发行版的软件包直接视为另一种格式使用。安装失败时先检查这些基础条件，再处理运行日志。

uname -m
cat /etc/os-release

Android 通常优先选择 v2rayNG。较新的主流设备多使用 arm64，但仍应以设备实际支持的应用架构为准；无法确认或遇到架构不匹配提示时，可查看通用版入口。v2flyNG 更适合需要 V2Fly 内核或希望核对兼容性的场景。替换客户端不应成为第一项排错动作，先确认订阅有效、协议受支持，以及设备时间和网络条件正常。

迁移前的配置边界

不同客户端的界面备份并不保证能够直接互相导入。标准节点分享链接通常比整目录复制更便于迁移，但仍取决于双方支持的协议字段。订阅分组、路由规则、快捷键和界面偏好可能属于客户端私有配置，应分开记录。准备切换时保留原客户端，先关闭其代理接管，再在新客户端验证一个节点；确认基本链路正常以后，再迁移复杂规则。

安装入口统一见客户端下载页。选择顺序应是系统、架构、界面形式，最后才是个人偏好。若设备受单位管理、缺少管理员权限或不能安装虚拟网卡，还应提前评估是否只使用应用代理。能够运行普通代理并不意味着一定具备启用 TUN 的权限；把权限限制看作部署条件，比反复更换安装包更容易找到适合的方案。

安装配置：工作目录与首次运行

建立可维护的安装位置

先从下载页选对安装入口。安装器按提示选择位置；压缩包则先完整解压，再从解压目录运行程序。不要直接在压缩软件的预览窗口中启动，因为临时解压目录可能缺少内核、资源或写入权限。工作目录应便于识别和备份，避免混入多个不同构建的文件。采用便携运行方式时，还要确认配置实际保存位置，不能假设所有数据都在可执行文件旁边。

Windows 首次运行 v2rayN 时，若提示缺少运行组件，应依据提示安装对应架构的运行环境，然后重新启动客户端。不要通过随意复制系统库文件解决依赖问题。若程序立即退出，先查看客户端目录中的日志或系统事件信息，区分缺少依赖、权限不足与安全软件拦截。具体安装顺序可对照Windows 安装与首次运行排查。

确认内核与监听状态

启动界面后，先查看日志区域是否出现启动失败、文件不存在或端口绑定失败。存在节点并启用服务后，才有条件检查内核是否真正监听。常见本地入口是回环地址配合监听端口，端口值以当前参数设置为准。旧教程中的端口只能作为理解示例，不应直接覆盖当前配置；不同构建也可能采用合并入口，而不是各自单独的两种端口。

在 设置 → 参数设置 → Core 基础设置 附近核对本地监听相关选项。SOCKS 与 HTTP 入口服务的应用类型不同；应用填写代理时，要让协议、地址和端口对应。首次配置保持回环监听，只有确实需要为其他设备提供服务时，才考虑局域网监听。开放局域网会扩大可访问范围，需要同时安排访问限制、防火墙与设备信任边界。

netstat -ano | findstr :10808

上方是 Windows 查看示例端口占用的命令，实际检查时将端口数字替换为参数设置中的值。输出末列可用于定位进程，只有确认归属后才决定关闭或调整。不要看到占用就直接终止陌生系统进程。若是另一个代理程序占用，先退出重复实例；若端口被正常应用使用，可以修改监听端口，再同步调整手动填写代理的应用。详细方法见本地端口冲突处理。

其他桌面与移动设备

macOS 安装后按系统提示完成打开授权，先核对安装来源与应用身份，不要用全局关闭系统防护代替单个应用授权。Linux 使用发行版对应的包管理工具安装，出现依赖提示时先阅读缺少的组件。桌面环境、图形显示后端与托盘支持可能影响界面行为；关闭窗口未必退出进程，判断后台是否仍在运行，应结合托盘与进程列表。

Android 安装客户端后，首次启动连接通常会出现系统 VPN 授权提示，这是建立流量入口所需的系统许可。先导入有效配置，再确认提示对应当前应用。首次验证阶段关闭其他会接管网络的工具，避免两个入口互相覆盖。此时的完成标准不是“程序已打开”，而是能够找到配置位置、看懂启动日志，并明确当前服务是否运行，为下一章导入订阅做好准备。

订阅管理：导入、更新与分组

先建立分组，再更新服务器

订阅地址通常带有个人访问标识，应按凭据管理。只从经过授权的配置提供方取得地址，不要把完整链接发到公开评论、截图或在线转换页面。地址看起来能够在浏览器打开，并不能证明返回内容适合当前客户端；它可能返回账户页面、错误信息或其他格式。导入前应确认地址完整，没有混入说明文字、换行或聊天软件附加的标点。

v2rayN 中先进入 订阅分组 → 订阅分组设置，新增一组并填写便于识别的备注，再粘贴订阅地址。保存后选择更新相应分组，或者使用更新全部订阅的操作。不同构建可能把分组操作放在菜单或列表工具区，重点是先保存地址再执行更新。只粘贴地址而没有更新，服务器列表通常不会立即出现；只新增备注也不会产生节点。

更新结束后查看日志，再核对列表所属分组。返回成功但列表为空，可能是内容格式不支持、地址返回了错误页，也可能是当前过滤条件隐藏了全部服务器。先清除搜索与过滤，再切换到对应分组确认，不要马上删除原有配置。若同一地址在另一设备正常，比较两端客户端能力和更新时间，有助于判断是兼容性差异还是网络获取失败。

节点更新与手动修改的关系

订阅提供方可能调整服务器地址、备注与参数，下一次更新会依据客户端规则重建或替换部分条目。直接修改订阅节点不一定能长期保留。需要试验时，可先复制为独立的手动节点并注明用途，再修改一项参数；不要在批量更新后凭旧备注判断它仍是同一条配置。测试结束后清理临时副本，避免日后选中已经过期的参数。

多个订阅应按来源或用途分别建立分组，而不是全部塞入一组再依赖备注猜测。过滤关键词只用于缩小视图，不代表删除节点，也不等于修改路由。筛选后设置活动服务器，要确认它属于预期分组；更新后若活动条目发生变化，应重新核对。进一步的整理方法见订阅分组与服务器过滤。

更新失败的分支判断

更新失败先看获取阶段是否发生错误。连接超时说明获取地址的链路存在问题；返回内容无法解析，则要检查响应是否真的是订阅数据。若客户端提供直连更新与经代理更新两种方式，应根据当前链路选择。尚未建立有效代理时强制经代理更新，容易形成“需要更新才能连接，又需要连接才能更新”的循环，可先用仍有效的配置验证获取路径。

不要将反复点击更新当作修复方法。先确认订阅账户与地址状态，再核对网络、系统时间和错误日志；服务端暂时不可用时，保留现有有效条目通常比删除重建更稳妥。日志对外分享前应遮盖完整地址、用户标识和服务器信息。逐项自查可参考订阅更新失败与解析为空清单，处理后只重试一次，并记录错误是否发生变化。

这一阶段的完成标准是：至少一个分组能够更新，能够找到其中一条配置，并明确怎样设置为活动服务器。订阅更新成功和节点连接成功是两件事。前者说明配置获取完成，后者还取决于服务器、协议及入口设置。只有分清这两个结果，后面检查系统代理时，才不会把获取问题与实际访问问题混在一起。

代理模式：系统入口与连接验证

系统代理不是全设备接管

选好活动服务器并确认内核启动后，再设置系统代理。v2rayN 中可从主界面或托盘的系统代理相关菜单选择自动配置系统代理；入口文字以当前界面为准。这一步把本地代理地址写入系统设置，愿意遵循这些设置的应用才会使用它。部分程序自带网络栈，或在自身设置中固定了代理方式，即使系统代理开启，也可能继续直接连接。

清除系统代理通常只恢复系统入口，并不一定停止内核监听。此时手动指向本地端口的应用仍可能经过客户端。相反，直接退出客户端也不保证所有环境都会自动清理之前写入的设置。因此判断状态要分别看系统代理、内核运行与应用设置，不能只看托盘图标。准备退出时先清除系统代理，再正常退出，可减少应用继续连接失效本地端口的情况。

应用手动代理与端口对应

应用支持手动代理时，主机一般填写 127.0.0.1，端口填写客户端当前监听值，并选择对应的 HTTP 或 SOCKS 类型。这里的回环地址指向本机，不是远端节点服务器。把远端节点端口直接填入普通应用的代理栏，通常不会得到可用连接，因为应用并不会替代客户端实现节点协议和认证。需要共享到其他设备时，回环地址也不能继续照搬。

首次验证选择一个能够明确复现的访问目标，先在关闭代理时记录结果，再启用系统代理重试。应用可能保留连接池与旧页面缓存，必要时完全退出后重新启动。查看客户端是否出现对应连接记录，并核对出站方向。若客户端没有收到请求，应先检查应用入口，而不是更换远端服务器；收到请求但失败，才继续沿路由与出站链路判断。

区分测试结果与实际体验

列表中的延迟测试、连接测试和实际网页访问，可能采用不同目标、不同协议与不同计时方式。单次测试数值不能代表所有站点的速度，也不能证明视频、下载或实时应用必然正常。测试失败同样需要看具体原因：目标测试服务不可达与节点无法连接不是同一问题。保留同一设备、同一目标与同一模式再比较，结果才有参考意义。

浏览器正常而另一个应用失败时，先查看后者是否支持系统代理、是否开启独立代理、是否保留旧环境变量。开发工具、终端与桌面程序的设置往往互不相通。排查时不要一次给所有应用加代理，否则无法确定是哪种入口起作用。先让一个应用在显式配置下工作，再逐步恢复其他应用原本的设置，能够更快定位覆盖关系。

如果启用系统代理后所有遵循设置的应用都无法访问，先检查本地端口是否仍在监听，活动服务器是否被删除，以及内核日志是否出现错误。临时清除系统代理，确认普通网络可以恢复，是区分本地入口问题与基础网络问题的重要步骤。更多短问题可到常见问题查阅；完成本章后，应能够说明某个请求究竟有没有进入客户端。

路由分流：匹配顺序与 DNS 条件

先使用预设，再增加例外

路由对已经进入内核的请求进行分类，再选择直接连接、代理或阻断等处理方式。v2rayN 可在路由设置中选择预设，例如 绕过大陆（Whitelist）。这类模式通常根据域名和地址规则安排直连与代理，但具体覆盖范围取决于实际规则内容及数据文件。名称只是用途提示，不能据此推断某个域名一定命中哪条规则。

第一次使用保留一个符合用途的预设，先验证常用应用，再添加少量明确的例外。若直接切换为全部代理进行对照后目标能够访问，可以怀疑原规则选择了不同出口，但仍需结合日志确认。不要把这种对照结果直接理解成“全部代理永远更合适”，因为本地服务、局域网地址与部分账户服务可能需要继续直接连接。

顺序、范围与兜底行为

常见规则按顺序检查，先命中的有效规则决定处理结果；实际细节应以内核和客户端生成配置为准。具体域名例外应放在覆盖面更大的分类规则之前，否则可能始终轮不到它。添加规则时至少记录匹配条件、目标出口、插入位置和预期结果。只保存一个域名却没有选择正确出口，或者把例外放在已经覆盖它的规则后面，都容易造成“规则没有生效”的误判。

精确域名与域名后缀不是同一种范围。只想处理单一主机时，避免误用覆盖整个域的写法；网站还可能依赖登录、图片和接口等其他域名，主页面正常不代表依赖请求全部正常。应根据失败请求补充必要条件，而不是把大量无关域名加入例外。若无法确定客户端输入框采用哪种语法，先查该字段说明，不要把内核原始字段直接粘到任意界面。

{
  "type": "field",
  "domain": ["full:example.com", "domain:example.org"],
  "outboundTag": "direct"
}

上方是 Xray 路由规则对象示例，不是完整运行配置。它演示精确域名、域名后缀和出站标签的关系；只有放进完整配置的规则数组，并存在名为 direct 的出站时才有对应作用。示例域名用于说明格式。通过图形客户端维护配置时，优先使用路由编辑入口，不要直接改写自动生成文件，否则下一次启动或切换节点可能覆盖手工修改。

DNS 与地址规则的关系

基于域名的规则需要内核看到域名信息，基于地址的规则则依赖实际取得的地址。应用若先自行解析并只提交地址，域名规则可能缺少匹配条件；内核也可能按配置执行额外解析。嗅探可以在部分协议中辅助取得域名线索，但并非所有流量都能恢复，且需要考虑兼容性。不要将启用嗅探当作修复全部分流问题的统一开关。

排查分流时，固定一个目标与一个活动服务器，记录原模式，再临时添加一条范围最小的例外。比较连接日志中的目标与出站方向，必要时清理应用缓存并重新建立连接。已有长连接不会因为规则保存而必然立即重建。测试完成后删除无效例外，避免规则越积越多。稳定的规则集合应当能解释每一条为何存在，而不是依赖不断追加来维持偶然可用。

TUN 模式：接管范围与恢复顺序

普通代理可用后再启用

TUN 通过虚拟网络接口与相关路由设置，把符合条件的流量引入客户端处理。它适合不能使用普通系统代理的应用，但不意味着所有协议、所有网卡与所有网络环境都必然兼容。先完成普通代理验证，再尝试 TUN，才能在失败时明确问题属于接管阶段。节点本身无法连接时启用 TUN，通常只会增加需要排查的层次，不会修复错误的出站参数。

v2rayN 中找到 TUN 模式开关及相关设置，核对当前构建需要的权限和组件。启用过程中可能要求提升权限，以创建接口或调整系统路由。只对来源明确的客户端授予必要权限。企业管理设备、受限账户或特殊桌面环境可能禁止这些操作，应遵循设备管理策略，不要通过修改全局安全配置强行绕过限制。

入口叠加与路由冲突

首次启用时保持其他条件不变，只增加 TUN 这一项。系统代理是否需要保留，应按当前客户端的实现与说明判断；两种入口叠加可能改变请求路径，不能一边随意开关一边判断结果。还应暂时退出其他 VPN、虚拟网卡工具或会接管路由的软件。多个工具同时修改默认路由时，流量归属与恢复顺序都可能变得难以解释。

局域网访问是启用后应立即检查的项目，包括路由器管理页、打印机、文件共享和本地开发服务。若这些目标失效，要核对私有地址、回环与本地网段的绕行设置，不要把全部本地地址送往远端。多网卡、热点共享和虚拟机网络也需要单独验证，因为它们可能使用不同的网段。正确的接管范围应来自实际拓扑，而不是照抄他人的网络排除列表。

DNS、UDP 与应用行为

TUN 场景下 DNS 请求可能经过不同路径。应用使用自己的加密解析、系统保留缓存，或某条查询绕开预期入口，都可能使结果与普通代理不同。应先确认域名能否解析、解析请求走向哪里，再判断连接是否被规则送往预期出口。不要同时修改 DNS 上游、路由模式与 TUN 协议栈；每次只改变一个条件，才有办法回到已知正常状态。

部分实时应用和协议使用 UDP，是否能够正常工作还取决于本地接管方式、内核能力、节点配置以及远端服务。浏览器页面可访问，并不能证明这条链路上的 UDP 同样可用。应使用出现问题的应用进行针对性验证，查看是否有对应连接和错误。若只有某类应用异常，先比较它的传输与 DNS 特征，不要直接认定整个 TUN 功能失效。

若关闭开关后仍异常，正常退出客户端，检查系统是否还保留虚拟接口、旧代理或其他工具的连接。优先使用客户端提供的恢复操作，必要时重启系统，不要随意删除无法识别的网卡与路由。基础网络恢复后，先验证普通代理，再单独启用 TUN。记录首次异常发生在创建接口、DNS 查询还是目标连接阶段，能显著缩小下一次检查范围。

完成本章应同时满足三项条件：需要接管的应用可用、本地网络服务仍可访问、关闭模式后网络能够恢复。只有前两项正常而退出后无法恢复，仍不适合作为日常默认配置。把 TUN 当作有明确用途的入口方案，而不是所有设备必须打开的开关，更容易维持可解释、可回退的网络环境。

日常维护：备份、更新与故障记录

把配置备份与更新分开

稳定运行后，先确认客户端配置保存位置，再安排备份。备份应包含需要保留的订阅分组、手动节点、路由与个性化设置，是否能够直接复制目录取决于当前安装方式。复制前先退出客户端，避免数据库或配置文件仍在写入。订阅地址与用户标识属于敏感数据，备份文件也要限制访问，不要默认同步到所有共享设备或公开空间。

更新客户端、更新内核、更新订阅和更新规则数据是不同操作。客户端更新可能改变界面与配置格式；内核更新可能改变协议行为；订阅更新修改服务器参数；规则数据更新则影响分类判断。出现异常时，需要知道最近发生的是哪一种变化。不要在同一次维护中同时更换客户端、内核、节点与规则，否则很难确定引起结果变化的因素。

更新前后的对照流程

更新前记录当前安装方式、活动服务器、代理入口与路由模式，保留可恢复的配置备份。正常退出客户端后再更新，避免后台内核占用文件。更新完成先用原有简单配置验证，不要立刻导入新的复杂规则。若客户端提示配置迁移，应先阅读提示；较新的配置结构未必能由旧构建读取，因此回退程序时还需要配套恢复之前的配置副本。

自动启动与自动连接也应在基础链路稳定后再设置。开机时网络可能尚未准备好，订阅更新或连接失败不一定表示节点失效。先查看网络就绪后的手动重试结果，再评估启动顺序。Android 设备若后台连接频繁中断，可检查系统对客户端的电池优化与后台运行限制，只调整必要范围，不要为了单个应用关闭所有设备管理功能。

日志按阶段阅读

日志检查先找最早出现的相关错误，而不是只盯最后一行。启动阶段的端口绑定失败，会让之后的应用请求全部失败；订阅获取错误则未必影响已经存在的节点。连接超时、名称解析失败、认证或握手失败，应分别回到网络、DNS 与参数层面判断。错误文字相同也可能发生在不同目标，阅读时需要结合时间、目标地址和操作步骤。

操作：更新指定订阅分组
入口：普通系统代理，TUN 已关闭
现象：更新失败，已有节点仍可连接
对照：清除系统代理后再次更新
记录：保留相关时间段错误，移除敏感地址

上方记录格式不包含真实凭据，适合整理自己的排查过程。分享时应隐藏完整订阅地址、服务器域名或地址、用户标识与个人目录名称；若日志包含请求目标，也要按实际需要做脱敏。不要只发一张裁掉上下文的错误截图。说明客户端类型、操作系统、操作顺序及最后一次正常状态，比大量重复截图更有帮助，也更便于复现问题。

退出与恢复的例行检查

日常退出先关闭不再需要的 TUN，再清除系统代理，最后正常退出客户端。若应用手动填写了本地代理，也需要同步恢复，否则系统设置已经清除，应用仍会继续连接本机端口。切换网络后遇到异常，先确认基础网络和认证页面已经可用；公共网络的登录步骤尚未完成时，代理软件无法替代网络本身的接入要求。

维护的目标是保留一个已知可用基线：一个可用服务器、一种清楚的入口、一套能够解释的路由和一份可恢复备份。遇到问题先回到这条基线，再逐项恢复额外功能。定期清理临时节点、过期例外和重复分组，能够减少误选与规则冲突。若问题已能归入固定类型，可到常见问题按现象核对，避免每次都从重新安装开始。

进阶路线：配置理解与单变量验证

先明确要解决的问题

进阶不等于打开所有高级开关，而是能解释一次请求如何经过配置。先写下具体需求，例如某个开发工具需要独立代理、某个域名必须直连，或某个应用需要 TUN 接管。明确目标以后，再选择最小范围的设置。若普通系统代理已经满足用途，就没有必要仅因菜单中存在相关选项而启用虚拟网卡、自定义 DNS 与复杂的多出口规则。

建议学习顺序是读取当前设置、理解生成配置、验证单条规则，最后再研究自定义配置。客户端通常会根据节点、路由与全局参数生成内核配置，因此原始文件并不是所有设置的唯一来源。先找到某个图形选项对应的字段，观察保存前后的变化，再确认其作用范围。直接整份替换运行文件，可能使界面状态与实际配置脱节，也不利于后续维护。

认识入站、出站与标签引用

原始配置中的入站负责接收流量，出站负责建立后续连接，路由负责把符合条件的请求分配给出站。标签用于在这些部分之间引用对象，名称本身没有固定魔法含义。引用了不存在的出站标签，或重复使用容易混淆的标签，会让配置失去预期行为。阅读示例时应同时找定义与引用，不要只复制某一段看起来相关的规则。

下面是可独立阅读的 Xray 最小配置示例：在本机建立一个 SOCKS 入口，再将收到的请求直接连接目标。它不包含远端代理节点，也不能替代订阅。端口必须空闲，并且不应与正在运行的客户端入口冲突。示例用于观察字段关系，日常配置仍优先通过图形客户端管理；测试结束后停止测试实例，避免后台留下重复监听。

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

建立单变量测试方法

测试时固定应用、目标与网络条件，每次只改一个选项，并记录原值。假设要验证某条域名规则，就不要同时更换服务器和 DNS；假设要判断 TUN 是否影响本地服务，就先保持路由不变，只切换入口。结果不符合预期时先恢复原值，再设计下一次对照。这种方法看似慢，却能避免多项改动相互抵消，最后无法知道哪一项真正起作用。

复杂需求应拆成可以独立验收的小任务。先让应用显式使用本地代理，再加入目标域名例外，最后观察切换网络后的行为。每一步都要有成功条件和回退方式。对连接池、DNS 缓存与长连接造成的延迟变化，应通过重启应用或重新建立连接进行对照，而不是不断重复保存设置。保留一份简单测试配置，比维护大量未经解释的规则更有价值。

停止扩展与返回基线

当问题涉及服务器端协议参数、账户状态或远端服务限制时，客户端侧能做的主要是提供准确现象与日志。不要为了掩盖远端错误而无限添加本地规则。向配置提供方反馈时，说明协议类型、失败阶段和已完成的对照，并去除个人凭据。对尚未确认支持的特性，先核对客户端与内核能力，不要通过名称相近推断兼容。

完成这条路线后，应能够从入口、规则、出站三个方向解释问题，知道哪些设置属于客户端、哪些属于内核、哪些必须由服务器配合。需要重新走连接步骤时返回快速上手教程；需要更换安装形式时查阅客户端选型指南与下载页。长期保留简单可用的基线，按真实需求逐项扩展，就是这份手册的最终使用方式。