V2Ray 配置文件参考

01 / STRUCTURE

JSON 结构与配置边界

配置文件先描述对象之间的关系，再由内核把这些对象连接成处理链。应用把请求交给入站，路由检查目标和来源条件，最后选择出站建立连接。DNS 可以参与域名解析，策略约束连接资源，日志记录运行过程。这几个部分不是依次执行的脚本段落，调整它们在文件里的书写位置，通常不会改变处理先后；数组内部的顺序却可能直接影响结果。

先辨认实际读取的配置

v2rayN 等图形客户端通常根据节点、路由和 DNS 界面生成运行配置。界面中的订阅分组、窗口布局、测速设置属于客户端数据，不是内核顶层字段。磁盘上看到名为 config.json 的文件，也不能立刻认定它就是当前运行文件。应从客户端的运行信息、配置查看入口或启动日志确认内核类型与配置来源，再决定在哪里修改。

手工修改生成文件往往只影响一次运行。切换节点、更新订阅、保存设置或重启内核时，客户端可能重新生成文件，把修改覆盖。日常维护优先使用界面提供的路由、DNS 与自定义配置入口。确实需要完整自定义配置时，要先了解该模式是否仍接收客户端生成的规则，避免以为两个配置会自动合并。

从可独立运行的最小结构开始

下面的完整基线监听本机回环地址的 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": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

从这一结构向外扩展时，每次只加入一个功能。先增加一个带独立标签的出站，再添加引用它的规则，随后验证命中情况；不要同时更换 DNS、开启嗅探、调整策略和修改默认出站。最小基线的意义不是功能齐全，而是提供一个可以退回的状态，让每项变更都有清楚的因果关系。

对象、数组与字段类型

inbounds 与 outbounds 是数组，可分别放多个对象；routing、dns、policy 与 log 是对象。字符串必须使用英文双引号，布尔值写成 true 或 false，数字与字符串也应按字段要求区分。端口范围类字段有时接受字符串，不应据此推断所有端口字段都能混用类型。

为保证跨工具可读，本页示例采用严格 JSON：没有注释、尾随逗号或重复键。部分加载器允许扩展语法，但编辑器能打开并不意味着当前内核能加载。尤其要避免把说明文字粘到引号外，或从文档复制中文引号。错误定位通常指向发现问题的位置，真正缺少的逗号可能在上一行。

六个常用字段并非全部顶层字段。统计、管理接口与其他扩展模块可能需要另外配置；不要为了让结构看起来完整而机械加入空模块。查阅时应先判断问题属于接收、匹配、解析还是连接，再进入对应章节。这样比逐个尝试网上搜到的参数更容易保留正确的配置边界。

02 / INBOUNDS

inbounds 入站配置

入站定义内核从哪里接收流量，以及如何理解收到的数据。本地应用使用 SOCKS 或 HTTP 代理时，连接的就是一个代理入站，而不是远程节点地址。入站可用只说明应用能够接触内核，不能证明远程出站连接成功。排查时先把本地接收与远程连接拆开，能够减少端口问题被误判为节点问题的情况。

监听地址与端口

listen 决定监听的网络接口，port 决定本地服务端口。仅供本机程序使用时，明确写 127.0.0.1 能缩小接收范围。若改成所有接口可访问的地址，局域网内其他设备也可能访问该端口，需要同时考虑系统防火墙、接入范围和认证设置。开放监听不是共享成功的充分条件，也不应作为连接失败时的默认修复操作。

两个入站不能在相同地址与端口上重复监听同一种传输。端口占用可能来自另一个客户端实例，也可能来自上一次没有正常退出的内核进程。出现绑定失败时，先结束重复运行的实例，再检查端口是否恢复可用。直接更改端口后，还必须同步修改浏览器、系统代理或其他应用的代理地址，否则应用仍会连接旧端口。

SOCKS 与 HTTP 不可互换

下面是可并入顶层的 inbounds 字段片段。两个入口使用不同端口，并以标签区分来源。SOCKS 的 UDP 开关只表示该入口允许相应请求，不代表所有应用、所有出站和整个网络路径都支持 UDP。HTTP 入口主要服务于使用 HTTP 代理协议的应用，不能因为端口可连就把它当成 SOCKS 使用。

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

应用里的代理类型必须与入口协议对应。把 HTTP 请求直接发送到 SOCKS 端口，可能得到断开、协议错误或空响应；这时更换节点不会解决问题。还要区分应用是否把目标域名交给代理，还是先自行解析再提交 IP。两种方式会改变内核能看到的目标信息，并进一步影响后续域名规则。

标签与来源识别

tag 是配置内部使用的名称，不是网络地址，也不决定监听行为。建议使用稳定、简短且语义明确的标签，例如本地 SOCKS 与本地 HTTP 分别命名。路由里的 inboundTag 必须逐字引用标签，包括大小写。修改标签后漏改规则，会让原本针对入口的规则失效，流量转而匹配后续规则或默认出站。

独立标签适合区分不同应用入口。例如保留一个普通入口，再创建另一个专用于测试的入口，通过入站标签把测试流量送到指定出站。这样不用反复修改所有应用的全局规则，也能验证新出口。不过入口越多，端口与规则关系越复杂；暂时不用的入口应删除或停用，避免把过期测试路径留在长期配置中。

嗅探能补充什么信息

某些请求进入内核时只携带 IP，嗅探可以尝试从受支持协议的初始数据中提取域名信息，例如 HTTP 主机名或部分 TLS 握手中的服务器名称。它并非解密工具，也不能保证识别所有加密流量。目标应用的协议、握手形式及隐私特性都会影响可见信息，所以不能把开启嗅探等同于所有域名规则都会命中。

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

上面是放入单个入站对象的字段片段，不是顶层对象。destOverride 涉及从嗅探结果修正目标的行为，具体支持项与选项需按内核核对。若只想让嗅探结果参与路由，而不改写连接目标，应确认当前内核是否提供相应路由专用选项。不要照抄另一个内核的扩展字段来假定两者行为相同。

验证入站时，先确认客户端日志没有监听错误，再让一个明确支持代理设置的应用指向该入口。若内核完全没有接收到请求，重点检查应用设置与接管范围；若已出现接收记录，再转向路由和出站章节。Android 的网络接管还受系统授权和按应用设置影响，其界面入口与桌面系统代理不同。

03 / OUTBOUNDS

outbounds 出站配置

出站描述内核如何连接目标，可以直接建立连接、交给远程代理，或按规则拒绝请求。入站负责接收，出站负责发送，两者之间通过路由关联。远程节点不可用时，本地入站仍可能正常监听；客户端界面能够显示节点名称，也不意味着其出站参数已经被当前内核接受。需要把配置生成成功与连接建立成功分别验证。

默认出口由顺序决定

传统配置中，没有被路由规则选中的流量通常交给 outbounds 数组的第一个出站。这个默认行为非常重要：只交换两个对象的位置，就可能改变所有未命中请求的路径。不能仅根据标签叫作 direct 或 proxy 推断默认出口；名称只是引用，实际行为由协议、设置与所在位置共同决定。

以下字段片段把直连放在首位，再提供一个拒绝出口。它适合解释本地基线与规则引用关系，并不是包含远程节点的配置。若实际需求是让未命中的请求进入远程代理，就必须重新设计首项或末尾兜底规则，同时检查域名解析、订阅更新和本地网络访问是否会被一并送往该出口。

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

直连、拒绝与远程协议

freedom 是直接连接目标的出站协议。直连仍受本机网络、防火墙和目标服务状态约束，不能因为绕过了远程节点就认定一定可达。blackhole 用于拒绝或丢弃匹配流量，适合明确的阻断规则；应用侧可能表现为失败、空响应或等待，具体取决于协议和响应配置。诊断时要先确认是否被主动送入拒绝出口。

远程代理出站还包含服务器地址、端口、身份信息，以及传输与安全参数。VMess、VLESS、Trojan 和 Shadowsocks 的设置对象并不通用，不能只替换 protocol 就把一种节点转换成另一种。应由可信的节点资料或客户端导入功能生成对应字段，然后检查生成配置，而不是在不完整的网络片段上逐项猜值。

节点地址对应连接的服务器，TLS 服务器名称用于握手校验或相关协议行为，两者不一定相同，但必须符合服务端部署。传输层的路径、主机名与安全层服务器名称也有不同用途。遇到握手失败时，应按层核对，不能把三个位置都改成服务器 IP。关闭证书验证会掩盖问题，不宜作为常规排错步骤。

内核支持范围先于字段拼接

Xray 与 V2Fly 共享一部分历史配置概念，但扩展协议和传输选项并不保证互通。节点需要 REALITY 或特定流控字段时，要先确认客户端实际启动的内核能够处理它。v2rayNG 与 v2flyNG 的内核取向不同；桌面端使用 v2rayN 时，也应以当前节点和运行信息为准，不根据客户端名称推断所有能力。

协议、传输与安全层是三个相关但不同的维度。VLESS 是代理协议，TLS 或 REALITY 属于安全相关设置，具体网络传输还有自己的参数。把某项功能写在错误层级，可能直接触发配置错误，也可能在加载后表现为协商失败。关于这些层次的背景，可结合REALITY 与 XTLS Vision 原理说明查阅，实际字段仍以所用内核为准。

标签与连接路径的复查

每个需要被规则引用的出站都应有唯一标签。重复标签使配置含义不清，工具对重复值的处理也不值得依赖。重命名出站后，应同步检查路由、可能存在的出口链以及其他引用处。仅修改界面中的节点显示名称，不一定会改变生成配置的出站标签；这也是查看实际运行配置比只看列表名称更可靠的原因。

诊断出站时，可先使用本地直连基线验证目标服务，再在同一个入口与相同测试目标下切换到远程出口。若只有远程路径失败，进一步检查服务器地址解析、端口连通、安全握手和认证参数。不同目标可能采用不同路由，不能用一次网页访问成功推断所有出口都正常，也不能用一个目标超时判断整个节点完全不可用。

最终维护时，应把默认出口、显式直连、显式拒绝和远程出口的职责写清楚。新增出口先单独验证，再让少量规则引用，最后再考虑改变默认路径。这样的顺序能防止一个新节点配置错误影响全部请求，也方便在发生故障时只回退相关规则，而不必重建整份配置。

04 / ROUTING

routing 规则与顺序

路由把请求条件映射到出站标签。理解它的关键不是规则数量，而是匹配顺序、条件组合和可见目标信息。传统字段规则通常从上往下检查，首次匹配后选定出口，不会自动寻找后面更具体的规则。因此，精确例外一般要放在宽泛规则之前，兜底放在末尾；文件中较靠后的规则并不具有覆盖前面规则的特殊权力。

一条规则内部如何组合

同一规则里的不同条件通常需要同时满足。例如同时填写 inboundTag 与 domain，含义是来源入口符合并且域名符合，而不是任意一个条件符合即可。同一条件的列表通常表示多个候选值，例如两个域名任选其一。需要表达两组独立条件时，应拆成两条规则，避免把本来想写的“或”误写成“且”。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "domain": [
          "full:example.com",
          "domain:example.org"
        ],
        "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",
          "fe80::/10"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

这是与前文基线兼容的路由字段片段。第一条只针对指定 SOCKS 入站；HTTP 入站即使访问相同域名，也不会命中它。第二条列出回环、私有和部分本地地址范围，但它不是完整的特殊用途地址数据库。实际配置如果需要更全面的地址分类，应使用经过确认的数据集合，并了解其更新与覆盖范围。

域名表达式需要区分精度

full: 用于完整域名匹配，适合只指定某一个主机名；domain: 用于匹配指定域及其子域。没有前缀的表达式可能按关键词匹配，其范围比看起来更宽。正则表达式还会受到 JSON 转义规则影响，过宽的表达式也可能增加理解和维护成本。能够用完整域名或域后缀表达时，优先采用更明确的写法。

域名规则匹配的是请求携带或内核识别到的目标信息，不是网页最终跳转后的所有资源。一个页面可能同时请求多个域名，所以主页走指定出口，并不代表图片、接口和视频也走同一出口。诊断规则时应选择单一目标请求观察，避免把整个网页的综合结果当成某条域名规则的直接证据。

解析策略改变的是匹配过程

AsIs 不为了路由的 IP 匹配主动解析域名；请求本身若已经是 IP，IP 规则仍然可以匹配。IPIfNonMatch 会在域名目标未匹配现有规则时尝试解析，再进行匹配。IPOnDemand 在路由处理需要 IP 信息时触发解析。它们不是系统 DNS 开关，也不是出口的域名解析策略。

切换到会触发解析的策略，可能改变延迟和命中结果。若 DNS 返回不同地区的地址，某些 IP 分类规则就会选择不同出口。相反，应用已经在内核外把域名变成 IP 时，仅修改内核的域名解析策略不能恢复原始域名。需要结合入站协议、嗅探和应用的解析方式分析，而不是不断交换 DNS 地址。

用例外、分类、兜底组织规则

可先放需要明确拒绝或指定出口的精确目标，再放本地网络与业务分类，最后处理剩余请求。具体顺序取决于策略，但每条规则都应能说明为什么位于当前位置。若末尾写一条覆盖全部目标的规则，后面的规则就不会发挥作用；若不写末尾规则，应明确接受首个出站作为默认出口的结果。

使用 geosite: 或 geoip: 分类时，需要对应数据文件和有效分类名称。内核支持语法，不等于部署环境已经携带所需数据。更新后某个分类加载失败，应先查数据路径与标签是否存在，不要直接删除所有分流规则。生成文件、客户端内置规则与自定义规则也可能有排序差异，应始终以运行配置为准。

调整规则后，通过日志确认目标、来源与出站是否符合预期。对于“部分网站正常、部分失败”的情况，优先比较实际命中的出口，再比较 DNS 与连接过程。只看客户端总开关或节点颜色，无法确认某一个请求的具体路由。长期维护时给规则分组保留简短说明，比持续追加重复规则更利于回退。

05 / DNS

dns 解析与连接路径

DNS 问题需要先确认“谁在解析”。应用可以自己查询，操作系统可以代为解析，内核也有内置解析器，远程代理还可能在另一端解析目标域名。顶层 dns 主要配置内核内置解析行为，不会自动改写设备上所有应用的 DNS 设置。把一个服务器地址填进配置后，仍然要确认实际请求是否经过这个解析器。

区分解析位置与查询出口

使用 SOCKS 时，应用可能把域名直接交给代理，也可能先在本机得到 IP 再发起连接。HTTP 代理请求通常能携带域名，但具体应用仍可能做预解析。虚拟网络接管场景还涉及 DNS 请求的拦截方式。只有明确输入给内核的是域名还是 IP，才能判断域名路由、内置 DNS 和出站解析各自是否参与。

下面是 dns 字段片段，演示静态主机映射、服务器列表与地址族选择。示例采用可访问的公共解析地址，但实际网络可能限制其可达性，也可能有组织内部解析需求。应根据自身网络条件选择，而不是把地址原样复制后就认为所有解析问题已经解决。

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

192.0.2.10 是文档示例地址，该映射只用于展示格式，不是可用的网站服务。静态映射应谨慎使用：它会让受影响域名固定到指定地址，可能破坏负载均衡、服务迁移和证书对应关系。测试结束后应删除示例映射，再用实际需要的域名与经过确认的地址建立生产规则。

DNS 策略与路由策略并不等价

queryStrategy 控制内置 DNS 查询或返回的地址族倾向；路由中的 domainStrategy 控制匹配时是否为域名取 IP；直连出站还可能有自己的域名解析策略。三个名字都与解析有关，但作用位置不同。只修改顶层 DNS，不保证直连出站会按相同方式使用结果，也不保证每个远程代理出站都在本地解析目标。

以传统直连出站为例，需要让它使用内置解析结果时，可根据内核支持情况配置相应策略。下面片段给直连出站增加 UseIP，表示连接域名时先取得 IP。它并不决定路由阶段的匹配顺序，也不修改其他出站。具体可用策略名称及地址族细分值，仍应以所运行内核的字段定义为准。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    }
  ]
}

查询本身也需要能够发出去

内置 DNS 产生的网络查询需要有可达路径。不同服务器形式，例如普通地址、加密解析地址或本地系统解析，可能采用不同连接机制，并不一定全部遵循同一套路由。给 DNS 请求加标签并单独分流属于进一步配置，需要核对当前内核的支持方式；不能假定填写任何 DNS 地址都会自动走当前选中的远程节点。

还要避免启动依赖循环。假设远程节点地址是域名，而解析服务器只能通过该远程节点访问，那么建立远程连接前所需的解析可能无法完成。加密解析服务自身若也是域名，也存在首次解析需求。排查时先保证节点地址和解析服务的初始解析路径可达，再讨论所有业务域名最终应该在哪里解析。

地址族、缓存与分域解析

设备具有 IPv6 地址不等于目标方向的 IPv6 路径正常。只请求 IPv4 有助于缩小某些问题范围，但不是所有环境的长期答案。若仅某一地址族失败，应检查路由、接口和上游连通性。双栈网络里解析结果与实际连接选择可能不同，要结合日志中的目标地址判断，不能只看 DNS 返回列表的第一项。

更换服务器后，应用、系统、内核和上游都可能仍有缓存。验证时应关闭旧连接，按客户端提供的方式重启相关组件，必要时处理系统缓存，再发起新请求。已有连接继续使用旧地址，并不能证明新设置没有保存。还要避免一次同时清空缓存、换节点和改规则，否则即使恢复也无法识别真正原因。

分域选择解析服务器时，规则列表、预期地址范围与回退设置可能相互影响。只有确实需要不同解析视图时才增加复杂配置，并记录每组域名的用途。内部域名尤其应交给能识别它的内部解析服务。若遇到连接建立但页面仍打不开，可按连接后无法上网排查清单继续检查系统代理、路由和目标服务。

06 / POLICY

policy 连接与统计策略

policy 用于配置用户等级对应的连接行为，以及系统层面的部分统计开关。它不是分流规则，不负责选择节点，也不会因为把超时数字调小就让连接更快。很多配置无需手动修改策略即可正常运行；只有出现明确的资源管理、连接保留或统计需求时，才值得逐项调整并对照实际流量观察。

等级对象与用户字段如何关联

levels 以等级编号作为对象键，例如 "0"。协议用户对象中的 level 用来选择策略等级，但不同协议的用户结构并不相同。有些本地入站设置还提供默认用户等级。不能把 level 随意放在任意顶层位置，也不能根据节点列表的排序推断用户等级。

下面是策略字段片段，展示等级与系统统计设置的层级。所列数值是教学配置值，并非针对所有网络的推荐参数。实际内核可能有不同默认值或细节行为，尤其在连接复用、不同传输和协议实现中，应先验证当前支持情况。没有明确需求时，保留默认策略通常比复制一组所谓优化参数更容易维护。

{
  "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 作用于连接一侧结束后，另一方向仍可继续传输的阶段，并非一般意义上的上传限速和下载限速。它们不应拿来设置带宽配额。某些协议或传输层对半关闭的处理不同，因此出现单向传输中断时，需要结合协议行为和日志，不宜只增加这两个数字。

统计开关不是完整统计系统

开启策略里的统计字段，只是允许相应计数，不等于自动出现可视化面板。完整统计通常还需要统计模块、相应管理接口以及读取工具。用户级统计还涉及可识别的用户信息。若客户端本身已经生成这些配置，应优先检查客户端的完整实现，不要另行添加同端口管理入口造成冲突。

客户端显示的流量也未必等同于内核某个单独计数器。系统接管范围、连接重试、协议开销和计数位置都会影响数值。比较流量时，应先说明统计发生在哪一层、从何时开始以及是否包含全部入口。不能把某个界面数字直接当成上游服务的计费依据，也不应在不了解统计边界时判断计数出错。

按业务验证，而不是追求统一参数

策略变更应围绕真实使用场景验证。短网页请求可检查首次连接和连续请求；长连接应用需要观察空闲后是否还能恢复数据；大文件传输则要确认单向结束与连接保留没有导致中途截断。一次只改一个字段，并记录原值、测试方式和结果，才能区分网络波动与策略本身的影响。

设备资源紧张时，还要检查是否存在重复内核、过多测速任务或不必要的后台请求。策略不是解决所有资源问题的总开关。若没有证据表明连接管理是瓶颈，先清理多余任务与失效入口，通常比缩短所有超时更直接。需要恢复时，回到客户端默认策略，再按相同测试复查，避免保留一组来源不明的长期参数。

07 / LOG

log 日志与错误定位

日志用于说明某一次请求发生了什么，不是只凭一条英文报错就能确定责任位置。应结合请求时间、入站来源、目标地址、出站标签和后续状态分析。后台应用会不断发起连接，若同时测试多个网站，很容易把别的请求错误对应到当前操作。诊断开始前先缩小流量范围，再复现一个明确目标。

日志级别与输出位置

loglevel 控制错误日志的详细程度，常见级别包括 debug、info、warning、error 与 none。平时可使用较克制的级别，排查路由和连接时临时提高详细程度。详细日志可能较多，并包含目标信息，问题定位后应恢复原设置，避免长期积累不必要的数据。

{
  "log": {
    "access": "access.log",
    "error": "error.log",
    "loglevel": "info"
  }
}

这是文件输出的字段片段。相对路径通常与进程工作目录有关，不一定就是配置文件所在目录。图形客户端也可能接管标准输出并展示在运行日志窗口中。若找不到文件，先确认启动方式、工作目录与目录写入权限，不要因此判断内核没有运行。需要固定位置时，应使用本机实际存在且允许写入的路径。

访问日志与错误日志的用途不同。访问记录可帮助观察请求接收和路径，错误记录关注异常过程，但某条访问记录并不保证目标内容最终完整传输。不同内核和日志级别展示的字段也可能不同。若没有看到预期的出站标签，可以临时提高日志详细度，或回到实际运行配置核对规则，而不是据此猜测默认路径。

按处理链阅读常见错误

出现 connection refused 时，通常意味着连接被目标地址对应的一端明确拒绝。若目标是本地代理端口，先检查内核是否监听；若目标是远程节点端口，检查服务是否运行、地址与端口是否正确。它不天然等于认证失败，因为认证通常发生在连接建立之后；必须先辨认日志里的地址属于哪一层。

i/o timeout 说明某个读写阶段超出了等待时间，但可能发生在建立连接、握手或传输过程中。地址不可达、响应缺失、路径丢包和错误协议都可能产生类似表象。应寻找同一请求之前的记录，确认它最后完成到哪一步。只把所有超时参数调大，往往只会延长等待，并不能修复连接路径。

TLS 相关错误应核对系统时间、服务器名称、证书链及安全设置。使用 IP 连接与使用域名校验可能有不同要求，传输层主机名也不等于证书名称。若服务端要求特定安全协议而客户端配置成另一种，端口仍可能可连但握手失败。此时应该修正字段组合，而不是将所有验证选项关闭。

启动错误与运行错误分别处理

启动前失败通常指向 JSON 语法、字段类型、不可识别协议、数据文件或端口绑定。先让内核稳定启动，再测试网络。运行中失败则要按请求追踪。若客户端不断启动又退出，不要把反复出现的启动提示误当成正常运行；应找到第一次致命错误，后面的连接失败可能只是内核已经退出的结果。

遇到标签不存在，先检查规则引用和出站数组；遇到分类数据加载失败，核对数据文件与分类名称；遇到权限错误，检查输出目录和接管功能所需权限。不要为了消除报错直接删除整个模块。每条错误都应对应一个配置对象，尽量在这个对象的范围内修复，再重新执行相同的启动或请求测试。

保留必要证据与隐去敏感信息

分享日志求助前，应删去身份信息、完整订阅地址、远程节点凭据和不希望公开的访问目标。截图也要检查窗口标题、剪贴板内容与侧边栏。为了保留排查价值，可以保留字段名称、错误类型、相对时间关系和匿名化后的标签，不要只截取最后一行而省略关键上下文。

建议记录测试时间、使用入口、测试目标、预期出口和实际结果，形成一条完整证据链。若修改规则后错误内容没有任何变化，应确认运行文件确实更新、旧进程确实停止，以及测试应用没有复用旧连接。更详细的报错语义可继续查阅v2rayN 运行日志定位方法，但最终判断仍以当前配置和同一次请求为准。

日志文件还需要控制保存范围。长期运行环境应结合客户端能力定期清理或轮转，避免磁盘占用持续增长。删除正在写入的文件是否立即释放空间取决于系统行为，所以维护前最好先停止相关日志输出或关闭内核。日志保存的目标是支持复现与诊断，不是无期限记录所有访问。

08 / VALIDATION

配置验证与变更维护

配置验证应分为文本、结构、启动、路径和业务五层。文本能解析不等于字段有效，字段有效不等于端口能够监听，端口能监听不等于请求命中正确出口，连接成功也不等于所有应用都已经纳入接管。按层检查，才能避免在上游问题尚未解决时不断改动下游参数。

保存原配置与变更目的

修改前先保存一份已知可用配置，并记录它适用的客户端、内核和工作模式。备份应放在受控位置，不要把含身份信息的文件随意同步或公开。文件名可以标注用途和本地维护日期，但不要只依赖“最终版”这类含糊名称。回退时需要知道它对应哪组入口、出口和规则，而不仅是知道文件曾经能够打开。

每次变更写清楚预期效果，例如“指定域名改走直连”或“新增测试入口”，随后设计能直接验证这一效果的请求。如果目标只是修复某一个域名，不应顺便更换所有 DNS 和连接策略。范围越小，测试失败时需要检查的差异越少，也更容易判断是否应该撤销本次修改。

第一层：语法与结构检查

使用本地编辑器的 JSON 诊断功能检查括号、引号、逗号与字段类型，避免把配置上传到不明在线工具。接着逐个检查顶层对象的位置：嗅探属于单个入站，出站设置属于对应出站，规则属于 routing.rules。结构位置错误有时比拼写错误更隐蔽，因为整份文件仍然可以通过普通 JSON 解析。

再检查所有引用：规则中的出口标签是否存在，入站标签是否逐字一致，分类名称是否在当前数据文件中，日志路径是否可写。标签不是自动生成的变量引用，修改一端不会同步修改另一端。对照表中最好同时记录显示名称与实际标签，避免把客户端界面名称误当成内核字段值。

第二层：启动与本地路径

通过客户端提供的配置检查或运行信息确认内核能够加载。不同内核的命令行检查方式可能不同，本页不把某一个启动参数当成通用命令。启动成功后查看本地监听是否正常，再让支持代理的测试应用明确使用该入口。若没有接收记录，回到代理地址、端口、应用设置和系统授权检查。

可先回退到第一章的完整直连基线，确认本地请求能被接收并发送。如果基线也失败，就没有必要先研究远程节点安全参数。若基线成功而自定义配置失败，可按入站、出站、路由、DNS、策略的顺序逐段恢复。每恢复一段都重启并测试，找到首次出现差异的边界。

第三层：路由与业务复核

选择一个预期走指定出口的目标，再选择一个不应被该规则影响的目标作对照。记录两者实际出站，确认规则没有扩大范围。域名规则还要考虑子域、页面资源与重定向；端口规则需要区分目标端口和本地监听端口。对照测试比单次看到网页打开更能证明规则含义与实际行为一致。

同一内核配置在不同系统上，文件路径、监听权限和网络接管入口可能不同。应用自身的网络设置也未必跟随桌面环境。不能把一台设备上的成功配置只替换节点后，就认定另一台设备具备完全相同的路径。首次迁移时应重新验证入口和授权，再复用协议与路由逻辑。

更新、回退与长期查阅

更新客户端或切换内核后，先保留旧配置和变更记录，复核生成配置是否仍含原有规则。订阅更新主要影响节点资料，通常不等于完整运行配置的版本管理。若自定义字段被覆盖，应返回客户端支持的持久配置入口，不要把反复修改临时文件作为固定维护流程。

出现问题时，优先撤销最近一次相关变更，再重复相同测试。恢复可用后比较前后差异，定位到具体字段，而不是把整份旧文件永久替换回去却不再分析。涉及内核差异时，可以先保留原协议和传输组合，避免在同一次回退中更换客户端、内核、节点与规则，导致测试条件全部改变。

日常连接操作继续使用上手教程中的主线流程；需要换平台或选择客户端时查阅三款客户端对比，安装包入口见下载页。本页则按字段保留查阅路径：接收问题看入站，出口问题看出站，命中异常看路由，域名问题看 DNS，连接保留看策略，最后用日志和对照测试验证结论。