百度系服务（网盘/首页）地区 IPv4 节点 HTTP/2 响应挂起与 TCP 重置故障报告

[TwoBall]

一、 故障现象描述

在当前家宽 IPv4 网络环境下，访问百度系核心网页（**百度网盘 pan.baidu.com** 与 **百度首页 [www.baidu.com]( https://www.baidu.com)**）极其缓慢，页面框架加载后长时间打转挂起，最终部分模块或数据超时报错：

1. 百度网盘：主页文件列表及初始化配置长时间转圈，需要死等 10s~60s 超时后页面才勉强渲染。
2. 百度首页：页面顶部及右侧 AI 对话/历史模块卡死无法加载。

---

二、F12 开发者控制台抓包日志（错误证据）

1. 百度网盘 (pan.baidu.com) 报错日志：

• 核心配置接口 10 秒超时挂起（导致 Vue 框架渲染雪崩）：

[BpABTest Error] - _startABTestDataLoading err - {"message":"timeout of 10000ms exceeded","name":"AxiosError","code":"ECONNABORTED"}
URL: https://pan.baidu.com/xep/getcfg

• 模板变量接口 TCP 强制重置：

GET https://pan.baidu.com/api/gettemplatevariable net::ERR_CONNECTION_RESET

• 风控上报接口空响应 / 阻塞：

GET https://mbd.baidu.com/ztbox?action=zpblog... net::ERR_EMPTY_RESPONSE / ERR_BLOCKED_BY_ORB

• 同源控制台手动 fetch 测试： 在 pan.baidu.com 控制台运行 fetch('/api/gettemplatevariable')，直接处于 Promise {<pending>} 挂起状态，无法按正常时延返回。

2. 百度首页 ([www.baidu.com]( https://www.baidu.com)) 报错日志：

• AI 助手历史消息接口 TCP 强制重置：

POST https://chat.baidu.com/aichat/api/messages/list?tk=... net::ERR_CONNECTION_RESET
预加载消息列表失败: TypeError: Failed to fetch

---

三、 交叉测试与组对照数据（关键定位证据）

为排除链路物理中断，通过不同协议与网络环境进行了对比测试：

测试环境	连接协议 / 请求头特征	测试结果	诊断结论
**终端 curl**	IPv4 + HTTP/1.1 + 极简 Header	200 OK (瞬间返回)	证明物理 IP 连通性、TLS 握手及 443 端口正常
Chrome 浏览器	IPv4 + HTTP/2 + 完整 Cookie	ERR_CONNECTION_RESET / 死等 10s-60s 超时	百度该地区 IPv4 HTTP/2 节点 / WAF 存在协议栈死锁 bug
Chrome 浏览器	IPv6 + HTTP/2 + 完整 Cookie	200 OK (几十毫秒秒开)	IPv6 节点完全正常，成功绕过故障 IPv4 节点

• curl 测试抓包示例： curl -v -4 [https://pan.baidu.com/api/gettemplatevariable]( https://pan.baidu.com/api/gettemplatevariable)

Connected to pan.baidu.com (36.110.192.103) port 443 ALPN: server accepted http/1.1 < HTTP/1.1 200 OK {"errno":-6,"result":[],"request_id":...}

---

四、 已排除的本地网络与设备因素

1. 已排除本地代理/旁路由/Fake-IP 劫持：将终端网关与 DNS 直连主路由，绕过任何 Side Gateway / DNS 分流，IPv4 问题依旧。
2. 已排除 IP 被封/风控连坐：重新拨号获取全新的公网 IPv4 地址，问题依旧。
3. 已排除浏览器插件与油猴脚本：在无痕模式（ Incognito ）、禁用所有扩展程序及 UserScript （如 LinkSwift ）下测试，问题依旧。

---

五、 结论与诉求

综合以上数据，并非用户侧本地网络或物理链路故障，而是百度在当前地区/运营商下的 IPv4 CDN 边缘节点（如 36.110.192.103 等）在处理 Chrome 发起的 HTTP/2 多路复用连接及特定 Cookie 请求头时存在严重的网关响应超时（ECONNABORTED）与 TCP 重置（ERR_CONNECTION_RESET） Bug。

诉求：请排查并修复该地区 IPv4 节点 pan.baidu.com、chat.baidu.com 及 mbd.baidu.com 域名的 HTTP/2 协议栈 / WAF 转发异常。

[TwoBall]

# 百度网盘 IPv4 节点 HTTP/2 测试结果

测试地址：

`https://pan.baidu.com/api/gettemplatevariable`

测试环境：

- 系统：Ubuntu
- curl：8.18.0
- 测试协议：HTTP/2
- 强制 IPv4：`-4`
- 测试方式：`--resolve` 固定百度 IPv4 地址

---

## 1. IPv4：36.110.192.112

### 测试命令

```bash
curl -4 --http2 -v \
--resolve pan.baidu.com:443:36.110.192.112 \
https://pan.baidu.com/api/gettemplatevariable
````

### 关键结果

```text
IPv4: 36.110.192.112
ALPN: curl offers h2,http/1.1
ALPN: server accepted http/1.1
using HTTP/1.x
```

### HTTP 协议协商

| 项目 | 结果 |
| ---------- | ----------------------------- |
| 客户端支持 | HTTP/2 、HTTP/1.1 |
| 服务端选择 | **HTTP/1.1** |
| 实际使用协议 | **HTTP/1.1** |
| HTTP 状态码 | `200 OK` |
| TLS | TLS 1.2 |
| TLS Cipher | `ECDHE-RSA-AES128-GCM-SHA256` |

---

## 2. IPv4：36.110.192.103

### 测试命令

```bash
curl -4 --http2 -v \
--resolve pan.baidu.com:443:36.110.192.103 \
https://pan.baidu.com/api/gettemplatevariable
```

### 关键结果

```text
IPv4: 36.110.192.103
ALPN: curl offers h2,http/1.1
ALPN: server accepted http/1.1
using HTTP/1.x
```

### HTTP 协议协商

| 项目 | 结果 |
| ---------- | ----------------------------- |
| 客户端支持 | HTTP/2 、HTTP/1.1 |
| 服务端选择 | **HTTP/1.1** |
| 实际使用协议 | **HTTP/1.1** |
| HTTP 状态码 | `200 OK` |
| TLS | TLS 1.2 |
| TLS Cipher | `ECDHE-RSA-AES128-GCM-SHA256` |

---

## 3. 两个 IPv4 节点对比

| 项目 | 36.110.192.112 | 36.110.192.103 |
| -------------- | -------------- | -------------- |
| IPv4 | ✅ | ✅ |
| TLS 连接 | ✅ | ✅ |
| 客户端提供 HTTP/2 | ✅ | ✅ |
| 服务端接受 HTTP/2 | ❌ | ❌ |
| 服务端接受 HTTP/1.1 | ✅ | ✅ |
| 实际协议 | **HTTP/1.1** | **HTTP/1.1** |
| HTTP 状态码 | `200 OK` | `200 OK` |
| HTTPS 请求 | 正常 | 正常 |

## 4. 初步结论

两个百度 IPv4 地址：

* `36.110.192.112`
* `36.110.192.103`

在 Ubuntu + curl 8.18.0 环境下进行 HTTP/2 协商时，客户端均声明支持：

```text
h2,http/1.1
```

但百度服务端均返回：

```text
ALPN: server accepted http/1.1
```

因此，**本次测试没有观察到这两个 IPv4 地址提供 HTTP/2 的情况，实际均回落到了 HTTP/1.1 。**

这意味着目前还不能证明：

> “百度某个 IPv4 节点的 HTTP/2 有问题”。

目前能够确认的是：

> **36.110.192.103 和 36.110.192.112 均可以正常建立 HTTPS 连接，并返回 HTTP 200 ，但本次测试中均未协商使用 HTTP/2 。**

````