Firefox访问ESP32托管网页时重复请求静态文件的原因及解决方法

这类ESP32托管网页出现静态资源双请求的问题，90%以上是服务端HTTP响应不规范触发了Firefox的重试逻辑，结合你的场景具体对应几种情况：

• 你的ESP32 Web服务没有给静态资源返回标准的Content-Length响应头，也没有显式标记连接关闭。Firefox加载head中同步引入的CSS、JS这类阻塞渲染的资源时，如果发出请求后在超时阈值内没收到明确的响应结束标识，会自动发起第二次重试请求，最终在网络面板留下两条同路径的请求记录。
• 服务端漏处理/favicon.ico请求。Firefox打开页面时会自动请求站点图标，如果你在ESP32代码里没有配置favicon的路由，且把所有未匹配路径的请求都重定向到首页，就会导致首页HTML被第二次拉取，看起来像是页面被重复请求。
• 路由重复注册。如果你用的是ESP32自带的WebServer或者AsyncWebServer库，同一个资源路径重复注册了处理回调，会导致单次请求触发两次响应逻辑，从浏览器侧看就和两次独立请求表现一致。
• 少数情况是Firefox的预测预连接机制触发的试探请求，这类重复请求一般在网络面板里会标记为「已取消」状态，不会真正拉取完整资源。

按优先级操作即可彻底解决问题：

1. 先修ESP32端的响应逻辑，所有资源响应必须带齐标准头：
   • 每个静态资源返回时，准确填写Content-Length为文件实际字节数，不要用分块传输编码，避免浏览器判断响应长度异常触发重试
   • 如果你没有实现HTTP Keep-Alive逻辑，所有响应都加上Connection: close头，明确告知浏览器资源发完后直接断开TCP连接，不要等待复用
   • 给CSS、JS、静态图片这类不常修改的资源加上Cache-Control: max-age=3600头，告诉浏览器1小时内直接用本地缓存，不要重复发请求
2. 补全favicon路由处理：最简单的方式是对/favicon.ico路径直接返回204 No Content状态码，不需要返回实际图标内容，避免请求落到通配路由上被重定向到首页。
3. 检查服务端路由注册代码，确认首页、CSS、JS对应的路径只注册了一次处理回调，不要重复绑定。
4. 如果排查后确认是Firefox预连接机制导致的非必要请求，可以在页面head标签内加一行meta配置禁用预取：

   <meta http-equiv="x-dns-prefetch-control" content="off">
   

排查小技巧：打开Firefox网络面板看重复请求的状态，如果第二条请求状态是「已取消」，优先修Content-Length和Connection响应头；如果第二条请求返回200状态，优先查favicon路由和重复注册的问题。

内容的提问来源于stack exchange，提问作者Mark