V2Ray 配置文件参考大全

JSON 结构总览：对象、数组与引用关系

先读数据流，再读字段

一份配置不是节点参数的平铺清单，而是请求处理路径的描述。应用先把请求交给入站，路由模块根据请求属性选择出站，出站再建立到目标或代理服务器的连接。DNS 为其中需要解析域名的环节提供地址，策略则约束连接生命周期与统计行为。阅读时先找到这条路径，再查看每个模块的细节，比逐行猜测字段更容易发现配置之间的关联。

顶层通常是一个对象，花括号内按名称放置模块。inbounds 与 outbounds 是数组，因为一个进程可以监听多个入口，也可以拥有多个出口；routing、dns、policy 通常是对象。数组元素用逗号分隔，最后一项后面不要加逗号。布尔值写成 true 或 false，端口一般使用数字，协议名和标签使用字符串，不能把界面上的所有文字都原样加引号填入。

以下是一份用于本机结构验证的完整直连配置。它只在回环地址提供 SOCKS 入口，不包含远程代理节点，所有请求通过本机网络发出。用途是确认内核能够加载配置、应用能够接入监听端口，以及日志能够记录请求。它不等于已经建立远程代理，也不能用直连成功推断订阅参数正确。测试结束后，应明确选择要继续使用的客户端配置。

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

标签是配置内部的连接点

tag 是内部标识，不是显示名称的强制翻译。路由里的 outboundTag 必须与目标出站的标签完全一致，包括大小写；inboundTag 则用于限定规则适用的入口。建议标签短而明确，并在同类对象中保持唯一。把出站标签改成更顺眼的名称时，也要同步修改引用它的路由。否则文件可能能被解析，却在运行或请求转发时出现找不到目标的问题。

配置字段缺失与显式写入空值不是一回事。省略某个可选字段时，内核通常采用该实现的默认行为；填写 null、空字符串或空对象，并不保证得到同样结果。复制示例时应确认字段所在层级，不要把 streamSettings 放进协议账户对象，也不要把 rules 直接放在顶层。配置能够通过 JSON 语法检查，只说明括号和数据类型形式基本成立，并不证明内核认识这些字段。

客户端生成配置与手工配置的边界

图形客户端往往根据节点、路由模板和 DNS 选项重新生成运行配置。直接修改临时文件，下一次切换节点或重启后可能被覆盖。长期需要保留的选项，应优先在客户端对应设置中修改；只有明确采用自定义配置导入流程时，才把完整 JSON 作为主要维护对象。导出的配置还可能包含服务器地址和账户信息，分享排错材料前应移除这些内容，只保留字段结构和必要的错误上下文。

Xray 与 V2Fly 共享不少历史结构，但并不保证新特性、别名和默认值始终一致。本页采用的经典结构适合解释数据流，不是跨内核兼容承诺。遇到“未知字段”或“未知传输类型”，先检查正在运行的内核，再核对该内核使用的配置格式。尤其不要把另一种配置格式的字段名称混入同一文件。可以结合术语表区分协议、传输、安全层和客户端，避免在错误层级寻找设置入口。

inbounds 入站：监听地址、端口与流量探测

监听位置决定谁能接入

入站定义客户端从哪里接收应用请求。桌面常见的 SOCKS 入口接收支持 SOCKS 代理的程序流量，HTTP 入口接收按 HTTP 代理协议提交的请求。这里的协议是本地应用与客户端之间的交互方式，不是远程节点采用的 VMess 或 VLESS。应用设置的代理类型必须与入站一致；把 SOCKS 端口填进仅支持 HTTP 代理的设置栏，通常不会因为端口连通就自动转换成正确协议。

listen 为 127.0.0.1 时，入口只接受本机 IPv4 回环连接。改成 0.0.0.0 表示监听所有本地 IPv4 接口，并不等于只允许家庭网络访问。若设备同时连接其他网络，也可能在相应接口提供服务。需要局域网共享时，应同时考虑系统防火墙、允许访问的来源以及入口认证，不能只打开客户端里的一个开关就认为访问范围已经受到限制。

port 是本地监听端口，与节点服务器端口独立。修改本地端口后，浏览器、开发工具或其他手动填写代理的应用也要同步更新。端口被占用时，先确认是否已有另一份客户端实例或其他程序监听，不要只反复切换节点。日志中的绑定失败发生在本地入口建立阶段，还没有进入远程协议协商；此时调整服务器 UUID、TLS 或路由并不能解决监听冲突。

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

SOCKS、UDP 与系统代理不是同一开关

示例中的 udp 允许 SOCKS 入站处理 UDP 请求，但它不能让原本不使用 SOCKS 的应用自动进入代理，也不保证后续出站及远端服务支持这类流量。完整链路还涉及应用是否发起 SOCKS UDP 关联、系统网络是否允许传送，以及远端协议组合能否承载。排查时应先用明确支持该方式的应用测试，不要把浏览器网页正常打开当作所有 UDP 场景已经通过验证。

系统代理通常只影响遵循系统代理设置的应用，并不是对整个设备所有连接的接管。应用如果忽略系统设置，或自行连接目标地址，请求不会因为客户端正在运行就必然进入该入站。客户端中的虚拟网卡或透明接管属于另外的接入机制，还需要处理路由、权限和 DNS。本文先按显式代理解释，查阅时应确认实际使用的是哪一种入口，再根据对应日志判断请求是否到达内核。

sniffing 获取的信息用于哪一步

sniffing 尝试从已接入流量的协议特征中提取目标信息，例如 HTTP 主机名或 TLS 握手中的服务器名称。它不是解密所有应用内容，也不是任意连接都能恢复域名。应用只提供目标 IP，而流量特征又无法识别时，域名路由仍可能没有可用名称。因此，开启探测只能补充部分路由依据，不能替代正确的应用代理设置和完整的 DNS 设计。

destOverride 指定尝试识别的类型；routeOnly 用于表达仅将识别结果用于路由、保留原始目标的意图。该选项应先核对当前内核支持情况，不能把某个客户端界面里的同名行为直接视为全部实现一致。诊断域名规则时，可以对照开启前后的目标记录与出站选择，判断是没有提取到名称、名称未命中，还是匹配后被另一条更靠前的规则截走。

如果确实需要共享入口，先把只限本机的基础配置验证成功，再逐项扩展监听范围和访问权限。不要同时修改监听、认证、系统代理与节点参数，否则连接失败时无法区分是本地访问被阻止，还是上游握手没有成功。完成后再从另一台可信设备验证允许的访问路径，并检查不应开放的接口。有关图形界面中的连接步骤，可返回使用指南按顺序核对。

outbounds 出站：协议账户、默认出口与标签

出站对象描述下一跳

出站决定内核接到请求后怎样发起后续连接。freedom 表示直接连接目标，blackhole 用于阻断，VMess、VLESS 等协议出站则把请求发送到指定代理服务器。远程节点地址是下一跳，不是用户最终访问的网站。阅读配置时应把服务器地址、用户目标和 DNS 服务器分开记录，三者都可能出现域名与端口，但在数据流中承担不同角色。

经典配置中，没有命中路由规则的请求通常交给 outbounds 数组中的第一个出站。因此出站顺序具有实际含义，不是单纯的展示顺序。把 direct 移到第一项，会改变未匹配流量的路径。为了减少误解，可以既安排明确的默认出口，也在路由末尾增加符合预期的兜底规则。调整后应使用新的连接验证，因为已建立的连接不一定随配置变化立刻迁移。

下面是 VLESS 出站的结构示例，只展示服务器与账户字段，不能直接作为已具备传输安全的可连接节点。example.com 是说明用地址，全零 UUID 是演示值；实际部署必须使用服务端提供的参数。尤其不能看到端口为 443 就推断 TLS 已启用，端口号只决定连接位置，是否建立安全层由相应传输配置与服务端共同决定。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "encryption": "none"
              }
            ]
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

账户字段不能跨协议照搬

VLESS 的 encryption 写为 none，描述的是这一协议层的设置，不表示整条连接一定没有保护；实际安全层还要查看 streamSettings。VMess 的账户配置有不同字段和协商逻辑，不能把两者的用户对象直接互换。节点分享链接里的参数也可能使用缩写或不同命名，导入后应以客户端解析出的协议类型为起点检查，而不是逐个把链接查询参数粘进 JSON。

账户身份、传输方式和服务端支持必须组成一套匹配的配置。UUID 正确但传输不符，可能在账户认证之前就断开；安全层建立成功但身份字段错误，也仍然无法完成代理请求。日志中连接已经到达服务器并不等于账号已经通过验证。需要了解两种协议的取舍，可阅读VMess 和 VLESS 区别对照，再回到具体节点核对字段。

直连与阻断也需要明确命名

direct、proxy、block 是本文采用的标签，不是内核自动创建的固定对象。规则写了 outboundTag: "block"，就必须存在对应出站。直接连接仍可能涉及域名解析、IPv4 与 IPv6 选择、系统路由和本地防火墙，并不是绕过所有网络配置。某个目标通过直连失败，也不能据此断言代理出站一定损坏；应分别测试两条路径。

客户端支持多个节点，不意味着运行配置会以同一种方式排列所有出站。部分模式只生成当前节点，部分模式会生成额外出站或内部链路。切换节点后手写规则如果引用了已不存在的标签，就可能失效。长期维护时应优先使用客户端允许的固定路由目标，并检查最终生效配置，而不是依赖一次导出时看到的临时名称。多个出站同名也会让引用含义不清，应避免这种写法。

订阅更新后，服务器地址、端口、传输参数和节点标识都有可能变化。不要只保留旧地址再拼接新账户字段，也不要把不同节点的安全层参数混合。先保存一份可工作的客户端配置，再导入更新并单独测试一个节点。如果需要理解分享链接与原生配置的对应关系，可查阅订阅格式与分享链接对照，区分订阅容器、节点描述和最终运行配置。

routing 路由：规则顺序、匹配条件与兜底

从上到下检查第一条命中规则

路由模块根据已经接入内核的请求属性选择出口，不负责让尚未进入内核的应用流量自动出现。经典字段规则通常按数组顺序匹配，第一条满足条件的规则决定结果。规则越靠前，优先级越高。因此最先排查的不是列表里“有没有那条规则”，而是请求在抵达它之前是否已被其他规则接走。宽泛的全流量规则应放在后面，否则后续精细规则没有参与判断的机会。

同一条规则里，不同类别的条件通常需要同时满足；同一个数组中的多个候选值通常表示任选其一。例如一条规则同时包含 inboundTag 和 domain，含义是来自指定入口且域名满足条件，而不是满足入口或域名任意一项。希望表达两个独立场景时，拆成两条规则比把所有字段塞进一条更清楚，也便于在日志中逐步定位。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["socks-in"],
        "domain": ["full:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "127.0.0.0/8",
          "::1/128",
          "fc00::/7",
          "fe80::/10"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

域名规则与地址规则的边界

full:example.com 表示精确域名匹配，domain:example.com 用于匹配该域名及其子域名。裸字符串与正则规则又有不同语义，不能仅凭文字看起来相似就认为覆盖范围一样。处理单个网站例外时，先用精确匹配建立可验证结果，再按需要扩大范围。正则表达式还要经过 JSON 字符串转义，反斜杠层级错误可能导致规则含义改变，即使文件仍能正常加载。

IP 规则匹配目标地址或路由过程中获得的解析地址，不是把浏览器地址栏里的域名当作地址直接比较。应用若只提交一个 IP，且没有可用域名信息，域名规则可能无法参与。反过来，应用提交域名时是否触发额外解析，与 domainStrategy 有关。把域名列表写得很完整，也无法修复入口没有接收到请求、目标信息缺失或规则顺序不当的问题。

IPIfNonMatch 不代表每个请求都先解析再逐条检查。若域名阶段已经命中宽泛规则，可能根本不会进入期待的 IP 匹配过程。示例末尾的 network 规则就是显式代理兜底，使用时要注意它与解析策略的组合：如果希望域名请求先依据解析结果判断私网地址，应重新设计规则或选择适合的解析策略，而不是假定前面的私网 IP 列表必然优先处理所有域名。

资源文件与规则结果要分别验证

geosite: 与 geoip: 形式依赖客户端或内核能够读取对应分类数据。类别名存在与否、数据是否可用、内容如何更新，都应在实际环境确认。资源缺失是配置依赖问题，域名分类不符合预期是数据覆盖问题，两者不要混为一谈。首次调试可以使用明确域名与明确网段，验证路由逻辑后再加入分类集合，避免同时处理过多未知因素。

验证规则时，先记录入口标签、请求目标、传输类型以及最终出站，然后只改变一个条件。已有网页连接、后台连接池和应用缓存可能继续沿用旧路径，最好关闭原连接再发起新请求。规则命中只说明内核选择了某个出口，不说明远端必然可达。若出站选择正确但请求失败，下一步应转向出站握手、DNS 或目标服务，而不是继续重排已经证明有效的规则。

dns 配置：解析来源、匹配范围与连接依赖

先确定是谁在解析域名

一个请求可能经过应用自身 DNS、系统解析器、内核内置 DNS，以及远端代理环境的解析。配置了顶层 dns，不表示设备上所有应用的域名查询都被接管。显式代理中，应用可以把域名交给代理，也可以先解析后只交出 IP；这两种请求为路由留下的信息不同。查问题前应先确定应用提交的目标形态，而不是只看客户端 DNS 设置页填写了哪个服务器。

内置 DNS 主要为内核需要解析地址的环节服务，例如路由策略要求获取 IP、部分出站需要解析目标，以及某些域名连接过程。是否走内置解析，还取决于对应模块与选项。系统代理设置通常不会改写系统 DNS。若网页可用但其他应用异常，可能是应用使用了不同解析路径；此时应分别验证应用接入与解析来源，不能把所有失败都归结为 DNS 服务器不稳定。

下面的局部配置使用公开解析地址说明服务器列表与静态映射结构。hosts 里的测试名称指向文档保留地址，只用于观察映射行为，不提供实际网站服务。实际使用时删除这条演示映射，并根据网络可达性、解析需求与隐私要求选择解析服务。示例并不要求所有环境固定使用这些地址，更不能据此推断访问结果一定适合当前网络。

{
  "dns": {
    "hosts": {
      "full:resolver-test.example": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

域名范围与回退行为要配套考虑

服务器对象可以包含 address、domains、expectIPs 等字段，用于描述解析服务地址、优先匹配范围和预期结果。域名范围不是简单的访问规则：解析请求匹配某台服务器，并不意味着实际网站连接也会使用相同出站。解析路径与业务路径需要分别配置，再检查二者是否符合预期。不要把 DNS 服务器分组直接等同于路由里的代理与直连分组。

在支持这些字段的经典配置中，expectIPs 用来判断解析结果是否符合预期，skipFallback 和相关回退选项会影响未匹配或结果不符时的处理。不同内核的回退细节应以实际实现为准。不要把多个服务器列表理解为始终严格按书写顺序逐个尝试，也不要假定配置一台后备服务器就能覆盖所有失败。应通过日志观察实际发出的查询与返回结果，再决定是否收紧匹配范围。

queryStrategy 影响内置 DNS 查询的地址族，常见取值包括 UseIP、UseIPv4 和 UseIPv6。仅返回 IPv4 可能绕开某些 IPv6 路径问题，但这不是对整个系统禁用 IPv6，也不是长期修复所有连接失败的通用办法。如果系统本身的 IPv6 路由不可用，应先确认问题位置；应用自带的解析器也未必遵循这里的查询策略。

解析服务器本身也需要可达路径

使用加密 DNS 时，除了查询内容，还要考虑解析服务地址如何建立连接，以及它自身的域名由谁解析。若代理服务器地址需要 DNS，而 DNS 连接又依赖尚未建立的同一代理，就可能形成启动循环。设计时应为必要的引导解析保留明确路径，并核对相应 DNS 协议在当前内核中的支持方式。不要仅把一个 HTTPS 地址填入服务器列表，就认为连接依赖已经自动解决。

hosts 可以对少量名称提供明确映射，但长期固定网站地址可能与负载均衡、地址变更和证书使用场景冲突。用于排错时，应记录原始结果、映射前后的变化以及撤销方式。改动 DNS 后，系统、应用和内核都可能持有缓存，验证要使用新请求，并在必要时按客户端提供的方式清理缓存或重启相关进程。只刷新网页并不保证重新发生解析。

比较结果时，不只记录是否“能打开”，还要区分查询超时、返回空结果、地址族不可达与后续连接失败。域名能解析但目标端口拒绝连接，问题已转到连接层；直接使用 IP 可达而域名请求失败，也还需核对安全层要求的服务器名称。相关概念可在路由与 DNS 术语中继续查阅，再按本页验证章节逐环节收敛问题范围。

policy 策略：用户等级、超时与统计

策略不是出站选择规则

policy 管理连接处理与统计方面的行为，不负责按域名选择代理出口。路由里的 domainStrategy、DNS 的查询策略、用户等级策略属于不同层级，虽然中文界面可能都含有“策略”二字，却不能互相替代。需要改变网站走直连还是代理，应查阅路由；需要解释连接为何在空闲一段时间后结束，才应进一步检查超时、应用行为与服务端限制。

levels 是以等级编号为键的对象。键名在 JSON 中仍然写成字符串，例如 "0"；账户对象中的 level 则通常是数字。等级用来把用户或相应处理过程关联到一组策略，不是节点速度评分，也不是界面里排列节点的优先级。没有显式设置等级时，许多配置会落到默认等级，但具体适用模块与缺省行为仍应核对当前内核。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 8,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": false,
        "statsUserDownlink": false
      }
    },
    "system": {
      "statsInboundUplink": false,
      "statsInboundDownlink": false,
      "statsOutboundUplink": false,
      "statsOutboundDownlink": false
    }
  }
}

理解各类时间限制的触发阶段

handshake 约束支持该策略的协议处理过程中等待握手完成的时间，不能把它当作所有网络连接阶段共同使用的总超时。连接服务器、TLS 协商、代理协议认证与应用请求各有上下文。示例值只是便于说明单位和结构的起点，不是针对所有网络推荐的最优值。弱网络下适当放宽可能有帮助，但认证参数错误不会因为等待更久而变正确。

connIdle 表示连接在没有数据活动时允许保持的时间。把它设置得过短，可能影响长时间静默后继续使用的会话；设置得很长，则可能让闲置连接占用更多资源。是否保持连接也受应用、远端服务和中间网络设备影响，因此不能只凭一次长连接中断就认定此字段生效。先看断开前是否存在实际流量，再结合客户端与服务端日志判断哪一端主动结束。

uplinkOnly 与 downlinkOnly 用于一侧流结束后，另一侧仍可继续传输的等待阶段。这里的上下行以连接处理方向定义，不是带宽上限。下载已完成而上传方向关闭，或应用主动半关闭连接时，相关策略可能影响收尾过程。它们不能用来控制下载速度，也不应为了“加速”随意归零。应先确认问题是否发生在连接建立、持续传输还是连接收尾。

统计开关与统计展示分开处理

开启用户统计通常还需要配合顶层统计模块、可识别的用户信息以及读取统计的接口或客户端能力。单独把 statsUserUplink 改为 true，不会自动出现一张流量图。不同协议支持的用户标识与统计维度也可能不同。排查统计为空时，要先确认实际流量经过哪个入口和账户，再查看是否真的启用了对应计数，而不是立即怀疑代理连接没有建立。

系统级入口与出口统计按对应对象汇总，用户统计则按账户维度处理。它们可能因为统计位置、重连、连接复用和计数重置而呈现不同结果，不能要求每个读数在任何时刻完全相同。客户端显示的速度也可能来自定期采样后的差值，而不是配置中的固定参数。调整统计不应同时改变路由与节点，以免把数据采集差异误判为实际转发路径变化。

多数个人桌面场景可以先保留客户端生成的策略，只有复现出明确的空闲断开、握手等待或统计需求时再调整。每次记录原值、修改原因与验证条件，并保留恢复入口。内核策略无法覆盖操作系统休眠、移动网络切换、远端超时或应用自身连接池管理。把所有超时都调大，会延后错误暴露，却未必改善真实连接质量；有证据地修改比统一套用所谓优化参数更可靠。

传输与安全层：streamSettings、TLS 与 flow

协议、传输和安全层分开核对

节点配置至少涉及代理协议、承载传输与连接安全三个维度。VLESS 或 VMess 描述代理协议；TCP、WebSocket 等描述承载方式；TLS 或 REALITY 描述相应安全机制。界面把它们放在同一张表里，不代表这些名称可以填入同一个字段。连接失败时，先按三个维度分别对照服务端资料，再检查额外参数，比只反复切换“协议类型”更容易识别不匹配。

streamSettings 通常与出站的 settings 并列。前者说明怎样建立承载连接，后者说明代理协议本身的服务器和账户参数。下面给出经典 WebSocket 与 TLS 的局部结构，用于说明字段位置。它需要与实际出站合并，且服务器必须提供对应服务。网络名称与传输配置在不同内核演进中可能存在别名或变化，复制前应核对正在运行的实现。

{
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com",
      "allowInsecure": false
    },
    "wsSettings": {
      "path": "/proxy",
      "headers": {
        "Host": "example.com"
      }
    }
  }
}

地址、serverName 与 Host 各有用途

出站中的 address 是实际连接的下一跳地址；serverName 用于 TLS 服务器名称相关处理；WebSocket 的 Host 属于 HTTP 请求信息。三者可以在合法部署中不同，但不能因为“看起来都是域名”就随意互换。服务端如果通过服务器名称或 HTTP 主机名分配站点，某个字段错误就可能连接到别的服务，即使地址和端口本身可达。

path 必须与服务端约定的 WebSocket 路径一致，包含大小写、前导斜杠及可能存在的查询部分。HTTP 404 或升级失败有时反映的是路径或反向代理转发配置不匹配，而不是账户身份错误。应先确认请求到达预期服务，再检查代理协议认证。TLS 握手失败则发生得更早，此时反复修改 WebSocket 路径往往不会改变结果，因为 HTTP 层还没有开始工作。

allowInsecure 应保持为 false，证书验证异常时先检查系统时间、服务器名称、证书有效范围与部署状态。关闭验证会掩盖重要错误，并不能修复连接到了错误服务这一事实。某些环境需要额外的受信任证书设置，应按实际证书链处理，而不是通过全局跳过验证来替代。排错记录中应保留具体错误类型，避免只留下“TLS 失败”这类信息不足的描述。

REALITY 与 Vision 有明确适用范围

REALITY 是 Xray 生态中的相关安全能力，不能假定 V2Fly 或任意导入器都支持相同字段。服务端提供的名称、公开参数、短标识和客户端指纹需要成套对应，字段名则应以当前内核与客户端支持的结构为准。不要从不同教程中分别复制一段再组合成节点，也不要把用于其他目的的私密材料填进客户端。需要深入理解机制，可阅读REALITY 与 XTLS Vision 原理解析。

flow 位于相应协议账户设置中，xtls-rprx-vision 只适用于支持它的服务端与传输组合。它不是普遍适用的速度选项，也不应给所有 VLESS 节点统一补上。服务端未配置对应流控时，客户端单方面填写可能导致连接失败。指纹字段同样是特定安全层中的选项，不能替代正确的服务器名称，更不能凭指纹名称推断实际浏览器的全部网络行为。

多路复用 Mux 与上述安全层也是不同概念。它尝试让多个逻辑请求共享承载连接，是否合适取决于协议支持、传输组合和业务流量。默认开启并不保证更快，对某些组合还可能不适用。遇到只有并发或长连接场景失败时，可在其他参数保持不变的前提下做对照测试。不要把关闭 Mux、修改 flow、替换指纹和调整 TLS 同时作为一次改动，否则无法知道真正起作用的是哪一项。

把节点导入成功视为“字段被解析”即可，不应直接视为所有传输能力已被验证。客户端可能保留不了另一内核的扩展字段，也可能在编辑界面保存时重新生成配置。应在导入后检查关键参数，再进行一次新连接测试；需要换用支持相应能力的客户端时，从下载页选择对应平台，并保留原配置作为对照，避免排错过程中失去可工作的参照。

配置验证：加载检查、日志定位与回退

分开验证语法、加载和实际请求

配置验证分三个层次。第一层是 JSON 语法，确认括号、逗号、字符串和数据类型有效；第二层是内核加载，确认字段、协议、资源与引用可被当前实现接受；第三层是实际请求，确认应用进入正确入口、路由选择符合预期、出站握手成功并获得目标响应。前一层通过不能替代后一层。尤其是局部示例合并后，需要重新检查完整文件，而不是只验证刚复制的那一小段。

图形客户端优先使用自身提供的配置检查、日志与重启内核功能，具体入口随客户端界面而变化。修改前保留原配置或导出副本，修改后确认保存动作确实完成，再重新加载内核。若客户端自动生成配置，应检查保存的界面选项而不是只编辑运行目录中的临时文件。看到进程存在也不等于新配置已成功加载，旧进程仍在服务或新进程启动后立即退出，都需要从日志辨认。

定位问题时可以暂时提高日志详细程度。下面是局部日志设置，适合短时间观察目标、连接过程与路由结果。详细日志可能包含访问域名、服务器地址和账户相关上下文，不宜长期收集或原样公开。记录到足够证据后，应恢复较低日志级别，并按本机文件管理方式处理不再需要的记录。提供排错材料时，保留错误行及必要上下文即可。

{
  "log": {
    "loglevel": "info"
  }
}

沿数据流逐段确认

第一步确认请求到达入站。用一个明确遵循代理设置的应用发起新请求，并查看日志中是否出现相应目标。如果没有记录，先查应用代理类型、监听地址、端口和系统代理生效范围。第二步确认路由出口。若日志显示的出站与预期不同，再检查标签引用、规则顺序与目标信息；此时不应先修改账户身份。第三步才检查远端连接、安全层与代理协议握手，最后观察目标服务返回。

错误文本需要结合阶段理解。“连接被拒绝”一般表示对应地址和端口没有接受连接，可能来自本地入口，也可能来自远端；“超时”可能发生在解析、建连或等待响应；证书错误则通常需要检查安全层上下文。不要只摘取最后一个词下结论。把报错前的目标、端口和所用出口一起记录，才能判断这条错误属于哪一段连接。重复点击测试但不保存上下文，通常不会增加有效信息。

建立可回退的最小改动流程

每次只改一个独立变量，例如先修正监听端口，验证后再调整域名规则。涉及多项必须同步变化的节点参数，则把整组作为一个变更单元，并保留完整旧组用于回退。验证使用相同应用、相同目标和新的连接，避免一轮测试用网页，下一轮改用不同协议的工具。若问题只在特定应用出现，也要检查该应用是否自带解析、连接复用或代理绕过设置。

延迟测试也只能证明它实际覆盖的链路。TCP 建连成功不表示代理认证成功，真连接请求通过不表示大文件吞吐稳定，下载速度正常也不证明每条域名路由都符合预期。可以结合v2rayN 测速方法说明理解测试范围。对路由问题应优先观察出口，对解析问题应优先观察查询，对吞吐问题再进行持续传输测试，不用单一数值概括全部配置状态。

迁移到另一台设备或另一种内核时，不要只复制最终 JSON 就结束。系统权限、监听冲突、分类数据、证书信任和客户端生成规则都可能不同。先在新环境完成最小入口与单节点连接，再逐步恢复自定义 DNS、路由和策略。路由器或旁路由还涉及系统层转发，可另读OpenWrt 运行 Xray 的部署思路，不要把桌面显式代理配置直接视为透明接管方案。