v2rayN 开启流量嗅探 (Sniffing) 导致部分网游与网银断连？配置 domainsExcluded 嗅探白名单实操

一、成也嗅探、败也嗅探的“连接中断谜团”

在 v2rayN 的默认参数设置中，有一项几乎默认勾选的核心功能：启用流量嗅探（Enable Sniffing）。

Contents

在 95% 的日常网页浏览场景下，它是个大功臣：当本地应用程序因为 DNS 污染拿到了一个虚假的 IP 地址并发起连接时，Xray 核心会拆开数据包的前几个字节，从 HTTP Host 或 TLS Client Hello 的 SNI 中“嗅探”出你真正想访问的真实域名，然后用这个域名直接覆盖（Override）掉原有的目标 IP，交给远端服务器去重新解析。

然而，在剩下的 5% 特殊场景下，这种“强行覆盖目标地址”的行为会直接酿成惨剧：

特定外服端游与联机大厅（如部分 Steam P2P 对战、暴雪战网子服务）：客户端明明已经通过专用通道拿到了对战房间的精确纯 IP 地址并发包，但由于包里带有一层通用的 TLS 证书域名，v2rayN 嗅探后自作聪明地把精确的对战服 IP 替换成了宽泛的证书域名，导致远端节点解析到了错误的服务器，游戏直接卡在加载界面掉线；

非标准首包协议（如米家智能家居控制、苹果 APNs 推送、部分银行 U 盾控件）：客户端连接建立后，等待服务器先发包（Server Speaks First），而嗅探器却在原地死等客户端先发 TLS 握手包，直到超时断开。

二、解开死结的两个核心开关：`routeOnly` 与 `domainsExcluded`

Xray-core 官方针对上述痛点提供了两个极其精妙的控制阀门：

`routeOnly: true`（嗅探结果仅用于路由分流，不覆写目标地址）：

开启后，Xray 依然会嗅探出包里的域名，用来判断这条流量该走 `direct`（直连）还是走 `proxy`（代理）；但在真正把数据包发出去时，保留原有的目标 IP 不作篡改！这既保证了分流规则生效，又不会破坏游戏的精确 IP 直连；

`domainsExcluded`（嗅探豁免黑名单）：

一旦嗅探到包里的域名命中了这个列表，立即放弃任何嗅探覆写动作，原封不动透传原始流量。

三、在 v2rayN 中精细调优 Sniffing 配置

步骤 1：在图形设置中开启“仅用于路由 (routeOnly)”

打开 v2rayN 主界面，点击顶部菜单 「设置」 -> 「参数设置」。

在 「Core:基础设置」 选项卡中，找到流量嗅探相关勾选项：

保持勾选 「启用流量嗅探 (enable sniffing)」；
务必同时勾选下方的「仅用于路由 (routeOnly)」！

注意：如果你开启了 `routeOnly`，请确保你的 v2rayN 已经配置了防污染的远程 DNS 或 Fake-IP，因为此时本地解析出的 IP 将直接决定最终连接目标。

步骤 2：在入站配置中注入 `domainsExcluded` 行业级豁免清单

如果你未开启全局 `routeOnly`，则需要排除已知的敏感冲突服务。在 v2rayN 的入站配置（Inbound）或自定义配置模板中，将 `sniffing` 节点完善为以下生产级结构：

"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
],
"routeOnly": false,
"domainsExcluded": [
"courier.push.apple.com",
"rbsxbxp-mimc.chat.xiaomi.net",
"Mijia Cloud",
"dlg.io.mi.com",
"+.battle.net",
"+.blizzard.com",
"+.steamcontent.com",
"+.stun.twilio.com"
]
}

四、关键排除项释义与效果验证

`courier.push.apple.com`：苹果 iCloud 与 iMessage 的底层长连接推送通道，排除后可解决 Mac/iOS 共享局域网代理时通知延迟收不到的问题；
`Mijia Cloud` / `dlg.io.mi.com`：小米智能家居设备使用的私有伪 TLS 证书签名，排除后解决电脑模拟器或智能家居控制面板断连；
`+.battle.net` / `+.steamcontent.com`：保留游戏客户端自主调度的精准 CDN 与对战节点 IP，保存重启服务后，原先卡在登录框或对战房间加载超时的问题立即迎刃而解。