Workbox 3.2注册路由返回ERR_CONNECTION_RESET问题排查求助

我之前也碰到过类似的SSR页面在Workbox路由里出现连接重置的问题，结合你的描述，咱们一步步拆解排查：

可能的原因 #

1. SSR分块响应与Workbox 3.x的兼容性bug #

Node.js SSR通常会用Transfer-Encoding: chunked分块传输编码来逐步返回渲染后的HTML，但Workbox 3.x的networkOnly/networkFirst策略在处理这类流式响应时存在缺陷——Service Worker无法正确识别分块内容的结束，导致连接被强制重置，表面返回200状态码，但实际没有有效响应内容。

2. 路由匹配范围过宽 #

你的正则表达式/?(?:id|en|sg|my|bn)/?$可能匹配了一些意料之外的请求（比如带复杂查询参数的请求、或者子路由的根路径），这些请求的响应格式和标准SSR页面不一致，触发了异常。

3. Workbox 3.x的固有局限性 #

Workbox 3.x是比较早期的版本，对现代SSR场景的支持不够完善，尤其是在处理非静态资源的网络请求时，存在不少未修复的细节bug。

解决方法 #

方法一：修改SSR响应的传输方式 #

在Node.js的SSR服务中，关闭分块传输，改为一次性返回完整的HTML内容。以Express为例，可以手动设置Content-Length头，强制禁用chunked编码：

// Express SSR路由示例
app.get('/en', (req, res) => {
  const html = renderToString(<App />);
  // 计算HTML内容的字节长度，设置Content-Length
  res.set('Content-Length', Buffer.byteLength(html, 'utf8'));
  res.send(html);
});

这样Service Worker就能正确接收完整的响应内容，不会出现连接重置。

方法二：收紧路由匹配规则 #

把正则表达式改得更精确，避免匹配不必要的请求，比如明确匹配根路径下的语言路由，不包含无关的子路径或参数：

const pagesHandler = workbox.strategies.networkOnly();
// 精确匹配 /, /id, /en, /sg, /my, /bn 这些路由
workbox.routing.registerRoute(new RegExp('^/(?:id|en|sg|my|bn)?$'), pagesHandler);

如果需要支持带查询参数的场景，可以调整正则为：

new RegExp('^/(?:id|en|sg|my|bn)?(?:\\?.*)?$')

方法三：升级Workbox版本 #

Workbox 4.x及以上版本修复了大量流式响应和SSR相关的兼容性问题，建议升级到最新稳定版（比如Workbox 6.x）。升级后，networkOnly策略对chunked响应的处理会更完善，同时API也更稳定。

方法四：临时绕过Service Worker处理SSR路由 #

如果以上方法都不适用，可以在注册Service Worker时，直接排除这些SSR路由，让浏览器直接请求服务器：

// 注册Service Worker时的示例
if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js', {
      scope: '/',
      // 排除SSR语言路由
      exclude: ['/id', '/en', '/sg', '/my', '/bn']
    });
  });
}

不过这种方法相当于放弃了对这些路由的Service Worker控制，适合临时应急，不推荐长期使用。

验证步骤 #

1. 先尝试优化路由匹配规则，确认是否是匹配范围过大导致的异常；
2. 如果问题依旧，修改SSR服务的响应头，禁用chunked传输；
3. 最后考虑升级Workbox版本，从根源上解决兼容性问题。

内容的提问来源于stack exchange，提问作者Pahlevi Fikri Auliya