V2Ray 配置文件参考

一、JSON 结构与配置加载边界

从一条请求理解顶层对象

一份配置描述的是内核怎样接收连接、选择转发方式以及处理辅助功能，不是订阅地址的另一种写法。应用先把请求送进某个入站，路由模块读取目标与来源信息，再把连接交给选定的出站。DNS、日志和策略在不同环节参与处理。理解这条路径后，修改配置时就能先确定问题属于哪一层，而不是同时改动几个看起来相关的开关。

常见顶层对象包括 log、inbounds、outbounds、routing、dns 与 policy。入站和出站通常是数组，因为可以同时存在多个监听入口和多种出口；路由则用规则数组表达匹配顺序。数组的位置可能影响行为，对象字段的书写顺序通常不影响语义。整理排版可以提高可读性，但不应为了美观随意重排出站或路由规则。

先建立可运行的本地基线

下面的完整示例在本机回环地址监听 SOCKS 端口，并使用直连出站。它只用于确认内核能够读取文件、绑定端口和处理本地请求，不会建立远端代理隧道。启动前确认端口没有被客户端占用，测试时让应用明确使用这个 SOCKS 入口。示例未启用 UDP，便于把首次验证收敛到 TCP 请求；后续章节再分别说明其他能力。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

JSON 的字符串必须使用英文双引号，布尔值写成 true 或 false，数字不需要引号。数组和对象的末项后面不要保留逗号，也不要把中文说明直接插入代码。某些工具允许带注释的扩展格式，但编辑器能打开并不代表内核接受。跨工具传递配置时，使用严格 JSON 更容易定位语法问题，文件保存为 UTF-8 文本即可。

字段存在，不等于当前内核支持

V2Fly 与 Xray 有共同的配置沿革，但协议支持、传输选项和字段演进并不完全相同。阅读示例时先确认运行进程对应哪个内核，再核对该内核的字段定义。客户端界面出现一个选项，只能说明客户端提供了相应配置入口，不能推导出任意内核都接受相同 JSON。sing-box 使用另一套结构，本页示例不能直接作为它的配置文件加载。

还要区分“编辑的文件”和“进程加载的文件”。图形客户端可能在启动时生成临时运行配置，自定义配置也可能通过独立条目载入。保存某个目录中的 JSON 后没有变化，首先查看启动日志或配置详情，确认实际加载路径与当前条目。不要默认程序目录里名称相似的文件就是生效文件，更不要同时编辑客户端数据库和生成文件来碰运气。

配置文件的可维护性主要来自清晰的边界。建议先保留一份能够工作的基线，再把每次修改限制在一个对象中；确认有效后记录修改原因和预期结果。片段合并时特别注意顶层同名字段，只能保留一个对应对象或数组，不能把两份完整配置首尾拼接。重复键即使被解析器接受，也可能只保留其中一个值，使编辑结果与阅读印象不一致。

本页按照入口、出口、路由、解析和策略展开，最后回到客户端管理与验证流程。实际使用时可以按目录跳读，但涉及转发异常时仍应沿请求路径检查。先确认流量确实进入目标进程，再讨论规则有没有命中；否则在没有入口流量的情况下调整路由，只会让排查记录增加变量，无法说明任何规则是否正确。

二、inbounds 入站监听与流量入口

监听地址、端口与协议各管一件事

inbounds 中的每个对象定义一个入口。listen 决定绑定哪个本地地址，port 决定监听端口，protocol 决定入口接受什么协议。应用必须使用与入口一致的代理方式，不能把 HTTP 代理地址填入只接收 SOCKS 的端口。端口号只是本地约定，不代表某种固定能力；复制配置时应以当前文件和客户端显示的实际值为准。

仅供本机使用时，把监听地址明确设置为 127.0.0.1。它是 IPv4 回环地址，其他设备无法直接访问这个监听。若改为 0.0.0.0，含义是绑定所有 IPv4 接口，不是一个可填入其他设备的目标地址。开放局域网访问还涉及主机地址、防火墙和认证，应作为单独变更处理，不要为解决本机连接失败而直接扩大监听范围。

SOCKS 与 HTTP 的并列入口

下面的片段在第一章的 SOCKS 入口之外增加 HTTP 入口，适合需要分别填写两类代理设置的应用。把它作为完整的 inbounds 数组替换原数组，而不是在顶层再写第二个同名字段。两个入口使用不同端口，出站仍可共用同一个对象。这里的标签只用于配置内部引用，不会让系统自动识别或自动启用代理。

{
  "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 表示允许处理 SOCKS UDP 转发请求，不代表所有经过系统代理的程序都获得 UDP 支持。应用本身必须使用对应能力，出站协议、服务器与网络路径也要支持相应流量。HTTP 入站则主要服务于遵循 HTTP 代理设置的应用。遇到浏览器正常、其他程序异常，应先检查它们采用的入口机制，而不是只比较目标域名。

tag 应当简短、唯一、便于阅读。路由可用 inboundTag 匹配某个入口，从而让不同本地端口采用不同出口。标签没有自动纠错能力，改名后必须同步修改引用；否则规则可能不再匹配，却没有明显的语法错误。建议在配置说明中记录每个入口对应哪类应用，避免长期维护后只剩端口数字而无法确认用途。

嗅探能补充目标信息，但不是解析替代品

部分应用把域名解析成 IP 后才发送代理请求，路由收到的目标就不再是原始域名。sniffing 可以尝试从受支持的应用层握手中识别域名，供后续处理使用。常见的 destOverride 值包括 http 和 tls。但嗅探不保证对所有流量有效，也不能解密任意应用数据；是否改变连接目标还要结合所用内核的具体行为核对。

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

这个片段应放入某个入站对象内部，不是独立顶层模块。启用前先说明目的：是为了补充域名路由，还是要处理目标地址恢复。若应用协议不在支持范围内，或者握手没有提供可识别信息，就仍需依赖原始目标和 IP 规则。不要把嗅探当成所有域名分流问题的统一修复；改变嗅探设置后，应重新检查受影响应用的连接结果。

排查端口绑定失败时，先关闭可能重复运行的客户端，再检查是否有其他进程占用相同地址与端口。不要连续改几个端口后忘记更新应用设置。若监听已经成功但应用没有请求记录，检查应用是否采用自身代理设置、是否绕过本机地址，以及系统代理是否仍指向旧端口。入口确认后再检查出站，能避免把“没有连接进入”误判成“远端不可用”。

三、outbounds 出站协议与传输参数

出站对象定义实际转发方式

outbounds 可以包含直连、阻断和远端代理等不同对象。protocol 指定出站协议，settings 保存该协议需要的参数，tag 供路由引用。出站标签不是服务器地址，也不是客户端显示的别名；中文别名改变后，生成配置中的标签是否变化由客户端决定。查阅运行配置时，应以对象中真实存在的标签为准，不能凭界面名称推测引用关系。

没有路由规则命中时，常见配置会使用出站数组中的第一个对象。因此，数组顺序不是纯粹的排版问题。把直连对象从第二项移到第一项，可能改变所有未匹配流量的去向。为了让行为更容易阅读，可以在路由末尾设置明确的兜底规则，但仍应确认第一出站的含义，特别是处理客户端生成配置和自行维护配置之间的迁移时。

直连和阻断的最小对象

下面定义两个出站：freedom 把流量交给本机网络直接连接目标，blackhole 则丢弃匹配流量。它们本身不需要远端服务器信息。这个数组可以与第一章的入站组合使用，不过如果没有新增路由，阻断对象不会因为存在于数组中就自动生效。配置对象负责提供能力，路由负责选择能力，两者应分开理解。

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

远端代理出站通常还需要服务地址、端口、身份参数与传输设置。这些内容必须由实际服务配置决定，不能从客户端名称推导。VMess、VLESS 与 Trojan 的认证字段并不相同，TLS、WebSocket 等传输参数也不应混入错误层级。优先导入服务方提供的有效订阅或链接，再查看客户端生成结果，比手工从零拼接多层结构更容易保持一致。

协议、传输与安全层分别核对

streamSettings 描述底层传输和安全相关设置，与 settings 中的协议身份信息分工不同。服务端使用什么传输，客户端就必须使用对应结构；路径、主机名和安全参数需要成套匹配。把传输名称改成另一种方式并不能自动转换服务端。遇到握手失败时，先核对服务端要求的组合，再检查本地选项，而不是逐个尝试所有下拉项。

连接地址与 TLS 验证使用的服务器名称不是同一概念。前者决定连接到哪里，后者参与证书身份验证；某些部署中二者可以不同，但必须有明确的服务配置依据。证书报错时应检查系统时间、服务器名称和证书链，而不是直接跳过验证。跳过验证会改变连接的安全条件，不能用作长期解决方案，也不能证明其他参数已经正确。

REALITY 等专用能力需要对应内核和相匹配的服务端参数。不要因为 JSON 中也出现安全相关字段，就把示例直接移植到另一套内核。v2rayN 可管理不同内核的条目，但不等于所有条目都能随意切换执行程序。Android 端的 v2rayNG 与 v2flyNG 也应按各自内核能力选择；三款客户端的分工可参阅客户端对比。

出站排错应从单个对象开始。暂时使用明确的兜底规则让测试请求只走目标出站，确认基本连接后再恢复复杂分流。若只有某一类网站失败，检查目标解析和规则；若所有目标都无法建立连接，再核对远端地址、认证与传输。不要同时启用多种连接优化来掩盖基础错误，因为新增层次会让日志中的失败位置更难对应到原始请求。

订阅更新后，服务方可能调整连接参数，客户端也可能重新生成内部标签。手工维护的自定义路由如果引用旧标签，就需要再次检查。建议把远端参数交给订阅条目管理，把长期稳定的分流意图放在路由设置中。确实需要完全自定义出站时，应记录参数来源和内核要求，分享排错材料前移除身份字段与私人订阅地址。

四、routing 路由规则与匹配顺序

先匹配的规则决定出口

routing.rules 是有顺序的规则数组。对常见字段规则而言，同一个数组字段中的多个候选通常按“任一符合”处理，而不同条件字段之间需要同时满足。例如一条规则同时设置入站标签和域名，就只处理从指定入口进入、且目标域名符合条件的连接。规则越靠前越先参与匹配，特例应放在广泛规则之前，兜底规则放在最后。

下面的示例先阻断文档示例域名，再把私有地址交给直连，最后把其余 TCP 与 UDP 流量也交给直连。它用于演示顺序与标签引用，不是一套远端代理分流方案。使用前需要有标签为 direct 和 block 的出站，并安装可被当前内核读取的 GeoIP 数据文件；没有数据库时应先移除对应规则完成基线验证。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:example.org"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

域名写法需要表达精确意图

full:example.org 表示精确匹配这个域名，domain:example.org 用于匹配该域名及其子域名。正则规则的表达能力更强，但也更容易匹配过宽；普通需求优先用明确的完整域名或后缀规则。不要把网页完整地址直接写进域名列表，路径、查询参数与片段不属于域名条件，使用带路径的地址常会导致规则看起来存在却始终不命中。

IP 条件可以使用单个地址、网段或数据库引用。域名规则与 IP 规则处理的是不同信息，不能假定一个域名命中某个类别后，它的所有解析地址也具有相同分类。内容分发网络可能让多个站点共享地址，也可能让同一站点返回不同地区地址。对需要精确控制的业务，优先说明匹配依据，再决定使用域名还是地址，避免用大网段替代少量明确域名。

domainStrategy 控制路由中的解析时机

AsIs 以连接已有的目标信息参与路由，不为了匹配 IP 规则主动进行额外解析。IPIfNonMatch 会在已有条件未匹配时尝试解析域名，再进行相应匹配；IPOnDemand 则在匹配过程需要 IP 信息时触发解析。选择后两者意味着路由结果可能依赖 DNS 返回值，解析失败或地址变化都会影响判断，应与第五章一起阅读。

这里的路由解析策略不等于所有出站的地址处理策略，也不等于操作系统 DNS 设置。名称相似的字段处在不同模块，作用时间和范围可能不同。修改之前先定位对象路径，再描述预期：“域名未命中时使用解析地址参与规则”比“打开智能解析”更明确。若应用已经提交 IP 目标，相关域名解析策略也无法凭空恢复原始域名。

GeoIP 与 GeoSite 数据需要配套管理。更新文件后，确认实际运行的内核读取了新的文件，并按客户端要求重启或重载；只替换另一目录中的副本不会改变结果。若出现找不到类别、无法读取数据等错误，先确认文件来源与路径，再考虑规则写法。具体更新思路可查阅GeoIP 与 GeoSite 数据库更新指南。

客户端中的“绕过大陆”等预设是成组规则，不是单个开关的同义词。切换预设可能同时改变域名、IP 与兜底出口，因此排错时应查看生成的完整规则。需要添加单个例外时，把它放在会提前命中的广泛规则之前，并确认保存后重新加载。测试至少覆盖一个应命中的目标和一个不应命中的目标，才能判断条件是否过宽。

多入口场景还可以通过 inboundTag 隔离应用，例如让单独的本地端口使用固定出口。这种方式比反复调整系统代理更适合可手工指定代理的程序，但前提是应用确实连接了对应入口。若路由无效，按入口标签、原始目标、规则顺序、出站标签四项依次核对；不要一看到访问结果不符就先更换数据库或修改远端协议。

五、dns 解析配置与查询路径

先分清哪一层发起解析

一次访问可能涉及应用自己的解析、操作系统解析、内核内置 DNS，以及远端服务的解析。顶层 dns 配置只管理内核内置解析器参与的部分，不会自动接管所有程序的域名查询。浏览器启用自身的加密 DNS 后，查询路径又可能不同。排查时先记录目标以域名还是 IP 进入内核，再判断当前问题是否真的属于这个对象。

内置 DNS 可以被路由的域名解析策略、特定出站行为等功能调用。仅添加一个服务器数组，不会让所有代理请求都先在本地解析；远端协议也可能把域名交给另一端处理。反过来，应用若在请求前已经解析并提交 IP，内核就可能没有机会使用这里的服务器。看到系统解析结果正常，只能证明系统这条路径可用，不能证明内核解析也相同。

最小服务器与静态映射示例

下面片段使用一个普通 DNS 服务器，并给文档示例域名添加静态映射。映射地址属于文档示例用途，不承载真实站点服务，验证时只观察解析结果，不用它判断网页连通性。静态映射的作用是说明结构，不建议把大量网站地址长期固化到配置里；服务地址变更后，固定记录容易变成难以察觉的故障来源。

{
  "dns": {
    "hosts": {
      "example.org": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1"
    ]
  }
}

hosts 提供内置解析器的静态结果，servers 定义上游服务器。服务器地址能否到达取决于当前网络，示例地址不是任何环境中的保证。普通 DNS 与加密 DNS 在传输、证书和引导解析方面存在差异；切换前应先验证所选服务的可达性，再检查该内核支持的配置形式，而不是把一个网页地址直接当作解析接口。

分域解析与结果约束

服务器也可以写成对象，通过 domains 声明优先匹配的域名范围。下面给示例域名设置专门服务器，其余查询交给默认候选。匹配服务器失败后是否回退，以及回退包含哪些候选，还与所用内核的设置有关。不要仅根据数组位置认定“只要在前面就始终优先”，应分别理解域名匹配、候选选择和失败回退这几个阶段。

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": [
          "domain:example.org"
        ]
      },
      "8.8.8.8"
    ]
  }
}

部分配置会进一步通过 expectIPs 约束可接受的解析结果。它是结果筛选条件，不是把错误答案自动修正成正确答案。约束过严时，服务器虽然返回地址，内核仍可能拒绝结果，表现得像解析失败。使用数据库引用约束结果还会增加数据文件依赖，排错时应先简化为不带结果限制的解析，再逐项恢复条件确认影响。

路由中的 domainStrategy 与 DNS 的组合尤其容易形成误解。若使用按需解析，首次连接可能需要等待域名结果才能决定出口；若上游又依赖尚未建立的代理路径，就要检查是否出现循环依赖。远端服务器本身使用域名时，也需要有可用的引导解析方式。应把服务器地址解析和普通业务域名解析分开验证，不能只看一个测试网站。

IPv4 与 IPv6 结果也需要分别观察。网络能获得 IPv6 地址，不代表对应出口具备完整的 IPv6 连通性；应用可能优先尝试某类地址，随后回退，形成间歇性等待。不要一出现慢连接就永久关闭某个地址族。先用同一目标分别验证解析结果和连接路径，再按内核支持的查询策略调整，避免把链路问题误写成域名分类问题。

TUN 场景还包含系统 DNS 如何进入虚拟网卡、是否存在劫持或重定向等额外环节。这些行为不能只靠本页的顶层 DNS 对象解释，需要结合客户端生成的 TUN 配置查看。相关原理见v2rayN TUN 模式说明。任何涉及 DNS 的变更，都建议重新建立应用连接并注意缓存影响，避免拿旧解析结果评价新配置。

六、policy 等级策略、超时与统计

策略等级不是路由优先级

policy 用于定义连接行为和统计相关策略，其中 levels 按用户等级组织配置。这里的等级不是订阅分组序号，也不是路由规则的执行优先级。某些协议用户配置中的 level 会关联对应策略，未单独指定时通常使用默认等级。修改一个没有任何用户引用的等级，可能不会改变当前连接，因此应先确认策略应用到谁。

下面的片段给等级零设置连接阶段和空闲处理参数。数值以秒为单位，用于展示字段关系，不是适合所有网络的推荐模板。应把它作为顶层 policy 对象合并进配置。若已经有其他等级或系统统计设置，需要保留原有字段再调整，不能用示例整体覆盖之后，又把缺失功能误判为内核行为变化。

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    }
  }
}

连接生命周期中的四个时间字段

handshake 约束入站连接完成握手阶段的等待时间，不是所有远端连接过程的统一超时。把它增加，不能解决认证字段错误或传输方式不匹配。若链路在建立后才出现停顿，就应检查空闲策略、远端状态和应用行为。日志中同样出现“超时”两个字，并不意味着都由这个字段控制，必须结合出错阶段理解。

connIdle 关注连接在没有数据传输时的空闲持续时间。设置过短可能影响长时间保持但低频传输的会话，设置很长则可能延迟释放失去实际用途的连接。即时通信、远程终端和普通网页的连接特征不同，不能只用一次网页加载判断是否合理。调整后应观察原先出问题的应用，并覆盖它实际可能经历的等待时间。

uplinkOnly 与 downlinkOnly 分别涉及连接只剩单向传输阶段时的等待行为。它们不是上传和下载速度限制，也不是路由选择条件。某些应用会在发送结束后继续等待较长响应，因此单向阶段的处理会影响连接结束时机。遇到响应被提前截断，先确认连接状态与日志，再考虑这些字段，避免把服务端主动关闭误当成客户端策略。

统计开关不等于完整统计界面

需要内核统计时，常见配置会同时包含顶层 stats 对象和 policy.system 下的统计开关。下面仅演示入站与出站总量统计的开启方式。它不会自行创建图形面板，也不代表客户端一定读取这些计数；读取方式还涉及客户端实现或相应接口。没有查询途径时，增加统计字段本身不会让界面凭空出现新栏目。

{
  "stats": {},
  "policy": {
    "system": {
      "statsInboundUplink": true,
      "statsInboundDownlink": true,
      "statsOutboundUplink": true,
      "statsOutboundDownlink": true
    }
  }
}

如果同时需要前面的等级策略，应把 levels 和 system 合并到同一个 policy 对象，而不是复制两个同名对象。用户级统计还有协议和用户标识等关联条件，不应把系统统计开关误当成用户统计配置。比较计数时也要考虑进程重启、会话结束和客户端汇总方式，否则两次界面读数的差异可能只是统计周期不同。

缓冲与资源相关选项属于更进一步的调优范围。没有资源瓶颈证据时，优先保留内核默认值，避免照抄所谓通用优化参数。缓冲增加可能提高内存占用，缩小则可能影响特定流量；效果还取决于并发连接和应用读写模式。先确认协议、路由与 DNS 正确，再对单一瓶颈做对照测试，比一次写入大量策略更容易解释结果。

策略排错要保留稳定的观察窗口。先记录发生问题的应用、空闲时长与连接阶段，再只修改一个字段，重启受影响连接后复测。若改变策略仍无差异，应检查实际加载文件、用户等级和当前执行内核。不要不断加大超时来延后失败；若根因是远端拒绝或地址不可达，延长等待只会让每次错误更晚暴露，并不会恢复连接。

七、v2rayN 生成配置与自定义配置

把持久设置与运行产物分开维护

v2rayN 把节点、订阅分组、路由与参数设置保存为客户端可管理的数据，再按照选定内核生成运行配置。生成文件更接近执行产物，不一定是长期编辑入口。直接修改生成结果后，切换服务器、重载或重新启动都可能覆盖变更。需要长期保留的设置，应优先在对应界面中修改；需要完全掌控 JSON 时，再评估自定义配置条目的管理方式。

使用前先明确当前工作模式：普通节点条目通常由客户端负责拼接入站、出站和公共设置；自定义配置条目则可能保留更多文件内容。两类模式的菜单操作未必作用于同一层。不能默认切换界面上的路由预设，就会重写任意自定义 JSON。判断某个设置是否生效，应查看重新加载后的实际运行配置，而不是只确认界面按钮处于选中状态。

公共参数、节点参数与订阅来源

本地监听端口、内核选择等公共参数可从参数设置相关页面查找，具体名称随客户端界面调整而变化。远端地址、认证和传输属于节点参数，订阅地址与更新间隔属于订阅分组。把问题放在正确入口处理很重要：更新间隔不会改变握手协议，系统代理设置不会修改远端服务器，切换路由预设也不等于重新下载订阅内容。

订阅更新可以覆盖来源条目的连接信息，所以长期手工修改订阅节点时，要考虑下一次更新的影响。如果只是临时试验，先复制为可独立管理的条目，并明确标记用途；如果是服务方参数变化，应更新来源而不是反复修补旧字段。订阅无法获取时先处理地址、网络与时间问题，具体步骤见订阅更新失败排查。

内核切换不能只替换程序名称

v2rayN 可按客户端提供的入口管理不同内核，但某个条目能否切换，取决于它所使用的协议和传输能力。不要把 Xray 专用配置交给 V2Fly 后，仅凭 JSON 语法正确就认定可用。sing-box 的配置对象结构不同，更不能直接复用本页片段。切换前先确认客户端会重新生成匹配格式，或为自定义配置准备独立的对应文件。

Windows 的 WPF 界面与跨平台桌面界面在菜单组织、托盘和系统集成上可能不同，但入口、出口和路由这些概念仍可共用。macOS 与 Linux 还需要留意系统代理和权限机制的差异，特别是 TUN 相关操作。安装包选择见桌面版与 WPF 版区别，不要为了找到相同菜单而安装不适合当前平台的包。

Android 端的 v2rayNG 与 v2flyNG 应按各自内核和界面管理设置，不能把桌面端菜单路径机械照搬。导入链接或订阅时，检查客户端支持的协议与参数；导入完整 JSON 时，还要确认这是客户端明确支持的导入类型。订阅链接、单节点分享链接和完整配置文件是三类不同资料，即使都以文本形式保存，也不能互相替代。

建议为自定义配置建立简单的变更记录，写明修改对象、预期行为和回退方式。记录保存在本地，不必把私人配置上传到公开位置。需要分享排错材料时，保留对象结构、标签和错误信息，移除身份字段、私人服务器地址与订阅链接。只遮住一段认证内容不一定足够，其他字段也可能暴露服务信息或个人使用习惯。

维护顺序应保持单一来源：由界面管理的内容在界面修改，由自定义文件管理的内容在文件修改。不要让两套配置长期相互覆盖。每次变更后先检查生成结果，再观察进程日志，最后测试应用；若界面显示与实际行为不同，优先确认加载链路。对于只想完成连接的用户，仍应回到快速上手主线，不必先掌握所有顶层对象。

八、配置验证、日志定位与回退

按语法、加载、入口、出口依次检查

配置排错的第一步是判断失败发生在哪个阶段。JSON 语法错误会阻止文件被正确解析；字段不受支持或引用不存在，可能在加载阶段报错；端口被占用会影响监听；远端握手问题则通常发生在已有请求进入之后。这些阶段的修复方法不同。先读取第一条有实际含义的错误，不要只关注最后一行“启动失败”，因为后续提示往往只是前面错误的结果。

编辑前保留当前可工作的文件或客户端设置备份，记录本次只准备修改哪个对象。编辑完成后先检查括号、逗号、值类型与重复键，再通过客户端重载观察内核是否成功启动。若客户端提供配置查看或日志入口，确认其中显示的是刚修改的条目。不要在失败后继续叠加新规则；先回到最近可工作的状态，才能说明是哪项变更造成差异。

用明确的本地请求验证入口

下面两条命令使用支持相应选项的 curl，分别测试本地 SOCKS 和 HTTP 入口。它们对应第二章的端口，仅在该配置实际运行时使用。SOCKS 命令中的 socks5-hostname 会把目标域名交给代理侧处理；如果改用本地解析方式，测试的 DNS 路径就不同。测试站点的可达性仍受当前网络和出口影响，命令不是成功保证。

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

若提示无法连接本地端口，先检查进程、监听地址与端口，不需要立即改远端设置。若本地连接建立后才失败，再检查目标解析、路由选择和出站握手。测试时尽量保持同一目标与同一入口，只改变一个条件；混用浏览器缓存、系统代理和命令行直连会引入不同路径，使看似相同的访问实际上无法比较。

临时增加日志，不长期保留详细记录

默认警告级别适合日常使用，排查路由或连接问题时可以临时提高到 info。下面片段仅调整错误日志的详细程度，不指定文件路径，便于先由客户端日志界面接收。若需要写入文件，确认目录可写、路径符合当前操作系统格式，并留意文件增长。日志中可能含有目标域名和连接信息，分享前应检查并清理敏感内容。

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

读日志时应围绕一次新建请求，按时间顺序观察入口接收、目标识别、出站选择与失败位置。规则没有命中时检查条件和顺序；标签不存在时检查引用；证书错误时检查时间与服务器身份；数据库读取失败时检查文件路径和类别。不同内核的措辞可能不同，不要把一段网上常见错误描述当作唯一判断标准，应结合本次请求的上下文。

复杂配置最有效的回退方式是逐层恢复。先验证第一章的本地直连基线，再加入目标出站，然后恢复少量路由，最后恢复 DNS 和策略调整。若使用图形客户端，不必手工替换整套运行文件，可以通过独立测试条目保持生产条目不变。恢复过程中每一步都建立新连接，并写下结果，避免旧会话继续沿用先前出口干扰判断。

单次访问成功不等于配置完整正确。至少测试一个预期直连的目标、一个预期走其他出口的目标，以及需要长期保持的应用；如果启用了 UDP 或 TUN，还应分别验证对应流量。验证范围要与本次变更一致，不要把 TCP 网页正常推导为所有流量正常。遇到仅特定应用失败，可继续查阅疑难解答，按入口机制缩小范围。

结束排查后恢复合适的日志级别，移除临时域名映射和测试规则，确认客户端重新启动后仍能加载同一套设置。把最终有效的修改回写到长期维护来源，而不是只留在生成文件中。需要理解内核归属时可参阅Project V、V2Fly 与 Xray 生态关系；维护配置的目标是让每项行为都能解释、复测和回退，而不是不断增加字段。