NET::ERR_INSUFFICIENT_RESOURCES这个报错乍一看很唬人，其实它并不是CDN节点真的没资源了，而是浏览器端在发起请求时发现可用的连接资源不足，无法继续创建新的并发请求。这类问题在图片站、电商列表页、微前端架构的项目里尤其高发，一个页面动辄加载几百张缩略图，一旦超出限制就会出现部分资源加载失败、控制台刷屏报错的情况。想彻底解决它，得先弄清楚这个错误背后的运行机制。
一、错误产生的底层机制：浏览器并发连接限制
Chrome浏览器对同一个域名（即相同的protocol + host + port组合）同时建立的TCP连接数有硬性上限，HTTP/1.1协议下通常是6个。这意味着即使你的页面里有一百张图片要加载，浏览器也只能同时发出6个请求，其余的请求要排队等待。正常情况下排队机制会平稳运转，但在某些异常场景下，比如单个请求长时间不释放连接、前端代码失控地一次性创建了海量请求，浏览器的连接池就会被占满甚至击穿，此时新请求无法分配资源，控制台就会抛出ERR_INSUFFICIENT_RESOURCES错误。
需要注意的是，这个限制是按域名隔离计算的。如果页面从同一个CDN域名加载全部资源，所有请求都挤在同一个域名的6个连接里，压力就非常集中。反过来，如果资源分散在多个域名下，每个域名都有独立的连接配额，这就是早年常见的域名分片（Domain Sharding）技术。不过在HTTP/2普及之后，单域名多路复用已经取代了域名分片，这个后面会详细讲。
另一个容易忽略的因素是服务端行为。如果CDN节点的Keep-Alive没有开启，或者回源配置不合理导致每个请求都经历漫长的回源等待，连接长时间被占用不能复用，浏览器端的排队队列就会越积越长，最终触发资源不足。所以排查这个问题不能只盯着前端，CDN配置和源站性能同样要检查。
二、常见诱因排查：从代码到配置逐层检查
第一个要查的是页面的请求总量。打开Chrome DevTools的Network面板，刷新页面后看底部的请求数统计。如果单个页面加载的资源数超过两三百个，基本可以判定是请求数量失控。典型场景包括：列表页一次性渲染所有图片、代码里用循环动态创建<img>标签且没有做任何节流、微前端场景下多个子应用的资源重复加载等。
第二个要查的是是否存在请求风暴。有些前端代码会在组件挂载时发起请求，如果组件被频繁重渲染，或者事件监听没有解绑导致重复触发，短时间内可能产生成百上千个重复请求。可以在Network面板按时间轴观察请求密度，如果发现同一接口或同一图片在一秒内被请求了几十次，那问题多半出在代码逻辑上，比如防抖节流缺失、useEffect依赖数组写错等。
第三个要查的是CDN与源站的配置。重点确认这几项：CDN节点的Keep-Alive是否开启、回源超时时间设置是否过长、源站Nginx的keepalive_timeout和worker_connections是否过小。源站配置可以这样检查和调整：
# 查看当前Nginx并发连接配置
nginx -T | grep -E "keepalive|worker_connections"
# 常见的优化配置示例（nginx.conf）
worker_processes auto;
events {
worker_connections 10240; # 单个worker允许的最大连接数
}
http {
keepalive_timeout 65s; # 保持连接65秒，避免频繁握手
keepalive_requests 1000; # 单连接最多处理1000个请求后关闭
}如果源站每个连接只处理一个请求就断开，浏览器和CDN之间就要反复进行TCP握手，并发能力会被大幅削弱。把keepalive_requests调大、确保响应头里带上Connection: keep-alive，能显著提升连接复用率。
三、解决方案：从减少请求到升级协议
最直接有效的手段是减少请求数量。对于小图标，用雪碧图（CSS Sprite）把几十个图标合并成一张图，通过background-position定位展示；对于小体积的静态资源，考虑用构建工具做文件合并，比如Webpack的splitChunks合理拆分反而要控制chunk数量，别把公共代码打得太碎。图片类资源务必上懒加载，只加载视口内的图片：
<img src="placeholder.png" data-src="https://cdn.ipipp.com/images/photo.jpg" alt="商品图" loading="lazy">
<script>
// 配合IntersectionObserver实现按需加载
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
observer.unobserve(img);
}
});
});
document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));
</script>第二个方案是升级HTTP/2。HTTP/2支持多路复用，一个TCP连接上可以并行传输无数个请求，从根本上绕开了HTTP/1.1的6连接限制。大多数CDN厂商在控制台都支持一键开启HTTP/2，前提是你的站点域名已经配置了HTTPS证书。开启后可以用curl验证：
# 检查CDN响应是否已经协商到HTTP/2 curl -I --http2 https://cdn.ipipp.com/images/photo.jpg # 返回 HTTP/2 200 说明协议已生效
第三个方案是治理异常代码。给高频触发的请求加上防抖或节流，修复组件重复渲染导致的重复请求。如果确实有大量同域名资源必须同时加载，也可以适度做域名分片，把资源分散到两三个CDN域名下，但注意分片数量别超过3个，否则额外的DNS查询和TLS握手反而会拖慢速度。
四、验证与监控：确认问题真正解决
优化完成后不要只看页面能不能打开，要做系统验证。先在Chrome的Network面板里限制网络为Slow 3G再刷新页面，模拟弱网环境下的极端加载情况，观察是否还有请求失败。再用Performance面板录制一次完整加载过程，查看请求队列的长度变化，健康的页面请求应该是平滑排队而不是长时间堆积。
长期来看建议在CDN控制台开启实时监控，关注两个核心指标：一是5xx错误率和回源失败率，如果回源超时频繁，说明源站处理能力不足，需要扩容或优化源站；二是并发连接峰值，把它和浏览器端的限制做对照，评估是否还有优化空间。同时接入前端错误上报，把ERR_INSUFFICIENT_RESOURCES这类网络错误捕获后上报到监控平台，出现异常波动时能第一时间发现，而不是等用户投诉才知道页面加载出了问题。
CDNERR_INSUFFICIENT_RESOURCES资源不足修改时间：2026-09-04 22:46:45