Chrome/Chromium浏览器下Express+NGINX视频流Range请求处理异常导致请求泛滥问题排查

我之前碰到过一模一样的场景，Chrome对视频流Range请求的处理逻辑确实和Firefox有不小的差异。结合你提供的代码、配置和日志，咱们一步步拆解问题，找到解决方案。

问题复盘 #

你搭建了Express视频流服务，通过NGINX反向代理，Firefox能正常按8MB的批次请求视频片段，播放流畅且请求有序；但Chrome/Chromium系浏览器却会疯狂发送大量无序甚至重复的Range请求，短短1分钟就发送了662次请求，传输量远超视频实际大小，服务器负载直接飙升。

核心代码与配置分析 #

Express端点实现 #

先看你的Express处理逻辑，整体思路是没问题的：

app.get("<my-site>/api/video/:encoded", (req, res) => {
  const { filePath, fileName } = validationHelper(req.params.encoded)
  fs.stat(filePath, (err, stats) => {
    if (err || !stats.isFile()) {
      console.warn(`[404] File not found: ${filePath}`)
      res.status(404).json({ error: "Video not found" })
      return
    }
    const range = req.headers.range
    const fileSize = stats.size

    // 无Range头时返回完整视频
    if (!range) {
      res.writeHead(200, {
        "Content-Length": fileSize,
        "Content-Type": "video/mp4"
      })
      fs.createReadStream(filePath).pipe(res)
      return
    }

    // 处理Range请求，切割为8MB chunks
    const MAX_CHUNK_SIZE = 8 * 1024 * 1024 // 8MB
    const parts = range.replace(/bytes=/, "").split("-")
    const start = parseInt(parts[0], 10)
    let end = parts[1] ? parseInt(parts[1], 10) : start + MAX_CHUNK_SIZE - 1
    end = Math.min(end, fileSize - 1)

    if (start >= fileSize || end >= fileSize) {
      res.status(416).header("Content-Range", `bytes */${fileSize}`).end()
      return
    }

    const contentLength = end - start + 1
    const stream = fs.createReadStream(filePath, { start, end })
    console.log(JSON.stringify({ range, start, end, contentLength, fileSize }))
    
    res.writeHead(206, {
      "Content-Range": `bytes ${start}-${end}/${fileSize}`,
      "Accept-Ranges": "bytes",
      "Content-Length": contentLength,
      "Content-Type": "video/mp4",
    })
    stream.pipe(res)
  })
})

这里的关键点：你处理客户端只传起始字节的Range请求（比如bytes=51740672-）时，会自动截断为8MB的片段，这个逻辑本身没问题，但Chrome可能对这种截断的响应有特殊的预加载逻辑。

NGINX反向代理配置 #

你的NGINX配置已经做了大部分正确的设置：

location /<my-site> {
  proxy_pass http://localhost:<port>;
  proxy_http_version 1.1;
  proxy_set_header Range $http_range;
  proxy_set_header If-Range $http_if_range;
  proxy_set_header If-None-Match $http_if_none_match;
  proxy_set_header If-Modified-Since $http_if_modified_since;

  # 禁用Range请求的缓存
  proxy_cache off;
  proxy_buffering off;
  proxy_request_buffering off;
  proxy_no_cache $http_range;
  proxy_cache_bypass $http_range;

  # 连接超时设置
  proxy_read_timeout 300s;
  proxy_send_timeout 300s;

  # 禁止NGINX修改Range响应
  proxy_force_ranges off;
  proxy_max_temp_file_size 0;
}

你已经确保了HTTP/1.1版本、传递了所有Range相关头、关闭了缓冲和缓存，这些都是视频流代理的必要配置，但可能漏掉了连接复用的关键头。

浏览器行为差异与日志分析 #

Firefox的正常表现 #

Firefox会按顺序请求8MB的视频片段，播放完当前批次后再请求下一批，完全符合按需加载的预期，不会产生额外的无效请求。

Chrome的异常表现 #

从你提供的日志和请求头来看：

• Chrome一开始会请求几个正常的8MB片段，但很快就开始发送大量无序请求，比如直接请求文件末尾的片段（bytes=1339228160-），甚至重复请求同一范围
• 你的响应头是符合HTTP规范的（206状态码、正确的Content-Range），但Chrome似乎在频繁查找视频的关键帧，导致请求泛滥

关键解决方案 #

1. 修复MP4文件的索引位置（最可能的根因） #

Chrome对MP4文件的结构非常敏感，如果视频的moov atom（包含视频索引信息的部分）在文件末尾，Chrome会先请求文件尾部获取索引，然后再频繁请求不同位置的关键帧，导致大量无序请求。

你可以用ffmpeg工具将moov atom移到文件头部：

ffmpeg -i input.mp4 -movflags faststart output.mp4

处理后的视频文件会让Chrome快速获取索引，从而按顺序请求视频片段，避免泛滥。

2. 完善NGINX的连接头配置 #

添加以下配置，确保Chrome的Keep-Alive连接正常复用：

proxy_set_header Connection $http_connection;
proxy_set_header Upgrade $http_upgrade;
gzip off; # 禁用gzip，避免干扰视频流传输

另外，确认NGINX没有其他全局配置会影响Range请求的处理。

3. 优化Express的响应头 #

添加Last-Modified头，配合客户端的缓存验证机制，减少重复请求：

// 在res.writeHead之前添加
const lastModified = stats.mtime.toUTCString();
res.setHeader('Last-Modified', lastModified);

这样Chrome可以通过If-Modified-Since头验证缓存，避免重复请求相同的视频片段。

4. 前端video标签优化 #

调整video标签的属性，帮助Chrome更好地识别视频格式：

<video controls preload="metadata" playsinline>
  <source src={props.src} type="video/mp4; codecs='avc1.42E01E, mp4a.40.2'" />
</video>

指定具体的编码格式，让浏览器无需额外请求即可确认视频兼容性，减少无效请求。

验证步骤 #

1. 先处理一个测试视频文件，将moov atom移到头部
2. 修改NGINX和Express配置，添加上述优化项
3. 在Chrome中打开视频，观察服务器日志，确认请求恢复为有序的8MB片段
4. 监控服务器的请求量和带宽使用，对比优化前后的差异

内容来源于stack exchange