V2Ray JSON 配置文件参考

JSON 结构与配置来源

先确认配置由谁生成，再决定在哪里修改。v2rayN、v2rayNG 与 v2flyNG 都是图形客户端，负责把节点、订阅、路由和本地设置组织成内核运行所需的内容。客户端界面保存的资料、订阅返回的数据与最终运行的 JSON，属于不同层次。订阅链接不能直接当作配置文件，客户端数据库也不等于内核配置。排查时应寻找当前连接实际使用的配置，而不是只看曾经导出的某个文件。

顶层对象与请求路径

常见配置以一个对象为根节点。对象中的键表示功能模块，模块值可能是对象，也可能是数组。inbounds 和 outbounds 是数组，因为同一进程可以同时提供多个入口和多种出口。routing 则是对象，内部的 rules 才是有顺序的规则数组。理解层级比记住字段排列更重要：顶层键通常不依赖书写顺序，路由规则数组和出站数组却可能影响实际行为。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [],
  "outbounds": [],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  },
  "dns": {
    "servers": ["localhost"]
  },
  "policy": {
    "levels": {}
  }
}

上面的内容是结构骨架，不是可完成转发的配置：空入站没有接收请求的端口，空出站也没有转发目标。实际请求通常沿“应用程序→入站→路由→出站”的路径流动，DNS 可能参与其中的域名解析，日志记录过程中的事件，策略影响连接资源和超时。各模块不是独立开关；一个拼写正确但未被引用的出站标签，并不会自动接管任何流量。

语法正确与语义正确

标准 JSON 的键和字符串使用英文双引号，布尔值使用小写 true、false，数字通常不加引号。数组或对象最后一个成员之后不能再写逗号，也不要把说明文字直接放进代码。部分实现接受扩展语法，但跨客户端复制时应按标准 JSON 编写。重复键尤其容易造成误判：不同解析过程可能保留不同值，因此同一对象内只保留一份同名字段。

语法解析通过只说明括号、类型和字符合法，并不能证明协议参数可用。内核还要检查协议名称、字段支持范围、标签引用和监听资源。即使成功启动，也可能因为远端地址、认证信息或传输参数不一致而连接失败。应把“文件能解析”“进程能启动”“请求能通过”“规则符合预期”视为四个不同检查点，逐步确认，避免用一次网页访问概括全部状态。

内核差异与修改边界

Project V 是相关工具的生态背景，V2Fly 与 Xray 是需要分别识别的内核实现。它们有共同的配置概念，但不能据此假定所有新字段、传输组合和默认值都相同。尤其是 REALITY 等扩展，应按实际内核的对应字段配置，不能把专属于某个实现的段落直接合并到另一份文件。本手册示例采用常见基础结构，涉及扩展能力时先确认客户端当前选用的内核。

图形客户端通常会在切换节点、更新订阅或重新连接时生成配置。直接修改临时生成文件，可能在下一次操作后被覆盖。需要长期保留的修改，应优先写入客户端提供的路由、DNS 或自定义配置入口，并确认它们如何参与合并。修改前另存原始资料，记录改动字段和预期现象；一次只改变一个层次，才能在失败后准确回退。首次选择客户端可参考客户端与平台下载页。

log 日志与观察方法

日志用于解释某次运行发生了什么，不用于证明所有连接都正常。配置启动失败时，先看错误日志；应用能连接本地端口却无法完成请求时，再结合访问记录、目标地址和出站行为判断。内核日志、客户端界面日志和系统服务日志可能来自不同进程，显示时间与详细程度也不同。比较两份记录前，应确认它们属于同一轮启动，避免把旧错误当成当前故障。

日志级别与输出位置

loglevel 控制错误类日志的详细程度。常见取值包括 debug、info、warning、error 和 none。日常使用通常保持较克制的级别，复现问题时再短暂提高。调高详细程度只能增加观察信息，不能改变规则匹配或修复握手。若问题只在某个应用发生，优先缩小复现范围，而不是长时间记录全部日常连接。

{
  "log": {
    "access": "./access.log",
    "error": "./error.log",
    "loglevel": "warning"
  }
}

这是一段需要并入顶层对象的配置。两个路径均为相对路径，实际落点取决于进程工作目录，不一定是 JSON 所在目录。桌面客户端通过快捷方式启动、由服务启动或从终端启动时，工作目录可能不同。没有找到文件时，先查看启动方式与目录权限，再考虑日志是否被关闭。把路径改成可写位置，比反复提高日志级别更直接；不要为此扩大整个程序目录的访问权限。

如果客户端已经收集内核输出，额外指定文件并非必需。未指定文件时的输出位置应以实际内核与启动方式为准。有的界面只显示摘要，有的会单独提供访问日志开关。若文件一直增长，还需要从运行环境安排轮换或清理，不能假定内核会自动限制大小。记录保存多久应由排错需要决定，完成复现后恢复原来的日志级别，避免磁盘被长周期记录占满。

按时间建立最短证据链

一次有效复现应包含清晰的起点和终点。先停止旧连接，记下重新启动的时间，再用一个已知地址发起一次请求。观察是否出现入站接收、目标识别、规则选择以及出站错误。不同实现未必逐项打印这些信息，不应要求每份日志都有相同句式；重点是把时间、目标和结果关联起来。连续刷新多个页面会引入预连接、后台请求和缓存，反而让记录难以对应。

常见错误可以按层次理解。监听失败通常与端口占用、地址不存在或权限有关；域名解析失败指向解析链路；远端连接超时可能涉及目标可达性和传输条件；认证或握手错误则需要比较服务端与客户端参数。一个最终的超时提示并不能单独说明哪层出错。应寻找它之前的第一条有意义错误，而不是只复制最后一行。多次重试产生的重复信息，也不能当作多个独立原因。

区分日志缺失与流量未进入

没有访问记录时，首先确认应用是否真的使用该入站。浏览器可能读取系统代理，而命令行工具可能只读取自己的参数；已有连接也可能继续沿原来的通道传输。测试时重新建立连接，并显式指定代理地址，可以减少变量。若应用请求根本未进入内核，调整出站、DNS 或路由都不会改变结果。系统代理与内核路由的职责区别，见系统代理与路由模式说明。

若已经能看到请求进入，但记录中的出站与预期不同，应转到路由章节检查顺序与标签。若出站正确且只有部分目标失败，则比较目标是否使用不同地址族、传输协议或域名解析路径。日志是一条观察线索，需要与可重复的测试结合。保存一次成功记录和一次失败记录，逐项比较差异，通常比同时修改端口、解析器和路由模式更容易定位真正的变化。

inbounds 本地入口

入站定义内核在哪里接收请求，以及按什么协议理解应用发来的数据。桌面常见的是本地 SOCKS 或 HTTP 入口。端口只是入口编号，不决定出口是否经过远端节点，也不代表全部应用都会自动使用代理。应用必须主动连接这个端口，或者由系统代理等入口机制把请求交给它。排查前应先确认应用所需协议，不能把 SOCKS 端口随意填进只接受 HTTP 代理的设置栏。

监听地址、端口与标签

listen 决定绑定地址，port 决定监听端口，protocol 决定入站协议，tag 用于后续引用。仅供本机使用时，明确监听 127.0.0.1 可以限制访问范围。这个地址只表示本机 IPv4 回环，不等同于所有接口，也不等同于 IPv6 回环。若应用连接的是另一种地址族，应核对双方地址，不要仅凭“localhost”这个名称判断连接位置。

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

示例允许本机应用使用不带认证的 SOCKS 入口，并开启 UDP 转发能力。这里的 udp 不意味着系统中所有 UDP 都被接管；应用仍需使用 SOCKS 的相关机制，出口也要能够处理相应流量。若只测试网页，成功结果通常只能证明当前 TCP 请求通过，不能据此判断语音、实时通信或其他 UDP 应用。遇到差异时，应分别检查应用支持、入站能力和出站链路。

局域网访问与安全边界

允许局域网连接不仅是把监听地址改成 0.0.0.0。还需要考虑主机防火墙、网络接口、认证方式和允许来源。全接口监听会扩大可到达范围，机器切换到不同网络后，暴露面也随之改变。只需要某个局域网接口时，可以绑定该接口地址并配合防火墙限制来源。没有明确共享需求时，保持回环监听更容易管理，也能避免其他设备误用本机入口。

同一地址上的同一传输类型端口不能被多个进程重复占用。客户端后台残留、另一款工具使用相同端口，或同时启动两份配置，都可能造成绑定失败。此时应先关闭多余实例，确认端口归属，再决定是否更换端口。若改了入站端口，应用代理设置和系统代理也要同步更新；只修改 JSON 而保留旧代理地址，表现往往是连接被拒绝，而不是协议握手错误。

嗅探识别与目标覆盖

嗅探尝试从请求内容识别域名等目标信息。例如应用先把域名解析成 IP，再通过入口提交 IP 目标，HTTP 请求头或 TLS 握手中的信息可能帮助恢复域名。这有助于域名规则参与路由，但识别能力依赖实际协议内容，并非任何加密流量都能还原域名。没有可识别信息、目标使用特殊握手或协议超出范围时，路由仍可能只能依据 IP 与其他条件。

destOverride 涉及识别结果如何影响目标，不应把“识别域名”和“只用于路由”混为一谈。不同内核提供的控制字段和默认行为可能不同；需要仅影响匹配、不改写连接目标时，应确认实际实现的对应能力后再配置。排查开启嗅探后出现的访问差异，可先对同一个目标分别关闭与开启嗅探测试，观察目标和规则变化，而不是同时更换节点与 DNS。

多个入站可以服务不同用途，例如为测试请求单独设一个标签，再用 inboundTag 指向专用出站。标签是逻辑名称，不会创建端口，也不会自动启用系统代理。规划时让名称描述用途，避免沿用大量难以区分的编号。完成监听测试后再叠加嗅探和分流，可以把入口问题与后续策略问题分开；图形界面的基础操作仍以快速上手步骤为主。

outbounds 出站选择

出站决定请求被选中后如何处理。它可以直接连接目标，也可以按指定代理协议发送给远端，或者主动拒绝连接。出站不是“节点列表”的简单同义词：直连与阻断同样属于出站，却不需要远端服务器。一个配置中可以存在多个出站，但只有默认路径或路由引用到的出站才会参与请求处理。先确认请求选择了谁，再检查该出口的参数，排错顺序会更清楚。

基础出站与默认行为

常规配置中，路由未匹配到指定出口时，会使用出站数组中的第一个出站作为默认出口。因此调整数组顺序可能改变未命中流量的去向。建议明确记录默认出口的用途，并为每个需要引用的出站设置唯一标签。标签在同一份配置中前后保持一致，大小写和字符也应一致；它不是界面显示名称的必然副本，更不能凭节点备注猜测实际生成的标签。

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

示例把直连放在第一位，因此没有额外规则时，请求会从本机网络直接发出。blackhole 表示阻断处理，只有路由指向 block 时才会被使用。它不是备用线路，也不会因为直连失败自动接管。把两个出站写进数组，不等于构建了故障切换；负载选择、探测或链式处理都属于另外的配置能力，需要明确支持和额外设置。

协议参数与传输参数分层

远端代理出站通常同时包含协议层设置和传输层设置。前者描述服务器、端口、认证和协议特性，后者描述底层连接方式及其安全参数。服务端与客户端必须在关键字段上对应；远端端口可达，仅证明网络层能建立连接，不证明认证与传输组合正确。遇到握手失败时，应对照提供方给出的完整参数，而不是把所有字段都改成看起来熟悉的默认值。

VMess、VLESS、Trojan 与 Shadowsocks 的认证结构和能力不同，不能只修改 protocol 名称就互相转换。TLS 与 REALITY 等组合也不能脱离内核支持范围讨论。有关协议之间的选型，可先阅读四种代理协议的场景对比。本页不提供含虚构远端凭据的“万能节点”，完整实验配置使用直连出口，目的是隔离本地结构问题，而不是模拟一条实际远端线路。

域名目标与连接责任

出站收到域名后，是交给本机解析、使用内置 DNS 解析，还是把域名交给远端，取决于出站协议和相关设置。freedom 的 domainStrategy 与 routing.domainStrategy 名称相似，却不属于同一层。前者影响直连出站如何处理域名目标，后者影响路由匹配是否进行解析。把路由策略改成解析 IP，不代表所有出口都统一改用相同的解析过程。

在多出口配置中，还要区分最终访问目标与代理服务器自身的地址。服务器域名也需要被解析和连接；若相关流量再次被送入依赖它自身的路径，就可能形成循环依赖。图形客户端通常会处理必要的排除或直连逻辑，自定义配置则应明确分析启动连接从哪里建立。出现尚未完成握手就反复超时的情况时，应先检查服务器地址解析、底层可达性及出口选择。

修改节点参数时，优先在客户端的节点编辑入口完成，避免手写内容随后被订阅更新覆盖。需要固定出口标签的自定义规则，应确认客户端生成标签是否稳定，节点切换后是否仍能引用。若标签由客户端重新生成，使用其提供的路由设置通常比复制运行文件更可靠。保留一组已知可用的基础配置作为对照，能把“出口本身失败”和“路由选择错误”拆成两个可验证的问题。

routing 规则匹配

路由按规则顺序检查请求，并把匹配结果交给指定出站。它不是系统代理开关，也不会主动让未进入内核的应用流量出现。规则写得正确而应用仍走原网络时，先检查入口；请求已经进入但出口不对时，才检查规则顺序、匹配字段和标签引用。把入口接管与内核分配分开理解，是分析“全局”和“绕过大陆”等界面模式的前提。

顺序、条件与目标信息

同一条规则中的不同条件通常需要同时满足，例如指定入站标签并限制端口；同类数组中的多个候选则提供可匹配项。规则一旦命中，后面的普通规则不会再覆盖它。宽泛规则应放在精确例外之后，否则例外永远没有机会生效。域名条件要依赖可用的域名信息，IP 条件则依赖目标地址或解析结果；不能要求只有 IP 的请求天然命中域名列表。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

示例先阻断一个专用测试域名，再处理私有地址，最后把指定入站的其余 TCP 与 UDP 请求交给直连。blocked.example 是示例用途域名，不是需要替换的认证资料。这里的两个出站标签应与前章定义一致。第三条规则较宽，因此若要增加某个目标的例外，通常应插入第三条之前。写在它之后，即使语法正确，也可能完全没有匹配机会。

域名写法与数据文件

full: 用于完整域名匹配，domain: 常用于域名及其子域，regexp: 则表达正则条件。未加前缀的写法有自身匹配语义，不能一概当成精确域名。需要避免误匹配时，优先选择能直接表达意图的前缀，不要用复杂正则代替清晰的完整域名或域名后缀。正则还受到 JSON 字符串转义影响，表达式里的反斜杠需要按字符串规则处理。

geoip: 与 geosite: 引用相应规则数据，而不是运行时在线搜索结果。使用前要确认内核能够读取所需数据文件，以及其中是否包含引用的分类。分类名称存在不代表它覆盖所有目标，数据更新也可能改变匹配范围。出现某个网站被分到意外出口时，应比较实际访问域名、附属资源和数据内容；一个页面往往包含多个独立请求，不能只看地址栏域名。

domainStrategy 的解析时机

AsIs 尽量按已有目标信息匹配，不为了 IP 规则主动执行相应的域名解析。IPIfNonMatch 在域名阶段未能找到适用规则时，再尝试解析并使用 IP 条件；IPOnDemand 则在匹配需要 IP 信息时触发解析。它们改变的是匹配过程中获取信息的方式，不是“更快”“更全面”的固定等级。过早解析会增加依赖，过少解析又可能让预期中的 IP 分类没有机会参与。

尤其要注意兜底规则。如果前面已有一条能够匹配所有请求的规则，使用 IPIfNonMatch 时可能已经得到结果，不再进入希望发生的解析阶段。此时问题不是 DNS 不工作，而是规则已提前结束匹配。应结合规则顺序设计解析策略，而不是只切换一个字段。私有地址规则也只匹配内核实际掌握的地址，域名解析到私有地址的情形，需要单独验证解析时机。

客户端生成的“绕过大陆”通常是规则集合，而不是某个内核统一存在的单值选项。不同配置模板可能采用不同域名列表、IP 分类和默认出口。要解释实际行为，必须查看当前规则，而不能只引用模式名称。需要按应用场景选择模式时，可阅读系统代理与全局、绕过大陆模式；遇到速度差异，则继续区分规则选择、解析路径与远端线路，避免把所有现象归结为某个模式名称。

dns 域名解析

DNS 配置首先要回答“谁发起查询，查询从哪里发出，结果被谁使用”。操作系统解析器、浏览器自身的解析机制、内核内置 DNS 和远端服务器的解析可能同时存在。修改内核的 dns 不会自动替换所有应用的解析方式，也不会把全部系统查询接入内核。只有相关请求路径确实调用内置解析器时，这部分设置才会影响结果。

基础服务器与静态映射

servers 列出内置 DNS 使用的服务器或相应设置，hosts 则可定义静态域名映射。下面示例把一个实验域名映射到回环地址，其余查询交给本机解析机制。静态映射适合隔离测试，不适合用来长期固定频繁变化的服务地址。服务可能依据地区、负载和地址族返回不同结果，固定地址会绕开这些选择，也可能在服务端调整后失效。

{
  "dns": {
    "hosts": {
      "full:manual.example": "127.0.0.1"
    },
    "servers": [
      "localhost"
    ]
  }
}

这段配置并不会让任意浏览器访问该实验域名时都解析为回环地址；前提是那次访问实际使用了内核内置 DNS。若直连出站采用系统解析路径，应用又已自行解析，结果可能与预期不同。因此验证静态映射时，要同步确认调用路径。实验完成后移除测试映射，避免之后把连接回环失败误判成真实目标故障。对于生产配置，映射应有明确用途和可追溯的维护记录。

路由解析与出站解析

路由阶段可能为了 IP 规则解析一个域名，但出站仍可能使用域名继续建立连接。一次路由查询不等于最终连接必然使用同一条地址结果。直连出站是否使用内置 DNS，取决于它的域名策略；代理出站是否在本地解析目标，则取决于协议与具体设置。分析某个请求时，应分别记录路由判断采用的信息，以及最终出口建立连接时采用的信息，不能只看一处解析日志。

应用也可能先解析，再把 IP 发送给 SOCKS 入口。此时内核未必知道原始域名；嗅探有时能补充，但不能保证成功。需要验证内核侧域名处理时，应使用支持把域名交给代理的测试方式，并确认应用没有预先替换成地址。反过来，若希望比较本地解析与代理侧解析差异，也应显式控制这一变量，而不是在浏览器缓存、系统缓存与客户端缓存之间猜测。

解析传输与循环依赖

指定一个解析服务器地址，并不意味着查询会自动经过远端代理。不同形式的 DNS 服务器配置可能走不同传输路径，需要分别分析。若使用需要先解析域名才能连接的加密解析端点，还要考虑初始解析如何完成。若解析服务器的访问依赖某条代理，而代理服务器的域名又依赖这个解析服务器，就可能在建立首个连接前陷入循环。设计时应给启动依赖留下明确、可达的路径。

不要一次替换多个解析器并同时改变路由策略。应先记录当前返回地址，再只改变一个查询环节，用同一目标复测。多个解析服务器也不必然按书写顺序逐个尝试，实际行为可能涉及匹配条件、并发、回退及实现差异。需要按域名选择解析源时，应查清当前内核支持的服务器对象字段；不要把其他工具中的“首选”“备用”语义直接套用到这里。

地址族与缓存边界

同时存在 IPv4 和 IPv6 结果时，最终表现还取决于本机网络、出口支持与连接选择逻辑。不能仅因某次请求等待较长就立即关闭一种地址族；应先确认返回了哪些地址、哪次连接失败，以及失败后是否存在回退。解析成功只说明获得结果，不说明这些地址都可达。地址可达也不等于直接访问 IP 能替代域名，因为 TLS 服务器名称和虚拟主机仍可能要求原始域名。

缓存使测试更稳定，也会掩盖配置变化。修改后应新建请求，必要时按应用提供的方法清理对应缓存，并区分内核重启前后的记录。不要把重启所有软件当成唯一诊断手段；有针对性地确定缓存位于哪一层，才能解释问题为何出现。若表现为整体速度下降，可继续阅读速度慢的分层排查，把解析等待与远端传输速度分别测量。

policy 连接策略

连接策略管理计时和资源，不负责选择路由，也不替代应用自身的超时设置。连接经常中断时，不应首先把所有超时调大。应先确认是握手未完成、已经建立但长期空闲，还是一侧已经结束发送。不同阶段由不同字段约束，应用、操作系统和远端设备也可能有自己的计时器。只有确认断开发生在哪个阶段，策略修改才有可解释的目标。

级别对象与用户关联

policy.levels 使用级别名称组织策略，JSON 对象键需要写成字符串，例如 "0"。支持用户级别的协议配置可以通过相关 level 字段关联策略；具体作用对象取决于协议实现与实际生成配置。把某一级别写进策略，并不代表所有连接自动使用它。排查时要确认连接对应用户的级别，以及没有显式指定时采用的默认行为。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    }
  }
}

示例中的计时单位为秒，用于说明一组连接阶段限制，不是对所有网络条件都合适的推荐值。handshake 约束相关握手阶段可等待的时间，connIdle 约束连接空闲时间，uplinkOnly 与 downlinkOnly 涉及单向传输阶段的等待边界。字段作用需要结合内核文档及连接状态理解，不能把它们简单等同于浏览器“网页加载超时”。

握手、空闲与半关闭

握手失败可能来自参数不一致，而不仅是线路慢。若认证或安全参数错误，延长握手时间只会更晚看到失败；若证据表明链路建立确实需要更长等待，再做小幅调整才有意义。观察时应比较开始建连、首次收到数据和错误出现的时间。还要确认日志描述的握手属于哪一层，不能把应用层会话、代理协议与底层传输的握手混为一个阶段。

空闲连接与低速连接也不同。长连接应用可能在一段时间内没有业务数据，却仍希望保留会话；另一些应用通过心跳保持活跃。策略计时与应用心跳周期不匹配时，可能出现规律性的断开。此时应确认断开间隔、是否存在实际数据，以及远端或中间设备是否先关闭连接。只增加本地空闲时间，无法阻止远端按自己的规则结束会话，也不能修复无线网络切换造成的状态丢失。

半关闭表示一侧已经结束发送，但另一侧可能还有内容需要传递。部分协议依赖这个阶段完成响应，单向等待值过短可能截断尚未完成的数据。另一方面，全部设置为很长又会让已经失去用途的连接占用资源。应通过具体应用复现，观察响应是否完整、连接由谁先关闭，再调整对应字段。不要用一个页面加载成功，推断所有长连接和单向传输场景都已覆盖。

统计与缓冲不是速度开关

策略中还可能出现用户或系统流量统计相关字段，但开启统计只是记录条件之一。若客户端需要展示相关信息，还涉及统计模块、接口及客户端读取方式。单独复制统计开关，并不会自然出现一套界面数据。类似地，缓冲区设置会影响内存使用和数据处理行为，却不能突破远端带宽、线路拥塞或服务端限制；把缓冲调大也不等于任何请求都更快。

对于图形客户端，优先保持其生成的基础策略，除非存在明确且可复现的需求。客户端可能针对当前内核和功能安排默认值，自定义整段覆盖后可能意外移除原有字段。只需要修改一个值时，应确认客户端是按字段合并还是整段替换。记录改动前后的配置差异，尤其检查未主动修改的级别和系统策略是否仍然存在，避免表面上只改超时，实际丢失其他设置。

验证策略调整时使用同一应用和相同操作过程，并给出可观察的判定标准，例如空闲后是否还能继续发送、单向响应是否完整。若无法稳定复现，应先保留原值，收集更多证据，而不是同时改握手、空闲和缓冲。内存受限的环境还应观察并发连接和日志量，避免把资源压力误诊为线路问题。策略的目标是让边界符合实际使用方式，而不是追求数值越大越好的表面配置。

完整示例与分层验证

先用仅含本地入口和直连出口的配置验证结构，再加入真实节点与复杂分流。这样可以把远端认证、传输条件和订阅生成逻辑暂时移出实验范围。下面是一份完整的基础配置，接收本机 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": {
        "domainStrategy": "AsIs"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  },
  "dns": {
    "servers": ["localhost"]
  },
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    }
  }
}

运行前停止占用同一监听端口的其他实例。若使用客户端的自定义配置入口，确认导入的是完整配置，而不是只能接收某个子段的输入框；两者结构不同。保存后先检查内核能否启动，再查看监听状态。实验中没有启用嗅探，是为了让规则测试直接依赖应用提交的目标名称。dns 保留基础结构，但直连出站采用 AsIs 时，不应据此断言请求一定经过内置 DNS。

按入口、匹配、出口逐层测试

第一步确认应用能连接本机端口。若出现立即拒绝连接，检查进程是否启动、地址族是否一致、端口是否被改动。第二步显式提交域名目标，避免应用先解析成 IP。第三步比较普通目标与阻断目标的行为。下面命令适用于已提供相应命令行工具的环境，仅向正在运行的本地入口发请求；在把该工具名定义为其他命令别名的终端中，应使用对应的实际可执行程序。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2raygpu.com/
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://blocked.example/

socks5h 让域名交给代理入口处理，便于测试完整域名规则。第一条请求的成功还依赖本机网络和目标站点可用；第二条应被阻断，但单看失败本身仍不足以证明规则命中，因为示例域名本来就不是普通业务目标。需要同时检查请求目标与出站记录，或在受控环境中用可访问目标临时替换测试规则，完成后恢复。不要把任何一次超时直接当成阻断成功。

基础路径确认后，再通过客户端导入已有真实节点资料，将其加入实际出口选择。每次只增加一项能力，例如先验证远端出口，再增加域名规则，最后增加解析条件。若导入后立即失败，把新增部分与基础配置逐层比较；不要把完整实验配置覆盖进客户端自动生成流程，却继续假设原来的节点与路由仍被保留。配置来源发生变化时，验证起点也要重新确认。

故障记录与回退顺序

保存故障记录时，写清使用的客户端、实际内核、配置来源、入口地址、测试目标和期望出口。去除认证资料后，保留标签之间的关系，否则别人无法判断路由引用是否有效。若只有某个应用失败，先比较它与成功应用的入口方式、域名提交方式及连接复用行为。若所有应用都失败，再沿启动、监听、解析、远端连接的顺序排查，避免一开始就重装客户端。

回退应按最后一次修改逆序进行。先撤销新增规则或字段，重新启动并复测；仍未恢复时，再切回已知可用的配置来源。订阅更新引起的变化要区分节点资料变化与本地模板变化，不能把旧文件和新界面混合使用。平台安装差异可查下载页，基础连接操作回到快速上手教程，术语含义可在术语手册中查阅。

最后检查目标是否真正达成：语法通过、监听正常、请求进入、出口符合规则、解析路径清楚、连接在预期边界内结束。任何一项不确定，都应继续保留对应观察点。手册中的片段用于解释模块，只有标为完整示例的配置才能整体使用；复制子段时要合并到正确层级，并保留其他必要模块。稳定配置来自可以重复验证的依赖关系，而不是不断叠加更多字段。