V2Ray 配置文件
结构与规则参考

JSON 结构与配置边界

一份配置文件描述的是内核如何接收连接、选择路径并建立出站连接，不是客户端所有设置的合集。窗口位置、订阅分组、更新周期、系统代理开关通常由图形客户端保存；监听端口、协议参数和路由规则才会进入运行配置。先把这两层分开，才能判断应该修改界面选项、自定义模板，还是一份独立 JSON 文件。

顶层对象与数据类型

JSON 最外层是一个对象，字段名和字符串使用英文双引号。对象用花括号表达，数组用方括号表达，端口通常写成数字，布尔值写成小写的 true 或 false。最后一个成员后面不加逗号。不要把中文引号、注释或复制页面时带入的不可见字符放进文件；某些工具能容忍的写法，不代表所有内核入口都能读取。

inbounds 和 outbounds 都是数组，因为一个进程可以同时提供多个入口，也可以定义多个出口。routing、dns、policy 则是对象，各自管理规则、解析和连接策略。字段名区分大小写，标签也是精确匹配；把 outboundTag 写成别的大小写，不能期待程序自动纠正。

{
  "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": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

先读懂最小配置

上面是一份本地 SOCKS 入站直连出站的完整基础示例。应用把请求交给本机的指定端口后，内核通过 freedom 使用当前网络建立连接。它不包含远程代理服务器，也不会自动设置浏览器或操作系统代理。它的用途是确认配置能加载、端口能监听、应用能进入内核，而不是演示远程节点连接。

这个示例没有写路由，未被规则选择的连接会使用第一个出站。因此出站数组的顺序具有实际含义，不能只把它当作展示顺序。后续加入远程出站时，应明确设计默认路径；否则看似只添加了一个节点，实际上可能改变所有未命中规则的请求。建议先写出“默认走哪里”，再安排数组和兜底规则。

完整文件、片段与客户端模板

配置片段只展示某个字段附近的结构，例如一个 routing 对象或者一项出站。合并时要放回同名顶层字段，而不是把两个完整对象直接前后拼接。一个顶层字段也不要重复出现；不同解析器对重复键的处理可能不同，表面能启动并不意味着两份规则都生效。更稳妥的做法是整理成一个明确的数组或对象。

图形客户端通常会根据当前服务器、路由预设和本地端口生成运行文件。直接编辑这份文件后，下一次切换服务器或重启内核，修改可能被覆盖。应先查看客户端提供的自定义配置、路由编辑或导入入口。只有确定文件由用户独立管理时，才把它作为长期配置源；不要同时让界面和手工编辑竞争同一字段。

缺省字段会采用内核默认值，但默认值不应成为理解配置的障碍。对安全边界、默认出站和路由解析策略，建议明确填写；对尚未使用的复杂功能，则先省略。查阅示例时还要确认内核家族，V2Fly 与 Xray 的基础形态接近，不代表每个扩展字段通用。出现未知字段或启动错误，先核对支持范围，再考虑网络因素。

保存时保留一份可用基线，并把修改目的记在文件旁的普通笔记里，不要向严格 JSON 中插入说明文字。每轮只更改一组相关字段，加载成功后再测试对应行为。这样能把“语法错误”“结构放错层级”和“连接参数不匹配”分开处理，避免一次复制大段配置后失去可回退的状态。

inbounds 入站与本地监听

入站是应用把连接交给内核的入口。配置中最先需要确认的不是远程服务器，而是应用实际连接了哪个本地地址、哪个端口、使用哪种代理协议。即使远程节点参数完全正确，浏览器仍指向旧端口，也不会进入这份配置。排查时应把应用代理设置与入站监听放在一起对照，而不是只看客户端是否显示运行中。

监听地址与开放范围

listen 决定绑定的本地地址，port 决定监听端口。仅供本机使用时，优先绑定 127.0.0.1，它是 IPv4 回环地址。应用写 localhost 时，系统也可能解析到 IPv6 回环地址；如果内核只监听 IPv4，而应用只尝试 IPv6，就可能连接失败。诊断阶段可先显式使用同一个回环地址。

监听所有接口与允许局域网设备访问不是同一个开关。扩大绑定范围之后，还要考虑防火墙、设备网络位置和入站认证。没有认证的代理入口不应直接暴露给不受信任的网络。需要共享时，应先明确使用者和网络边界，再配置认证及防火墙来源限制；远程服务器的认证信息不能代替本地入站自己的访问控制。

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

SOCKS 与 HTTP 入口的区别

上面是入站字段片段，两个端口分别提供 SOCKS 和 HTTP 代理。应用选择 SOCKS5 时应连接前者，选择 HTTP 代理时应连接后者。HTTP 代理通过 CONNECT 可以承载 HTTPS 目标连接，所以不能根据目标网址以 HTTPS 开头，就把代理入口误认为必须使用 TLS。代理入口协议与目标网站协议属于不同层次。

SOCKS 入站的 udp 表示允许处理 SOCKS UDP 转发，但它不是全链路 UDP 可用的保证。应用必须支持相应方式，远程出站和服务端也需要承载 UDP，网络路径还要允许对应报文。HTTP 入站不能直接替代通用 UDP 入口。遇到网页正常、某个实时应用异常时，应单独检查它的传输方式，而不是反复更改网页代理端口。

入站标签与嗅探范围

tag 给入口一个可被路由引用的名字。例如浏览器和测试工具使用不同入站，就能通过 inboundTag 区分两类流量。标签本身不会创建监听，也不会限制应用；真正决定应用能否接入的是地址、端口和协议。标签建议保持简短稳定，修改名字时同步修改引用它的路由，否则规则会失去匹配对象。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"]
  }
}

这段 sniffing 对象放在具体入站内部，与 settings 同级。它尝试从支持的协议握手中识别域名，以辅助域名路由。它不能解读所有加密内容，也不能保证每个连接都能恢复域名。对于直接提供 IP 的请求，识别结果可能影响目标处理；是否只用于路由等扩展选项，应按实际内核支持情况确认。

端口冲突与系统代理

监听失败通常需要先看日志中的地址和端口。可能是另一个客户端实例已经占用，也可能是系统服务或其他本地代理正在监听。不要只修改一个数字就结束：改完入站之后，还要同步手动配置的浏览器、终端工具及其他应用。由客户端管理的系统代理通常会随设置更新，但仍应在系统代理页面确认实际值。

系统代理只是告诉遵循该设置的应用去连接某个入口，不等于接管设备的全部连接。部分应用有自己的代理设置，部分应用完全忽略系统代理；这与入站能否启动是两个问题。若客户端提供 TUN 模式，其流量接管、路由和权限还涉及系统侧机制，不能单靠增加一个 SOCKS 入站实现。验证时先用明确支持代理的应用缩小范围。

一次有效的入站测试，应同时确认内核成功启动、目标端口存在监听，以及应用请求能出现在对应日志中。只看到进程存在还不够，配置加载失败后客户端界面可能仍然保留。完成这三步再向下检查出站，可以避免把本地入口问题误判成远程线路故障，也能为后续按入口分流留下稳定的基线。

outbounds 出站与标签关系

出站决定内核接收连接之后，使用什么方式抵达目标。它可以直接连接，也可以交给远程代理服务器，或者按规则丢弃连接。outbounds 中每个对象都要先看协议，再看该协议对应的 settings。不同协议的设置结构并不通用，不能仅修改 protocol 名字，就把一份已有配置转换成另一个协议。

直连、代理与阻断

freedom 表示从当前设备所在网络直接建立连接；blackhole 用于丢弃匹配流量。direct、proxy 和 block 则只是常见标签，并非内置协议。一个名为 direct 的标签如果实际指向远程协议，仍然会走远程出口。因此阅读配置时要同时核对标签与协议，不能凭标签英文推断行为。

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

这段片段可以作为基础测试配置的出口部分。若规则没有选中其他出站，第一个出口通常承担默认路径。客户端生成配置时可能自行安排默认出站和兜底规则，所以手工阅读时应看最终运行文件，而不是只看界面显示的当前服务器名称。新增一项出站不会自动让它获得流量，必须有默认顺序或路由引用与之关联。

远程出站的参数层次

远程代理配置通常包含服务器地址、端口、用户认证及传输安全设置。地址描述实际连接的服务器，端口描述该服务监听位置，用户字段必须符合所选协议。传输路径、服务名称或 TLS 服务器名称则属于其他层级。把这些值全部复制到一个地址栏，或者把链接中的编码内容直接塞入认证字段，都会破坏原本的结构。

订阅和分享链接是交换服务器参数的载体，不等于完整的运行配置。客户端导入后，还会结合本地端口、DNS 和路由生成文件。分享链接能被识别，只说明格式大体可读取，并不证明认证有效、证书匹配或传输端点存在。远程参数应来自有使用授权的服务配置，不应从其他示例中拼凑认证值和路径。

多个出站与切换边界

一个配置可以包含多个远程出站，并由不同规则分别引用。每个标签应具有唯一含义，避免重复命名后无法确定实际引用对象。手工修改标签时，除了路由，还要检查其他可能引用出口的功能。仅在出站列表中调整排列，并不等于建立健康检查或自动切换；没有配置相关机制时，内核不会因为某条路径较慢就自行改走另一条。

某些协议还包含域名解析策略、连接复用或底层套接字选项，这些字段应在基础链路成功后再调整。比如解析策略会影响直连出口如何处理域名，但不能替代路由对象里的域名策略；连接复用会改变连接组织方式，却不负责修正错误的服务器认证。把优化和可用性分开，排错记录才不会混在一起。

远程出站地址如果使用域名，还涉及启动时解析它的问题。解析该服务器域名所需的路径，应在代理尚未建立时也能工作，否则可能出现“为了连接代理先要经过同一代理”的循环。需要通过本地解析、明确的引导解析方案或服务提供方给出的有效地址来打破循环，不能只反复切换客户端的系统代理开关。

配置与客户端的分工

v2rayN 在桌面端适合管理服务器和路由模板；Android 上的 v2rayNG 使用 Xray 生态，v2flyNG 作为 V2Fly 路线的备选。相同的基础出站概念可以复用，但专有协议扩展、传输字段和导入行为应分别核对。选客户端时先看设备平台与配置需求，安装入口统一在下载页，不要把客户端名称当作内核字段填写。

保存远程参数之前，建议逐项对照来源：连接地址、端口、认证、传输和安全必须属于同一份服务配置。建立连接后再观察请求是否真正走到预期出口；连接测试成功不代表所有目标都命中这条路由。若本地直连测试正常而远程出站失败，应把检查范围收敛到服务器解析、握手和认证，暂时保持入站不变。

routing 匹配顺序与分流规则

路由连接入站与出站：它检查目标域名、地址、端口或入口标签，然后选择已经定义的出口。规则一般从上到下检查，先命中的规则决定去向。把精确例外放在前面，把覆盖范围广的规则放在后面，是比记忆某套预设更可靠的原则。没有命中规则的连接，则回到默认出站行为，不会自动按域名所属地区作出判断。

先写目标，再写条件

outboundTag 必须精确对应某项出站的 tag。引用不存在的名字，不会凭空生成出口；具体表现可能是加载检查失败或转发失败。规则中 type 为 field 时，条件字段描述匹配范围。建议先确认可用出口，再逐条加规则，否则很难区分是条件没命中，还是命中后找不到目标出口。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

这个路由片段可以与前文的直连、阻断出口配合使用。blocked.example 是保留示例域名，用于展示精确匹配语法；实际测试时可换成自己有权管理的测试域名。geosite 与 geoip 引用外部规则数据，运行环境需要提供相应数据文件。没有安装匹配的数据集时，不应把加载错误归因于网络线路。

同字段与跨字段的逻辑

同一个域名数组里的多项通常表示任意一项匹配即可；同一条规则里同时写域名、端口和网络类型，则需要这些不同条件同时成立。例如希望“某域名或者某个 IP”走同一出口，通常应拆成两条规则，而不是把域名和 IP 写进一条并期待逻辑或。先画出条件关系，再转成 JSON，能减少表面完整但永远匹配不到的规则。

full: 用于完整域名匹配，domain: 用于指定域及其子域匹配，regexp: 用于正则表达式。未加前缀的字符串匹配范围可能比预想宽，不适合需要严格限定的例外。规则目标是主机名，不是完整网址；通常不要把 https://、路径和查询参数写进域名条件，因为路由并不按网页地址栏全文匹配。

域名策略与 IP 规则

AsIs 不会单纯为了路由的 IP 条件主动解析域名，因此应用交给内核的是域名时，只有 IP 规则不一定得到预期结果。IPIfNonMatch 会在域名阶段未匹配时尝试解析后继续匹配，IPOnDemand 则在匹配需要 IP 的规则时触发解析。两者会增加解析介入的机会，也改变规则顺序产生的实际效果。

解析结果可能包含多个地址，而且目标服务的地址会变化。IP 规则匹配成功不代表这个地址永久对应某个域名；共享基础设施也可能让多个服务使用相同地址段。能用稳定域名表达意图时，优先使用域名条件；确实需要控制本地网段或固定服务地址时再使用 IP 条件。数据集分类也不是证书或服务归属的绝对证明。

{
  "type": "field",
  "inboundTag": ["local-socks"],
  "network": "tcp",
  "port": "443",
  "outboundTag": "direct"
}

这条独立规则表示：来自指定 SOCKS 入口、目标端口为四四三且使用 TCP 的连接走直连。三个条件同时成立才命中，不是对该端口的全局放行。端口描述目标端口，不是本地监听端口。将规则放到数组前部时，还要考虑它是否抢先覆盖后面的域名阻断；规则越宽泛，越需要谨慎安排位置。

默认出口与验证方法

需要显式兜底时，可在规则末尾加入覆盖 TCP 与 UDP 的规则，并指向已经定义的默认出口。它后面的同类规则通常失去作用，所以兜底必须最后检查。若默认采用第一个出站，也应在配置笔记里说明，避免后来重排出口时意外改变行为。不要混淆客户端的“全局代理”模式与系统是否接管全部应用，前者主要描述选路策略。

遇到规则不生效，依次检查应用传入的是域名还是 IP、是否被更靠前的规则截获、标签是否一致，以及数据文件是否可加载。修改后要让内核重新加载对应配置，旧的长连接可能仍沿用原路径。测试时关闭旧连接并重新发起请求，才能避免把连接复用造成的延续行为误认为规则没有更新。

DNS 解析与路由的协作

DNS 把域名转换为地址，但在代理链路中，发起解析的角色不止一个。应用可能在请求交给代理前自行解析，内核可能为路由或直连出口解析，远程服务器也可能解析最终目标。写了一个 dns 对象，只能说明配置了内核解析器，不能据此断定设备上的所有域名查询都经过它。先找出解析发生在哪一层，再选择调整位置。

内核 DNS 的基本结构

servers 指定内核可使用的解析服务器，hosts 可为特定域名提供静态映射。下面使用回环域名映射与示例解析器地址展示结构。它不包含拦截系统 DNS 的入站，也没有修改应用自身的解析设置。替换解析器时要确认当前网络允许访问，并符合所在环境的管理要求，而不是单凭地址看起来常见就直接使用。

{
  "dns": {
    "hosts": {
      "loopback.example": "127.0.0.1"
    },
    "servers": [
      "1.1.1.1"
    ]
  }
}

这里的静态映射适合验证内核解析流程，不是对系统 hosts 文件的修改。只有使用到内核 DNS 的请求才会受到影响，浏览器直接通过其他解析方式得到的地址不会被它追溯替换。正式配置中静态映射也需要维护，服务迁移后旧地址可能失效。不要用固定 IP 长期替代动态服务域名，除非服务方明确提供这种连接方式。

分域解析与回退

在支持相应字段的内核中，服务器对象可以通过 domains 指定优先匹配的域名范围，通过 expectIPs 对响应地址范围作判断。两者含义不同：前者筛选问题，后者检查答案。它们也不等于 routing 规则，DNS 选择了解析器之后，实际业务连接仍要根据出站与路由决定路径。不要把解析器分组误认为连接已经完成分流。

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      "1.1.1.1"
    ]
  }
}

这个例子依赖可用的规则数据集，展示了优先匹配和普通解析器并存的形态。具体回退行为还受内核支持的回退选项影响；不要把数组顺序简单理解成永远串行的主备队列。如果希望严格禁止某类查询落到其他服务器，应查清相应版本的回退开关，而不是只删改一项地址。配置后需分别验证匹配域名和未匹配域名。

解析流量本身的路径

普通 UDP 解析、通过 HTTPS 的解析以及使用本地网络栈的解析方式，实际出口可能不同。部分地址形式由内核内部转发，部分本地模式绕过通常的路由处理。解析器 URL 的写法应遵循实际内核文档，不能仅给普通地址加个前缀就假定走了代理。尤其要检查建立加密解析连接时，解析器主机名本身如何先获得地址。

远程出站域名和远程解析器域名互相依赖，是常见的启动循环。表现可能是首次连接失败、切换网络后长时间等待，或者已有缓存时正常、重启后异常。处理思路是建立一个在代理连接之前可用的引导解析路径，并明确它只负责哪些基础域名。不要为了消除一次超时，把所有解析器和出站都绑到同一条尚未建立的链路。

IPv4、IPv6 与缓存差异

解析得到 IPv6 地址不意味着设备到目标的 IPv6 路径可用；同样，禁用 IPv6 也不是所有超时问题的通用修复。先检查本地网络、远程服务和出站的地址族能力，再决定是否限定解析结果。内核提供的查询策略字段在不同家族中存在差异，应该按实际支持范围配置，避免把网络策略写成一个无法识别的字段。

应用缓存、系统缓存、内核缓存和递归解析器缓存可能同时存在。修改 DNS 后刷新网页仍看到旧行为，并不能立刻证明配置没生效。先重建应用连接，再按需要清理对应层缓存，并观察一次新的查询。测试时使用可控域名或明确记录查询时间；不要依赖某个大型网站地址是否变化来判断解析器是否切换成功。

若网页慢而日志没有明确解析错误，应把首次访问与连续访问分开比较。首次慢可能涉及解析或握手，持续下载慢更可能涉及线路、负载或本地处理。进一步可按网速慢的分层定位方法检查，不要同时更换 DNS、节点和路由，否则无法判断真正起作用的是哪一项。

policy 策略、日志与统计

policy 管理的是连接行为与统计开关，不是另一个域名分流表。它可以按用户等级设置握手等待、空闲超时等参数，也可以控制系统级流量统计。路由决定走哪里，策略决定连接如何被管理；把两者混淆，容易在路径问题上反复调整超时，却始终没有触及实际故障原因。

等级与超时的对应关系

levels 的键是等级编号字符串，等级由支持该机制的协议用户配置关联。某个入站没有显式用户，或者协议不采用相应等级时，不能假定任意等级设置都会影响它。常见起点是确认默认等级，再观察连接行为。不要把等级编号理解成优先级或带宽档位，它不负责把某一组流量自动安排到更快的出口。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    },
    "system": {
      "statsInboundUplink": true,
      "statsInboundDownlink": true,
      "statsOutboundUplink": true,
      "statsOutboundDownlink": true
    }
  },
  "stats": {}
}

这里的时长字段单位为秒，展示结构而非适合所有网络的优化方案。handshake 约束握手等待，connIdle 约束没有数据交换的空闲状态；另两个字段涉及单方向结束后等待另一方向的时间。连接长时间没有业务数据时，超时可能是预期行为。把数值无限增大，只会延后回收，不会恢复已经失效的网络路径。

需要长期维持的业务连接，应先确认应用自身是否有心跳、服务端是否允许持续连接，以及网络设备有没有空闲回收。仅调整内核空闲时间，不能改变中间设备的限制。反过来，把时间调得过短可能让本来正常的低频请求频繁重连。应先记录断开间隔和日志，再判断是哪一层主动结束，而不是把所有断开都归为客户端耗电或后台问题。

统计开关不等于统计界面

示例中同时包含统计对象和系统统计开关，但这并不会自动生成可访问的图表或管理页面。读取统计还需要相应接口及客户端支持，部分计数也依赖入站、出站标签或用户标识。界面数字不更新时，先确认客户端是否真的读取该内核的统计，而不是继续增加路由字段。统计反映处理量，也不能直接解释远端业务为什么失败。

如果要自行配置管理接口，应把监听限制在可信本机范围，并理解接口路由与权限边界。不要为了让一个工具方便读取，就将管理入口绑定到所有网络接口。对于一般桌面用户，优先使用客户端已经提供的统计功能；独立配置只保留确实需要的内容，可以减少不必要的监听和后续维护成本。

日志级别与问题定位

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

这是临时观察连接的日志片段。日常可以使用较克制的级别，排查时短暂提升信息量，复现后恢复。访问日志、错误日志与日志详细程度是不同设置；没有指定文件路径时，还要看客户端如何捕获内核输出。若准备写入文件，应选择可写目录并管理文件大小，不能假定应用安装目录在每个平台上都有写权限。

日志顺序应按时间串联：配置是否加载、入站是否监听、请求是否进入、选择哪个出站、在哪个阶段结束。单独摘出一句超时往往不足以定位，前面的解析失败或握手错误可能才是根因。分享日志前，应去除服务器认证、订阅地址和个人访问目标；保留错误类型、发生阶段及必要的匿名化标签即可。

策略调整的验证边界

连接复用、缓存和旧连接会让策略变更的效果延后。修改超时后，应用已经建立的连接未必立即采用新行为，应该重新启动相关连接再测。测试时维持同一目标和相同操作，记录空闲时间与重连情况，避免把服务器负载变化当成策略收益。只有能重复复现的差异，才值得保留为长期配置。

Android 的后台保活与电池优化还受系统调度影响，并不是增大 connIdle 就能解决。v2rayNG 被系统停止后，内核配置本身无法继续工作，应先查看应用电池权限与运行模式。相关取舍见v2rayNG 耗电与后台运行排查。保持系统层和内核层分别验证，才能避免以额外耗电换来没有实际改善的长超时。

传输参数与 TLS 安全层

同一个代理协议可以运行在不同传输之上，而同一种传输也可能承载不同协议。理解配置时，可从内向外分成代理协议、传输方式和安全层：协议处理用户认证与请求语义，传输负责字节如何抵达服务端，安全层负责相应连接的加密及身份验证。某一层配置正确，不代表其余层会自动补齐。

streamSettings 的位置

streamSettings 通常位于具体出站对象内部，与 protocol、settings 同级。它不是放进协议用户对象，也不是任意写到顶层。下面只展示一段 WebSocket 与 TLS 的传输片段，需要与真实服务提供的出站参数组合。域名采用保留示例名称，路径只是语法演示，不对应可连接的远程服务。

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

这里的服务器连接地址不在片段内，它由出站协议的服务器配置提供。serverName 用于 TLS 服务器名称与证书验证相关处理，WebSocket 的 Host 则用于应用层主机选择。两者在一些部署中相同，在另一些部署中有明确分工。不能因为看起来都是域名，就在没有服务端说明的情况下任意互换。

路径、主机与证书

WebSocket 路径需要与服务端接收端点一致，开头的斜杠、大小写和附加内容都可能影响匹配。路径不正确时，服务器仍可能返回一个正常网页或其他 HTTP 响应，但代理握手并未成立。看到能够打开服务器首页，不等于传输端点配置正确。排查应关注升级握手和内核错误，而不是只测试域名是否能在浏览器访问。

证书验证失败时，先检查设备时间、证书覆盖的域名、信任链以及实际连到的服务。allowInsecure 关闭验证会改变安全边界，不应作为长期修复证书错误的方法。使用 IP 连接而服务证书签给域名时，仍需要按正确服务配置填写服务器名称。证书问题与代理用户认证是两套机制，修改用户标识无法修复域名不匹配。

传输字段不能跨类型套用

切换传输不是只改 network 一个字段。WebSocket 路径、gRPC 服务名称和其他传输的参数分别属于不同设置对象，需要与服务端整体一致。保留一组无关字段有时会被忽略，有时会导致加载或握手异常。建议只保留实际使用的传输对象，并把服务端给出的参数逐项对应，避免混合多份分享链接的内容。

基础 TCP、WebSocket 和 gRPC 等方式在资源占用、连接管理和部署条件上有所不同，但不存在脱离服务端条件的通用最快选项。客户端选择了某种方式，而服务端没有对应端点，连接就无法建立。调优时先保持可用传输不变，再比较同一网络下的实际行为；不要把一种传输的名称直接当成速度保证。

内核家族与扩展能力

V2Fly 与 Xray 属于相关的代理内核生态，但配置能力会分别演进。REALITY 等专有安全能力应使用实际支持它的内核，并按该内核的字段规范配置，不能把名称直接替换到本节 TLS 示例里。相似的 JSON 外观不意味着参数兼容；分享链接导入后，也应确认客户端选用的内核与节点要求相符。

连接复用同样要考虑协议和服务端条件。启用后可能减少部分新建连接成本，也可能在特定链路或业务上产生不同表现。遇到单个长连接异常时，可先回到不额外叠加复用的基线，保持其他参数相同做对照。不要一次同时修改复用、传输、TLS 与 DNS，组合变化过多会让一次偶然成功难以复现。

如果本地入口正常、服务器端口也可达，但日志停在 TLS 或传输握手，应暂时停止调整路由与 policy。先核对系统时间、服务器名称、路径、服务名称及认证是否来自同一条配置，再检查中间反向代理的端点映射。按层排查通常比反复导入订阅更能保留有效线索，也不会把可用规则一并覆盖。

配置合并、测试与故障回退

配置维护的关键不是一次收集更多字段，而是让每次变更都能解释、验证和撤回。开始前确认当前客户端、实际内核、配置来源及默认出口，然后保存一份能够正常运行的基线。基线既包括 JSON，也包括客户端当前的模式和系统代理状态；只保留文件而忘记外部开关，恢复时仍可能得到不同结果。

按依赖关系合并片段

先建立能启动的入站与直连出口，再添加远程出站，然后加入只覆盖一个目标的路由，最后调整 DNS 和策略。这个顺序不是功能限制，而是排错依赖：入口不通时无法验证出口，出口不存在时无法验证规则，基础连接失败时优化超时也没有意义。每一步成功后保存记录，再进入下一层，出现问题时便有明确的回退点。

合并数组时添加成员，合并对象时逐项核对键，不要简单把片段粘在文件末尾。特别留意重复的 routing、dns 和 log 字段，以及多处定义的同名标签。模板工具如果自动生成部分字段，还要判断它是在替换整个对象，还是只追加某个数组；理解合并方式比肉眼看到“内容都在”更重要。

启动前与启动后的检查

先用本地编辑器的 JSON 检查确认语法，再让实际运行的内核检查配置结构。语法通过不代表字段被支持，内核加载通过也不代表远程服务器可连接。错误信息应分层理解：解析错误先看引号和逗号，未知字段先看内核能力，监听失败先看本地端口，握手失败再看远程参数。不要让网络测试掩盖一个尚未成功加载的文件。

测试工具应明确指定代理，避免依赖系统代理状态造成混淆。下面的请求用于验证本地 SOCKS 入口能否处理一个 HTTPS 目标，socks5h 表示把域名交给 SOCKS 侧处理。结果仍受所选出口和网络影响，它不是延迟评分，也不能证明所有应用已接入。Windows 上显式使用程序名，可避免终端环境中同名别名带来的差异。

curl.exe --proxy socks5h://127.0.0.1:10808 --head https://example.com
curl --proxy http://127.0.0.1:10809 --head https://example.com

客户端重建与订阅更新

在 v2rayN 中，切换服务器、切换路由预设或重新启动内核，都可能重建运行配置。若手工修改很快消失，应寻找持久化设置入口，而不是继续编辑临时输出。首次安装位置、写入权限和启动设置，可结合v2rayN 首次安装设置清单检查；基本连接顺序则回到上手教程核对。

订阅更新还可能改变服务器条目、节点名称和可选参数。自定义规则如果依赖某个经常变化的条目名称，要确认客户端如何映射到运行标签，不能假定显示名称永远等于出站标签。多来源管理可参考订阅分组与过滤方法。更新前后保留结构差异，比只记下“更新后失效”更利于定位。

常见问题与恢复顺序

最终的验证记录应能回答四个问题：请求从哪个入口进入、目标以域名还是 IP 表示、命中哪条规则、由哪个出口建立连接。只写“能用”不足以证明分流正确，只写“超时”也不足以判断故障层次。对照这条链路记录一次成功与一次失败，往往就能缩小到少量字段，而不必重写整份配置。

维护完成后，恢复合适的日志级别，删除不再需要的测试入口与临时静态映射，并把长期配置保存到客户端认可的位置。保留精简、可解释的规则，比堆叠多套预设更容易长期维护。后续只想完成连接操作时查阅教程；需要判断字段含义、依赖关系或合并方式时，再按本页目录返回对应章节。