静态资源服务带宽优化核心是减少传输体积、提升复用率、降低重复请求；通过启用Gzip/Brotli压缩文本资源（减60%~80%体积）、合理设置Cache-Control与ETag实现强缓存和304校验、启用HTTP/2多路复用、精简响应头等策略协同达成。
静态资源服务的带宽优化，核心在于减少传输体积、提升复用率、降低重复请求。Nginx 本身不产生内容，但能高效调度和压缩，关键在配置策略是否贴合实际访问模式。
启用 Gzip 或 Brotli 压缩
文本类资源（HTML、CSS、JS、SVG、JSON）压缩效果显著，通常可减少 60%~80% 体积。Gzip 兼容性好，Brotli 压缩率更高（尤其小文件），但需客户端支持（现代浏览器均支持）。
- Gzip 需加载
ngx_http_gzip_module（默认编译进大多数发行版），开启后设置gzip on，并指定最小响应体大小（如gzip_min_length 1024）避免小文件压缩开销反超收益 - Brotli 需手动编译或使用支持模块（如
nginx-brotli），启用时建议与 Gzip 共存，并通过Accept-Encoding自动协商，优先返回 Brotli - 避免对已压缩格式（如 JPG、PNG、MP4、WOFF2）启用压缩，既无效又耗 CPU
合理设置缓存头（Cache-Control 与 ETag）
客户端缓存是节省带宽最直接的方式。关键是让浏览器“少下载、不重验”。
- 对指纹化资源（如
app.a1b2c3.js）设Cache-Control: public, max-age=31536000（1年），确保长期强缓存 - 对无版本号的通用资源（如
logo.png），配合ETag或Last-Modified，让 304 响应替代 200，仅传 HTTP 头（几十字节） - 禁用
Cache-Control: no-cache或频繁变更的max-age，否则失去缓存意义
启用 HTTP/2 或 HTTP/3（优先 HTTP/2）
多路复用、头部压缩、服务器推送（HTTP/2）可显著降低 TCP 连接开销和首字节延迟，间接提升带宽利用率——尤其在资源数量多、单个体积小的场景下。
- HTTP/2 要求 HTTPS，需配置有效证书；启用只需在
listen指令后加http2 - HTTP/3（基于 QUIC）进一步减少握手延迟，但依赖 OpenSSL 3.0+ 和 nginx 1.25.0+，部署复杂度高，当前建议以 HTTP/2 为主
- 避免混用 HTTP/1.1 与 HTTP/2 的同一域名，防止连接竞争和队头阻塞残留
精简响应头与关闭非必要功能
每个字节都计入带宽，包括响应头本身。默认头中常含冗余信息。
- 用
server_tokens off关闭Server头，省去约 20 字节/请求 - 移除或覆盖
X-Powered-By等第三方头（若上游应用注入） - 禁用
ssi（服务器端包含）、autoindex等非必需模块，减少潜在响应膨胀与安全暴露 - 对 CDN 回源请求，可统一由 CDN 设置缓存头，Nginx 后端只专注内容交付，避免重复逻辑
