Chrome 133 引发 net::ERR_CONTENT_LENGTH_MISMATCH 问题的分析与解决

问题现象

最近有用户反馈，在使用浏览器访问系统时，部分静态资源请求出现 net::ERR_CONTENT_LENGTH_MISMATCH 错误。具体表现如下：

• 页面请求多个静态资源（HTML/JS/CSS），但部分请求随机失败
• 每次刷新页面时，失败的资源不固定，但问题持续发生

问题排查

介入排查后，发现以下关键信息：

• 使用 Chrome 131 及以下版本、Edge、Firefox 均无法复现该问题
• 升级到 Chrome 133 后，问题立即复现

ERR_CONTENT_LENGTH_MISMATCH 的常见原因

• 服务器返回的数据大小与 Content-Length 头部声明的长度不匹配
• 数据传输过程中连接中断，导致客户端未接收完整数据
• 代理层或防火墙可能影响数据完整性

抓包分析

在网关侧和 Windows 侧同时进行抓包分析，发现以下问题：

1. Nginx 返回的数据没有异常：服务器端数据发送正常，Content-Length 与实际数据大小匹配

2. 客户端主动断开连接：在数据传输几十毫秒后，数据尚未传输完成时，客户端向 Nginx 发送了 FIN 包，即 Chrome 在数据未传输完成时主动发送 FIN，断开了连接

   说明：RST 包的产生原因很好理解。Nginx 接收到 FIN 后，立即关闭该连接的 socket。当后续请求到达时，内核无法识别这条已关闭的连接，直接返回 RST 包

同时查看了 Windows 侧抓取的网络包，确认确实是 Chrome 发出的 FIN 包，排除了现场防火墙拦截的可能性。

初步结论

• Chrome 133 在数据传输未完成时，主动发送 FIN 终止连接，导致部分静态资源加载失败
• Edge、Chrome 131 及以下版本均无此问题，升级至 Chrome 133 后，问题立即复现
• 结论：Chrome 133 的 TCP 处理逻辑存在 Bug，并非 Nginx 或防火墙导致的问题

Bug 反馈与官方响应

• 在 Chromium Bug Tracker 提交了问题报告：https://issues.chromium.org/issues/397848897
• 发现该问题已有人提交：https://issues.chromium.org/issues/391126826
• 官方确认：问题由 TcpSocketIoCompletionPortWin 引发
• 临时解决方案：Chrome 133.0.6943.142 版本默认关闭该特性

TcpSocketIoCompletionPortWin 详解

TcpSocketIoCompletionPortWin 在 Chrome 网络栈中的作用：

• 功能：负责 Windows 平台的 TCP 异步 I/O 处理，使用 IOCP（I/O Completion Port）机制进行高效管理
• 影响范围：
  1. HTTP(S) 连接：网页加载的所有 TCP 请求（包括静态资源）
  2. WebSocket 连接：影响 WebSocket 长连接数据传输
  3. Chromium IPC：影响 Chrome 进程间的数据传输
  4. QUIC/TLS 连接：影响 TLS 加密连接的数据流控制

源码位置

net/socket/tcp_socket_win.cc
net/socket/tcp_socket_win.h
net/socket/tcp_socket_io_completion_port_win.cc
net/socket/tcp_socket_io_completion_port_win.h

源码链接：https://source.chromium.org/chromium/chromium/src/+/main:net/socket/tcp_socket_io_completion_port_win.cc

注：虽然对网络这块很感兴趣，但深入分析该模块的实现细节需要较多时间，这里主要关注问题的根本原因和后续修复方案。