V2Ray 配置文件参考大全

顶层对象不是执行步骤清单

V2Ray 配置文件以一个 JSON 对象作为根节点，常见顶层字段包括 log、dns、inbounds、outbounds、routing、policy 和 stats。这些字段写在文件中的先后位置不会改变处理顺序。内核加载配置时先解析整个对象，再建立监听入口、出站对象、路由器和名称解析器。把 routing 写在 inbounds 前面不会让路由先于入站执行；真正决定关联关系的是标签和规则引用。

inbounds 与 outbounds 都是数组，因为一个进程可以同时监听多个本地端口，也可以保留多个出口。数组中的每个对象通常带有 tag。路由规则通过 inboundTag、outboundTag 或 balancerTag 引用这些标签。标签应当在同一配置内保持唯一，并使用短而稳定的名称，例如 socks-in、proxy、direct 和 block。修改标签后必须同步检查全部引用，否则配置可能能够解析，却在建立路由时提示目标不存在。

一份可读的最小结构

{
  "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"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

这份示例只建立本地 SOCKS 入口和两个基础出口，没有配置远程代理连接。它适合用来观察结构层级：协议专属参数放在对应对象的 settings 中，传输层参数通常放在 streamSettings 中，连接复用等扩展能力则有自己的子对象。不要把另一个层级的字段平移到 settings，因为 JSON 语法即使正确，内核也可能忽略不属于该对象的字段，或者直接报告反序列化错误。

对象、数组与数据类型

配置错误经常不是协议问题，而是 JSON 数据类型不匹配。端口通常是数字，因此写作 10808，不应随意写成字符串 "10808"；布尔开关使用 true 或 false，不能写成引号包围的文字。规则中的域名和 IP 条件大多采用数组，即使只有一项也应保留方括号。对象属性之间需要逗号，最后一个属性后不能保留多余逗号。中文全角引号、不可见空格和从富文本复制来的弯引号，也会让解析器在看似正常的位置报错。

客户端生成配置时往往会把订阅节点、路由预设和本地端口合并为最终文件。v2rayN 适合在 Windows、macOS 与 Linux 上查看和调整这类桌面配置；Android 上的 v2rayNG 与 v2flyNG 通常由界面保存设置，再在启动时生成运行配置。界面里的名称未必与底层字段逐字一致，例如“绕过局域网”最终可能表现为一条 geoip:private 直连规则。需要核对时，应以客户端实际导出的运行配置和日志为准，而不是把界面截图当作完整配置。

建立可维护的阅读方法

阅读较长配置时，可以先列出所有入站和出站标签，再沿路由规则逐条追踪目标标签，最后检查 DNS 与传输参数。不要从某个深层字段开始猜测整个连接行为。一个请求先进入某个入站，携带目标域名、目标 IP、端口和可能的协议识别结果；路由器根据条件选出出站；出站再按照协议和传输设置连接目标。DNS 可能在规则匹配或出站连接阶段参与其中，policy 则影响连接统计、空闲超时和会话行为。按这条链路阅读，能够把“配置能加载”和“连接能完成”区分开。

出站标签与三类基本去向

一份实用配置通常至少包含代理、直连和阻断三种出站。代理出站连接订阅或手动配置中的远程服务器；freedom 出站直接访问目标；blackhole 出站终止匹配流量。它们分别可以使用 proxy、direct、block 等标签。标签本身没有特殊含义，真正的行为由 protocol 决定，但稳定命名有助于阅读路由规则。

数组顺序可能影响没有命中路由规则时使用的默认出口。为了避免依赖模糊默认值，建议将主要代理出站放在清晰位置，并为局域网、阻断列表和需要直连的目标写出明确规则。客户端可能在生成配置时加入额外出站，例如 DNS 专用出口或链式代理中间出口。手动编辑前要先看清这些标签是否被其他对象引用，不要仅凭名称删除。

VLESS 出站示例

{
  "tag": "proxy",
  "protocol": "vless",
  "settings": {
    "vnext": [
      {
        "address": "server.example.com",
        "port": 443,
        "users": [
          {
            "id": "00000000-0000-4000-8000-000000000000",
            "encryption": "none",
            "flow": ""
          }
        ]
      }
    ]
  },
  "streamSettings": {
    "network": "tcp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "server.example.com",
      "allowInsecure": false
    }
  }
}

address 是远端服务器地址，既可以是域名，也可以是 IP；port 是远端监听端口。users 中的 id 是身份标识，必须与服务端配置一致。VLESS 的 encryption 常按协议要求填写指定值，它不等同于传输层的 TLS。flow 只有在服务端明确启用对应流控方式时才填写，不能根据其他节点的配置随意复制。

streamSettings 描述连接如何承载协议数据。network 必须与服务端一致；security 决定是否启用 TLS 或其他安全层；serverName 用于证书名称与握手目标。远端地址、握手名称和实际证书名称可能承担不同职责，不能只因为它们经常相同，就认为任何时候都可以互换。allowInsecure 控制证书验证行为，正常配置应保留验证。证书名称不匹配时，应检查节点参数、系统时间、服务器名称和中间网络，而不是直接关闭验证掩盖问题。

REALITY 连接参数如何对应

{
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "serverName": "www.example.com",
      "fingerprint": "chrome",
      "publicKey": "example-public-key",
      "shortId": "0123456789abcdef",
      "spiderX": "/"
    }
  }
}

REALITY 配置通常位于 realitySettings。serverName、publicKey、shortId 和服务端设置之间存在严格对应关系，任何一项抄错都可能在握手阶段失败。fingerprint 表示客户端握手指纹选项，应使用内核与服务端方案支持的值。示例中的公钥只是字段格式说明，不能用于实际连接。

遇到 REALITY 节点无法连接时，应先区分网络不可达、时间异常、参数不匹配和路由误分流。先确认远端地址与端口可达，再核对服务器名称、公钥、短标识和流控参数，最后检查目标服务器地址是否被某条直连或阻断规则错误处理。只盯着协议名称反复切换设置，通常无法定位真正问题。

直连、阻断与 DNS 专用出站

[
  {
    "tag": "direct",
    "protocol": "freedom",
    "settings": {
      "domainStrategy": "UseIP"
    }
  },
  {
    "tag": "block",
    "protocol": "blackhole",
    "settings": {
      "response": {
        "type": "none"
      }
    }
  }
]

freedom 表示由当前设备直接连接目标。其 domainStrategy 决定出站接到域名时是否以及如何解析，但它与顶层 routing.domainStrategy 不是同一个控制点：前者作用于直连出站建立连接的阶段，后者作用于路由匹配阶段。blackhole 用于终止命中的连接，适合明确的阻断规则。阻断后应用通常只看到连接失败，因此必须通过路由日志确认是否命中了 block。

订阅节点与手写配置的边界

v2rayN、v2rayNG 和 v2flyNG 会把订阅内容转化为各自支持的节点模型，再生成底层出站配置。订阅更新可能覆盖节点协议参数，因此不宜直接在自动生成文件里长期维护服务器字段。需要调整本地路由、DNS 或入站时，优先使用客户端提供的自定义配置、路由预设或覆写入口。若客户端不支持某个字段，应先确认所用内核家族是否认识该字段，再决定是否使用完整自定义配置。

桌面场景首推 v2rayN，是因为它同时提供节点管理、路由设置和运行日志入口，便于对照本章字段。安装包应从安装包页面按平台选择。Android 场景可在 v2rayNG 与 v2flyNG 之间按内核需求选择，两者生成配置的细节可能不同，导入同一订阅后也应以各自运行日志为准。

先区分系统解析与内置解析

应用发起连接时，域名可能由应用或操作系统先解析，也可能以域名形式交给本地代理。前一种情况下，入站看到的目标可能已经是 IP；后一种情况下，V2Ray 的内置 DNS 与路由策略才有机会直接参与解析。启用 TUN 模式时，更多系统流量可能进入客户端处理链，但具体请求是否由内置 DNS 处理，仍取决于客户端生成的入口、DNS 劫持和路由配置。

因此，设置了 dns.servers 并不意味着设备上所有名称查询都会自动使用它。浏览器自身的安全 DNS、应用内置解析器、系统缓存与终端工具都可能形成独立路径。排查解析异常时，要先回答三个问题：查询由谁发起、发送到哪个服务器、得到的地址最终是否被路由规则采用。只更换 DNS 服务器而不确认路径，容易出现配置改了但现象没有变化。

基础 DNS 对象示例

{
  "dns": {
    "hosts": {
      "domain:internal.example": "192.0.2.10"
    },
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": ["geosite:geolocation-!cn"],
        "skipFallback": true
      },
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

hosts 提供静态域名映射，适合受控测试和固定内部地址，不适合代替持续变化的公共解析。示例地址只用于说明结构。servers 可以包含简单地址，也可以使用对象形式附加域名范围、预期 IP 范围和回退控制。列表顺序与匹配条件共同决定查询去向。配置多个服务器不是简单地让所有服务器同时竞争；具体行为会受域名条件、回退逻辑和内核实现影响。

domains 用于指定某个服务器优先处理的域名集合，语法与路由域名规则相近。expectIPs 用于检查返回地址是否符合预期分类，它不是地址过滤器的通用替代。若返回结果不满足条件，解析器可能尝试其他服务器。数据文件缺失或过期时，基于 Geo 分类的预期判断也会失去准确性。skipFallback 会影响该服务器是否参与回退，设置前要理解当前服务器分组，而不是对每项都统一开启。

queryStrategy 与地址族选择

queryStrategy 控制查询使用的地址族策略。常见含义包括同时考虑可用地址、只使用 IPv4 或只使用 IPv6，具体可用值应与当前内核支持保持一致。地址族选择必须符合设备网络条件：如果本地网络没有可用的 IPv6 路径，却强制只查询 IPv6，域名本身可能解析成功，但后续连接仍会失败；反过来，网络只在特定地址族上可达时，也不能简单依赖默认结果。

双栈环境中的失败还可能来自“解析得到多个地址，但应用或出站优先尝试了不可达地址”。这时需要同时观察 DNS 返回、出站选择和连接日志。不要把每次超时都归因于 DNS；解析日志已经给出地址而连接阶段超时，说明问题已经进入出站网络或远端服务阶段。相反，日志显示域名查询失败、没有可用记录或所有预期条件都不满足，才应集中检查 DNS 段。

DNS 查询走哪个出站

DNS 服务器本身也是一个连接目标，它可能被路由规则交给直连或代理出站。如果 DNS 服务器使用域名表示，还可能产生“解析 DNS 服务器域名所需的前置解析”问题。为降低循环依赖，基础 DNS 服务器地址常使用可直接连接的 IP，或者通过明确的专用出站和路由规则处理。使用基于 HTTPS 的解析端点时，还要考虑端点域名、证书名称和它自身的解析路径。

可以为 DNS 查询设置独立出站标签，再通过协议条件或入站标签路由。但这种设计应保持路径清楚：请求进入内置 DNS，DNS 查询经指定出站到服务器，结果返回路由器用于匹配，最终业务流量再走业务出站。若把 DNS 查询错误地送入一个依赖同一 DNS 结果才能连接的代理出站，就可能形成启动阶段的循环等待。客户端预设通常会处理基本依赖，手动覆写时不要删除不熟悉的 DNS 路由。

缓存、Fake DNS 与 TUN 场景

系统缓存、应用缓存和内置解析缓存可能同时存在。修改 DNS 后立即重复访问同一域名，旧结果不一定马上消失。验证时可以重启目标应用与客户端，或使用一个尚未查询的新域名观察完整过程。TUN 模式可能使用 Fake DNS 把域名映射为保留地址，再在流量进入时还原域名，以便进行域名路由。这类保留地址不应被当成真实远端 IP，也不应直接拿去判断 GeoIP 分类。

Fake DNS 适合解决只向系统提交 IP 流量时缺少域名信息的问题，但它要求 DNS 接管、映射表和 TUN 入站保持一致。出现应用获得地址却无法连接时，应检查映射是否被同一运行实例识别、请求是否绕过了 TUN，以及保留地址是否被其他规则提前直连。关于 TUN 的系统接管逻辑和客户端入口，可参阅TUN 模式全局接管流量原理详解。

第一层：确认 JSON 可以解析

语法验证只回答配置是否是合法 JSON。重点检查双引号、逗号、方括号与花括号是否成对，以及数字、布尔值和字符串是否使用正确类型。JSON 不接受注释，也不接受对象末尾的多余逗号。从网页、聊天记录或文档复制配置时，先保存为纯文本 UTF-8 文件，避免弯引号和不可见控制字符。

语法错误通常会给出行号和列号，但真正错误可能位于上一行。例如解析器在新属性开头报告错误，常见原因是上一项末尾缺少逗号。遇到文件结尾错误，则优先检查某个对象或数组是否没有闭合。编辑器的括号配对功能很有帮助，但不能替代对数据类型和字段层级的检查。

第二层：确认标签和字段属于正确位置

合法 JSON 仍可能不是合法的 V2Ray 配置。第二层验证需要检查顶层字段名称、协议专属 settings、传输层 streamSettings 和路由引用。常见结构错误包括把 tlsSettings 放到出站根部、把单个出站对象写成对象而不是数组、在规则中引用不存在的 outboundTag，以及把字符串数组写成单个字符串。

未知字段的处理方式可能因内核而异：有的会直接拒绝加载，有的可能忽略字段。被忽略比立即报错更难排查，因为配置看似启动成功，预期功能却没有生效。若日志出现 unknown field、failed to parse、failed to build 或找不到标签，应先回到对应对象层级检查，不要继续测试网络连通性。

第三层：确认客户端实际加载了哪份配置

v2rayN、v2rayNG 和 v2flyNG 都可能根据界面设置在启动时生成运行配置。用户编辑的文件不一定就是内核最终读取的文件，尤其在订阅节点、路由预设、系统代理和 TUN 模式共同启用时。验证前应从客户端日志确认配置生成与内核启动是否成功，并查看客户端提供的导出、预览或运行目录入口。

订阅更新通常会替换节点参数，但未必替换本地路由；完整自定义配置则可能绕过部分界面设置。需要明确当前使用的是“订阅节点加客户端模板”，还是“完整自定义配置”。两种模式混在一起时，经常出现界面里修改了端口但运行文件没有变化，或者手写路由被预设重新生成。订阅刷新失败的独立排查方法可查看订阅更新失败与自动更新设置。

分阶段建立连接基线

1. 验证启动：确认内核启动完成，本地 SOCKS 或 HTTP 端口已经监听，没有端口占用和配置解析错误。
2. 验证本地入口：让一个明确支持代理的应用连接本地端口，检查访问日志是否出现对应入站标签。
3. 验证单一出站：暂时使用简单路由，确认目标请求能够经代理出站完成连接，避免复杂规则干扰。
4. 恢复 DNS 与路由：逐组加入局域网、域名、GeoIP 和阻断规则，每次记录请求最终使用的出站。
5. 恢复系统接管：最后再开启系统代理或 TUN，让更多应用进入处理链，并分别验证浏览器与终端。

这套顺序把问题拆成启动、本地入口、远程出站、分流和系统接管五层。若第一层尚未完成，就没有必要分析远程协议；若本地入口没有收到请求，则应检查应用代理设置；若简单出站可用而恢复路由后失败，则问题集中在 DNS 或规则；若手动代理可用但系统接管后异常，则重点检查系统代理状态、TUN 权限和路由冲突。

日志级别与可读信息

log.loglevel 可以在排错期间调整为包含更多细节的级别。记录越详细，越容易观察入站、路由和出站，但输出量也更大。正常使用时不必长期保留高详细度。排错日志应围绕一次明确测试截取，从内核启动开始，到目标请求失败或成功结束，避免在大量历史记录里混淆不同配置。

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "info",
    "dnsLog": true
  }
}

日志配置的具体路径与输出方式可能由客户端接管。空字符串是否表示控制台输出，也应结合当前内核和客户端行为确认。dnsLog 有助于观察内置解析过程，但只有经过内置 DNS 的查询才会出现。完整的日志阅读方法可参考V2Ray 运行日志常见报错含义与定位。

变更记录比反复试错更有效

每轮测试只改一个字段组，并记录修改前值、修改后值、测试目标和日志结果。例如把 domainStrategy 从 AsIs 改为 IPIfNonMatch 后，只验证需要 IP 规则的域名；不要同时更换节点、DNS 服务器和 TUN 模式。若结果变差，可以准确回退；若结果改善，也能知道是哪项生效。

客户端升级或切换内核后，应重新执行最小验证流程，而不是默认旧配置全部兼容。不要编造或依赖固定版本号判断字段支持；应查看当前客户端选择的内核类型、启动日志和配置错误信息。需要重新安装客户端时，可从安装包页面选择 Windows、macOS、Android 或 Linux 对应入口。