V2Ray 配置文件参考大全

V2Ray 与 Xray 的主配置可以理解为一个描述流量处理管线的 JSON 对象：入站接收连接，路由判断去向，出站执行连接，DNS 与策略对象为这条管线补充解析和资源约束。

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

配置文件最外层由一个 JSON 对象构成，常见键包括 log、dns、inbounds、outbounds、routing、policy 与 stats。这些键在文本中的先后位置通常不决定执行顺序，因为 JSON 对象按键名表达结构，而不是按书写位置表达流程。真正具有顺序语义的地方主要是数组，例如 routing.rules 会从前向后匹配，先命中的规则先决定出站；多个入站与出站也通过各自的 tag 被其他对象引用。

阅读配置时，较稳妥的方法是先记录所有标签，再沿引用关系检查。一个入站标签可能被路由规则的 inboundTag 使用，一个出站标签会被 outboundTag 指向，DNS 服务器又可能通过 tag 与路由规则连接。标签本身只是配置内部的标识符，不会自动产生分流效果。若规则写了一个并不存在的标签，配置可能在启动阶段报错，也可能在运行到相关路径时表现为流量没有可用去向，具体取决于内核及字段位置。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": ["1.1.1.1", "localhost"]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

数组、对象与值类型

inbounds、outbounds 和 routing.rules 都是数组，因此使用方括号；单个入站、出站或规则则是对象，使用花括号。端口是数字，不应写成带单位的字符串；布尔值只能写为 true 或 false；缺省字段与值为 null 并不等价。缺省表示让内核采用默认行为，而显式的空值只有在字段定义允许时才有意义。许多启动失败都不是协议问题，而是括号闭合错误、对象之间缺逗号、字符串误用中文引号，或把本应为数组的字段写成单个字符串。

标准 JSON 不允许注释，也不允许最后一个成员后保留尾随逗号。网上示例为了讲解常写 // 注释，但复制到客户端核心配置前必须删除。v2rayN、v2rayNG 与 v2flyNG 可能在图形界面之外维护自己的配置层，界面中的节点、订阅和路由设置经过转换后才交给内核。因此，手工编辑前应先确认正在修改的是客户端管理文件、生成后的运行配置，还是独立核心读取的配置；三者不能根据文件名相似就视为同一对象。

从最小配置逐步增加复杂度

排查配置时应先保留一个本地入站、一个明确可用的出站和最少量路由，再逐步加入 DNS、嗅探、多个传输以及统计策略。一次加入多个模块会让错误来源互相遮蔽。例如连接失败既可能来自远端参数，也可能是域名先被错误 DNS 路径解析，或前置规则把连接送到了 blocked。最小化不是删除必要安全字段，而是缩短变量链：保持服务端要求的地址、端口、用户标识、传输和安全参数不变，只暂时移除不影响连通性的附加规则。

保存前还应确认文本编码为 UTF-8、文件内容只有一个根对象、键名大小写与字段定义一致。outboundTag 和 outboundtag 是不同名称，协议名也不应凭界面译名推测。完成结构检查后，再进入入站、出站与路由三部分逐段验证，这比直接在一份大型配置中反复改动端口更容易得到可解释的结果。

出站负责把经过路由选择的连接发送到目标位置。它既可以连接远端协议服务器，也可以直接访问目标、拒绝连接，或把流量交给另一个出站继续处理。

协议字段必须作为一个整体核对

远端出站通常由 protocol、settings 和 streamSettings 共同定义。以 VLESS 为例，服务器地址与端口位于 vnext 项，用户标识位于 users；传输方式、安全层与服务器名称则在 streamSettings 中。只核对地址、端口和用户标识并不足以证明配置一致，客户端与服务端的网络传输、TLS 类安全设置、路径、主机名以及相关扩展参数也必须相互对应。

配置界面常把这些字段分散在“地址”“用户”“传输”“安全”等页面中，而 JSON 将它们放在相邻对象。订阅导入异常时，先在客户端详情页逐项查看，不要仅根据节点显示名称判断。节点名称通常只是本地备注，不参与协议握手；真正影响连接的是结构化字段。若手工迁移参数，应避免把 URI 中经过编码的文本直接当作 JSON 原值，也不要把界面中表示“默认”的空白项擅自改成字符串 "default"。

{
  "outbounds": [
    {
      "tag": "remote-vless",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example.com"
        },
        "wsSettings": {
          "path": "/example-path",
          "headers": {
            "Host": "server.example.com"
          }
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ]
}

direct 与 blocked 是明确的处理路径

freedom 出站通常用于直接连接目标，常被标记为 direct；blackhole 用于终止被规则选中的连接，常标记为 blocked。这些标签只是约定俗成的名称，可以更改，但路由引用必须同步。把 freedom 放在出站数组中不会自动让本地地址直连，仍需路由规则把相应流量指向它。类似地，定义 blackhole 也不会自动拦截任何域名，只有匹配规则引用后才会生效。

当没有规则命中时，内核通常会选择默认出站，具体行为与配置结构和内核实现有关。为了避免配置阅读者依赖隐含顺序，大型配置宜为关键流量写出明确规则，并保持出站标签具有可读含义。远端出站、直连出站与阻断出站的名称应体现用途，而不是使用容易混淆的连续数字。名称清晰后，日志中的出站标识也更容易对应到配置。

出站链、代理设置与循环

部分内核允许通过 proxySettings 或其他机制让一个出站经由另一个出站建立连接。这适用于明确设计的链式出口，但也增加了 DNS、握手与故障定位的层数。链条中的每一段都要有唯一标签，且不能形成 A 指向 B、B 又指向 A 的循环。远端服务器域名如何解析也需要单独考虑：如果用于建立第一段连接的 DNS 查询反过来依赖尚未建立的出站，就可能出现启动后持续超时的闭环。

排查链式配置时，应先让最后承担物理连接的单个出站独立可用，再逐段向前加入。日志中若只有“连接被关闭”，需要结合出站标签判断失败发生在哪一层。远端拒绝、域名解析失败、TLS 服务器名称不符与本地路由提前选择错误出站，都会在表面上表现为应用打不开页面。逐层验证比同时替换所有协议参数更能保留证据。

桌面端优先使用 v2rayN 管理节点与核心配置，Android 可根据内核需求选择 v2rayNG 或 v2flyNG。若需要比较 Xray 与 V2Fly 的定位，可继续阅读Xray 与 V2Fly 内核区别梳理；内核分支的字段支持范围可能不同，迁移复杂配置前应确认目标客户端实际启用的内核。

DNS 配置决定内核在需要解析域名时向哪些服务器查询，以及特定域名应优先进入哪组解析路径。它与操作系统 DNS、应用自身解析和路由阶段解析并非同一个层面。

先区分查询由谁发起

应用可能先在系统层完成解析，然后只把目标 IP 交给代理；应用也可能把域名原样交给 SOCKS 或 HTTP 入站；部分应用还会使用自己的加密 DNS 机制。只有进入内核并由内核执行的查询，才会直接受顶层 dns 对象控制。因此，修改配置后若观察不到预期变化，应先确认入站接收到的是域名还是 IP，并检查嗅探是否恢复了域名。仅更换 dns.servers 不能强制所有系统程序放弃自己的解析路径。

servers 可以包含简单地址，也可以包含带 address、domains、expectIPs、skipFallback 等属性的对象。简单数组适合单一路径；对象形式适合按域名选择服务器。服务器列表并非始终按“第一个失败才使用第二个”的传统备用概念工作，域名筛选、回退设置与内核实现会共同决定查询对象。设计复杂 DNS 前，先用两个职责清晰的服务器验证，再加入域名范围和回退限制。

{
  "dns": {
    "hosts": {
      "router.example": "192.168.1.1"
    },
    "servers": [
      {
        "address": "localhost",
        "domains": [
          "full:router.example",
          "domain:internal.example"
        ],
        "skipFallback": true
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "domain:public.example"
        ]
      },
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

hosts、domains 与预期结果

hosts 用于给明确名称提供静态映射，适合少量稳定的本地服务名称，不适合作为大型动态域名表。静态映射优先级较高，地址变化后若忘记更新，会造成“只有某个名称持续指向旧地址”的现象。排查时应同时检查操作系统 hosts 文件、客户端界面中的主机覆盖项与核心配置中的 dns.hosts，避免多层覆盖彼此冲突。

服务器对象中的 domains 用于筛选交给该服务器的域名，语法与路由域名条件相近，但用途不同：前者选择解析器，后者选择连接出站。expectIPs 可约束期望返回地址的范围，用于判定结果是否符合预设；它不是把任意响应改写成目标范围。约束写得过窄时，正常响应也可能被排除并进入回退。skipFallback 则影响该服务器参与回退的方式，组合使用前应先画出“域名选择—服务器查询—结果检查—连接路由”四步关系。

DNS 查询如何选择出站

DNS 服务器地址本身也需要建立连接。若服务器写为域名，首先还存在解析解析器域名的问题；若写为 IP，则省去这一层，但仍要由路由选择网络出站。较复杂的配置会给 DNS 流量分配标签，再在路由中按该标签或协议送往特定出站。此时必须避免闭环：远端出站依赖域名解析，而该域名解析又被要求通过尚未建立的远端出站完成。

建立可解释路径的方法是先让远端服务器地址具备稳定的基础解析路径，再决定普通目标域名如何分流。若配置中同时使用 domainStrategy 与 DNS 规则，路由为了判断 IP 条件而触发的解析也会进入 DNS 模块。于是一个表面上的路由问题，可能实际由 DNS 服务器筛选或回退结果引起。排查日志时应按时间顺序观察查询、获得地址、选择出站和连接目标，而不是只截取最后一条超时信息。

缓存、IPv4 与 IPv6 选择

queryStrategy 用来限制或偏向查询返回的地址族，支持范围随内核而异。强制只使用一种地址族可能绕开本地网络不完整的问题，但也可能排除本来可达的目标。应先确认操作系统是否具备对应网络连通性，再决定是否限制查询。客户端、内核与系统解析器都可能缓存结果，修改 DNS 后立即重试不一定触发新查询；可以重启相关客户端进程并重新建立连接，但不应把清空缓存当作长期配置方案。

针对“域名无法访问而直接 IP 可以访问”的情况，先核对查询是否返回地址，再检查返回地址是否被路由规则送到预期出站。针对“部分域名偶发失败”，则需要比较失败与成功时选择的 DNS 服务器、地址族和出站标签。更换服务器只能验证解析器路径，不能代替对规则条件的检查。关于常见客户端连接主线与验证方法，可回到入门指南逐步确认。

远端协议定义身份与请求格式，streamSettings 定义这些数据如何承载在网络连接上。两端协议参数正确但传输层不一致，连接仍无法完成。

network 决定后续设置对象

streamSettings.network 指定传输类型，常见配置可能涉及 TCP、WebSocket、gRPC 或 mKCP。选择某种网络后，应使用与之对应的设置对象，例如 WebSocket 使用 wsSettings，gRPC 使用对应服务名称设置。把另一个传输的字段保留在配置中通常不会把两者自动组合，反而会造成阅读误判。迁移节点时应先确认界面显示的传输类型，再展开其专属字段逐项核对。

传输类型不是可以由客户端单方面优化的选项。服务端监听什么传输、使用什么路径或服务名称，客户端就必须按相同结构连接。遇到错误时频繁在 TCP、WebSocket 与 gRPC 之间切换，通常只会增加变量。较稳妥的做法是根据来源配置固定传输类型，检查地址是否可解析、端口是否可达，然后再检查路径、主机字段与安全层。

{
  "streamSettings": {
    "network": "grpc",
    "security": "tls",
    "tlsSettings": {
      "serverName": "edge.example.com",
      "allowInsecure": false,
      "alpn": ["h2"]
    },
    "grpcSettings": {
      "serviceName": "example-service",
      "multiMode": false
    },
    "sockopt": {
      "tcpKeepAliveIdle": 100
    }
  }
}

WebSocket 路径、Host 与 TLS 名称

WebSocket 配置中的 path 是 HTTP 握手路径，是否带前导斜线、是否包含查询部分，都应与服务端入口一致。headers.Host 属于 WebSocket 握手头，而 tlsSettings.serverName 用于 TLS 服务器名称验证，两者可能相同，也可能因部署结构而不同。将它们视为一个字段同步替换，可能让其中一层通过而另一层失败。

服务器地址 address 决定最初连接到哪个主机，TLS 名称决定证书与握手所针对的名称，WebSocket Host 则由 HTTP 层处理。排查时应按连接建立顺序理解这三者。若地址可以建立 TCP 连接但 TLS 失败，重点检查系统时间、服务器名称和安全参数；若 TLS 成功后 WebSocket 被拒绝，则继续检查路径和 Host。单纯把证书验证选项改为宽松值会降低错误可见性，不应作为常规修复。

gRPC、mKCP 与传输专属字段

gRPC 配置通常需要准确的 serviceName，并依赖 HTTP/2 相关协商。服务名称是配置值，不是节点备注，也不应自行添加 URL 形式的斜线。若中间层不支持所需连接方式，表现可能是握手后立即关闭。mKCP 属于基于 UDP 的传输，除双方参数外，还依赖当前网络是否能稳定承载 UDP；TCP 可达不能证明 UDP 路径也可达。

传输专属参数数量较多时，应优先使用客户端按节点信息生成的结构，再针对明确需求修改。互联网上跨内核、跨时期的示例可能包含已经调整的字段名称。v2rayN 通常搭配桌面端核心管理，v2rayNG 使用 Xray 内核路径，v2flyNG 则面向 V2Fly 内核；同名传输的基础概念相近，但扩展字段未必完全一致。无法确认支持范围时，先删除非必要扩展并保留服务端要求的核心字段。

security、TLS 与 Reality 的层级

security 决定启用的安全层，对应设置对象必须与其一致。TLS 参数放在 tlsSettings，Reality 参数使用内核规定的独立设置对象。两类配置不能仅替换 security 字符串而沿用全部旧字段。服务器名称、公钥类参数、短标识及指纹类选择都属于特定安全方式的握手条件，必须来自同一份有效配置。

安全层错误与用户标识错误在界面上都可能表现为连接测试失败，因此日志阶段需要区分 DNS、TCP、TLS 或协议认证发生在哪一步。若连服务器端口都无法建立连接，继续修改服务器名称没有意义；若 TCP 已建立但安全握手失败，则不要先改路由规则。把故障定位到层级之后再改参数，可以防止一项改动暂时改变报错形式，却没有解决根因。