本文速览
本文适合已经会导入服务器、希望进一步读懂 V2Ray 配置的用户。重点不是记忆全部字段,而是建立“流量从入站进入、经过路由判断、再由出站发送”的结构模型,并学会通过 tag、日志和配置边界定位问题。
先建立配置文件的流量路径
V2Ray 配置文件是一个 JSON 对象,顶层字段分别控制日志、域名解析、入站、出站和路由。核心不会按照文件从上到下逐行执行,而是在启动时读取全部配置,建立监听端口、出站处理器和路由规则。理解配置时应当按数据流阅读,而不是按文本行号阅读。
应用首先把请求交给本机的 SOCKS 或 HTTP 代理端口,对应配置中的
inbounds。入站识别目标地址后,把连接交给路由模块;routing 按规则顺序选择一个出站标签;最终由 outbounds 中标签对应的处理器建立远端连接或直接访问目标。dns 为需要解析的域名提供结果,log 则记录这一过程中的警告与错误。
应用请求
入站接收
嗅探补全
路由匹配
出站发送
下面的样本使用本机 SOCKS 端口
10808,定义一个 VMess 代理出站和一个 freedom 直连出站。私有地址先走直连,其余 TCP 与 UDP 流量交给代理出站。示例域名使用保留的 example.com,作用只是展示结构,不能直接作为可用服务器配置。{
"log": {
"loglevel": "warning"
},
"dns": {
"servers": [
"localhost",
"1.1.1.1"
]
},
"inbounds": [
{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls"
]
}
}
],
"outbounds": [
{
"tag": "proxy",
"protocol": "vmess",
"settings": {
"vnext": [
{
"address": "server.example.com",
"port": 443,
"users": [
{
"id": "11111111-2222-4333-8444-555555555555",
"security": "auto"
}
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "none"
}
},
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
],
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}
inbounds:定义谁能把流量交给核心
配置要点
inbounds 是入站数组,每个元素都代表一个监听入口。样本将地址限制为 127.0.0.1,端口设为 10808,协议设为 socks。这意味着只有本机程序可以连接该端口,局域网中的其他设备不能直接使用这个入口。listen 与 port 决定核心在哪里等待连接,protocol 决定如何解释进入端口的数据。端口没有特殊魔法,只要处于有效范围、没有被其他程序占用,并与应用填写的代理端口一致即可。若浏览器设置为 127.0.0.1:10808,配置却监听 10809,请求不会进入核心。10808
本机 SOCKS 端口
127.0.0.1
仅本机监听
1 个
示例入站
UDP 开启
SOCKS 入站能力
settings 与 sniffing 分别控制什么
配置要点
入站的
settings 由所选协议决定。SOCKS 入站中的 auth 和 udp 有意义,但把这些字段原样放入其他协议的入站并不一定有效。阅读文档时应先确认字段属于哪个协议,不要只根据相似名称迁移配置。sniffing 用来从连接初始数据中补充目标域名。应用有时先把域名解析为 IP,再向代理提交 IP;开启嗅探后,核心可能从 HTTP 主机字段或 TLS 握手信息中恢复域名,使基于域名的 routing 规则有机会命中。嗅探不是域名解析器,也不会替代 dns。tag是入站的内部标识,可供路由规则通过inboundTag区分流量来源。listen: 127.0.0.1适合仅供当前设备使用的本地代理入口。port冲突时,日志通常会出现监听失败或地址已被占用的提示。udp: true表示 SOCKS 入站允许处理 UDP 请求,但最终能否传输还取决于出站协议与服务端配置。
outbounds:定义流量从哪里离开
配置要点
outbounds 同样是数组,但职责与入站相反:它描述核心怎样连接最终目标。代理出站通常包含服务器地址、服务器端口、用户标识、协议参数和传输设置;直连出站使用 freedom,由当前设备直接访问目标;如需明确阻断,也可以使用专门的拒绝出站并通过标签引用。样本中的
proxy 与 direct 都是 tag。routing 不会复制出站内容,只记录应交给哪个 tag。修改标签时必须同步检查路由规则,例如把 direct 改为 local-direct 后,仍引用旧名称的 outboundTag 就无法指向预期出站。proxy 出站
- 协议
- VMess
- 远端端口
- 443
- 传输
- TCP
- 用户标识
- UUID 格式
服务器地址、用户标识和传输参数必须与服务端配置一致。
direct 出站
- 协议
- freedom
- 远端服务器
- 不需要
- 引用标签
- direct
- 典型用途
- 局域网直连
由本机网络直接建立连接,仍受本机 DNS、路由和防火墙影响。
协议参数与传输参数不是同一层
以 VMess 为例,
settings 中的 vnext 描述远端服务器和用户;streamSettings 描述底层网络与安全方式。服务器端口正确但传输方式不一致时,TCP 连接可能已经建立,协议握手仍会失败。因此排查连接问题时,不能只核对地址、端口和用户标识。| 字段位置 | 负责内容 | 常见错误 |
|---|---|---|
settings.vnext |
服务器地址、端口与用户参数 | 地址失效、端口错误、用户标识不一致 |
streamSettings.network |
TCP、WebSocket 等传输类型 | 客户端与服务端选择不同传输 |
streamSettings.security |
传输层安全方式 | 安全方式与服务端不匹配 |
tag |
供 routing 引用的内部名称 | 拼写变化后未同步修改规则 |
结论:先核对层级,再比较字段值
地址和端口属于协议设置,网络类型和传输安全属于 streamSettings。把参数放错层级,即使值本身正确,核心也不会按预期解释。
routing:按规则把入站连接交给出站
配置要点
routing.rules 是有顺序的规则数组。核心从第一条开始检查,遇到首个匹配规则后使用该规则指定的 outboundTag。因此更具体的规则通常放在前面,范围更大的兜底规则放在后面。若把覆盖全部 TCP 与 UDP 的规则放在首位,后续局域网直连规则就没有命中机会。样本第一条通过
geoip:private 匹配私有地址,并交给 direct。常见私有范围包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。第二条匹配 TCP 与 UDP,作为剩余流量的代理出口。这里的规则数量不多,但已经体现“具体规则优先、宽泛规则靠后”的基本原则。- 确认规则的
type为核心支持的类型,常用字段匹配规则使用field。 - 检查条件属于域名、IP、端口、网络类型、入站标签中的哪一类。
- 从上到下寻找第一条可能命中的规则,不要只看预期规则本身。
- 核对
outboundTag是否与 outbounds 中某个 tag 完全一致,包括大小写。 - 临时调整日志级别并重启核心,通过日志确认实际目标与错误阶段。
domainStrategy 决定何时为了路由解析域名
配置要点
样本使用
IPIfNonMatch。当目标以域名形式进入,且域名规则没有匹配时,路由模块可以解析该域名,再尝试匹配 IP 规则。这使某些基于地址库的规则能够处理域名目标,但也会增加一次解析过程。domainStrategy 不是“所有 DNS 请求走哪个出站”的开关,也不等同于系统 DNS 设置。它主要影响 routing 在匹配过程中是否以及何时把域名解析为 IP。DNS 服务器选择、查询流量路径与最终连接的目标地址仍需结合 dns、路由规则和出站配置一起判断。| 匹配条件 | 示例 | 适合解决的问题 |
|---|---|---|
| 域名 | domain |
按完整域名、子域范围或预置域名类别分流 |
| IP | ip |
按 CIDR、单个地址或地址类别分流 |
| 端口 | port |
把指定目标端口交给特定出口 |
| 入站标签 | inboundTag |
让不同本地入口采用不同出口策略 |
| 网络类型 | network |
区分 TCP 与 UDP 流量 |
结论:分流异常先检查规则顺序
当目标总是走向同一个出口时,先查看它是否被前面的宽泛规则提前截获,再检查域名是否已变成 IP、出站标签是否存在。
dns 与 log:辅助解析和定位故障
配置要点
dns 定义核心可使用的 DNS 服务器及相关解析策略。样本依次列出 localhost 和 1.1.1.1,用于说明服务器列表结构。实际配置应根据网络环境与路由目标选择解析方式,并关注查询是否会被期望的出站处理。需要特别区分应用自己的解析、操作系统解析和 V2Ray 内置 DNS。应用若先解析域名并只把 IP 交给 SOCKS 入站,核心未必会重新执行同一域名查询;启用 sniffing 后可能恢复域名,但是否成功取决于协议流量中能否提取相应信息。排查域名分流时,应先确认核心实际收到的是域名还是 IP。
dns 段
- 示例服务器
- localhost
- 备用地址
- 1.1.1.1
- 主要职责
- 提供域名解析
- 关联模块
- routing
解析结果可能参与 IP 规则匹配,但 dns 本身不决定最终出口。
log 段
- 示例级别
- warning
- 排查级别
- info 或 debug
- 主要职责
- 记录运行状态
- 重点信息
- 监听与连接错误
详细日志适合临时诊断,完成排查后可恢复较精简的级别。
配置要点
loglevel 控制输出详细程度。日常运行使用 warning 可以保留警告与错误;需要观察请求路径时,可以临时改为 info 或 debug。详细级别会产生更多记录,不宜在问题已经解决后长期保留。- 启动后完全没有监听端口:先检查 JSON 语法、字段类型和端口占用。
- 本地端口可连接但远端失败:核对 outbounds 的服务器、协议与传输参数。
- 代理可用但分流错误:检查 routing 顺序、目标形态以及 outboundTag。
- 域名失败而 IP 可访问:检查 DNS 响应、解析路径和域名策略。
- 只有 UDP 应用异常:确认入站允许 UDP,并核对出站与服务端的 UDP 能力。
从客户端生成配置到手工排查
配置要点
v2rayN、v2rayNG 与 v2flyNG 会根据图形界面中的服务器和路由选项生成核心配置。订阅地址或分享链接主要提供单个服务器所需的协议参数,客户端还会补充本地入站、日志、DNS 和路由内容。因此,分享链接中的字段集合通常不等于最终交给核心的完整 JSON。
使用图形客户端时,不建议把运行时生成文件当成长期配置源直接修改。客户端重新启动核心、切换服务器或更新设置后,生成文件可能被覆盖。更稳妥的方式是先在界面中修改对应选项,再通过日志或生成结果核对字段。如果必须维护独立配置,则应把它作为单独文件管理,并在每次修改后执行语法检查与启动测试。
配置语法正确,为什么核心还是立即退出?
JSON 合法只表示文本能够解析。继续查看启动日志,检查未知字段、字段类型错误、端口占用以及 routing 引用不存在的出站标签。
浏览器已经填写 10808,为什么没有请求日志?
确认 inbounds 实际监听
127.0.0.1:10808,再检查浏览器选择的是 SOCKS 代理而不是 HTTP 代理。两端协议类型必须一致。添加直连规则后,流量仍然走 proxy?
把直连规则移动到宽泛代理规则之前,核对
outboundTag 是否准确写为 direct,并确认目标进入核心时是域名还是 IP。能把这份 JSON 直接导入 v2rayN 吗?
完整核心配置与客户端服务器条目的结构不同。需要托管完整配置时应使用客户端提供的相应配置入口;普通服务器导入则使用 VMess、VLESS 分享链接或订阅地址。
修改 loglevel 后为什么看不到变化?
保存文件后重启核心,并确认正在编辑的是当前进程实际读取的配置。图形客户端可能在每次启动时重新生成运行配置。
建议采用的最小排查顺序
- 先确认 JSON 能被解析,所有对象、数组、逗号与引号位置正确。
- 启动核心并检查
127.0.0.1:10808是否已经监听。 - 暂时保留一个明确的代理出站和一个直连出站,减少变量数量。
- 使用两条 routing 规则验证私有地址直连、其余流量代理。
- 确认基础连接成立后,再逐项加入域名类别、端口条件和更多出站。
- 每次只修改一组相关字段,重启后立即读取对应日志。
配置要点
读懂 V2Ray 配置的关键,是把字段还原为连接路径:inbounds 负责接收,routing 负责选择,outbounds 负责发送,dns 为域名匹配和连接提供解析结果,log 为每个阶段提供诊断线索。遇到问题时按这五个边界逐段缩小范围,比同时修改协议、端口、DNS 与路由更容易得到可验证的结论。