V2Ray 配置文件参考

JSON 结构与配置来源

先确定正在编辑哪一层

V2Ray 配置并不等于客户端窗口中看到的全部设置。v2rayN 保存订阅分组、界面选项和路由预设，再依据当前服务器与内核生成运行配置。v2rayNG、v2flyNG 也有各自的应用设置。修改前先区分订阅原始内容、客户端持久化设置与内核实际读取的 JSON；这三层可能描述同一节点，却不一定保存在同一文件中。

直接改动客户端临时生成的文件，常会出现“保存后有效，下次启动又恢复”的现象。原因通常是客户端重新生成了配置，而不是字段被内核随机忽略。优先从客户端提供的路由、自定义配置或节点编辑入口修改。确需维护完整 JSON 时，应使用明确支持完整配置的入口，并保存独立副本，记录所选内核，避免把临时文件当作唯一来源。

顶层对象与嵌套关系

常见顶层字段包括 log、inbounds、outbounds、routing、dns 和 policy。其中入站与出站是数组，数组里的每个对象代表一个监听入口或发送出口。路由对象中的 rules 又是数组，按顺序处理规则。字段所在层级与字段名称同样重要，把有效字段放进错误对象并不会产生预期作用。

{
  "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，端口通常使用数字。字符串里的反斜杠需要转义，特别是手写 Windows 日志路径时。使用能检查 JSON 语法的本地编辑器，可以先排除括号不配对和引号缺失。

下一层检查是引用关系。例如规则中的 outboundTag 必须找到对应出站的 tag；规则引用的入站标签也应确实存在。标签只是本配置内部的名称，不会自动创建代理能力。为了减少歧义，建议标签使用短而明确的英文名称，并保持唯一。修改标签时同时搜索所有引用，不要只改出站定义而遗漏路由与统计设置。

还要区分配置被接受与配置真正生效。内核可能允许某些缺省值，也可能因实现差异拒绝特定字段。每次保存后都应检查实际启动日志与活动内核，而不是只看编辑窗口没有报错。JSON 格式化只能确认语法形态，无法保证传输参数、服务器证书和远端协议一致；这些问题需要进入后续章节逐层验证。

建议把一次变更限制为一个目的，例如只调整路由顺序，或只更换 DNS 解析器。保存原始副本，并简要写下变更原因与预期结果。若同时改动入口、出口和解析方式，失败时很难判断原因。配置整理的目标不是让文件越短越好，而是让每个字段的归属、引用和生效条件都可以说明清楚。

inbounds：本地应用如何进入内核

监听地址、端口与协议

入站负责接收应用交给内核的流量。桌面环境最常见的是本地 SOCKS 或 HTTP 代理入口，应用需明确使用相应地址、端口与代理类型。listen 决定在哪个本地地址接受连接，port 决定监听端口，protocol 决定入口理解哪种请求。即使端口数字相同，HTTP 客户端也不能随意把它当作 SOCKS 服务使用。

只供本机使用时，优先监听 127.0.0.1。它是 IPv4 回环地址，其他设备无法通过电脑的局域网地址访问这个监听。0.0.0.0 表示监听所有 IPv4 接口，访问范围明显扩大，并不等于“自动变安全”。IPv6 监听需要单独理解地址和防火墙规则，不能假设改成全接口地址就同时正确覆盖所有网络栈。

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

这里的两个入口可以让不同应用按自身能力选择代理协议。udp: true 允许 SOCKS 入站处理相应 UDP 请求，但应用仍须支持 SOCKS 的 UDP 机制，出站与远端也必须支持完整路径。它不会把所有系统 UDP 流量自动吸收入站，更不会让原本完全忽略系统代理的程序改变行为。入口能力和系统流量接管是两个问题。

嗅探与目标地址的关系

嗅探用于从部分连接的协议特征中提取域名等信息，常见来源包括 HTTP Host 与 TLS 握手中的服务器名称。这样即使应用最初交给内核的是 IP，路由也可能获得可用于域名匹配的信息。不过不是每种流量都携带可见域名，嗅探也不是完整解密。不能用“打开嗅探”替代正确的 DNS 配置，更不能保证所有应用都会被还原出域名。

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

这段放在具体入站对象内。routeOnly 在支持它的实现中表示将嗅探结果用于路由，而不是直接替换连接目标；使用前要核对所选内核是否支持。遇到字段不被接受时，不应反复猜写同义名称。先回到不含嗅探的基础配置确认入口，再依据该内核的字段定义逐项加入，区分不支持字段与远端连接失败。

局域网共享与系统接管

需要让同一网络内其他设备使用电脑代理时，除了改变监听地址，还要确认电脑实际局域网 IP、系统防火墙、网络隔离和认证设置。不要把代理端口映射到公网，也不要在不可信网络中开放未认证入口。共享完成后，其他设备填写的是电脑的局域网地址，而不是各自的回环地址；手机上的回环地址始终指向手机本身。

系统代理只是通知遵循该设置的应用使用代理，并不修改所有应用的网络实现。TUN 则涉及虚拟网络接口、路由表、权限与 DNS 接管，通常应由客户端的专门功能配置。不要直接把某个内核的 TUN 字段加入另一种 JSON 结构。若系统代理可用而特定应用仍直连，应先查该应用是否支持系统代理，再考虑是否需要 TUN。

排查入站时先看客户端是否启动，再看日志是否出现地址已占用，最后核对应用所选代理类型。若浏览器使用 HTTP 入口正常，而另一个程序使用 SOCKS 失败，应分别检查该程序的认证、域名解析方式和 UDP 需求，而不是立即重装客户端。局域网场景的详细操作可参考允许局域网连接与共享代理。

outbounds：出口、协议与传输层

出站标签与默认出口

出站负责把内核接收的连接送向目标。它可以直接访问目标，也可以将流量交给远程代理服务器，或按规则拒绝请求。常见的 freedom 表示直连，blackhole 表示丢弃，VMess、VLESS、Trojan 等则描述与远端协作的协议。协议名称本身不能提供服务器，仍需要真实且有使用权限的地址、端口和认证资料。

在没有其他出口选择机制介入时，未命中路由规则的流量通常使用出站数组中的第一项。因此调整数组顺序并不只是整理文件格式，还可能改变默认访问路径。建议明确记录默认出站，并在路由章节设置可读的兜底规则。定义名为 proxy 的标签并不会自动让流量走代理；标签只是引用，实际行为由该对象的协议和设置决定。

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

这组出站可用于本地规则测试：普通请求直连，匹配阻断规则的请求被丢弃。这里没有代理服务器，也没有名为 proxy 的出口。阅读其他教程的路由片段时，必须先确认它引用的标签是否已经定义。直接复制一条指向不存在标签的规则，可能导致配置检查失败，不能指望客户端自动补齐缺少的服务器对象。

协议设置与传输设置分开核对

远程出站通常分为协议参数和传输参数。协议参数放在相应 settings 结构中，例如服务器地址、端口、用户标识或密码；传输和安全协商通常由 streamSettings 描述。两层必须与服务器端共同约定。只核对地址和认证信息，不核对传输方式、TLS 或路径，仍可能出现端口能建立连接但协议握手无法完成。

服务器地址、TLS 的服务器名称以及某些传输中的 Host 并非永远相同。地址决定首先连接哪里，服务器名称用于 TLS 身份与证书验证，Host 或路径还可能参与反向代理分发。不要为了让几项看起来一致而全部改成同一个值。使用订阅导入时，优先保留提供方给出的完整参数，再依据日志判断是否存在字段丢失或不兼容。

不要用降低验证要求掩盖问题

遇到证书错误，应先校准系统时间，再核对服务器名称、证书有效期与证书链。跳过证书验证会改变连接的信任条件，不应作为常规修复方式。若直连目标正常、远端代理握手失败，说明入站和部分本机网络已经可用，接下来应集中检查远程协议与传输，不必重新调整所有本地端口或把整个路由表清空。

部分协议还依赖额外的握手字段或专用安全设置，这些字段随内核实现而异。不能因为客户端能显示某个协议名称，就推断所有内核都支持同样参数。导入后若出现不支持协议、未知安全类型等错误，先检查活动内核与节点要求是否匹配。内核切换之后，也要重新确认客户端生成的传输字段是否发生变化。

多路复用、连接保活及其他优化选项也不是越多越好。它们改变连接组织方式，可能影响长连接、服务器资源和中间网络设备的行为。基础连接未建立前，先使用提供方推荐设置；仅当有明确问题、可复现测试和服务端支持时再调整。不要把某次短请求的成功当作长时间传输、UDP 或所有目标都可用的证明。

出站排错建议分成地址可达、传输握手、协议认证、目标访问四层。某一层成功只能缩小范围，不能跳过后续检查。节点全面超时的顺序可参考系统时间、端口与传输层排查。涉及认证资料时，分享日志或配置前应移除用户标识、密码与完整订阅地址，保留协议类型和错误类别即可。

routing：匹配顺序与分流边界

从一条连接理解规则命中

路由不是简单的域名列表，而是根据连接携带的目标地址、入口标签、端口及其他信息选择出站的过程。常见字段规则使用 type: "field"。规则按顺序检查，先命中的规则决定出口，因此越具体的例外通常越靠前。若宽泛规则排在前面，后面更细的规则可能永远没有机会执行，这也是规则存在却看似失效的常见原因。

同一规则中，不同条件字段通常需要同时满足；同一域名或 IP 数组中的多个条目通常表示任一匹配即可。例如同时写入 inboundTag 和 domain，表示指定入口中的指定域名，而不是两个独立的匹配入口。若想表达“这个入口全部走某出口，或者这些域名走某出口”，应拆成两条规则，分别说明条件。

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

这个片段依赖已存在的 direct 与 block 出站，也依赖运行环境可读取相应地理数据。第一条仅阻断精确域名，第二条处理私有地址，最后一条使其余 TCP 与 UDP 明确直连。示例用来展示顺序，不是通用生产策略。若要增加真正的代理出口，应先完成出站定义，再把需要代理的规则指向其标签。

域名规则与 IP 规则不是同一件事

full:example.com 用于完整域名匹配；domain:example.com 通常用于该域名及其子域名。没有前缀的字符串、正则表达式和分类数据各有自己的匹配语义，不应混为一谈。阻断主域名不一定覆盖另一个资源域名，网站加载失败也可能由多个请求中的某个资源被匹配造成。排查时应查看实际请求域名，而不是只看地址栏。

geosite: 和 geoip: 是数据集引用，不是内核内置的实时互联网查询。分类是否存在、包含哪些条目、数据文件能否加载，取决于当前数据资源。若日志提示找不到分类或数据文件，应先修复资源与路径，不要反复更换标签。分类规则发生变化时，也可能是数据更新导致匹配范围改变，而不是规则顺序发生了变化。

{
  "type": "field",
  "domain": ["geosite:category-ads-all"],
  "outboundTag": "block"
}

这条规则只有在数据文件包含该分类时才能使用。放置前先确认现有规则中是否已经有更宽泛的域名或全流量匹配。规则列表中重复的条目并不会提高效果，反而增加解释成本。若只需测试顺序，先使用前面精确匹配的保留示例域名，确认日志中的目标标签变化，再加入依赖外部数据的分类规则。

domainStrategy 决定何时为匹配解析

AsIs 尽量按照连接已有地址进行匹配；IPIfNonMatch 可在域名未匹配时尝试解析，再供 IP 规则判断；IPOnDemand 会在规则判断需要 IP 时更早触发解析。它们讨论的是路由判断中的解析时机，不等于应用端 DNS、系统 DNS 或出站连接目标地址族的全部设置。选择更积极的解析策略也可能增加查询与等待。

如果应用提交的是 IP，且没有可用的域名信息，域名规则可能无法命中；如果应用提交域名，而策略不触发解析，IP 规则也不一定拥有判断依据。先检查入站收到的目标类型，再决定是否使用嗅探或调整解析策略。不要把所有未命中都归因于规则格式；缺少匹配输入时，写得再精确的域名条件也不会自动获得目标名称。

实用的整理方式是把本地服务与必要例外放在前面，将需要明确选择出口的业务规则放在中间，最后写清默认行为。内网规则仍需结合目标环境，不能把所有特殊用途地址一概理解为普通公网访问。验证时同时测试应命中与不应命中的目标，才能发现范围过大。其他分流使用问题可继续查阅疑难解答。

dns：解析来源、查询路径与连接地址

先区分三种解析行为

配置 DNS 前，先区分应用自己解析、内核内置 DNS 解析和系统解析。应用可能先得到 IP，再把 IP 交给代理；也可能把域名交给内核，让后续流程解析。浏览器还可能启用独立的安全 DNS。修改内核的 dns 对象，不会自动覆盖所有应用与系统查询。若没有说明查询从哪里发起，就很难判断配置究竟影响了哪条路径。

内核内置 DNS 常用于路由的 IP 匹配，也可被某些出站的解析策略调用。它不是只要声明便自动启动的系统级 DNS 服务。要让系统或其他设备向内核发送 DNS 请求，还需要对应入口与转发结构；具体能力和字段应按内核选择。客户端启用 TUN 后的 DNS 接管又属于另一层，不能仅凭这一个对象推断系统查询已被接管。

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

这是内置解析器设置的局部示例。公共解析器地址仅用于展示结构，实际可达性取决于所在网络。domains 用于影响指定域名的解析器选择，不等于建立一条访问该域名的代理路由。还应注意回退行为：其他服务器是否参与查询取决于优先匹配、失败状态和回退设置，不能把域名选择条件当作严格隔离查询的唯一保证。

解析策略与出站策略分别设置

queryStrategy 可影响内置 DNS 请求的地址族，例如只请求 IPv4，或按支持情况处理 IPv4 与 IPv6。它与路由中的 domainStrategy 不是同一个字段，也与某些出站自己的域名策略不同。排查 IPv6 访问问题时，应同时确认解析结果、系统是否有可用 IPv6 路径、所选出站怎样使用地址，而不是只关闭其中一个开关。

如果网络没有稳定 IPv6 路径，却优先尝试不可达的 IPv6 目标，可能表现为请求等待后才成功。反过来，盲目限制 IPv4 也可能影响只有 IPv6 的资源。先观察失败目标的解析结果与连接错误，再决定地址族策略。测试一个双栈网站成功，并不能证明所有网络条件正常；不同目标的记录、连接回退与应用缓存都可能不同。

查询路径也需要可达

选择解析器时不仅要看解析器地址，还要看查询怎样到达它。普通 UDP 查询、加密 DNS 请求与调用本地系统解析器，可能走不同路径；某些本地解析模式会绕过通常的路由处理。不要仅凭协议名称就断言查询经过指定代理。应按内核支持的 DNS 发送机制核对，再结合日志与网络环境验证，避免把预期路径当作已发生的事实。

使用域名形式的加密 DNS 地址时，还要考虑启动依赖：为了访问解析器，需要先解析解析器域名；如果这一步又完全依赖同一个尚未可用的解析器，就可能形成循环。同样，代理服务器地址若也需要解析，而该查询被要求经由尚未建立的代理发送，也会陷入依赖。设计时应给启动阶段保留明确且可达的解析路径。

缓存会让 DNS 调整看起来没有立即生效。系统、浏览器、应用与内核都可能保留结果，只重启其中一层未必清除其他层。验证时关闭旧连接，按需要重启相关应用，并使用明确知道期望结果的目标。不要连续切换多个解析器后只看一次网页刷新；已有长连接可能根本没有重新查询，观察结果无法说明新设置是否被使用。

遇到域名失败而直接连接目标 IP 可达，问题范围通常偏向解析或域名相关握手，但仍须注意 TLS 证书依赖域名，直接用 IP 访问不一定是等价测试。更可靠的做法是分别检查 DNS 查询是否返回、返回地址是否可达、协议握手是否成功。每次只改变解析来源或地址族中的一项，保留前后日志，避免将多个变化混为同一个原因。

policy：用户等级、超时与统计边界

策略按用户等级关联

policy 用来设置连接处理策略与部分统计开关，不负责域名分流，也不决定远端服务器是否接受认证。常见结构包含 levels 与 system。前者按照用户等级设置超时和统计选项，后者面向系统级入站或出站统计。等级是配置关联值，不是付费等级或速度等级；数字更大并不表示连接更快。

某些协议用户对象可以设置 level，对应 levels 中同名数字字符串的条目。没有显式指定时，应依据该协议与内核的默认等级理解。定义了一个从未被用户引用的等级，不会让所有连接自动采用它。排查策略是否生效时，应先确认连接所属用户与等级，再看策略字段，避免只因为配置里存在对象就认定已被应用。

{
  "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 关注空闲连接；上下行单向等待项描述一侧结束后的保留时间。它们不是总下载时长限制，也不能替代应用自身的重试与超时设置。具体字段是否适用于当前连接，应按协议实现判断。

超时不能修复协议不一致

握手失败有多种原因：认证不匹配、传输方式不符、证书错误、目标不可达，都可能表现为连接结束。延长握手时间只能给本来较慢但有效的协商更多等待，无法把错误协议变成正确协议。若日志已经明确提示认证拒绝或字段不支持，继续增加时间只会让失败更晚出现。应先解决确定性错误，再讨论等待窗口是否合适。

空闲连接回收同样需要结合应用行为。即时通信、远程会话、流式响应和偶尔才发送数据的连接，对空闲时间的要求不同。把空闲阈值设得很小，可能导致后台连接反复建立；设得很大，则可能保留更多资源。调整前先确认客户端断开是否确实由空闲回收触发，而不是网络切换、省电策略、服务器主动关闭或中间设备超时。

统计开关不是统计界面

开启统计相关布尔值，不会自动生成图形报表。内核统计通常还需要统计模块、可识别用户及相应查询接口等配套条件；客户端显示的流量也可能采用自己的采集方式。不能把内核用户统计、客户端进程流量和网络接口总流量当作同一数值。转发、协议开销、统计范围与重启后的计数周期，都可能导致观察结果不同。

为了显示流量而手动加入 API 入站或控制接口时，尤其要谨慎。控制接口应限制在可信范围，不应为了方便从局域网读取而直接开放所有监听地址。普通用户通常可以使用客户端已有的日志与状态功能，无需另外搭建查询接口。本页示例关闭统计，是为了把配置重点放在连接与规则，不代表这些功能在所有环境中都必须关闭。

在 Android 上，连接进入后台后中断，常常涉及系统对应用后台活动的限制，而不是内核空闲策略。v2rayNG 的 VpnService 授权、后台运行权限与厂商省电设置应分别检查。相关操作可参考VpnService、省电白名单与分应用代理，不要用极大的超时值替代系统层面的正确授权。

策略调优应有明确的复现条件：记录使用的应用、连接空闲多久、是否切换网络、哪个方向仍在传输，再观察调整后的差异。若没有这些前提，很难确认变化是策略带来的还是环境偶然恢复。对于普通浏览与订阅使用，保持客户端生成的合理默认值通常更容易维护；优先解决入口、出口与路由这些直接影响连接正确性的配置。

客户端生成配置与内核差异

同一界面选项不等于同一 JSON

v2rayN 面向桌面环境，客户端中的系统代理、TUN、路由预设与内核切换最终会映射到不同的运行方式。v2rayNG 主要使用 Xray 内核，v2flyNG 是采用 V2Fly 内核的 Android 备选。三者可以处理相近的节点概念，但应用数据目录、导入入口、后台行为和生成配置方式并不相同，不能直接把一个客户端的整个数据文件夹覆盖到另一个客户端。

V2Fly 与 Xray 具有共同的配置传统，部分 JSON 字段相近，但各自的扩展、支持协议和字段演进并非完全一致。sing-box 则采用另一套结构，入站类型、出口定义、DNS 与路由动作都需要按自己的规范表达。看到同名协议不代表能逐字复制配置。迁移时先对应功能含义，再重新建立字段，而不是机械替换协议名称。

系统代理、路由与 TUN 分层理解

系统代理决定支持它的应用怎样把请求交给本地入口；内核路由决定已进入内核的请求走哪个出站；TUN 负责通过虚拟网络接口接收更广范围的系统流量。三者发生在不同层级。修改路由规则不能让完全没有进入内核的应用突然受控；启用 TUN 也不会自动保证每条内核规则正确，更不会修复错误的远程认证资料。

客户端中的“全局”通常表示某个层面的默认出口或流量接管范围，具体含义要看当前模式。它可能改变内核路由，也可能只是系统代理模式的名称。判断时应观察生成配置、实际入口和日志，而不是只依赖按钮文字。局域网服务失联时，既要检查内核是否把私有地址送错出口，也要检查 TUN 的系统路由是否把本地网络接管方式改变。

TUN 需要适当权限，并可能与其他虚拟网络软件产生冲突。若启用后所有网络中断，先关闭 TUN 恢复基本网络，再检查权限、虚拟接口、DNS 和路由冲突，不要同时修改远程服务器参数。系统代理模式能够连接，说明部分核心链路已经成立，此时保持原节点不变，集中验证接管层，通常比重新导入所有订阅更有效。

订阅、自定义规则与更新覆盖

订阅通常负责节点信息，未必负责本地路由、系统代理与 DNS。也有导入形式携带更完整配置，因此导入前要确认内容类型。更新订阅后节点参数变化是正常的同步行为，但本地手改节点可能被覆盖。需要长期保留的例外应放在客户端明确支持的本地规则或独立配置中，避免每次订阅刷新后重复手工修改同一字段。

完整自定义配置的行为也需要核对：客户端可能直接运行该配置，也可能补充监听端口、日志、控制接口或统计设置。不要默认文件内容就是最终运行内容。如果需要分析一次故障，应同时记录导入源、客户端选择和最终启动日志。配置导出也不等于可公开分享，里面可能包含服务器地址、认证字段及订阅链接，传播前应逐项移除敏感内容。

在 macOS、Windows 与 Linux 上，即使 JSON 相同，文件路径、目录权限、防火墙和系统代理入口仍然不同。日志文件应放在客户端有写权限的位置；不要把另一个系统的绝对路径直接粘贴过来。首次安装需要的目录与运行环境说明可阅读v2rayN 首次安装与初始设置，启动失败则先区分进程崩溃与配置被拒绝。

需要安装或更换客户端时，从安装包页面按操作系统与处理器架构选择，桌面优先使用 v2rayN。不要为了试验一个字段而频繁更换客户端和内核，否则配置差异与环境差异会叠加。将一次迁移拆成可回退的小步骤，并保留最后可用配置，才容易确认是哪一项能力或哪一层设置发生了变化。

完整配置示例与逐层验证

本机直连与精确阻断基线

下面是一份用于本机验证的完整 JSON：监听回环地址上的 SOCKS 与 HTTP 端口，普通流量直连，精确匹配的示例域名送入阻断出口。它不依赖远程代理认证，也不依赖分类数据文件，适合作为理解路由的基线。若客户端正在使用相同端口，应先停止其内核，或在独立测试副本中改用空闲端口，并同步更改应用端设置。

{
  "log": {
    "loglevel": "warning"
  },
  "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": {}
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

验证时应选择客户端支持的完整配置入口，确认当前运行的是目标内核，并查看配置加载结果。若启动立即失败，优先处理语法、未知字段和端口占用；若启动成功但应用没有请求记录，优先检查应用是否真的连接了本地入口。此时不要先调整 DNS 或远端传输，因为请求可能尚未到达需要这些设置的阶段。

按顺序做正向与反向测试

第一步用明确支持 HTTP 代理的应用，把地址设为 127.0.0.1、端口设为 10809，访问当前网络本来就能直连的目标。第二步访问精确阻断的示例域名，观察失败是否与规则一致。最后暂时移除该阻断规则并重新加载，比较结果。必须确保请求使用域名进入代理；如果应用预先解析成 IP，域名规则可能没有匹配依据。

反向测试同样重要：不在阻断范围内的目标应该保留正常访问能力。只看一个目标失败，无法证明规则正确，也可能是整个入口都不可用。测试时关闭应用已有连接，并注意浏览器缓存、安全 DNS 和独立代理扩展可能改变路径。如果不能确认应用行为，可先用单一应用完成整个对照实验，减少环境变量，再扩大到其他程序。

日志按连接阶段阅读

日志首先用于定位失败阶段，而不是收集越多越好。日常可保留较低噪声级别，复现问题时再临时提高详细程度。检查入口标签、目标地址、命中出口与最终错误是否属于同一次请求。多应用并发时，紧邻的两行不一定描述同一条连接。若日志出现大量重复连接，先缩小测试范围，避免把后台应用活动误认为当前目标的结果。

日志可能包含访问域名、局域网地址和服务器信息。排错结束后恢复日常日志级别，并清理不再需要的详细记录。需要向他人描述问题时，保留错误类别与发生阶段，移除认证资料、完整订阅地址和个人访问记录。不要直接公开整个客户端数据目录；它除了运行配置，还可能保存历史节点、分组信息和其他账户相关内容。

从基线逐步恢复实际配置

本地基线通过后，先恢复一个已知有效的远程出站，不同时加入复杂路由。确认远端链路后，再增加一条明确的分流规则，随后引入分类数据和 DNS，最后才考虑策略调优。每一步都测试应该命中和不应该命中的请求。出现问题时退回上一份可用副本，比在已经叠加多层变化的文件中连续尝试更容易定位原因。

订阅更新、内核切换与客户端升级之后，也可以复用相同验证顺序。不要把“窗口能打开”当作配置全部生效，不要把“一个网页能访问”当作所有协议都正常。只有入口、出口、规则和解析分别得到符合预期的结果，才能确认这份配置适合当前用途。日常操作回到快速上手教程，具体异常可在疑难解答中继续查阅。