v2rayN 配置手册从零到进阶

一、核心概念：先画出连接路径

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

先把图形界面与实际连接程序分开。v2rayN 负责保存服务器资料、管理订阅、选择路由及启动内核；内核负责监听本地端口、解析配置并建立连接。界面已经打开，不代表内核已经成功运行。遇到无法连接，第一步应看启动日志是否报错，而不是反复修改浏览器。配置语法错误、端口占用和组件缺失，都可能让界面正常显示、代理入口却没有建立。

Project V 是相关代理技术的生态背景，V2Fly 与 Xray 是其中需要区分的内核家族。协议支持、配置字段和功能实现会随内核变化，不能把名称相近理解为行为完全相同。图形客户端通常把界面选项转换成内核配置；普通用户不必先手写完整文件，但需要知道当前使用哪个内核。查阅说明时，应把客户端设置和内核参数分别核对，避免把另一套实现的字段直接粘贴进来。

服务器资料描述远端入口，包括地址、端口、认证信息、协议以及传输参数。客户端本身不提供这些资料，也不会因为安装完成就自动获得远端服务。分享链接通常携带一条连接所需的字段，订阅地址则用于获取和更新一组记录。两者都可能包含敏感信息。把订阅地址贴到公开讨论区，相当于公开访问入口；截图前也应遮挡认证标识与完整链接。

从应用到出站，按方向理解流量

一条典型路径是：应用先访问本机代理入口，内核根据路由规则选择出站，再连接远端服务器或直接访问目标。这里的“入站”指流量进入本机内核的方式，“出站”指内核向外建立连接的方式。直连也是一种出站，不是绕开所有处理。看到日志中的本地来源地址，不应把它误认为远端服务器地址；看到目标域名，也不代表域名已经通过预期的解析器得到结果。

系统代理只向遵循该设置的应用声明代理位置，TUN 则通过虚拟网络接口接管符合路由条件的流量。路由规则是在流量进入内核后决定走向，不能替代接管方式。一个应用完全不读取系统代理时，修改“绕过大陆”通常不能让它突然进入代理入口。排查时先回答“连接有没有进入内核”，再回答“进入后选择了哪个出站”，顺序颠倒容易得到误判。

协议、传输与加密不要混成一项

VMess、VLESS、Trojan 是连接协议层面的名称；TCP、WebSocket、gRPC 等描述传输方式；TLS 及相关安全设置又是另一层。导入一条资料后，要核对这些字段的组合，而不是只看协议名称相同就认为可以互换。例如服务端要求特定路径或服务名时，客户端缺少对应值，认证资料即使正确也可能失败。不要凭经验替换服务端给定的传输参数。

域名解析同样属于连接链路。应用可能先把域名解析为地址，也可能把域名交给代理端处理，具体取决于应用和代理协议。规则能否按域名匹配，与内核实际拿到什么信息有关。仅凭“网页打不开”无法判断是解析、认证还是路由故障。记录目标类型、应用使用方式和日志中的错误阶段，后续每一步才有明确检查对象。

二、客户端选型：按设备与内核选择

桌面设备先选 v2rayN

桌面场景首推 v2rayN。先确认操作系统，再确认处理器架构，最后选择对应安装形式。Windows 的桌面版采用跨平台界面，经典 WPF 版保留另一套桌面界面，两者不是不同的代理协议。首次使用可按下载页说明选择其中一种，已经有稳定配置时则不必为界面差异迁移。排错过程中同时安装并运行两套界面，反而可能造成监听端口与系统代理控制冲突。

macOS 需要区分 Apple Silicon 与 Intel，不能只凭电脑外观判断。可以在系统的“关于本机”查看芯片信息，再去对应入口下载。Linux 则同时核对发行版包管理方式和处理器架构，使用 deb 还是 rpm 取决于发行版，而不是个人偏好。架构不匹配与依赖缺失属于安装问题，尚未进入连接阶段，修改订阅或服务器参数通常不能解决。

选择客户端时，还要考虑应用是否只需要浏览器代理，是否需要接管不读取系统代理的程序，以及设备是否有安装虚拟网络接口所需的权限。先用最少功能满足当前需求，再逐步启用高级设置。不要把某个开关是否存在，直接等同于当前设备一定能够使用；操作系统权限、内核支持及网络环境都会影响最终行为。

安卓优先 v2rayNG，按需要选择 v2flyNG

Android 首选 v2rayNG，使用 Xray 内核；v2flyNG 使用 V2Fly 内核，适合明确需要该内核行为的场景。两者都应以实际支持的协议和传输组合为准，不能假设导入成功就一定能够建立连接。大多数较新的手机使用 arm64，但购买年份不是可靠的架构检测结果。不确定时查看设备信息与下载页说明，再决定选择架构包还是通用包。

移动端通过系统的 VPN 接口授权建立本地接管通道。首次启动连接时弹出系统确认窗口属于正常权限流程；如果设备已有其他占用该接口的服务，可能不能同时启用。应用显示已启动，只能说明本地服务进入了运行状态，不足以证明远端连接和目标访问均正常。后续仍需要通过日志、实际应用访问及分流结果完成验证。

迁移前先核对兼容边界

从一个客户端迁移到另一个客户端时，优先迁移订阅地址或标准分享链接，不直接复制整个程序目录。界面设置、路由模板与本地数据库格式未必通用。即使两个客户端都支持同一种协议，扩展参数的识别范围也可能不同。迁移后先选择一条已知可用记录，保持传输参数不变，完成基本访问，再补回自定义规则和应用分流。

还要检查订阅内容是否为通用分享链接集合，还是面向特定程序的完整配置。后者可能包含专有字段、脚本或模板，不能仅修改文件后缀就当成通用订阅。出现格式不支持时，先向资料提供方确认输出格式，而不是随意转换。选型的核心不是功能数量，而是现有连接资料、设备权限和维护方式能否形成稳定组合。

本章完成后，应能明确写出设备系统、处理器架构、客户端名称及使用内核。将这些信息保留在个人排错记录中，后续查阅文档就不会混用平台说明。需要进一步比较三款客户端的操作差异，可看横向评测；安装包入口仍统一使用下载中心，避免把介绍文章当作具体安装文件列表。

三、安装与初始化：先确认本地服务

按安装形式完成第一次启动

下载前核对系统与架构，安装后先保持默认配置启动。使用安装程序时，按界面提示选择目录和完成安装；如果实际取得的是压缩包，应先完整解压到可写的固定目录，再启动主程序。不要直接在压缩预览窗口运行，也不要只拖出一个可执行文件。内核、资源和配置可能位于相邻目录，缺少这些文件时，界面能够启动但后台组件可能无法工作。

程序目录应便于后续备份，避免位于临时下载缓存或经常自动清理的位置。若使用多个设备同步配置，不宜让文件同步工具同时改写正在运行的数据库。系统提示目录不可写时，先检查目录权限与安装位置，而不是关闭所有安全功能。普通启动阶段应使用普通用户权限，只有明确涉及虚拟网络接口或受保护操作时，再根据功能要求授权。

macOS 依据下载形式完成安装，并在系统隐私与安全设置中检查可信来源提示；Linux 使用对应发行版的软件安装方式，遇到依赖错误先阅读包管理器信息。不要把不同发行版的操作机械混用。首次打开后，确认窗口能正常关闭并重新启动，配置能够保存。这个检查可以提前发现只读目录、安装不完整或运行环境缺失，而不必等到订阅导入后才定位。

核对端口、内核和日志

在 v2rayN 的设置与运行日志中检查本地监听信息。常见配置会使用 SOCKS 端口 10808、HTTP 端口 10809，但不同发行版或已有配置可能改为其他端口，也可能使用混合入口。以当前界面和启动日志为准，不要仅按教程中的数字填写。远端服务器端口来自连接资料，与本机监听端口不是同一项，修改其中一个不会自动同步另一个。

如果日志提示地址已被使用，先检查是否有另一份客户端或同类本地服务正在运行。关闭重复实例后重新启动，或为当前实例设置不冲突的监听端口，并同步修改应用代理。不要只把错误提示隐藏。没有监听成功时，浏览器即使正确指向本机也无法连接；此时更换服务器没有意义，因为流量尚未离开本机代理入口。

保留最小初始配置

第一次配置时，先关闭 TUN、局域网共享及不必要的自定义路由，只保留本机入口和一条连接资料。这样遇到故障时，变量集中在内核启动、认证和远端可达性。等基本链路确认正常后，再逐项增加功能。若一开始就导入大量规则、更改 DNS、开启多个接管方式，即使访问失败，也很难判断是哪一层改变了实际路径。

Android 安装后先打开应用完成初始化，导入一条记录，再启动连接并确认系统授权。不要连续点击启动按钮来替代等待日志。若切换到其他应用后连接停止，可检查系统后台运行和电池管理设置，但只对确有需要的应用调整。后台限制、系统授权与远端认证分别属于不同层次，排查时应分别记录，而不是统称为“节点失效”。

初始化完成的标准是：配置能保存、内核能启动、本地入口没有端口冲突，且能找到日志位置。此时不要求所有应用都已经接入代理。建议记录当前监听地址、端口和默认路由名称，形成第一份基线。后续修改失败时，先退回这份基线；若连基线也不能启动，再检查程序文件和系统环境。常见启动错误可对照常见问题继续定位。

四、订阅导入：地址、更新与记录管理

先辨认输入内容，再选择导入入口

先判断拿到的是订阅地址、单条分享链接，还是完整配置。订阅地址通常是用于获取内容的网络地址；分享链接以相应协议前缀标识一条记录；完整配置则包含入站、出站或路由等结构。不要把三者都粘贴到同一个编辑框。复制时留意前后空格、换行和聊天软件附加的标点，尤其是较长链接被分成多行时，表面看起来完整，实际可能已经丢失字段。

在 v2rayN 中管理订阅时，进入“订阅分组”，新增分组并填写便于辨认的备注和订阅地址，保存后执行“更新全部订阅”或对应分组的更新操作。保存地址与拉取内容是两个步骤。刚保存后列表为空，不足以说明地址无效；应先看是否真正执行更新，再看日志是否成功取得内容。不同来源分开建组，有助于区分更新范围和保留策略。

单条分享链接可使用“从剪贴板导入分享链接”，桌面界面支持时也可使用 Ctrl+V。导入完成后，打开编辑窗口核对协议、地址、端口和传输方式。只看到记录名称出现，并不代表所有参数都被识别。对于带有额外传输选项的链接，尤其要检查安全设置、服务器名称、路径或服务名是否与原始资料一致，不要擅自把空值补成常见示例。

更新失败要区分获取与解析

订阅更新有两个主要阶段：先访问订阅地址，再解析返回内容。访问超时、证书错误和域名解析失败，属于获取阶段；地址能够访问却提示格式不支持，属于内容解析阶段。登录页面、过期提示或网页正文都不是有效订阅，即使服务器返回了成功状态也不能直接导入。日志若只显示简短错误，可以核对地址来源及有效期，不要将完整地址发送给不相关的人。

部分界面会区分直连更新与经代理更新。只有当前已经存在可用代理时，经代理更新才有意义。第一次安装尚无可用连接，却让订阅更新依赖该连接，会形成循环。应按资料提供方允许的访问方式获取内容，或先导入一条有效分享链接建立基础连接。切换更新方式后一次只重试一个分组，避免多次并发请求掩盖真正的错误原因。

订阅内的记录可能在更新后增删或改名，本地手动修改也可能被下一次刷新覆盖。重要的自定义记录应单独管理，并确认客户端是否提供保留或复制方式。不要靠修改订阅生成项来长期维护自己的参数。删除分组前也要确认是否同时删除组内记录；清空列表不是修复更新失败的必要步骤，先保存现有可用资料可以降低恢复成本。

导入后的验证与隐私边界

Android 的 v2rayNG 与 v2flyNG 同样遵循“管理订阅地址，再更新内容”的逻辑，具体入口以应用当前菜单为准。导入后选中一条记录，再启动连接并查看运行日志。列表排序、测速结果和当前选中状态是不同概念，不能认为排在第一条就一定会被使用。切换记录后，还要留意连接服务是否已经应用新设置，必要时按界面提供的方式重启连接。

验证时先使用一条来源明确、参数完整的记录，不一次性导入多个来源再凭名称猜测。连接失败应记录错误阶段，而不是公开认证内容。订阅地址可能附带访问令牌，分享链接可能包含身份标识，导出的配置还可能包含服务器认证字段。备份文件也需要按敏感资料处理，不能因为文件只是文本，就放进公开分享目录或未经审查的同步空间。

五、代理模式：确认应用如何进入内核

系统代理的三种操作不是三种路由

桌面端先用系统代理验证基本连接。v2rayN 的“自动配置系统代理”会把本机代理入口写入系统相关设置，供遵循该设置的应用使用；“清除系统代理”用于移除代理设置；“不改变系统代理”则保留现有系统设置，不主动改写。第三项不是自动恢复默认，也不是保证系统保持直连。切换之前若已经有其他程序配置代理，原有设置可能仍然存在。

系统代理与“全局”“绕过大陆”等路由选择属于两层设置。系统代理回答应用是否把流量送到本机入口，路由回答进入内核后怎样选择出站。把路由设为全局，不意味着所有应用都已被接管。遇到浏览器可用、另一个程序不可用，优先检查后者是否读取系统代理、是否有独立网络设置，暂时不要修改协议或重建整份订阅。

部分应用只在启动时读取系统代理，因此修改后需要完全退出并重新打开应用。已经建立的长连接也不一定立即改走新路径。验证切换效果时，应关闭相关连接或重启测试应用，再发起新请求。不要根据旧标签页仍然显示内容判断连接正常，因为页面可能来自缓存；也不要把一个仍存活的旧连接误认为新配置已经生效。

手动代理要核对协议与监听地址

如果应用提供独立代理设置，可以明确填写本机地址和实际监听端口。应用与客户端运行在同一台设备时，通常使用回环地址 127.0.0.1。HTTP 代理与 SOCKS 代理的协议类型必须对应入口，不能因为都填一个端口就认为两者等价。若当前内核提供混合入口，应以该入口的支持范围为准；若分别监听，则按协议填写各自端口。

应用中的“远端解析”或同类选项，会影响域名由本机还是代理链路处理。没有这个选项时，也不能推断解析一定发生在某一端。遇到只有域名访问失败、地址访问表现不同的情况，应记录应用协议与解析方式，再查 DNS。直接拿某个网站的地址代替域名测试也有边界：HTTPS 证书和虚拟主机可能依赖域名，失败并不自动证明网络不通。

连接验证与正常退出

验证时使用普通浏览器发起新请求，并查看同一时间的客户端日志。先确认有新连接进入，再检查是否出现认证、传输握手或目标连接错误。浏览器扩展、自定义代理插件和应用内设置可能覆盖系统代理，测试期间只保留一种明确的入口方式。若日志完全没有对应活动，通常应先查应用入口，而不是以远端服务器故障作为唯一解释。

退出客户端前，建议先清除由它设置的系统代理，再正常退出。异常结束后若系统仍指向已经停止的本机端口，遵循系统代理的应用就会持续连接失败。恢复时可以重新打开客户端清除设置，也可以在系统网络设置中检查代理地址。不要在不了解原有环境时清空企业代理等配置；使用前记录原值，才能在测试后恢复正确状态。

Android 通常不依靠桌面系统代理三选项工作，而是通过应用建立的 VPN 接口接管流量，应用分流与绕过设置也应在对应客户端中检查。完成本章后，应能说明测试应用采用系统代理、独立代理还是虚拟接口入口。如果这个答案仍不明确，先回到入口检查。只有入口清楚，下一章讨论的规则顺序与直连策略才有可验证的前提。

六、路由与 DNS：让规则和解析保持一致

先选内置方案，再增加例外

首次分流优先使用客户端已有的路由方案，再根据实际目标增加少量规则。“绕过大陆”通常表示相关域名或地址匹配到直连，其余连接按方案选择出站，但不同规则集和模板的实现不应视为完全一致。选择后查看规则说明及日志结果，确认本地服务、境内目标和其他目标的实际路径。界面显示方案名称，只说明选中了模板，不证明每个域名都已正确归类。

规则顺序非常重要。对采用顺序匹配的规则列表，前面的命中项会影响后面的机会，较具体的例外通常需要放在宽泛规则之前。添加规则时同时检查匹配条件和出站标签：域名写对但标签不存在，仍然不能工作；标签正确但规则被前面的广泛匹配覆盖，也不会得到预期结果。一次只新增一个目标，保存并应用后发起新连接，观察命中结果再扩大范围。

下面是 Xray 风格的路由片段，展示一个保留测试域名的完整匹配方式。它不是可以单独启动的完整文件，需要已有名为 direct 的出站。full: 表示精确域名，domain: 则用于该域及其子域的匹配范围。不要把示例域名当成真实服务清单，也不要在图形界面的分享链接导入框中粘贴路由对象。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

DNS 既影响可达性，也影响规则判断

DNS 配置先解决“谁来解析什么域名”。本地网络可达的解析器适合部分直连目标，另一部分目标可能需要通过指定路径访问解析服务。关键不只是填写服务器地址，还包括解析请求本身怎样到达该服务器。若解析器的访问必须依赖代理，而代理服务器地址又等待同一个解析器解析，就可能形成启动依赖循环。先保证服务器地址能够完成初始解析，再细分目标域名。

路由中的域名解析策略与 DNS 模块的查询策略不是同一参数。前者影响路由判断是否需要把域名解析成地址，后者影响查询地址类型等行为。下面的 DNS 片段仅展示按域名指定服务器与限制查询类型的语法，不是一套适合所有网络的推荐方案。使用前确认解析服务器可达，并检查完整配置中解析流量的出站路径，不能仅复制一段就推断解析已被接管。

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["full:example.com"]
      }
    ],
    "queryStrategy": "UseIPv4"
  }
}

IPv6 需要单独检查。应用可能优先使用 IPv6 地址，若代理或直连路径只验证过 IPv4，就会出现间歇失败或等待后才成功。应分别确认系统地址、解析结果、出站能力及规则范围，不能把禁用某一地址族当作永久通用修复。临时限制查询类型可以帮助定位，但记录原因后应重新评估，避免掩盖本来可以修复的网络或路由问题。

用明确目标验证规则

选择一个应该直连的目标和一个应该经代理的目标，分别发起新请求并核对日志。浏览器缓存、已有连接和系统 DNS 缓存可能保留旧结果，必要时重新打开应用或等待相关缓存失效。不要一次清除全部配置来验证一条规则。若只有某个子域异常，先检查精确匹配与后缀匹配范围，而不是把整个域名类别全部改走另一条路径。

抓取域名信息的嗅探功能有时能补充应用只提供地址的情况，但它不是所有协议的通用识别器，也不能保证恢复原始域名。涉及局域网服务时，还应保留本地解析与私有地址的可达性。规则越多，越需要记录来源、用途和优先级。更完整的字段解释可看DNS 分流解析说明，本章先以少量可验证规则建立基线。

七、TUN 模式：从应用代理到网络接管

先确认确实需要 TUN

当目标应用不读取系统代理，或希望按统一网络路径处理更多连接时，再考虑 TUN。它通过虚拟网络接口与系统路由接管流量，不是让远端服务器性能提高的加速开关。先保证普通本地代理模式可以正常访问，再启用 TUN，能够把故障范围限定在权限、接口、路由和解析这些新增环节。基础连接本来失败时，开启 TUN 通常只会增加排查变量。

v2rayN 中“启用 Tun”对应的实际实现可能与当前选择的核心组件及客户端配置有关，不能直接把 Xray 的普通入站片段当作通用 TUN 设置。先在界面核对相关组件是否可用，再按提示提供权限。系统要求授权时，应确认来自正在使用的客户端。启动失败先读日志中的接口创建、路由添加或权限错误，不要反复安装不相关的组件。

TUN 接管并不意味着每种协议都会自动成功。应用的 UDP 使用方式、服务器端支持、网络路径以及当前内核的转发能力，都可能影响结果。网页能打开而某类实时通信失败，应按该应用的实际协议继续检查，不直接套用浏览器测试结论。记录故障是否仅发生在 UDP、是否与特定目标有关，比仅描述“开了以后不能用”更有助于定位。

避免路由回环和解析依赖

启用前，先关闭其他会修改默认路由或占用虚拟接口的服务，记录原有网络状态。TUN 需要让代理进程访问远端服务器的连接仍能通过底层网络发出，否则可能把自身连接再次送回虚拟接口，造成回环。客户端通常会处理相应排除项，但复杂多网卡、企业网络或手动静态路由环境可能需要额外核对。不要在缺少日志依据时随意删除系统路由。

DNS 是另一处常见边界。TUN 可以接管网络流量，但系统、应用与内核可能各自维护解析缓存，部分应用还使用独立解析机制。应确认系统查询进入哪里、内核如何处理，以及解析服务器通过哪条出站访问。使用虚拟地址映射类功能时，更要保证对应地址范围由正确的接口承接；关闭后若残留旧解析结果，可能需要重新建立应用连接并等待缓存更新。

局域网访问也要单独验证。打印机、文件共享和本地管理页面往往使用私有地址或本地域名，若被宽泛规则错误接管，可能出现外部网站正常、内部服务失联。先检查私有网段和本地解析的处理，再决定是否增加排除项。局域网共享代理与 TUN 是两个不同需求，开启 TUN 不会自动把本机入口开放给其他设备，也不应为了修复本地访问直接开启共享。

按顺序做启用与回退测试

实际测试可以分为三个阶段：先验证浏览器新连接，再验证原本不读取系统代理的应用，最后验证局域网服务与休眠恢复。每个阶段观察同一时间的日志及应用行为。若系统代理与 TUN 同时启用，流量路径会更难辨认；初次测试可在确认不会破坏既有环境的前提下，暂时清除系统代理，只验证 TUN 路径，之后再决定日常组合。

出现全局断网时，先关闭 TUN 并正常退出客户端，再检查默认网络连接是否恢复。若仍异常，检查系统代理残留、虚拟接口与 DNS 设置，而不是继续叠加其他代理服务。休眠、网络切换和网卡重连可能改变底层接口，恢复后应重新验证。长期使用前至少完成一次从有线到无线或断开再连接的测试，确认不是只在首次启动时有效。

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

把可恢复状态保存下来

当连接、分流与应用接管都稳定后，先保存一份配置基线。记录客户端名称、使用内核、本地端口、路由方案、DNS 改动和 TUN 状态。导出功能与配置目录位置随安装形式不同，优先使用客户端提供的备份方式，并确认导出的内容包含哪些设置。只保存订阅地址不能恢复本地规则，只复制界面截图也不能恢复认证参数，两者都不能替代完整的恢复计划。

备份应在客户端完成保存后进行，必要时先正常退出，避免复制到正在写入的数据库。文件名称可注明用途与备份时间，但不要在文件名中放入订阅令牌。恢复测试也很重要：确认能够找到导入入口、理解覆盖范围，并知道旧配置如何保留。未经验证的备份只能说明文件存在，不能保证下一次重装后能够还原到相同行为。

订阅地址、分享链接和导出文件都应按敏感资料保管。提供排错信息时，保留错误类型与相关字段名称，遮挡身份标识、完整服务器认证信息和私人地址。日志中也可能带有访问目标及订阅请求内容，不能直接全部公开。需要让他人帮助判断格式时，可只提供经过处理的结构片段，并说明哪些值已经替换，而不是传播真实连接资料。

更新分层进行，不同时改变所有变量

客户端更新、内核更新、订阅更新与规则数据更新是不同操作。界面更新可能改变菜单和配置生成方式，内核更新可能改变字段支持，订阅更新则主要改变远端记录。稳定环境下应分别执行，更新前备份，更新后重复基本测试。若一次把所有内容都改掉，再出现错误就难以定位。不要为了追求更新频率，在没有恢复准备时替换仍在运行的程序文件。

更新客户端时先正常退出，确认后台进程不再占用文件，再按安装形式操作。使用多个安装目录时，注意实际启动的是哪一份，避免旧快捷方式继续打开旧配置。更新后的第一次启动先看日志，再验证系统代理、路由与 TUN，不能只看界面能否打开。若设置项发生迁移，应阅读界面说明并核对原有自定义值，不把默认值变化误认为远端故障。

规则资源同样有时效性。域名分类或地址集合调整后，原本的匹配结果可能变化；但出现单个目标异常时，不应立即把全部规则替换成未知来源。先确认命中的规则，再判断是分类变化、解析变化还是目标本身迁移。长期不再需要的例外规则应清理，并在删除前记录原因，避免规则越积越多、后续无人能够说明优先级。

按链路记录故障，而不是反复重装

排错记录至少包括发生时间、受影响应用、当前入口方式、选中记录、错误信息和最近一次改动。先判断是所有目标失败还是某个目标失败，是所有应用失败还是单个应用失败。全局故障优先检查内核启动、入口与基础网络；单目标故障则更多检查域名、路由和目标服务。通过范围缩小问题，比不断切换记录更容易得到可重复的结论。

日志级别只在必要时临时提高，完成定位后恢复日常级别，避免大量输出影响阅读并长期积累敏感访问记录。认证错误优先核对资料与系统时间，握手错误核对安全和传输参数，拒绝连接核对地址、端口及服务可达性。超时本身信息较少，需要结合失败发生在哪个阶段判断，不能仅凭一个词确定是服务端还是本地网络问题。

九、进阶路线：把配置变成可解释的实验

从阅读生成配置开始

进阶不等于立刻放弃图形界面。先观察客户端根据当前设置生成了哪些入站、出站和规则，理解界面与配置的对应关系。生成文件往往会被下一次应用设置覆盖，不适合直接当作长期编辑入口。需要自定义时，应使用客户端明确支持的配置方式，并确认它是补充字段、替换局部还是接管完整配置。不同模式的覆盖范围不同，不能只看编辑框都能输入文本就混用。

阅读配置可以按固定顺序进行：先看入站监听什么地址和端口，再看出站标签与协议，最后看路由怎样引用这些标签。接着检查 DNS、日志和其他辅助模块。先从一条真实连接的路径出发，不必一次理解所有字段。某个参数没有出现在文件中，可能使用内核默认行为，也可能由另一组件处理，不能简单推断为功能未开启。

下面是一个可用于理解结构的完整 Xray 最小配置，只提供本机 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": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

每次实验只提出一个问题

一个有效实验应有明确问题、单一改动和可观察结果。例如要确认某个域名是否命中直连，就固定客户端与连接资料，只调整一条域名规则，再观察新连接的出站选择。不要同时更换 DNS、开启嗅探和修改传输方式。实验失败后先恢复原值，确认基线仍然可用，再测试下一种解释。这样积累的是因果关系，而不是一份碰巧能运行的复杂配置。

学习顺序可以按规则匹配、域名解析、应用接管、局域网共享展开。每一项都先在单设备环境验证，再扩展到更多设备。比如允许局域网连接时，需要核对监听地址、防火墙和客户端所在网络，而不是只打开一个开关。其他设备应填写电脑在局域网中的地址，不能填写它们自己的回环地址；电脑地址变化后，也需要同步更新使用方设置。

局域网共享还涉及访问边界。只在可信网络开放必要端口，避免把没有认证保护的入口暴露到不受信任的网络。共享期间保留防火墙限制，并确认休眠、断网和地址变化后的行为。无需共享时关闭相关设置。完整操作可继续阅读允许局域网连接说明，先理解监听范围，再决定是否长期启用。

理解协议差异，保留回退能力

协议学习应围绕实际字段和故障阶段展开。VMess 与 VLESS 的认证、时间要求及安全组合存在差异，不能靠更换协议名称完成转换；传输、安全和服务端参数必须成套一致。先读懂现有资料，再研究另一种配置。需要快速建立概念时，可看VMess 与 VLESS 区别，随后回到实际客户端核对支持范围，不根据名称推断全部能力。

最终目标是一份能够解释、验证和恢复的配置：知道每条例外为什么存在，知道解析请求走哪里，知道应用如何进入内核，也知道关闭客户端后系统应恢复什么状态。遇到新需求时，先在现有基线上增加最少设置，验证后再保留。首次连接步骤仍可回看快速上手教程；需要重新选安装形式时回到下载中心，不必为解决单个问题重做所有阶段。