V2Ray 配置文件参考大全

JSON 结构总览与配置边界

先区分配置来源，再修改字段

V2Ray 配置不是一张节点信息表，而是一份描述流量如何进入、如何匹配规则、如何离开进程的运行说明。顶层对象通常包含 log、inbounds、outbounds、routing、dns 与 policy。它们并非每项都必须出现，省略后的行为由内核默认值决定。查阅某个字段前，先确认正在运行的是 Xray 还是 V2Fly，以及客户端是否会在启动时重新生成配置；否则修改的文件可能根本不是实际加载的那一份。

桌面用户通常从 v2rayN 开始：导入订阅后，在界面选择服务器、系统代理和路由模式，由客户端转换成内核配置。此时，订阅保存的是连接资料，界面保存的是用户偏好，运行目录里的 JSON 则可能只是生成结果。三者职责不同。需要检查故障时可以阅读生成结果，但长期修改应回到界面支持的设置或自定义配置入口。不要把一次临时编辑当成已保存的客户端设置，也不要在不了解覆盖行为时反复修改同一文件。

一份能启动的本地直连基线

下面是一份完整的基础配置：在本机回环地址提供 SOCKS 入站，收到的连接交给 freedom 出站，日志使用警告级别。它不连接任何远端代理，适合验证内核能否启动、本地端口是否可用，以及测试程序是否确实使用了该入站。端口只是示例，若已被客户端占用，应先停止冲突进程或选择其他空闲端口。直连基线可用，只说明本地链路成立，不能据此推断远端配置正确。

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

标准 JSON 要求属性名和字符串使用双引号，对象与数组的最后一个成员后不能留逗号，布尔值写成 true 或 false，数字端口不必加引号。部分内核工具能够读取带注释的扩展格式，但编辑器、客户端导入器或其他处理环节未必接受。为便于复制和定位问题，本文统一使用标准 JSON，不在代码内部插入注释。说明文字放在代码外，既减少解析差异，也便于逐段替换。

对象、数组与标签的协作方式

inbounds 和 outbounds 都是数组，因为一个进程可以监听多个入口，也能维护多种出口；每个数组成员则是一个对象。tag 是配置内部的引用名称，不是协议名称，也不会自动创建对应功能。把出站命名为 proxy，并不意味着它已经拥有远端地址。路由里的 outboundTag 必须能对应到某个实际出站，名称的大小写和拼写都应保持一致，建议使用简短、固定、含义明确的标签。

维护配置时，把改动拆成可验证的小步：先保存可启动的基线，再添加一个出站，随后增加一条路由，最后调整 DNS 或策略。每次修改都记录影响的字段、预期结果与恢复方式。数组成员的顺序可能影响默认出口和路由匹配，不能为了排版随意排序。若当前目标只是正常使用客户端，优先沿用界面生成的配置；只有确实需要特殊行为时，才进入手工维护流程，避免同时承担界面状态和内核文件两套配置的复杂度。

inbounds：本地监听与流量入口

listen、port 与 protocol 分别决定什么

入站负责接收应用程序交给内核的连接。listen 决定绑定的本地地址，port 决定监听端口，protocol 决定该端口理解的请求格式。三者缺一不可：应用连接到正确端口，却使用了错误协议，同样无法建立有效请求。SOCKS 入口不能直接作为普通 HTTP 代理地址填写，反过来也一样。排查时应把客户端显示的监听协议与应用代理类型逐项对照，而不是只检查端口数字是否一致。

仅供本机应用使用时，通常监听 127.0.0.1。这个地址只接受本机回环连接，不等同于局域网地址，也不会自动覆盖 IPv6 回环地址。监听 0.0.0.0 通常意味着绑定所有 IPv4 网卡，其他设备是否能够访问还受防火墙和网络隔离影响。扩大监听范围前，应明确哪些设备需要使用、采用何种认证，以及退出客户端后是否仍存在其他监听进程。允许局域网访问是访问边界的改变，不是单纯的连接优化。

SOCKS 与 HTTP 双入口片段

下面的片段展示两个独立入口，各自绑定不同端口，再通过标签供后续路由引用。SOCKS 中的 udp 表示允许该入站处理 SOCKS UDP 请求，但应用仍需实际使用相应机制，出站及网络路径也必须支持 UDP。HTTP 入站主要面向使用 HTTP 代理机制的应用，不能因为配置了两个入口，就认定所有程序、所有传输都会自动被接管。将本片段用于第一章基线时，应替换整个 inbounds 数组，而非再添加一个同名顶层字段。

{
  "inbounds": [
    {
      "tag": "socks-local",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "http-local",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

同一地址和端口通常不能由两个普通监听实例同时占用。出现绑定失败时，先检查是否重复启动了客户端，是否还运行着测试用内核，以及旧进程是否正常退出。不要只改应用端口而忘记修改入站，也不要只改入站却继续沿用系统里旧的代理端口。对于桌面 v2rayN，界面的本地监听端口可能与其他入口存在关联设置，实际结果应以运行配置和日志为准，不能把某个示例端口视为所有安装环境的固定标准。

嗅探与原始目标的关系

入站还可以包含 sniffing，用来从部分协议的初始数据中识别域名等信息，辅助域名路由判断。它不是解密工具，不保证识别所有连接，也不能替代正确的 DNS 配置。某些连接只携带 IP，某些协议的目标信息不可见，规则能够获得的输入因此不同。需要让识别结果仅服务于路由，而不改写实际目标时，应核对当前内核对相关选项的支持与语义，不要把不同内核的高级嗅探字段机械互抄。

判断入站是否工作，可以先在一个明确支持手工代理的应用中设置地址和协议，发起一次独立请求，再看日志是否出现对应入口标签。若完全没有记录，应检查应用是否绕过代理、是否使用另一套网络设置，或日志级别是否足以展示连接信息。系统代理只是一种把设置提供给应用的方式，不等于强制转发。有关接管范围的基础操作可回到使用指南，涉及无法连接的现象则可参照疑难解答逐项确认。

outbounds：协议出口与远端参数

先建立出口，再让规则引用它

出站描述内核如何把已接收的流量送往目标。freedom 表示直接连接目标，blackhole 用于丢弃或拒绝流量，远端代理协议则要求额外的服务器与账户参数。出站存在于数组中，并不意味着它一定会被使用；是否选中取决于路由结果及默认行为。常见运行方式下，没有规则命中的连接会使用第一个出站，因此调整数组顺序可能改变整体流向。维护时应明确记录默认出口，不要依赖标签的字面含义推断行为。

下面的片段只有直连和阻断两个出口，适合与基础入站合并，用于练习路由引用。它没有远端服务器，不应被描述为远端连接方案。settings 是协议专属对象，不同协议接受的字段不同；顶层共同字段相似，并不表示内部参数可以互换。将远端协议对象改成 freedom 时，应同时清理原协议的参数，避免遗留字段使阅读和排查变得混乱，也避免误以为内核会继续使用那些账户资料。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

连接资料、传输与安全层不能混为一谈

远端出站通常包含三类信息：服务器地址和端口、协议身份参数，以及传输与安全设置。VMess、VLESS 和 Trojan 的身份参数结构并不相同；TCP、WebSocket 等传输配置也不能只靠改一个名称完成切换。TLS 又位于另一个层次，涉及服务器名称与证书验证。导入链接时客户端会处理其中一部分映射，手工配置时则必须核对完整组合。一个字段单独看起来合理，不代表它与远端部署的其他设置能够配合。

服务器地址可以是域名，也可以是 IP，但连接地址与 TLS 校验所用的服务器名称不一定相同。使用域名时还涉及该域名如何解析，因而远端连接失败有时来自 DNS，而不是账户错误。遇到证书或握手错误，应核对系统时间、服务器名称、证书链和传输配置，不应先关闭证书验证。跳过验证会改变安全边界，还可能掩盖地址填错的问题；保留验证并修正配置，才便于区分真正的服务故障与本地误配。

内核支持范围决定配置能否迁移

Xray 与 V2Fly 共享一部分配置习惯，但并非所有协议特性、传输字段与可选值都能互通。尤其是带有特定安全机制或扩展功能的连接资料，应先确认运行内核支持，再进行导入或自定义。客户端名称也不能直接等同于每次启动的内核：v2rayN 的实际选择需要在界面和日志中确认，v2rayNG 以 Xray 方向为主，v2flyNG 则作为 V2Fly 方向的 Android 备选。跨内核迁移时，先验证一个出口，不要同时迁移整套路由与高级功能。

订阅管理还带来配置生命周期问题。更新订阅可能替换服务器参数，却不一定保留手工改写的底层对象；客户端也可能根据当前选择重新生成出口标签。若需要长期引用固定标签，应使用客户端明确支持的自定义配置方式，并在每次更新后检查实际生成结果。选择安装入口可前往下载中心，比较三款客户端的适用场景可阅读客户端对比。本页不提供远端服务，能否建立连接仍取决于真实服务参数与网络可达性。

routing：匹配顺序与分流规则

规则按顺序判断，不按具体程度自动排序

路由负责为连接选择出口。常见字段规则放在 routing.rules 数组里，内核按顺序检查，命中后采用对应处理结果，而不是把所有规则收集起来再挑选“最精确”的一条。因此，明确的例外通常应放在较宽泛的规则之前。若一条前置规则已经匹配全部 TCP 与 UDP 流量，后面的域名规则即使写得完全正确，也不会再有机会决定出口。排查分流时，先看顺序，再看条件，最后才考虑数据文件是否缺少条目。

同一字段内的多个候选通常表示任选其一，例如 domain 数组中任意一个域名条件成立即可；同一规则中不同类型的限制则通常共同参与判断。例如同时写入站标签、域名和端口，意味着连接需要满足这些约束，而不是命中任意一项就生效。把三个独立需求塞进一条规则，常会使匹配范围意外收窄。表达多个彼此独立的例外时，拆成数条规则更容易验证，也更容易观察哪一条产生作用。

不依赖地理数据的练习片段

下面的规则可以配合前两章的直连与阻断出口使用。它先阻断保留示例域名及其子域名，再让来自 SOCKS 入口的连接直连；其他流量仍按默认出口处理。这里使用 domain: 表达域名及子域匹配，使用 inboundTag 限定入口。示例目的是展示引用和顺序，而非推荐某种实际分流清单。验证时应使用明确的测试目标，并在日志中确认路由结果，不能只凭网页是否打开判断命中了哪条规则。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:example.org"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "inboundTag": [
          "socks-local"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

full: 常用于完整域名匹配，domain: 用于指定域及其子域，正则形式则适合确有必要的复杂条件。普通文本的匹配范围可能比直觉更宽，维护时应优先选用语义明确的写法。IP 规则可以使用地址或 CIDR 网段，但私有网段、回环地址与链路本地地址的含义不同，不能把它们都理解成同一种“本地地址”。规则中的目标 IP 也不必然等于最初解析得到的唯一地址，域名连接的解析阶段会影响可参与判断的信息。

domainStrategy 与地理数据的边界

AsIs 尽量按现有目标形式判断，不主动为了路由把域名解析成 IP；IPIfNonMatch 会在域名阶段未匹配时尝试解析，再参与后续判断；IPOnDemand 则在路由判断需要 IP 信息时尝试解析。它们控制的是路由阶段的解析策略，不是全局 DNS 开关，也不决定每个出站最终采用哪种地址族。选择前先问清楚：当前规则依赖域名还是 IP，以及是否愿意为获得 IP 匹配结果引入额外解析。

geosite 与 geoip 是依赖数据文件的规则引用，不是内核凭空生成的分类。相应文件缺失、目录不正确或分类名称不存在，都可能导致加载失败或行为不符预期。数据内容也会变化，不能把分类当作永久准确的业务边界。对于关键目标，应使用可解释的显式规则，并明确它位于分类规则之前还是之后。涉及本地服务时，还要考虑系统路由与防火墙，不要试图仅靠内核域名规则解决所有网络访问问题。

建议按“一个目标、一条预期出口、一段日志”验证路由。先暂时移除无关规则，确认目标携带的是域名还是 IP，再恢复数据分类和复杂条件。若需要对照完整分流场景，可以继续阅读V2Ray 路由规则实战。导入现成规则前应检查其标签引用、规则顺序与数据依赖是否适合当前配置；直接复制一整套清单，往往只是把原本可定位的问题藏进更多条件里。

dns：解析路径与域名信息

先分清是谁发起解析

DNS 问题常被笼统描述为“域名打不开”，但一次连接可能涉及应用自己的解析、操作系统解析、内核内置 DNS，以及远端服务器一侧的解析。它们不一定读取同一份设置。应用若先把域名转换为 IP，再把 IP 交给 SOCKS 入站，内核看到的起点就与直接收到域名不同。顶层添加 dns，并不会自动让系统和所有应用改用该解析器，也不会自动接管所有发往外部 DNS 服务的请求。

内置 DNS 可以为需要解析的内核功能提供结果，例如部分路由判断与直接出站的地址解析，但具体是否调用它，仍取决于相应模块的策略和当前内核实现。故障定位时，应记录域名最初在哪里被解析、请求从哪个出口离开，以及解析结果最终交给谁。只替换一个解析服务器而不梳理调用链，可能使网页偶尔恢复，却无法解释为什么另一个应用仍然失败，也无法保证后续改动不会再次触发同类问题。

基础服务器、静态映射与地址族

下面是一个标准 JSON 片段：为保留示例域名设置静态映射，并列出解析服务器，查询策略使用 IPv4。它展示字段结构，而不是针对所有网络的推荐名单。实际网络可能限制某种解析传输，某个服务器也未必在当前路径可达。静态映射应只用于明确知道目标地址的场景；如果服务地址经常变化，长期固定映射反而可能造成连接到旧地址、证书错误或区域调度失效。

{
  "dns": {
    "hosts": {
      "example.org": "93.184.215.14"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIPv4"
  }
}

queryStrategy 决定查询结果所涉及的地址族方向，常见取值包括 UseIP、UseIPv4 与 UseIPv6，具体支持应以运行内核为准。选择 IPv4 可以帮助隔离某些 IPv6 路径问题，但不能把它当作所有超时的通用修复。若服务仅有某种地址记录，限制地址族就可能得不到可用结果。反之，能返回 IPv6 地址，也不意味着本机拥有可用的 IPv6 路由或相应出站能力，解析成功与连接成功是不同阶段。

指定域名解析与循环依赖

servers 数组可以包含服务器对象，通过域名条件和预期 IP 范围表达更细的查询需求。这里的域名条件用于选择解析服务器，不等同于 routing.rules 的出口选择；解析器收到请求后，其网络连接如何发出，还与所用传输方式及内核实现有关。部分本地模式和普通模式存在不同的路由行为，配置加密解析服务前，应先确认当前字段的实际语义，不要假设所有 DNS 请求都会自动跟随代理出口。

尤其要避免引导解析的循环依赖：远端服务器地址需要先解析，而解析服务本身又只能通过尚未建立的远端连接访问。类似问题在使用域名形式的加密解析地址时也可能出现。处理时应先确保引导阶段可独立完成，明确远端服务器域名如何获得地址，再逐步加入复杂的解析路径。不要通过关闭安全检查或随意固定服务地址来掩盖循环；应把依赖链拆开，并检查系统 DNS、内核 DNS 和出站连接各自的职责。

FakeDNS 通过虚拟地址与域名映射帮助后续阶段恢复域名，通常需要入口接管、解析流程与内核功能相互配合。只添加一个名称或照抄一个片段，并不能使普通系统代理自动获得完整接管能力；退出相关模式时，还应留意应用与系统缓存中残留的虚拟地址。进一步的适用边界可阅读FakeDNS 原理与适用场景。常规排查优先使用简单解析路径，确认稳定后再决定是否需要这类机制。

policy、log 与 stats：运行策略

policy 控制连接行为，不负责选择出口

policy 常用于描述连接握手、空闲超时、半关闭处理以及流量统计开关。它不替代路由，也不会因为增加几项数字就自动提升连接质量。levels 中的键表示用户级别，对应协议用户对象上的级别信息；没有显式指定时，常见场景使用默认级别。不同协议能提供的用户信息不同，不能假设每个入口都能按相同方式统计。设置前应先确认当前连接究竟对应哪个级别，否则可能修改了一组根本没有使用的策略。

下面的片段为默认级别显式设置常见超时参数。handshake 是握手阶段允许的时间，connIdle 面向连接空闲阶段，uplinkOnly 与 downlinkOnly 用于一个方向结束后，另一个方向仍然开放的时间控制。这些值的单位是秒。示例用于解释结构，不代表需要把已有客户端默认值全部替换；如果当前使用正常，保留经过客户端适配的默认策略，通常比盲目缩短超时更容易维护。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    },
    "system": {
      "statsInboundUplink": false,
      "statsInboundDownlink": false
    }
  },
  "log": {
    "loglevel": "warning"
  }
}

握手时间过短时，网络抖动或多层传输建立过程可能尚未完成，连接就被提前结束。空闲超时过短则可能影响长连接、等待推送或间歇传输；设得过长又会让已无实际用途的连接保留更久。某些应用自身带有心跳和重试机制，实际表现还受到应用层行为影响。因此，调整策略应围绕可复现的问题，记录修改前后的日志和连接阶段，不要把一次偶然成功当作参数改动有效的证据，更不要把超时值当作服务响应速度的测量结果。

日志等级与输出位置

loglevel 常见等级包括 debug、info、warning、error 与 none。调试等级更详细，但日志体积和隐私暴露也随之增加；日常运行不必长期保留最详细记录。未配置文件路径时，输出可能由控制台或客户端接收；配置访问日志与错误日志路径时，应确保运行用户有写入权限，并理解相对路径以哪个工作目录为基准。文件没有新增内容，不一定表示没有连接，也可能是查看了旧路径或另一份日志。

访问记录与错误记录的用途不同：前者帮助观察请求目标和出口，后者帮助判断解析、连接或握手在哪个阶段失败。读取日志时，应先对齐同一次测试的时间范围，再看入口标签、目标地址和错误链。一个最终超时可能由前面的解析失败引起，不能只截取最后一行。日志也可能包含域名、地址、用户标识或本地路径，分享给他人前应先处理敏感内容，保留足以判断流程的信息即可，避免直接公开整份运行记录。

统计开关与管理接口的关系

顶层 stats 与策略里的统计开关负责不同环节：前者启用统计相关模块，后者决定哪些维度收集数据。即使添加了空的 stats 对象，也不会自动生成一个可以访问的图形面板；若要读取统计，通常还涉及管理接口、服务声明及入口隔离。本文不建议为了一次排错公开管理接口，也不把统计读数当作网络性能结论。客户端已有流量显示时，应优先使用其既有集成，不另起一套无法确认边界的接口配置。

对于“连接能建立，但过一段时间中断”的问题，先区分应用主动关闭、远端关闭、空闲策略触发与网络切换，再考虑调整 policy。若每次都在握手阶段失败，修改空闲参数并不能解决根因。更完整的日志阅读方法见V2Ray 运行日志怎么看。完成定位后，应恢复适合日常使用的日志等级，清理不再需要的调试文件，并把确有必要的策略改动纳入配置备份说明。

客户端设置与内核 JSON 的边界

v2rayN：界面状态不等于文件状态

桌面环境首推 v2rayN，但使用图形客户端并不意味着所有设置都位于同一个 JSON 文件。服务器列表、订阅地址、窗口偏好、路由模板与内核运行配置，可能分别保存。点击启动后，客户端会把当前选择组合成内核能够读取的配置；停止再启动、切换服务器或更新订阅，都可能重新生成结果。阅读文件时要先判断它是长期来源还是临时产物。来源不明确的文件不宜作为唯一备份，也不宜在内核运行时边改边猜是否已经生效。

系统代理属于操作系统与应用之间的设置约定，内核 JSON 则描述进程自身的监听和转发。两者配合才能完成常见桌面使用流程。清除系统代理并不必然停止内核，停止内核也不一定立即清除系统里残留的代理设置；如果应用继续请求一个已经关闭的本地端口，就会表现为整体无法访问。退出前后应分别确认系统代理状态与进程状态，不要把所有连接拒绝都归咎于远端服务，更不要通过叠加多个客户端来尝试修复残留设置。

跨平台与不同内核的配置差异

Windows、macOS 与 Linux 都可使用 v2rayN，但权限、运行目录、系统代理集成方式与网络接管机制并不完全一致。文件路径写法、配置所在目录的写权限、服务运行身份都可能影响实际加载结果。Android 用户通常选择 v2rayNG，使用 V2Fly 方向配置时可考虑 v2flyNG；系统提供的网络接管授权与桌面系统代理不是同一种机制。迁移时应保留连接资料，再按目标平台重新确认接管设置，而不是复制整个工作目录并期待所有路径和权限仍然有效。

同为 JSON，也可能属于完全不同的配置模型。v2rayN 可涉及不同内核，而本文的 inbounds、outbounds 和 routing 示例围绕 V2Fly / Xray 的常见结构展开，不能直接套入 sing-box 的配置结构。不要仅凭文件扩展名判断兼容性。遇到字段不识别，应先核对当前启动的内核，再检查配置入口要求的是完整配置、服务器对象，还是客户端专用的导入格式，避免在错误格式上不断修补字段。

TUN 与系统代理不能靠一个布尔值等同

TUN 通常需要虚拟网络接口、路由设置及对应权限，有时还涉及独立的接管组件或另一内核。客户端里的“启用 TUN”不意味着在本文基础 JSON 顶层添加一个同名字段就能获得相同效果。系统代理范围较明确，但依赖应用主动采用；TUN 的接管范围更广，却也需要处理本地网络、DNS 与出口回环等问题。切换模式时应一次只启用一条明确的接管路径，并确认远端连接自身不会再次被送回入口。

自定义完整配置与普通订阅使用也应分开管理。前者通常要求自行维护入口、出口、规则和数据依赖，后者则由客户端根据订阅与界面生成。导入成功只是格式被接受，不代表每个字段都已生效。若客户端提供配置预览或运行日志，应以实际加载结果作判断；若没有明确的合并说明，不要假设自定义片段会自动覆盖正确位置。保留一份能够恢复的常规配置，比维护多个互相覆盖的临时文件更可靠。

选择桌面界面时，可阅读v2rayN 桌面版与 WPF 版区别，按系统与界面习惯决定，而不是把界面框架差异等同于协议能力差异。安装文件从下载中心按平台选择，首次配置仍沿用使用指南的主线。只有确认界面无法表达实际需求后，再引入自定义内核文件，并在订阅更新、模式切换与重新启动后检查其持久性，确保下一次运行仍采用预期设置。

配置验证、日志定位与恢复流程

把语法正确与运行正确分开验证

配置排查应从最便宜的检查开始。第一步确认文件是标准 JSON，括号、逗号和字符串转义正确；第二步确认字段属于当前内核；第三步检查标签引用、数据文件、监听端口与路径权限；最后才进行真实连接测试。语法通过，只表示文件可以被解析，不表示远端可达或路由符合预期。一个没有远端出口的直连配置也可以完全合法，因此“内核能启动”和“指定目标按指定出口访问”必须作为两个独立的验证目标。

手工运行内核时，可以使用其配置测试模式，不必先让它长期监听。下方命令分别面向本地已有的 Xray 与 V2Ray 可执行程序，文件名 config.json 应对应实际要检查的配置；命令应在合适的工作目录执行，或改用正确的可执行文件路径。不同发行形态的命令参数可能存在差异，遇到未知参数时先查看程序自带帮助。图形客户端用户则优先使用日志和配置检查功能，不需要为了阅读本文另行部署一套后台进程。

xray run -test -config config.json

v2ray test -c config.json

通过配置测试后，应先停用冲突的监听实例，再启动目标配置。选一个明确支持代理设置的应用，仅设置本次验证所需的入口，发起一次请求并记下时间。使用第一章的直连基线时，预期是验证本地入口，而不是验证远端代理。随后再加入已确认参数的远端出口，最后恢复路由与 DNS。这样每个阶段都只新增一个主要变量，即使失败，也能缩小到刚加入的那部分，而不必同时猜测入口、解析和远端三个方向。

按现象回到对应层次

如果内核无法启动，优先检查解析错误、未知字段、端口占用和数据文件加载；如果程序提示本地连接被拒绝，优先检查监听地址、端口和进程状态；如果内核已接收到请求但提示域名解析失败，回到 DNS 调用链；如果远端握手失败，再核对地址、系统时间、协议身份与传输安全设置。对于超时，不应立即认定是哪一层故障，应沿日志向前寻找最后一个成功阶段，以及第一个明确失败的位置。

测试中要避免应用缓存干扰。已有连接可能继续复用旧通道，域名缓存可能保留上一次结果，系统代理变化也未必被正在运行的应用立即读取。必要时关闭相关连接或重启测试应用，再进行同样的请求，但不要同时清空所有设置，使原始故障失去可比性。网络切换也会改变可达性与解析路径，应记录测试时使用的网络环境。只有在相同条件下反复出现的结果，才适合用来判断某项配置改动是否真正有效。

保留恢复点，而不是积累补丁

每次确认一个阶段可用，就保存对应配置和简短说明，写明运行内核、入口端口、默认出口及依赖文件。备份中若包含订阅地址或账户资料，应按敏感信息管理，不要放进公开页面或共享记录。出现新问题时先回到最近的恢复点，再逐项重放改动；不要在失败配置上持续添加例外规则和超时参数。恢复正常后，应删除已经证实无效的补丁，避免后来维护者误把临时尝试理解成必要条件。

最后还应进行持久性检查：停止并重新启动客户端，确认订阅更新或模式切换没有覆盖必要设置，再用相同目标验证一次。调试结束后恢复合适的日志等级，撤销临时扩大的监听范围，并清理不再使用的系统代理设置。若仍不能定位，可携带已处理敏感信息的错误片段与最小复现步骤查阅疑难解答；若只是需要重新完成基础流程，则回到使用指南，不要把系统查阅手册中的所有可选项都当成必填步骤。