V2Ray JSON 配置参考

JSON 结构总览与配置归属

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

JSON 配置描述的是代理内核如何接收连接、选择出口、解析域名和管理会话，不等于客户端全部设置。v2rayN 保存的窗口状态、订阅分组、系统代理开关与自动更新间隔，通常属于客户端自己的数据；启动内核时，客户端再依据这些数据生成运行配置。v2rayNG 与 v2flyNG 也有各自的配置管理方式。先确认正在查看的是客户端存储文件、导出的自定义配置，还是本次启动实际使用的文件，否则即使修改内容正确，也可能没有进入运行过程。

内核配置的顶层通常包含 log、inbounds、outbounds、routing、dns 与 policy。其中入站和出站是数组，允许同时定义多个对象；路由与策略是对象，内部再嵌套规则或级别。字段在文件中的书写先后不代表执行先后，真正影响行为的是数组顺序和引用关系。例如路由规则从前往后匹配，而没有命中规则的连接通常使用出站数组的第一项。

建立可阅读的最小结构

下面是完整的本地直连测试配置，作用是检查 JSON 能否加载、回环地址能否监听以及本机能否直接访问目标。它只建立 SOCKS 入站与直连出站，不提供远端代理能力，也不配置系统代理。应用需要明确使用这个 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": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

阅读配置时可以先画出一条逻辑链：应用连接进入带有标签的入站，路由读取目标地址和入站标签，最后把连接交给某个出站。DNS 在需要解析时参与其中，策略则约束握手和空闲连接等行为。这个模型比逐行背诵字段更有用，因为同一个故障可能出现在不同层。例如应用未进入入站时，修改出站协议不会改变结果；出站标签拼错时，修改 DNS 也不能修复引用。

语法、合并与修改范围

本手册统一使用标准 JSON：键名和字符串用双引号，布尔值写成 true 或 false，端口写数字，数组与对象的最后一项后面不留逗号。部分加载器容许注释或扩展语法，但这种容许不能推广到所有客户端。重复键尤其应避免：不同解析器可能覆盖、拒绝或产生难以察觉的差异。把两段配置拼在一起时，应合并同一个顶层对象，而不是连续粘贴两个根对象。

修改前保留一份能工作的基线，并记录修改发生在哪个入口。通过图形界面管理的配置应优先回到对应设置页调整；手工编辑自动生成文件，可能在重启、切换节点或更新订阅后被重新生成。需要长期保留自定义字段时，应先确认客户端的自定义配置模式、覆盖规则和路由导入功能，而不是依赖某个临时文件路径。不同系统的数据目录并不相同，不宜照抄他人截图中的绝对路径。

内核选择也属于阅读前提。V2Fly 与 Xray 的部分协议、传输名称及扩展字段不同，不能因为文件同为 JSON 就假定可互换。先在客户端确认当前内核，再核对该内核识别的字段。遇到未知字段或协议错误，先缩小到对应对象，不要一次替换整份配置。术语含义可配合术语表查阅，操作流程则继续以教程页为主。

inbounds 入站与本地监听

监听地址、端口与协议

inbounds 定义内核接收连接的入口。一个入口至少需要明确协议及相关设置，常用本地入口为 SOCKS 和 HTTP。listen 控制监听地址，port 控制端口，tag 则给路由提供可引用的名称。标签只是配置内部标识，不会自动创建系统代理，也不会使浏览器主动连接。应用是否使用代理，仍由应用自己的代理选项、操作系统设置或其他流量接入方式决定。

仅供本机使用时，将监听地址写为 127.0.0.1 可以明确限制到 IPv4 回环接口。监听 0.0.0.0 意味着接收所有本机 IPv4 接口上的连接，局域网设备是否能够访问还取决于防火墙与网络环境，但暴露范围已经不同。不要为了排错直接扩大监听范围。若确需局域网共享，应同时规划认证、允许访问的来源和系统防火墙，并明确谁能够借用该出口。

端口必须与使用它的应用设置一致。SOCKS 与 HTTP 是不同的接入协议，不能只看端口数字相近就互换。下面片段提供两个独立入口，适用于区分两种协议的本地测试；端口只是示例选择，不代表所有客户端的默认值。若客户端使用混合入口，应遵循它实际生成的配置，不要额外创建重复监听。

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

UDP 与目标识别

SOCKS 设置中的 udp 允许该入口处理相应的 UDP 请求，但它不是让所有程序自动获得 UDP 代理能力的总开关。应用需要支持相应的接入方式，出站协议和远端也需要能够转发此类流量。操作系统的常规 HTTP 代理设置并不等于全机 UDP 接管。遇到网页可用而实时通信失败的情况，应分别检查应用接入、入口支持和出口能力，而不是仅反复切换这个布尔值。

sniffing 用于从部分连接的初始数据中识别目标信息。常见配置通过 destOverride 声明尝试识别 HTTP 主机名或 TLS 服务名，以便在原始目标只有 IP 时帮助域名路由。识别结果并非所有连接都有，也不能解密任意加密内容。协议是否暴露可识别信息、客户端实际启用哪些选项，都会影响结果。不要把开启识别理解成所有域名规则一定能够匹配。

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

上面对象应放进目标入站内部，而不是放在配置根部。是否使用识别结果改写连接目的地，以及是否只把结果用于路由，在不同内核中有额外选项和行为差异。若要保留原始 IP 连接语义，应核对当前内核支持的仅路由选项。识别也不能替代正确的 DNS 设计：当应用通过 SOCKS 提交域名时，本来就可能直接获得域名，不必为了域名匹配额外依赖识别。

监听失败的检查顺序

启动时报地址占用，应先检查是否有另一份客户端或旧内核仍在运行，再检查本次配置是否重复定义了同一地址和端口。更换监听端口以后，浏览器手工代理、应用代理以及客户端写入的系统代理都需要同步调整。只改 JSON 中的数字会让应用继续连接旧端口，看起来像内核没有响应。具体定位方法见本地端口占用与监听端口修改。

若没有启动错误却看不到访问记录，应确认应用确实连接了当前入口，并检查是否存在应用自身的代理绕过列表。再区分 IPv4 回环地址与 IPv6 回环地址，不能假设监听其中一个就覆盖另一个。排错期间可以暂时保留单个入口和单个测试应用，使每次请求都有明确来源；确认入口正常后，再恢复其他入口和复杂路由。这比同时调整多个网络层更容易确定故障位置。

outbounds 出站与标签引用

协议、出口与默认行为

outbounds 描述流量离开内核的方式。直连通常使用 freedom，拒绝连接通常使用 blackhole，远端代理则由对应协议的出站负责。protocol 决定 settings 的结构，不能仅替换协议名而继续沿用另一种协议的服务器字段。路由通过 outboundTag 引用出站的 tag，因此标签应当唯一、可读，并在改名后同步更新引用。

没有命中路由的流量通常交给第一项出站，因而数组顺序有实际意义。把直连移到第一项，相当于改变未匹配流量的去向；把拒绝出站放到第一项，可能造成大量连接立即失败。不要把出站数组当成会自动择优尝试的候选列表。普通出站对象的排列并不会形成失败回退、延迟测试或负载均衡，这些能力需要另外的机制与明确配置。

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

上面片段只定义两个出口，没有定义哪些请求应该被拒绝；只有路由引用 block 时，相关流量才会进入拒绝出站。它可以用于研究路由行为，但不能替代远端服务配置。远端代理对象需要与服务端提供的信息一致，包括地址、端口、用户认证、传输及安全参数。此类信息应从授权来源获取，不应根据其他协议的示例自行猜测，也不应放入公开的故障反馈中。

节点资料与内核能力

VMess、VLESS、Trojan 与 Shadowsocks 的认证字段和安全模型不同。订阅导入的价值之一，是由客户端把分享格式转换为它支持的内部表示，再生成内核配置。转换成功不代表每一个字段都已满足运行条件：某些协议或传输依赖特定内核，另一些链接可能携带客户端不认识的扩展参数。切换内核之前，应先核对目标协议是否被支持，再观察生成结果和启动日志。

远端地址负责建立连接，TLS 服务名负责身份验证，两者可能不同，但不能任意替换。端口也不决定协议类型，同一个端口号可能承载不同服务。连接超时不一定是认证错误；认证拒绝也不一定表现为明确的密码提示，某些服务只会关闭连接。排错时按地址可达、传输建立、安全握手、协议认证的顺序检查，能避免把全部失败都归结为节点失效。

直连解析与出站复用

直连也可能需要 DNS。假如路由选择了 direct，目标仍是域名，那么后续建连仍需要得到地址。路由阶段的 domainStrategy 与直连出站自身的解析选项作用阶段不同，不能因为名称相似就视为同一个开关。希望控制地址族或解析来源时，应分别确认 DNS 模块、路由及直连出站的设置，并通过日志核对实际连接地址，而不是仅观察最终页面能否打开。

连接复用不是所有协议和应用都适合的通用提速选项。它会改变多个逻辑连接共享底层连接的方式，也可能影响故障表现。出现个别站点中断、长连接异常或传输兼容问题时，应先用默认复用设置建立基线，再单独比较。不要同时修改复用、传输、安全验证和路由，否则成功后也难以解释到底是哪项变更起了作用。

更换节点后仍应保留稳定的路由标签设计。客户端可能为当前选中节点生成统一出口标签，使规则不必随着节点名称变化；手工模式则需要自行维护引用。导入外部规则前先对照本地已有出站名称，避免规则中的标签根本不存在。需要按延迟、地区及协议理解节点差异，可另读节点挑选与测试指标说明，但测试结果不改变配置引用必须正确这一前提。

streamSettings 传输与安全参数

代理协议与承载方式分层

代理协议回答怎样认证和转发流量，传输层回答连接如何承载，安全层回答如何保护与验证连接。三者不是同一个字段。VLESS 不等于 REALITY，WebSocket 也不是独立的代理认证协议；同一种代理协议可能搭配不同传输方式，而某种安全方案只在部分内核与组合中可用。解释配置时先把这三层拆开，才能判断分享链接中每个参数究竟应落在哪个对象。

streamSettings 常位于需要相关传输的入站或出站对象中，network 指定传输类型，security 指定连接安全方式，随后由各自的设置对象提供参数。它不能独立建立远端连接，也不能弥补认证资料缺失。下面是采用传统 TCP 命名的 TLS 局部示例，应只用于当前内核确实接受该命名、且服务端提供对应承载方式的配置，不能跨内核盲目粘贴。

{
  "streamSettings": {
    "network": "tcp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.org",
      "allowInsecure": false
    }
  }
}

示例中的 example.org 是文档演示域名，不是可供代理连接的服务地址。实际使用时，服务名必须与授权服务提供的证书身份和配置要求一致。若内核文档使用其他传输命名或不同设置结构，应采用对应结构，不要只把字符串换成看起来相近的名称。兼容性判断应依据当前运行内核的配置规范，而不是依据客户端按钮的中文翻译。

TLS 服务名与证书验证

serverName 用于 TLS 服务身份相关处理，常与证书名称及服务端选择有关。远端连接地址可以是 IP，也可以是域名；即使使用 IP 建连，也可能需要正确的域名服务名才能完成预期握手。反过来，随便填入一个常见域名并不能使证书有效。证书名称不匹配、证书链不完整、系统时间错误以及中间设备干预，都会造成安全握手失败。

allowInsecure 不应作为默认修复选项。关闭身份验证可能让表面上的证书报错消失，却同时改变了安全边界。排错先核对系统日期、服务名、证书有效期与信任链，再检查网络中是否存在替换证书的设备。若服务明确使用自建信任体系，应按其管理流程配置受信任证书，而不是把所有异常统一转化为跳过验证。订阅更新证书问题与节点握手证书问题也应分别记录。

WebSocket、路径与中间转发

采用 WebSocket 时，路径、请求主机与反向代理转发规则通常需要相互对应。TLS 服务名、HTTP 请求中的主机字段和底层连接地址有不同职责，即使它们在某个部署中恰好相同，也不代表可以混用。路径大小写、结尾斜杠或被中间代理改写，都可能让请求到达普通网页而不是预期服务。此时表现可能是 HTTP 状态错误，而不是传统的代理认证失败。

排查传输问题时，先确认服务端公布的承载类型，再检查是否需要 TLS、请求路径和主机信息。不要用是否能在浏览器打开某个网站来证明代理传输已经可用：普通网页访问与特定升级请求经过的服务分支可能不同。对于由客户端导入的节点，优先检查界面保存的参数是否完整，再查看生成配置，避免在自动文件与界面之间来回修改导致来源混乱。

传输和协议功能也存在内核差异。v2rayNG 与 v2flyNG 分别面向不同内核生态，不能把一个客户端成功识别的所有链接参数视为另一个客户端必然支持。桌面端 v2rayN 的内核选择同样需要与节点能力对应。遇到未知传输、字段不被识别或握手阶段立即中断，应先确认能力匹配，再考虑网络问题；不要通过连续切换多个参数去碰运气。

有条件时，每次只验证一个承载组合：固定远端资料，保留默认的连接复用与策略，先确认基本握手成功，再逐项恢复高级设置。记录错误发生在解析配置、建立 TCP、进行 TLS 还是交换代理数据的阶段。这样的记录能够直接指向需要核查的对象，也有助于在帮助中心按错误类型查找，而不是重复整个安装过程。

routing 规则顺序与匹配边界

先匹配规则，再选择出站

routing 负责把已经进入内核的连接分配到出口。它不会让尚未使用代理的应用进入内核，也不等于操作系统代理开关。规则一般按数组顺序从上到下检查，第一条匹配规则决定去向，因此应把范围明确的例外放在前面，把较宽的兜底放在后面。若一条规则覆盖了所有 TCP 与 UDP，后续相关规则通常就没有机会生效。

同一条字段规则中的不同条件通常共同约束匹配，而同一个字段数组里的多个候选值通常表示任选其一。例如同时写入入站标签和域名，意图是让指定入口访问指定域名时才匹配；如果希望某组 IP 或某组域名分别进入相同出口，拆成两条规则通常更清晰。不要把多个维度塞入同一条规则后，误以为任意条件满足即可。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:example.org"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "::1/128",
          "fc00::/7",
          "fe80::/10"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

这个片段与前文的 direct、block 出站标签配套：精确域名被拒绝，列出的本地地址范围直连，其余仍走默认出站。它演示的是规则机制，不是完整的访问分类方案。尤其在 AsIs 下，域名目标不会仅为了匹配 IP 规则而主动解析，所以不能声称加入私有地址段就覆盖了所有最终解析到局域网的域名。

域名形式与解析策略

full: 用于精确域名匹配，domain: 通常用于匹配指定域及其子域，regexp: 则采用正则表达式。普通字符串匹配的范围容易比预想更宽，查阅性也较差，宜尽量使用明确前缀。正则写进 JSON 字符串时还要经过 JSON 转义，例如正则中的反斜杠需要正确转义。规则看起来像域名列表，并不保证每项都遵循相同匹配语义。

路由的 domainStrategy 常见取值包括 AsIs、IPIfNonMatch 与 IPOnDemand。前者避免为路由匹配主动解析域名；后两者会在各自规定的条件下借助解析结果尝试 IP 规则。是否更早解析会影响请求次数、规则命中和故障路径，但不能简单等同于更快或更准确。应根据规则是否依赖 IP 分类，以及 DNS 是否已经具备可用路径来选择。

规则资源与模式切换

使用 geosite: 或 geoip: 分类时，还要考虑对应资源是否存在、内容是否符合预期以及客户端如何更新它们。分类名并不是内核凭空识别所有网站的能力，而是对资源数据的引用。加载时报资源不存在，应检查资源与规则的配套关系；能加载但结果异常，则需要确认目标实际命中了哪个分类。外部规则名称相同，也不代表不同资源包里的内容完全相同。

客户端的“全局”“绕过”等模式通常会生成或切换一组路由，而系统代理决定哪些应用请求被送到本地入口。切换模式后，手工添加的规则是否保留、插入到什么位置，需要检查实际配置。对两层设置的完整解释见系统代理与路由模式的区别。不要仅凭托盘图标判断所有应用都已使用同一路径。

验证规则时选择一个能够明确区分的目标，先只保留相关例外与兜底，再观察日志中的入站和出站标签。若目标命中了意外规则，应先检查前面更宽的规则、域名是否被应用预先解析以及目标识别是否参与，而不是先增加更多重复条目。确认最小规则有效后逐组恢复分类，这样可以定位是哪一组扩大了匹配范围。

dns 解析路径与地址族选择

区分应用、系统与内核解析

DNS 问题首先要确认查询发生在哪一层。应用可以自行解析，操作系统可以代应用解析，内核也可以在路由或建连阶段解析域名。这些过程可能并存。应用若先把域名解析成 IP 再交给 SOCKS，内核看到的原始目标就可能只有 IP；应用若把域名直接交给 SOCKS，内核则保留了域名目标。两种路径会影响域名路由是否需要额外识别，也影响哪个 DNS 设置真正参与请求。

配置顶层 dns 不等于接管本机全部域名查询。它主要为内核需要的解析提供配置，是否服务应用的 DNS 请求，还要看流量接入和 DNS 转发设计。浏览器自身的加密解析功能也可能走另一条路径。排查时应记录应用是否自行解析、使用什么代理协议以及是否启用其他 DNS 机制，避免仅凭系统网络设置推断所有查询来源。

{
  "dns": {
    "servers": [
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

这个局部片段让内核使用系统解析路径，并允许查询两类地址。它适合用作理解边界的基线，并不表示系统解析在所有网络中都能到达目标。localhost 在这里是内核约定的系统解析方式，不应理解为要求本机一定运行一个监听回环地址的 DNS 服务。若需要独立指定解析服务器，应使用当前内核支持的服务器表示方式，并进一步确认查询如何发送。

解析策略与路由策略分别处理

queryStrategy 控制内核 DNS 查询的地址族策略，常见值为 UseIP、UseIPv4 与 UseIPv6。限制为 IPv4 可能绕开某些不可用的 IPv6 路径，但会使仅有 IPv6 地址的目标失去可用结果。是否支持 IPv6 要看本机接口、默认路由、出口与目标，不能仅凭系统显示有一个 IPv6 地址就判定整条链路可用。

路由中的 domainStrategy 决定何时为规则匹配解析，而 DNS 中的查询策略决定解析时请求哪类地址；直连出站的相关策略又可能决定建连如何使用地址。三者属于不同阶段。修改其中一个字段后看到访问恢复，只能说明该路径发生变化，不能据此证明另外两处设置已经正确。应在保留工作基线的情况下逐一核查，而不是把所有名称相近的策略一并改成同样取值。

按域名选择不同解析服务器时，还要核对服务器对象里的域名范围、期望地址过滤及回退行为。服务器收到回答并不必然意味着该回答会被接受：期望地址条件不满足时，内核可能继续尝试其他路径。复杂分流应先从一个明确可达的解析源开始，再逐步添加分类和回退；否则解析失败可能来自服务器不可达、条件过滤或回退限制中的任意一项。

引导依赖与循环解析

远端服务地址本身如果是域名，就需要在建立连接前获得地址；加密 DNS 服务如果也使用域名，同样需要引导解析。若它的查询路径又依赖尚未建立的代理出口，就可能形成循环依赖。表现通常是启动后持续超时，看不到真正的远端握手。设计时应单独梳理远端地址、解析服务器地址及其出口，确保至少有一条无需依赖自身结果的可达路径。

DNS 查询是否经过路由、是否交由本地解析器，以及加密查询是否使用代理，取决于服务器形式和内核行为，不能仅凭顶层对象位置判断。存在特定本地处理语义的服务器形式时，也不能假定普通路由标签一定对其生效。需要明确核对当前内核的服务器类型说明，随后通过日志和实际请求路径验证。把“已填写 DNS 地址”当成“所有查询都走指定出口”是常见误读。

遇到某个域名失败时，先记录它是否得到回答、回答属于哪种地址族，再判断连接目标地址是否可达。能解析不代表能连接，能连接到地址也不代表 TLS 服务名正确。对于只在一个应用出现的问题，优先比较应用自己的解析设置；对于所有应用一致失败的问题，再检查公共解析路径和出口。更多按现象分类的处理入口见帮助中心，不要直接用关闭证书验证代替 DNS 排查。

policy 会话策略与统计开关

级别策略不是路由优先级

policy 管理会话层面的资源与超时行为，其中 levels 按用户级别组织策略，system 管理系统级统计等选项。级别不是规则优先级，也不是连接速度档位。只有相关协议用户或连接实际采用某一级别时，该级别策略才有意义。客户端生成配置时可能使用默认级别；手工增加一个级别对象，并不会自动把全部连接切换过去。

级别键在 JSON 中写成字符串，例如 "0"，内部字段则按其规范使用数字或布尔值。策略不负责创建出站、不负责修复证书，也不能让未被路由选中的节点自动参与连接。调参前应先确认问题属于握手超时、空闲会话回收还是统计缺失；若错误发生在 JSON 加载或监听端口阶段，策略尚未进入处理过程，修改这些数值不会触及故障原因。

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

上面给出的是显式策略片段，用于说明字段关系，不是推荐给所有网络的固定组合。时间字段以秒表示，具体生效场景与内核实现有关。若现有配置没有明确的问题，保持客户端生成的默认策略通常比照抄一组“优化参数”更容易维护。每一次调节都应有可重复的故障样本和观察目标，不能仅凭某次网页加载感觉判断策略优劣。

握手、空闲与单向连接

handshake 限制相关握手阶段可用的时间，但不是所有底层超时的统一上限。域名解析、传输建连和应用自身的等待策略可能另有机制。握手设置过短，在响应较慢时容易造成提前断开；设置很长则可能让不可用连接占用资源更久。排错应先观察错误发生在连接生命周期的哪个阶段，再判断它是否确实受这个策略字段控制。

connIdle 关注无数据交换的空闲连接。下载过程中持续有流量的连接，与长时间静默的消息通道不属于同一种情况。某些应用通过心跳保持会话，心跳间隔与内核空闲回收、中间设备的会话超时都可能相互影响。把空闲时间无限拉长并不能阻止路由器或远端主动回收，也不能修复丢失的网络路径。

uplinkOnly 与 downlinkOnly 处理会话进入只剩某一方向传输时的等待行为。半关闭连接在一些协议中属于正常过程，而不是立即可以判定的失败。对上传、流式响应或长轮询有特殊需求的应用，应先用默认策略验证，再根据日志和连接表现做单项比较。随意把等待时间缩得很小，可能让剩余响应尚未传完就结束会话。

统计依赖与资源边界

开启统计标志不等于客户端界面一定出现数字。内核还可能需要启用统计模块、提供读取接口，并由客户端主动查询。用户级统计通常还依赖协议用户身份等必要信息，匿名本地入口并不会凭空生成可区分的用户对象。若只是需要理解本地连接是否进入某个出口，访问日志往往比搭建统计接口更直接，不应为排错额外开放管理监听。

连接统计、网卡流量和服务计费也可能采用不同口径。传输封装、连接复用、其他进程流量以及采样时机都会影响比较，不能要求几个位置的数字始终相等。配置层面的统计用于观察对应对象的流量变化，不应推导为服务方的最终计费依据。涉及节点流量倍率时，应以服务说明为准，不要通过修改策略字段尝试改变计费结果。

策略调节还需要考虑设备资源。桌面端与 Android 的后台限制、休眠和网络切换方式不同，长连接中断可能来自系统回收而非内核空闲策略。v2rayNG 或 v2flyNG 在后台断开时，应先确认系统电池管理及网络权限；v2rayN 在电脑唤醒后出现异常，则先比较重建连接的结果。只有确认内核主动按策略回收会话，才有充分理由继续调节对应超时。

配置验证、日志与逐层排错

先验证加载，再验证访问

验证顺序应从配置语法开始，再进入内核结构、监听、接入、路由、解析、传输和应用结果。语法正确只表示解析器能读取 JSON，不表示协议字段被支持；内核成功启动只表示基本结构与资源满足加载条件，也不表示远端连接可用。把每层的成功证据分别记录，可以避免“文件能打开所以配置没问题”或“浏览器失败所以节点失效”这类跨层推断。

在客户端里先保存能工作的配置或导出副本，再建立单独的测试配置。优先使用客户端提供的配置测试与日志入口，确认测试的是实际选中的内核。若通过自定义配置运行，应核对客户端是否仍然追加路由、重写端口或合并其他选项。测试文件与运行文件不一致时，再完整的语法检查也无法解释真实行为，因此每次验证都应确认加载来源。

下面命令仅使用 Python 标准库检查并格式化 JSON。它不会验证 V2Fly 或 Xray 的字段语义，也不会启动连接。命令中的 config.json 指当前目录里的本地测试文件；Windows 若使用 Python 启动器，可以用第二条命令。系统没有安装相应工具时，继续使用客户端的测试功能即可，不必为了阅读手册额外改变运行环境。

python3 -m json.tool config.json
py -m json.tool config.json

短时提高日志细节

loglevel 控制日志详细程度，日常可以保持较克制的级别，排错时再短时提高。下面片段打开信息级别的错误日志输出，但未指定文件位置，输出会由实际启动方式接收。访问日志是否写入、写到哪里，以及客户端能否展示，需要分别核对；不要假定提高错误日志级别就必然产生完整访问记录。

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

检查日志先找首次错误，而不是只看最后一句“连接失败”。未知协议通常指向内核能力或协议名称，地址占用指向入站监听，找不到资源指向规则数据，解析超时指向 DNS 路径，证书名称错误指向安全层身份。重复重试会堆积相似记录，应标记一次测试的开始时间，只发起一个明确请求，减少其他应用流量对判断的干扰。

日志可能包含目标域名、地址、订阅链接片段或其他使用信息。分享前应删除认证资料、完整订阅地址和不相关的访问记录，只保留错误类型及必要字段。不要把整份含用户资料的配置贴到公开问答中。完成排错后恢复正常日志级别，检查本地日志保存位置和轮转方式，避免长期积累没有继续分析价值的记录。

最小复现与回退闭环

若入口正常而访问失败，可以先用本页直连基线验证应用到本地入口，再恢复一个已知资料完整的远端出站。接着加入单条路由，最后恢复 DNS 分类和策略。每一步都使用同一测试应用与目标，记录成功或失败及对应日志。这样能把问题定位到某次变更，而不是在包含大量节点、资源和覆盖规则的配置里同时搜索多个可能原因。

对于订阅更新失败，应把“下载订阅内容”与“使用订阅节点连接”分开验证。前者可能受链接状态、客户端更新路径或证书问题影响，后者则依赖节点参数与内核。节点还能访问并不能证明订阅地址仍有效，订阅可以更新也不能证明所有节点可连接。具体分支见订阅更新失败排查，不要在更新错误出现时先重写整个路由对象。

跨平台迁移时，通常可以沿用配置的逻辑设计，但文件路径、监听冲突、系统代理和后台运行限制需要重新检查。Windows 与 macOS 的初次启动问题可参考首次安装与初始设置；Linux 还应区分桌面会话中的代理设置与应用自身环境，Android 则要留意系统网络接入与后台管理。迁移成功的标准是应用请求按预期进入并离开内核，而不是文件复制没有报错。

最终收尾应包括保存工作配置、恢复常规日志级别、确认标签引用、检查监听范围，以及验证重启后修改仍然存在。随后再测试浏览、下载和需要长连接的实际应用，避免只用单一网页代表全部场景。字段含义不清时回到相应章节；需要重新建立操作主线时，使用快速上手教程。手册用于解释配置关系，教程用于按顺序完成操作，两者不应互相替代。