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

TwoBall 2026-08-13 01:20 1

一、 故障现象描述


在当前家宽 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.comchat.baidu.commbd.baidu.com 域名的 HTTP/2 协议栈 / WAF 转发异常。

最新回复 (1)
  • TwoBall 楼主 08-13 01:41
    1
    # 百度网盘 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 。**

    ````
* 帖子来源V2EX
返回