V2Ray 配置文件参考.

01 / STRUCTURE

JSON 结构与配置生效范围

先确认实际加载的文件

配置文件描述内核如何接收连接、选择出口以及解析域名，但它不是客户端全部设置的集合。v2rayN 的订阅分组、界面偏好和系统代理选项由客户端管理，内核通常只读取客户端生成的运行配置。排查前应先确认当前选中的内核、运行目录和日志里记录的配置路径。磁盘上名为 config.json 的文件可能有多份，修改未被加载的副本，不会改变现有连接行为。

JSON 顶层通常是一个对象，各模块以键名区分。inbounds 与 outbounds 是数组，因为同一个进程可以接收多种本地入口，也可以持有多个出口；routing、dns 和 policy 则是对象。不要仅凭界面中选项排列的位置推测嵌套关系。字段即使拼写正确，放错层级也可能被忽略，或者直接导致内核拒绝加载。

从最小闭环理解模块关系

下面是一份本地 SOCKS 入站转直连出口的基础配置，不包含远程代理服务器。它的作用是确认本机监听、请求接收和直连出站能够组成闭环。应用必须主动使用这个 SOCKS 入口，流量才会进入内核。示例中两个 tag 是配置内部名称，可以自行命名，但所有引用都要同步修改；标签不同于协议名，也不会自动创建对应出口。

{
  "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": {}
    }
  ]
}

读取这份配置时，先沿请求方向观察：应用连接本地监听地址，入站解释 SOCKS 请求，路由决定出口，出站再建立目标连接。没有单独的路由规则时，常见行为是由第一个出站承担默认出口。增加第二个出站并不意味着它会自动分担流量，必须由规则或其他明确机制引用。理解这个默认关系，比先记住大量参数更有助于解释实际现象。

严格区分语法正确与语义正确

标准 JSON 不允许注释、末尾逗号和单引号字符串。数字端口应写成数值，布尔开关应使用 true 或 false，不能用带引号的同名文本代替。反斜杠在字符串里具有转义作用，手写路径或正则表达式时尤其容易出错。编辑器能够格式化，只能说明文本结构基本成立，不能证明协议支持该字段，也不能证明远端参数与本地一致。

本文后续代码大多是顶层模块片段，目的是说明字段之间的关系，不是每一段都能单独启动。合并片段时应替换原有同名模块，不要在同一对象内追加重复键。重复键在不同解析器中的处理可能不一致，容易造成“文件看起来已经修改，运行结果却仍旧不同”的误判。数组内部也要保留正确的逗号与括号，避免把一个出口误塞进另一个出口的设置对象。

版本兼容应以当前实际内核为准，而不是只看客户端名称。相同客户端可以切换内核，不同发行包也可能包含不同能力。查阅字段时同时记录模块、字段路径、值类型和适用内核，遇到未知字段先缩小配置范围。不要通过不断添加网上找到的开关试错；保留一条能复现现象的请求，逐层确认入口、路由和出口，通常更容易找出真正的差异。

02 / INBOUNDS

inbounds：监听地址与入站协议

监听范围决定谁能使用入口

入站首先定义一个可连接的本地入口。listen 决定绑定的地址，port 决定端口，protocol 决定收到连接后按什么协议解释数据。只供本机程序使用时，优先绑定 127.0.0.1。如果改为所有接口监听，局域网内其他设备可能能够访问该端口，是否真正可达还取决于防火墙和网络环境，因此不能只改地址而不考虑访问控制。

地址与端口是配套信息。应用填写的代理地址必须指向当前设备上实际运行的内核，手机里的回环地址只指手机本身，不会指向旁边的电脑。监听 IPv4 回环也不等于已经监听 IPv6 回环。遇到应用使用 localhost 后连接失败，而直接使用回环数值地址可以连接的情况，应检查名称解析结果与监听地址族，避免把本地入口问题误判为远程服务器故障。

SOCKS 与 HTTP 入口分别接收什么

SOCKS 入站通常供支持 SOCKS 代理的应用使用；HTTP 入站接收 HTTP 代理请求，包括应用通过 CONNECT 建立的隧道。二者不是把浏览器流量强制改写成某一种网页协议，也不负责自动开启系统代理。应在应用中选择与入口一致的代理类型，不能把 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": {}
    }
  ]
}

这里开启 SOCKS 的 UDP 能力，只表示入口允许相关请求，并不保证所有 UDP 应用已经经过它。应用需要支持 SOCKS UDP 的使用方式，出口和远端服务也需要支持对应转发。系统代理通常不能覆盖全部应用或任意 UDP 流量，因此“网页正常而某个实时应用失败”不能直接归因于节点不可用。先确认该应用以什么方式接入，再检查后续链路是否支持它需要的传输。

嗅探用于补充目标信息

部分路由需要域名，而应用进入内核时可能只提供目标 IP。入站的嗅探功能可以尝试从连接开头识别 HTTP 主机名或 TLS 握手中的服务器名称，为路由提供更多线索。它不是通用的内容解密功能，也不能保证每条连接都能提取域名。不同内核对嗅探协议列表与选项的支持有差异，增加相关字段前应先确认当前内核文档，不要整段照搬其他内核的示例。

嗅探还涉及“仅用于路由判断”和“是否改写连接目标”的区别。某些内核提供只影响路由的选项，适合不希望改变原始目标地址的场景，但这类字段并非所有内核通用。排错时应先关闭额外嗅探，让一条明确的域名请求或 IP 请求成功，再逐项启用。否则入站提供的原始目标与嗅探得到的名称混在一起，会让日志中的路由结果更难解释。

入站启动失败最常见的本地原因是端口冲突、监听地址不存在或权限受限。同一台设备上的两个客户端如果使用相同地址和端口，通常无法同时监听。不要为了绕过冲突随意扩大监听范围；先退出不再使用的客户端，或有计划地调整端口，并同步更新应用代理设置。更完整的错误定位流程见日志排查，需要使用系统代理的操作步骤则见使用指南。

03 / OUTBOUNDS

outbounds：出口协议与传输设置

出口标签与默认顺序

出站负责把请求从内核送往目标或远程代理服务。protocol 选择出口协议，settings 保存该协议的具体参数，streamSettings 则用于配置底层传输与传输安全。标签只承担内部引用作用，名为 proxy 的出口不会因此自动具备代理能力。它必须真实存在，参数合法，并且被路由规则命中或处在默认出口位置，才能承担请求。

基础配置经常同时包含代理、直连和阻断出口。直连的 freedom 会由运行内核的设备直接连接目标；阻断的 blackhole 则主动终止匹配请求。这里的“直连”不表示跳过本机网络栈，也不表示一定避开系统层虚拟网卡。启用了 TUN 或其他全局接管机制时，需要确认内核自身连接有正确的绕行路径，否则可能发生请求再次进入自身的循环。

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

把节点身份与传输安全分开核对

远程代理出口通常包含服务器地址、端口以及协议所需的身份参数。VMess、VLESS、Trojan 和 Shadowsocks 的身份结构并不相同，不能只替换 protocol 就把一份配置变成另一种协议。订阅导入的价值之一，是让客户端按节点类型生成对应字段。手工修改时应逐项核对服务器提供的信息，不要根据分享链接外观推测加密方式、传输路径或安全设置。

下面片段演示 Trojan 出站的常见层级。proxy.example.com 与示例口令仅用于说明结构，不能连接真实服务；需要使用服务方提供的地址、端口、口令与证书名称替换。它与上一段直连示例是不同用途的配置片段，不要把整个顶层对象直接叠在一起。实际使用前还应确认当前内核支持该协议及所用传输字段。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "trojan",
      "settings": {
        "servers": [
          {
            "address": "proxy.example.com",
            "port": 443,
            "password": "your-password"
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "proxy.example.com",
          "allowInsecure": false
        }
      }
    }
  ]
}

传输方式回答连接如何承载数据，TLS 回答传输安全如何协商，代理协议则定义双方如何交换代理请求。这三层需要分别匹配远端。服务器接受哪一种传输、路径是否区分大小写、是否需要特定主机名，都应以服务端配置为准。更改客户端的一层并不能自动让服务端适应，组合不一致可能表现为立即断开、握手失败，也可能一直等待到超时。

证书名称与服务器地址并非同一字段

服务器地址用于找到远端，而 TLS 的 serverName 用于握手中的名称指示与证书验证，两者在某些部署中可以不同。把域名改成数值 IP 后，仍可能需要保留证书对应的服务器名称。不要通过关闭证书验证来长期掩盖名称错误；应先检查系统时间、证书覆盖范围与所填名称是否一致，再判断是否是服务端证书链或网络连接问题。

连接复用、底层套接字和高级传输参数都属于后续优化，不应成为首次配置的前置条件。一个节点在默认参数下能够工作后，再观察具体应用是否存在重复建连、长连接中断等问题，最后根据内核支持情况调整。批量套用一组“优化参数”会改变多个变量，使失败原因难以复现。尤其不要为了测速结果随意修改协议身份字段，它们并不是性能调节开关。

如果出口启动正常但连接失败，应区分域名解析失败、远端端口无法建立连接、TLS 协商失败与协议认证失败。前一层未成功时，检查后一层通常没有意义。证书相关现象可进一步阅读TLS 握手与 SNI 排查笔记；如果只是需要更换或安装图形客户端，仍从客户端页面选择，不需要单独寻找内核下载入口。

04 / ROUTING

routing：匹配顺序与分流规则

规则按顺序判断，不按精确度自动排序

路由模块把连接信息与规则逐项比对，再将命中的请求交给指定出口。常见规则使用 type: "field"，依据域名、目标 IP、端口、网络类型或入口标签作判断。规则从上到下检查，先命中的规则通常决定结果，因此更具体的例外应放在宽泛规则之前。把覆盖全部连接的规则放到顶部，会让后续精细规则失去实际作用，即使那些规则本身写得完全正确。

同一条规则中，不同条件字段通常是共同约束；同一个数组里的多个候选项通常表示任一匹配。例如域名数组可以列出多个站点，而同时写入端口条件，则还要求请求端口满足限制。不要把多个不同用途的条件堆在一条规则里期待它们互相替代。阅读规则时可以先用一句话复述：什么入口、访问什么目标、使用什么网络、交给哪个出口，再检查代码是否表达了相同含义。

域名、完整匹配与 IP 网段

domain: 适合表达某个域名及其子域范围，full: 用于完整域名匹配，regexp: 则交给正则表达式处理。规则不需要写网页路径，因为代理连接层通常看不到完整网页地址；把包含协议头和路径的 URL 当成域名条件，往往无法命中。对于已知固定主机，优先使用简单匹配，只有确实需要模式表达时再使用正则，便于维护和检查转义。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:telemetry.example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "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"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

这段片段要求已有标签为 block 和 direct 的出站。第一条是第二条覆盖范围内的例外，因此必须排在前面。私有网段示例只处理列出的地址，不代表已穷尽所有特殊用途网络；实际环境若需要链路本地地址等范围，应根据网络用途补充。未命中的请求继续使用默认出口，不会因为最后一条写了直连，就把所有剩余连接都转为直连。

domainStrategy 决定何时为路由解析域名

AsIs 尽量按现有目标信息判断，不为补充 IP 条件而主动解析域名。IPIfNonMatch 在域名阶段未命中时，可能解析后继续尝试 IP 规则；IPOnDemand 则可能在遇到需要 IP 信息的规则时触发解析。它们影响路由决策过程，并不等于 DNS 服务器列表，也不能替代出站连接目标时所需的解析行为。改变策略后，DNS 请求数量与规则结果都可能发生变化。

应用如果只交给内核一个 IP，单纯增加域名规则不会凭空恢复原始名称。此时应检查应用的代理方式、DNS 解析发生的位置，以及是否使用了适用的嗅探机制。相反，目标已经是域名时，也不能假设私有 IP 规则一定会提前命中；是否解析、何时解析，取决于当前策略。排错时记录“入站看到的是域名还是 IP”，通常比只看浏览器地址栏更有价值。

geosite 和 geoip 是分类数据引用，不是实时网络查询。它们依赖内核能够找到相应数据文件，类别名也必须存在。数据缺失可能导致启动失败，分类内容变化也可能使同一配置在更新后产生不同结果。先用单个明确域名或网段验证规则，再换成分类引用，可以把规则语法问题与分类数据问题分开，不必同时猜测两个变量。

维护规则时建议在配置外记录每条规则的用途与调整原因，避免把注释写进标准 JSON。删除旧规则前先看是否有后续规则依赖其顺序，尤其留意入口标签分流与总兜底规则。具体匹配语法和优先级示例见自定义路由规则笔记；需要区分系统代理与全局模式时，可结合FAQ理解客户端层面的行为。

05 / DNS

dns：解析入口与查询路径

先辨认是哪一层正在解析

一次访问可能涉及应用自身的解析、操作系统解析、内核内置 DNS，以及远程代理端的解析。配置里的 dns 只描述内核相关解析器的行为，不会自动替换设备上全部应用的 DNS 设置。浏览器可能启用自己的加密解析，应用也可能先获得 IP 再发送代理请求。因此判断 DNS 是否生效，必须先确认产生查询的组件，不能只观察系统设置页面中的服务器地址。

内核 DNS 的使用还受路由策略、出口设置和客户端生成逻辑影响。某些请求保留域名交给远端，某些请求为了匹配 IP 规则而在本地解析；二者可以同时存在。出现“网页能够打开，但日志没有对应查询”的情况，并不一定是配置无效。应先观察入口目标是域名还是 IP、请求最终由哪个出口处理，再判断预期中的解析应该发生在哪里。

servers、hosts 与查询地址族

servers 指定解析服务器，既可以使用简单地址，也可以按内核支持情况使用带域名条件的对象。hosts 用于明确的名称映射，适合受控测试或固定内部名称。下面示例采用数值解析服务器地址，并把保留示例域名映射到文档用途地址；这个映射只用于演示，不是一个可访问站点。使用数值地址可以减少启动阶段先解析 DNS 服务域名的依赖。

{
  "dns": {
    "hosts": {
      "lab.example.com": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

UseIP 表示允许查询 IPv4 与 IPv6 结果，其他查询策略的可用值应与所用内核对应。只返回 IPv4 可以用于缩小某些双栈故障范围，但不应被当成永久通用优化；网络如果需要 IPv6，强制限制反而会丢失可用路径。系统存在 IPv6 地址，也不代表当前网络具备稳定的端到端 IPv6 连通性，需要把地址配置和真实可达性分开判断。

DNS 服务器列表不等于连接出口列表

列出多个服务器不意味着它们总是严格按顺序逐个备用。域名条件、缓存、回退机制和内核实现都可能影响实际查询。需要分域解析时，应明确哪些名称交给哪个解析器，以及未匹配名称如何处理。对象形式的域名条件与路由中的域名规则虽然形式相近，作用位置却不同：前者选择解析器，后者选择连接出口，不能因为写法相似就混为一套规则。

加密 DNS 可以保护到解析服务之间的传输，但不会自动保证这段连接按预期经过某个出口。还需要理解该解析模式在当前内核中的发送路径，以及客户端是否另行设置了 DNS 路由。若解析服务使用域名地址，又依赖自身解析才能找到服务器，就可能形成启动依赖环。检查时可先使用能明确到达的数值地址建立基础解析，再逐步切换到目标方案。

缓存是 DNS 排查中的重要变量。客户端重载可能只清理内核缓存，浏览器与操作系统仍可能保留旧记录；已有连接更不会因为解析结果变化而自动重建。验证配置时应使用新连接，必要时关闭相关应用后重新打开，并记录测试时间与查询名称。不要持续快速刷新页面，把多个缓存层的结果混在一起，再据此判断某个服务器始终没有生效。

DNS 超时也可能是路由循环的结果。例如解析请求被发送到需要先解析域名才能建立的代理出口，或虚拟网卡把内核自身流量再次接入。此时反复增加公共解析服务器通常不能解决问题。应回到连接依赖关系，分别确认解析服务地址、代理服务地址和内核自身连接的路径。只有每个环节的前置条件都能独立满足，复杂的分域解析才有稳定基础。

在 v2rayN 或 v2rayNG 中调整 DNS 时，先使用客户端已有设置入口，再核对最终生成结果，避免界面设置与自定义片段互相覆盖。若只是首次连接，保持较少变量通常更合适；若要验证特定分流需求，则固定一个测试域名，分别观察解析与访问两个阶段。关于系统代理覆盖范围和应用独立解析的常见疑问，可继续查阅常见问题。

06 / POLICY

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

策略不是节点优先级

policy 用来描述连接资源和统计方面的策略，常见内容包括握手等待时间、空闲超时、单向连接保留时间与流量统计开关。它不会按照节点名称挑选出口，也不会替代路由规则。面对连接不稳定时，应先确认出口是否能够建立连接，再判断是否确有超时策略介入；把所有时间都调大，只会让某些本来应该尽快暴露的错误等待更久。

levels 中的数字键表示用户级别，JSON 对象键仍然需要使用引号。级别不是系统权限，也不是“数值越大速度越快”的排序。协议用户配置中的 level 与对应级别关联，未显式指定时常使用默认级别。某些场景主要使用本地无认证入口，没有为用户配置多个级别，此时大量定义高编号策略通常不会带来预期变化。

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

按连接阶段理解超时

示例中的时间字段通常以秒为单位，应以当前内核字段说明为准。handshake 约束握手阶段允许的等待时间，connIdle 关注连接没有数据活动时的保留时长；uplinkOnly 与 downlinkOnly 则涉及一侧关闭后另一方向继续保留的时间。它们描述不同阶段，不能用其中一个统一解释所有“连接被断开”的现象。

握手时间太短，可能在高时延或短暂拥塞时提前结束尚未完成的连接；过长则会延迟失败反馈。空闲超时过短，可能影响长期等待通知但很少传输数据的应用；过长又会保留更多连接资源。调整时应先找到具有稳定复现步骤的应用，记录断开前是否真的没有数据，再对相关字段作小范围变化，不要把持续有流量的传输故障直接归结为闲置超时。

单向关闭在网络连接中并不罕见。某一侧停止发送，不一定表示另一侧已完成响应，因此单向保留时间会影响部分请求的收尾。只有在日志与应用行为确实指向半关闭阶段时，才值得调整相关参数。若连接根本没有通过认证，或者服务器端主动终止会话，改变客户端这些时间字段不会解决协议不匹配，也无法强制远端继续维持连接。

统计开关需要完整采集链路

开启用户上传或下载统计，不等于客户端立刻就能显示对应数值。统计模块、相关用户标识、API 服务及客户端读取逻辑需要形成完整链路。某个界面的流量数字也可能来自虚拟网卡或其他统计来源，不能看到数字就断定某个 policy 字段已经生效。本文示例保持统计关闭，只展示字段所在层级，避免引入额外接口与采集配置。

系统级统计与用户级统计的粒度不同。入口统计可能汇总同一入口的多种请求，用户统计则依赖协议中可识别的用户对象。若希望按应用区分流量，仅开启用户统计未必满足需求；还要考虑入口划分、应用接入方式与客户端是否提供相关展示。不要为了获得一个界面指标而把控制接口暴露到局域网，接口监听范围仍应按实际使用需求限制。

当启用统计或其他高级模块后启动失败，先检查是否缺少配套模块、字段是否被当前内核支持，以及客户端是否已经生成了同名配置。不要同时保留两套彼此独立的 API 定义，再靠更换端口解决所有报错。回退到只有连接策略的最小配置后，逐项增加统计能力，可以把连接处理问题和观测功能问题分开，避免让采集链路影响正常使用。

评估策略改动时，不宜只看一次延迟测试。短请求、长连接和持续传输受影响的阶段不同，单项测试无法覆盖全部行为。应分别确认首次连接能否完成、闲置后能否恢复、已有任务是否被异常截断，并在测试后恢复常规日志级别。若无法说明某个数值具体解决了什么问题，就没有必要长期保留它；配置越简洁，后续迁移内核时越容易核对兼容性。

07 / CLIENT INTEGRATION

客户端生成配置与接管边界

界面选项如何变成运行配置

v2rayN、v2rayNG 与 v2flyNG 都把图形界面和内核连接处理分开。客户端负责保存节点、订阅与用户选项，再将当前选择转换成内核运行所需的配置。这样可以减少手写字段的负担，但也意味着生成文件未必是长期配置来源。切换节点、重启内核、修改路由模式或更新订阅，都可能触发重新生成；直接编辑运行文件，下一次操作后可能就被覆盖。

桌面端优先使用 v2rayN，根据实际内核和系统环境选择图形功能。安卓端可使用采用 Xray 内核的 v2rayNG，或作为 V2Fly 内核备选的 v2flyNG。不同客户端对自定义配置的接入方式并不完全一致，界面名称也可能调整，应以当前安装界面为准。遇到某个选项缺失时，不要把另一个客户端的完整操作路径当作通用步骤，而应先确认当前应用与所用内核。

区分订阅、节点与完整配置

订阅地址通常指向一组可更新的节点数据，节点分享链接描述单个服务的协议与连接参数，完整 JSON 则可能同时包含入口、出口、DNS 和路由。三者不能互相当作同一种文本导入。把完整配置放进只接受节点链接的导入入口，或者把订阅地址写进出站服务器地址，都无法得到正确结果。导入之前先辨认内容用途，比导入失败后不断尝试不同按钮更有效。

有些客户端允许导入完整配置，有些支持局部自定义或路由规则管理。使用前应先弄清楚它是整体替换、合并某个对象，还是仅追加数组项。相同片段在不同合并方式下可能产生不同效果：替换出站数组会丢失原有出口，追加路由规则又可能被更靠前的规则遮住。不要只确认文件保存成功，还要检查最终生成的内容是否包含预期标签和顺序。

系统代理与 TUN 是不同接入机制

系统代理是操作系统向遵循其设置的应用提供代理信息，不会自动覆盖全部程序；TUN 则通过虚拟网络接口与相关路由把流量交给客户端处理。两者可以涉及同一个内核，却不是同一个 JSON 开关。TUN 所需权限、虚拟接口和系统路由往往由客户端管理，不能仅在传统入站数组里添加一个陌生协议名，就认为已经完成系统接管。

同时运行多个网络代理工具时，要留意系统代理地址被谁修改、默认路由被谁接管，以及 DNS 设置最终由谁维护。一个客户端退出后，另一个客户端可能仍在占用端口或保留系统设置。出现“关闭软件后应用反而不能联网”的情况，应先检查系统代理是否仍指向已经停止的本地入口，再检查虚拟网卡与系统路由，而不是立即重装所有软件。

用一次小改动验证配置来源

判断自定义设置是否被采用时，可以选择一个容易观察、不会暴露服务信息的变化，例如修改本地入口端口并同步调整测试应用，或为已有出口添加明确的内部标签。重新启动相关连接后，查看监听状态与日志。若最终生成配置没有变化，说明问题还在客户端配置来源或合并逻辑，不应继续怀疑远端网络；若生成内容正确，再进入连接层排查。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["http-in"],
        "outboundTag": "direct"
      }
    ]
  }
}

上面的局部片段只演示按入口标签分流，需要同时存在名为 http-in 的入口与 direct 的出口。它不会创建这些对象，也不适合未经检查直接覆盖已有路由。维护自定义内容时，可单独保存修改目的、适用内核与依赖标签，但不把订阅地址或口令写进公开笔记。迁移设备前先导出必要设置，并按客户端能力检查敏感数据的保存方式。

首次使用仍建议沿使用指南完成导入、选择节点和验证，再考虑完整配置接管。想熟悉 v2rayN 的设置入口与日志区域，可阅读主界面功能速览。本页用于解释字段与边界，客户端具体按钮应以当前界面为准，不需要为了与示例完全一致而放弃已经稳定工作的默认配置。

08 / DIAGNOSTICS

日志检查与配置回退顺序

先判断进程是否启动成功

排查配置问题的第一条分界线，是内核能否保持运行。若启动后立刻退出，先读最早出现的错误，而不是直接测试网页。常见原因包括 JSON 结构错误、不支持的协议或字段、重复监听、所需数据文件缺失。后面连续出现的“连接被拒绝”可能只是内核退出后的连带现象，修复这些应用侧提示并不能代替修复最初的启动错误。

日志中出现文件位置时，应确认它属于当前运行实例。多个客户端或残留进程可能分别产生不同日志，旧窗口中的信息也未必对应最近一次测试。记录一次明确的重启时间，只保留当前实例的相关片段，并检查配置路径是否与编辑位置一致。如果客户端提供启动错误详情，优先从那里确认模块名称，再回到文件中定位，而不是先全文替换看起来相似的字段。

临时提高日志粒度

需要观察连接流程时，可在确认内核支持的前提下将日志级别临时调为 info，更细的调试级别只用于缩小后的问题范围。日志可能包含目标域名、连接地址或用户相关信息，分享前应删去敏感内容。记录越多不代表越容易定位，尤其多个应用同时联网时，正常连接会淹没真正的失败请求。测试阶段只保留一个应用和一个明确目标更有帮助。

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

这段配置仅替换顶层日志模块，不应被当成独立完整配置。修改后如果日志粒度没有变化，先确认是否需要重启内核，以及客户端是否覆盖了日志选项。排查结束后恢复常规级别，避免长期记录不必要的访问细节。若把日志写入文件，还需确认目录存在且当前进程具有写入权限；日志文件无法创建本身也可能导致额外错误，不能与连接故障混为一谈。

沿入口、解析、路由、出口逐层检查

内核运行正常后，先看测试请求有没有进入对应入站。完全没有记录时，检查应用代理类型、地址、端口和系统代理状态；已经进入但目标信息不对时，检查应用解析方式和嗅探；目标正确却去了错误出口时，检查规则顺序、标签与域名策略。只有确认已经选中预期出口，才继续查看服务器解析、连接、TLS 和协议认证，避免跨层猜测。

“超时”只说明某个阶段未在等待时间内完成，本身不是根因。服务器域名解析超时、目标端口建连超时和协议协商超时，应该采用不同检查方式。日志如果只保留了最后一条提示，可适度增加粒度重现一次，找到更早的阶段信息。不要看到超时就同时更换 DNS、传输方式和身份参数，否则即使偶然恢复，也无法确认是哪项变化产生了作用。

验证修复时，应同时观察新建请求和应用实际功能。已有长连接可能继续使用旧出口，浏览器缓存也可能让页面看似正常却没有产生新请求。关闭相关连接后再测试，确认请求经过预期入口与出口，并检查应用所需的其他请求是否也成功。真连接测速可帮助筛选服务可达性，但某一次测试通过不能代表所有域名、协议和应用场景都已经符合路由预期。

回退以恢复可解释状态为目标

如果多处修改后已经无法辨认问题来源，先回退到最近可启动的配置，只保留一个入口、一个确认可用的出口和最少规则。依次恢复 DNS、分流、策略与高级功能，每次都重新测试同一个目标。这个顺序不是要求永久减少功能，而是把复杂问题拆成可观察的步骤。只有每次新增内容都有明确结果，后续的配置演进才不会不断累积难以解释的例外。

需要更细的启动错误分类，可阅读从 Xray 日志定位配置错误；已经能启动但不确定代理是否生效，可参照首次连接验证笔记。仍有疑问时，回到FAQ按现象查阅。配置参考的最终目的，是让每个字段都有可说明的作用，而不是让文件越来越长。