V2Ray JSON 配置文件参考

01 / JSON 结构与连接路径

配置文件描述的是内核行为

图形客户端负责服务器管理、订阅更新、系统代理和内核启动。内核配置负责监听连接、执行路由、解析域名与建立出站。两者有关联，但不是同一份数据。客户端主窗口里保存的服务器记录，通常需要经过转换才能成为内核可读的配置；修改界面上的名称，也不意味着内核里的每个标记都会同步改名。

先把连接路径看成四步：应用连接入站，入站接收目标地址，路由选择出站，出站建立后续连接。DNS 可能在路由匹配或建立连接时参与。日志记录这些阶段的部分事件，策略则影响连接超时和统计行为。配置排查应沿着这条路径前进，不要从浏览器报错直接跳到更换所有 DNS 设置。

对象、数组与字段类型

JSON 的对象使用花括号，数组使用方括号。键名与字符串必须使用英文双引号，端口通常是数字，开关使用不带引号的布尔值。末尾多出的逗号、全角引号、未闭合的括号都会使严格 JSON 解析失败。某些内核或加载方式允许注释等扩展语法，但本页示例保持严格 JSON，方便在不同工具间检查。

顶层通常是一个对象。inbounds 与 outbounds 是数组，因为可以同时声明多个监听入口与多个出口；routing、dns、policy 则是对象，各自包含规则或子配置。重复书写同名顶层键不能表达追加关系，不同解析器可能覆盖前值或拒绝读取，应始终合并成唯一字段。

用完整的直连配置建立参照

下面是一份用于检查本地监听的完整配置。它只提供回环地址上的 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": {}
    }
  ]
}

读取示例时，先找监听地址与端口，再找入站协议，最后找默认出站。没有路由规则时，常见处理方式是使用出站数组的第一项。由此可见，数组顺序并非纯粹的排版问题；在客户端重新生成配置之后，默认出口也应重新核对，不能只检查某个代理协议对象是否仍然存在。

配置中的 tag 是供其他字段引用的标识，不是连接凭据。建议使用简短、唯一、含义稳定的名称。文件名也不决定其作用：叫作 config.json 的文件，只有被当前内核进程实际加载才会生效。查阅后续章节时，始终保留一份能启动的参照配置，每次仅改动一个相关片段。

02 / inbounds：监听地址与入站协议

先确定谁连接这个入口

入站定义内核在什么地址、什么端口接收哪一种连接。桌面应用最常见的入口是 SOCKS 或 HTTP 代理，两者不能只凭端口互换。应用选择了 HTTP 代理，却连接到仅接受 SOCKS 握手的监听端口时，即使端口处于监听状态，也可能立刻收到协议错误。排查时必须同时核对地址、端口和代理类型。

listen 决定监听范围。绑定 127.0.0.1 时，入口主要供本机使用；改为所有接口会扩大可访问范围，还受到系统防火墙与网络环境影响。远端代理协议的加密，并不会自动保护一个开放在局域网里的本地 SOCKS 入口。除非明确需要共享，并已配置访问控制，否则保留回环监听更容易限定边界。

SOCKS 与 HTTP 分开声明

下面的片段并列声明两个入口。SOCKS 使用示例端口 10808，HTTP 使用示例端口 10809。端口不是软件身份标识，修改后应用必须同步调整。两个监听项不能在同一地址上争用同一个 TCP 端口；有其他客户端仍在后台运行时，应先确认占用者，再决定关闭旧进程还是选择新的端口。

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

settings.auth 为 noauth 时，SOCKS 入口不要求用户名与密码。此设置适用于受控的本机监听，不应理解为允许任意网络共享。需要认证时，应按当前内核的 SOCKS 入站定义配置账户，并确认调用方支持相同认证方式。HTTP 入站拥有自己的设置结构，不能直接照搬 SOCKS 的认证字段。

udp 允许 SOCKS 入站处理相应的 UDP 请求，但它不等于给所有应用提供 UDP 代理。应用需要实际支持 SOCKS 的 UDP 转发方式，出站协议与远端服务也要具备相应能力。仅设置操作系统的 HTTP 代理，通常不会让任意 UDP 程序自动经过该 SOCKS 入口；这属于流量进入路径的差别。

嗅探信息与原始目标

sniffing 尝试从受支持的协议握手中获得域名等信息。应用若只提交目标 IP，嗅探可能补充路由需要的域名。示例中的 destOverride 指定可用于目标覆盖的协议类别，但能否提取信息取决于实际流量。它不能解密全部应用内容，也不能保证每个连接都能恢复出最初访问的域名。

启用嗅探可能改变连接用于路由或出站处理的目标信息。部分内核另有仅用于路由的相关选项，字段支持和细节需要单独确认。遇到启用后某个应用异常时，先比较关闭嗅探前后的日志与目标，再检查出站是否接受域名目标，不要把问题归因于入站端口本身。

入站标记还可以被路由中的 inboundTag 引用，用来给不同本地应用入口分配不同出口。此时应保持标记唯一，并为应用明确分配入口。一个常见错误是修改了入站名称，却忘记更新路由规则中的引用，结果连接落入后续规则或默认出站，看起来像是入站设置没有保存。

完成修改后，重新启动或重载当前内核，再检查监听是否成功。系统代理开关属于客户端或操作系统层，不会因增加一个入站对象而自动启用。对照快速上手流程确认应用确实使用了这个入口，然后再进入出站和路由排查，能够减少跨层反复修改。

03 / outbounds：出口、标记与协议参数

出站顺序与路由引用

出站定义内核如何继续连接目标。它可以直连、阻断，也可以通过某个代理协议连接远端服务器。tag 用于让路由规则选择具体出口；protocol 决定 settings 的结构。名字叫作 proxy 的出站不一定真是代理，必须查看协议内容；反过来，代理出站也可以使用其他唯一标记。

在常见配置中，没有匹配规则的连接会交给数组第一项。需要把代理作为默认路径时，应明确控制首项，并保留必要的直连规则。调试时不能为了阅读方便随意给出站数组排序。客户端生成器可能依据当前服务器与路由模式重新排列出站，最终应以正在运行的配置为准，而不是界面列表中的显示顺序。

直连与阻断的最小片段

freedom 表示由本机网络直接建立连接，blackhole 表示阻断相应连接。下面的片段可作为直连测试配置的出站部分，也可以合并进包含代理出口的配置。仅声明阻断出站不会自动阻断任何目标；必须有路由规则选中它，或使它成为默认出站，才会产生对应效果。

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

直连并不意味着跳过域名解析。目标是域名时，仍需要由相应组件把它变成可连接地址；具体使用内置 DNS 还是系统解析，以及地址族的选择，取决于当前内核和出站配置。路由里出现“直连”两个字，只说明出口选择，不足以证明解析请求走了哪条路径。

远端协议字段不能互相拼接

代理出口需要真实的服务器地址、端口与认证参数。VMess、VLESS、Trojan、Shadowsocks 的凭据结构不同，传输层和安全层也有各自约束。本页不提供带虚构账户的代理成品；实际使用时从可信的连接信息生成出站，再检查字段是否与服务端一致。不能把协议名称换掉，却保留另一种协议的用户对象。

传输设置通常位于 streamSettings 等对应结构中。传输类型必须与服务器实际部署一致，协议支持也受内核限制。REALITY 等功能不能被视为任意内核都接受的通用字段。选择内核前，可先看Xray 与 V2Fly 内核区别，再检查客户端生成的配置是否适用。

服务器地址、TLS 服务名、传输层主机字段可能恰好相同，但含义不同。服务器地址决定连接目的地，服务名参与握手与身份验证，某些传输头部供服务端分发请求。遇到握手错误时，应逐项比对来源信息，而不是把所有涉及域名的字段统一替换为服务器 IP。

不要把跳过证书验证当作常规修复。它不能解决协议不匹配、远端端口错误或系统时间偏差，反而会改变身份验证边界。出现证书相关错误时，先检查系统时间、服务名与证书覆盖范围；若服务端使用特殊部署方式，应取得明确的配置说明后再调整安全选项。

最后检查依赖关系：每个路由引用的出站标记都应真实存在，名称大小写保持一致。删除旧服务器产生的出站后，还要清理指向它的规则。需要多出口时，先用两个明确出口完成验证，再引入均衡、链式连接等额外机制；基础路径未确认前增加嵌套，只会让故障位置更难判断。

04 / routing：匹配条件与规则顺序

从上到下选择规则

路由根据连接信息选择出口。常见字段规则使用 type 为 field 的对象，并设置域名、IP、端口或入站标记等条件。通常按数组顺序检查，命中后使用相应出口。应把范围更小、优先级更高的例外放在前面，把宽泛规则放在后面，避免后续规则永远得不到处理机会。

同一条规则内，不同条件字段通常需要同时满足；同一个域名列表或 IP 列表里的多项通常表达备选匹配。想实现“命中某个域名，或者来自某个入站”时，应拆成两条规则，而不是把两个字段并排放在一个对象中。写规则前先用自然语言说清楚“且”与“或”，再映射到配置结构。

用可控目标验证顺序

下面的片段把示例域名交给阻断出口，把私有地址交给直连出口。它依赖上一章的 direct 和 block 出站，并需要当前内核可读取对应的地理数据。示例域名用于验证规则，不代表生产环境的推荐名单。其余连接仍交给默认出站，不会因为两条规则存在而自动变成全局代理。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

域名匹配应区分完整域名、包含子域的域名范围和正则表达式。例如 full:example.com 只匹配指定域名，domain:example.com 用于该域及其子域范围。普通字符串的匹配语义与这些前缀并不相同，容易产生比预期更宽的命中。规则清单应使用能够明确表达意图的形式。

路由解析策略不等于出口解析策略

AsIs 通常不为了 IP 规则主动解析传入域名；原始目标本来就是 IP 时，仍可匹配 IP 条件。IPIfNonMatch 在域名阶段未获得匹配时，尝试解析并进行 IP 匹配。IPOnDemand 则可能在规则检查需要 IP 信息时更早发起解析。三者控制的是路由判断阶段，不是完整的 DNS 流量方案。

以示例为例，传入目标若是完整域名 example.com，第一条即可匹配，不需要依靠后面的私有地址规则。目标若未命中域名规则，解析结果可能参与 IP 规则检查。若上方已经存在宽泛域名直连规则，后面的 IP 阻断规则就可能不会执行；仅修改解析策略不能修正规则顺序本身的问题。

规则数据缺失时，内核可能在加载阶段就报告错误；数据过旧或分类与预期不同时，则可能表现为启动成功但分流错误。先区分这两类情况，再决定检查文件位置还是检查规则内容。客户端更新规则数据与更新服务器订阅属于不同操作，不能用订阅更新成功来证明地理规则已经更新。

给指定入口分配出口时，可使用 inboundTag；按目标端口匹配时，可使用当前内核支持的端口表达形式。尽量先用单一条件验证，再添加组合。日志应同时观察目标与实际出口，只有目标地址符合预期而出口不符时，才把重点放到路由匹配，而不是直接修改远端协议参数。

所谓全局、规则或直连模式，往往是客户端对生成配置的一组预设，不是独立的通用 JSON 字段。切换模式后应重新确认默认出站和规则数组。对分流结果有疑问时，记录一个具体目标、入口、命中条件与最终出口，比“部分网站不通”更容易复现，也更适合在后续修改之间做对照。

05 / dns：解析来源、地址族与路由依赖

先区分三条解析路径

应用可能在连接代理之前自行解析域名，也可能把域名直接交给代理。内核还可能为了路由或出站连接使用自己的解析器，远端服务也可能承担最后的解析。这些路径可以同时存在。观察到配置里有 dns 对象，并不能推出所有应用的查询都已由它处理，更不能推出系统 DNS 已被替换。

例如，应用先得到 IP，再以 IP 作为 SOCKS 目标时，内核收到的初始目标可能没有域名。此时域名规则是否可用，要看嗅探等机制是否补充了信息。应用若把域名交给代理，路由和出站可以保留更多目标信息。因此，比较两种应用的连接结果前，应先确认它们向本地代理提交的是域名还是已解析地址。

一个基础内置 DNS 片段

下例设置两个普通 DNS 服务器，并要求内置解析优先按仅查询 IPv4 地址的策略工作。这里的地址用于说明结构，不代表所有网络下的最优选择，也不改变操作系统的 DNS 设置。DNS 服务的可达性、适用网络与隐私要求需要单独评估；写入一个地址并不会自动建立到它的可用路径。

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIPv4"
  }
}

servers 可以使用简单服务器条目，部分场景也支持带域名范围、期望地址等条件的对象。对象字段的意义并不等于“始终只访问这一台服务器”，实际候选与回退过程还受到当前内核算法影响。不要把多个复杂选项一次加齐；先确认简单查询可达，再逐项限制适用域名和回退行为。

地址族需要与真实网络一致

queryStrategy 用于控制内置解析的地址族策略。仅查询 IPv4 可以用于隔离某些地址族问题，但不是所有连接失败的通用修复。IPv6 可用的网络也可能需要保留相应查询。反过来，系统能获得 IPv6 地址，不代表到远端服务的 IPv6 路径、代理服务器和出站策略都已具备相同能力。

域名最终选中的地址族，还受到应用先行解析、出站解析方式与远端处理的影响。仅修改顶层 DNS 的查询策略，不能保证所有连接都只使用某一地址族。排查时应比较解析答案与实际拨号目标；如果二者不一致，先确认是否由其他解析器或远端服务处理，不要继续叠加相互冲突的 DNS 选项。

避免解析与代理的循环依赖

如果代理服务器地址本身是域名，而解析器又必须通过这个尚未建立的代理访问，就可能形成启动阶段的循环依赖。使用加密 DNS 且解析端点也是域名时，还要考虑端点的初始解析。设计时应明确哪一步负责引导解析、哪条路径不依赖代理启动，以及这些路径在当前网络里是否真实可达。

不同内核对 DNS 查询的路由、标签与本地解析模式可能有不同处理。不能把一个加密解析地址复制进字符串，就假定其查询一定进入指定代理出口。需要远端解析时，应同时核对端点格式、支持方式与出站路径；需要系统解析时，也要接受操作系统自身缓存和网络设置带来的影响。

测试 DNS 修改时，应用缓存、系统缓存与已有连接都可能掩盖变化。先关闭测试页面的旧连接，按平台提供的正常方式处理缓存，再使用同一域名复测。不要用大量随机域名代替有计划的验证。保留一次修改前后的解析目标和日志，能够区分“答案改变”与“出口改变”这两种完全不同的结果。

DNS 不是独立于路由的优化开关。路由可能依赖解析结果，解析连接又可能受出站路径影响。先把依赖画清楚，再调整域名规则或地址族；如果基础连接尚未建立，应回到简单解析配置，而不是提前加入复杂的域名分类、回退限制和多层转发。

06 / policy：超时、用户级别与统计

策略按级别关联，不按显示名称关联

policy 用于设置连接处理策略与部分统计开关。levels 下面的键是用户级别编号的字符串表示，具体连接如何关联该级别，取决于协议的用户字段或入站相关设置。客户端分组名称、服务器备注和订阅名称都不是策略级别，改动这些界面文字不会自动选择另一套超时参数。

没有显式设置用户级别的常见场景通常使用零级，但仍应核对当前协议与内核行为。需要分级时，先找到对应用户对象里负责级别的字段，再把同一编号写入策略表。只声明一个未被任何连接使用的级别，不会对现有连接产生预期影响，也不适合用来判断策略支持是否正常。

超时值描述的是阶段边界

以下数字均为教学示例，不作为内核默认值说明。handshake 约束握手阶段，connIdle 用于连接空闲处理，uplinkOnly 与 downlinkOnly 涉及单方向结束后的等待行为。常见字段以秒计，实际含义应以所用内核对应文档为准，尤其不要把它们当作测速或带宽参数。

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

握手时间过短，可能在网络抖动或服务端响应稍慢时提前中止；设置很长，也不会让错误密码或不匹配的传输突然成功。遇到握手失败，先看日志属于超时、认证错误还是协议不符。只有确实在等待阶段被限时终止，且路径本来能够完成连接时，才有理由评估超时边界。

空闲连接与持续传输连接不同。浏览器连接池、消息长连接、终端会话可能在一段时间内没有应用数据；设置过短的空闲限制，可能导致这些连接需要重新建立。观察到“放置后首次访问失败”时，应同时考虑应用重连、网络设备会话保持与远端行为，不能只凭时间间隔就判定是本地策略。

单向结束不等于整个会话结束

一些协议允许一端停止发送后继续接收剩余数据。单向等待参数用于处理这种连接状态，不是让下载持续更久的开关。把等待时间降得很低，可能截断仍有意义的收尾过程；设得很高，则可能让无效连接保留更久。没有明确问题时，保留内核默认策略通常比照抄一套“优化参数”更容易维护。

策略不能修复底层网络的丢包、远端拒绝连接或证书服务名错误。某个问题若发生在 TCP 建连之前，调整协议握手后的空闲时间就没有对应作用。阅读错误时应辨认阶段：本地监听、域名解析、远端拨号、协议握手、稳定传输，分别对应不同参数，不应跨阶段猜测。

统计开关与展示通道分开配置

示例把相关统计开关显式设为关闭，只用于展示字段位置。开启用户统计通常还需要可识别的用户信息与相应统计功能；要让外部程序读取数据，可能还涉及统计对象、API 服务与受控访问入口。单独把某个布尔值改成真，不会让客户端界面自动出现可用的统计面板。

统计字段也不能等同于服务提供方的计费数据。内核可能按特定层面统计连接字节，远端服务则可能采用不同口径。重启、切换内核与清理状态还可能改变本地累计范围。需要记录时，应先确定采集对象、时间区间和重置条件，不要把本地观测结果直接解释为账户余额或最终结算。

修改策略的稳妥方法是先保留默认值，只针对已经复现的现象调整一项。记录原值、目标现象与复测结果；如果没有改善就回退。检查连接是否真正重新建立，避免仍使用旧连接的应用掩盖效果。策略属于连接生命周期管理，应放在基础协议与路由确认之后处理。

07 / 客户端生成配置、订阅与 TUN

编辑的是源数据还是运行配置

v2rayN 适合桌面端管理服务器与启动内核；Android 主要使用 v2rayNG，v2flyNG 可作为 V2Fly 内核方向的备选。三者的界面设置与持久化方式不完全相同，但都需要区分服务器数据、客户端偏好和最终内核配置。不能把一种客户端的配置目录结构直接套到另一种客户端上。

客户端自动生成的运行文件可能在切换服务器、切换路由或重新启动时被覆盖。直接编辑临时文件，短时间内可能看见变化，却未必能长期保留。修改前应先确认入口属于“自定义配置”、路由设置还是普通服务器参数；需要完整控制 JSON 时，使用客户端明确支持的自定义配置机制，并阅读其覆盖范围。

订阅是服务器来源，不是通用顶层字段

订阅链接通常用于取得服务器条目或客户端支持的配置内容，解析发生在客户端层。subscription 不是可以随意写入 V2Ray 顶层对象的通用字段。更新订阅也不等于内核已经切换到新服务器：客户端可能更新了列表，但当前选中项、活动连接和运行进程仍保持原状态，需要分别检查。

更新失败时，先检查链接是否完整、是否仍有访问权限，以及返回内容是否符合客户端接受的格式。返回登录页面、错误提示或空文本，都可能表现为解析失败。不要把订阅地址发到公开页面，也不要将包含访问凭据的查询部分贴入日志截图。完整排查顺序见订阅更新失败自查清单。

TUN 属于接管入口与配套路由

TUN 通过虚拟网卡将流量引入处理链。客户端可能为此调用另一套支持该入口的内核或辅助组件，配置模型不一定就是本页的 V2Ray 风格 JSON。不能凭界面上有 TUN 开关，就在配置顶层增加一个同名对象。先确认当前 TUN 实际使用的组件、权限要求与配置格式，再查对应字段。

系统代理主要影响遵循代理设置的应用，TUN 的覆盖范围取决于系统路由、排除项、地址族与接管实现。启用后仍可能存在未被接管的流量，也可能因为路由设置错误导致网络异常。不要把“全局”理解为任何程序、任何协议都必然走同一个出口；最终仍要结合分流规则与应用行为验证。

TUN 场景尤其需要避免把代理连接再次送回虚拟网卡。客户端通常负责设置必要的绕行与排除，手动叠加路由可能破坏这些安排。启用后若内核自身无法连接服务器，先检查是否发生循环接管，再检查权限、网卡和 DNS。操作流程可参考v2rayN TUN 模式设置说明。

迁移配置时，先记录客户端与实际内核名称，再记录使用的协议和扩展功能。Xray 支持的某个出站或安全选项，不一定能交给 V2Fly 直接读取；同属 Project V 生态也不意味着字段永远兼容。更换内核后，应重新验证配置加载、握手与路由，而不是仅确认窗口仍能打开。

备份应包含理解恢复所需的源数据，而不只是一个临时生成文件。至少保留自定义规则、修改说明与必要的客户端导出内容，并妥善保护其中的服务器凭据。分享排错材料时，用教学假值替换地址之外的敏感认证数据；替换后再次检查嵌套对象、备注和订阅查询部分，避免只遮住界面第一行。

需要重新安装时，从客户端与平台下载入口选择对应系统和架构，不要用文件名相似来判断适配。安装完成后先恢复最小配置，再逐项恢复订阅、路由与接管设置。如果一次导入全部旧设置后才开始测试，无法分辨问题来自客户端环境变化，还是旧配置本身的兼容性。

08 / 配置验证、日志与回退顺序

按失败阶段缩小范围

排错的第一步是确定当前失败发生在哪一层。窗口能打开，只能说明客户端界面运行；内核进程启动，才说明配置至少通过了相关加载过程；本地端口可以连接，也不能证明远端认证成功。把这些条件分开验证，可以避免在 JSON 语法错误时反复换节点，或在应用未使用代理时不断修改路由。

保存之前先做静态检查：括号是否配对、字符串是否闭合、数组项之间是否缺逗号、字段值类型是否正确。再检查结构语义：出站引用是否存在、规则数据是否可读取、协议字段是否属于当前内核。严格 JSON 解析成功只能证明语法，不代表内核认识全部字段，也不代表该配置符合真实服务器要求。

日志级别先满足定位，再恢复日常设置

warning 适合减少普通运行信息，但可能不足以观察出站选择。定位时可以临时改为 info，必要时短时间使用当前内核支持的更详细级别。不同级别下显示的事件不同，没有某一条日志不等于没有对应行为。详细日志也可能包含目标地址，应在可控时间内采集并限制分享范围。

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

这段只是替换日志对象的片段，不是可单独启动的完整配置。输出文件路径若另外配置，需要保证内核进程具有写入权限，且路径属于当前运行环境。便携目录、受保护的安装目录与移动设备存储权限可能不同。遇到日志文件为空时，先检查输出位置和权限，再判断内核是否没有产生任何事件。

常见现象的检查顺序

本地连接被拒绝时，不必先研究远端 DNS。确认当前客户端没有退出，内核没有启动后立即崩溃，并且应用使用的是实际监听端口。若有多个客户端同时运行，确认测试的是哪一个进程。端口冲突往往发生在后台进程仍存在时，单纯关闭可见窗口不一定停止对应服务。

远端拨号超时与认证失败应分开处理。前者优先看目标地址是否能到达、域名是否解析到预期地址、出站是否绕回自身；后者更需要比对协议、密码或用户标识与传输安全参数。连续更换多个不相关字段，会让原本清楚的错误变成多种问题叠加，日志也失去可比性。

只有个别目标异常时，固定同一个应用与目标进行测试。检查该应用是否绕过代理、是否使用独立 DNS、是否保留旧连接，再观察命中的路由与最终出口。测速成功不能替代实际应用验证，因为测试可能采用不同的目标、连接方式和路由条件。相关概念可查名词解释。

用单变量复测形成回退记录

每次只修改一组具有直接因果关系的字段。例如修改本地端口时，允许同步修改应用连接端口；但不要同时调整 DNS、出站协议和路由模式。保存后按客户端要求重载或重启内核，再新建测试连接。已有长连接可能继续使用旧路径，刷新页面也不一定会建立全新的连接。

复测记录应包含修改目的、原配置片段、修改后的片段、测试目标和日志现象。无需记录虚构的性能结论，也不必把所有日志长期保留。能够稳定重现的“某条规则命中错误出口”，比缺少上下文的“网络变慢”更有价值。若结果没有改善，恢复原值，再验证基线仍然可用。

回到日常使用时，尽量让客户端承担可稳定表达的常规设置，把自定义 JSON 留给明确需要的行为。操作入口不清楚时，查阅v2rayN 主界面说明；首次配置顺序仍以入门指南为主。本手册负责解释字段与边界，实际生效情况始终以当前内核、运行配置和复测结果为依据。