长连接与短连接应依业务需求选择：api网关宜用长连接以降握手开销；静态资源服务长连接收益有限但默认保持更稳妥；iot/im等高并发保活场景长连接是刚需；仅后端不兼容等极少数情况才禁用长连接。
长连接和短连接不是“哪个更好”，而是“哪个更合适”。选型的关键，在于业务对连接生命周期、资源消耗和响应模式的真实需求。
API网关场景：优先启用Keep-Alive长连接
高频、小体量化请求（如微服务间调用、移动端API轮询）天然适合长连接。Nginx默认开启keepalive_timeout 75s，配合后端复用TCP连接，能显著降低握手开销。
- 短连接下100次请求需200次TCP握手；长连接仅需1次初始握手，后端TCP连接数可减少约70%
- 务必同步配置后端服务的keepalive参数（如Node.js的
agent.keepAlive = true），否则Nginx与后端之间仍是短连接 - 对于WebSocket等状态敏感协议，必须显式设置
proxy_http_version 1.1、Upgrade和Connection头，并延长proxy_read_timeout（建议≥3600s）
静态资源服务：长连接收益有限，但默认保持更稳妥
浏览器访问HTML/CSS/JS等静态文件时，通常会自动发起多个并行请求。Nginx本身处理静态文件极快（毫秒级），连接是否复用对单次响应影响不大，但对整页加载体验有间接影响。
- 现代浏览器默认使用HTTP/1.1并开启Keep-Alive，Nginx无需额外配置即可支持
- 若前端构建产物中资源引用路径明确（如
/static/js/app.abc123.js），且CDN或浏览器缓存已生效，连接复用价值进一步降低 - 不建议为静态服务单独关闭keepalive——它不会增加明显负担，反而能避免首屏多资源请求时反复建连的微小延迟
高并发保活类业务（IoT、IM）：长连接是刚需，配置需深度协同
设备心跳、消息通道、实时行情推送等场景，连接长期空闲但必须可靠存活。此时长连接不是优化项，而是架构前提。
- 内核层需调大
net.core.somaxconn和fs.file-max，防止连接数受限于系统句柄 - Nginx worker进程要配置足够
worker_connections（如65535），并启用use epoll（Linux） - upstream中启用
keepalive 100（表示每个worker最多缓存100个空闲连接到后端），避免频繁重建后端连接
何时考虑禁用长连接？
极少数情况才需要主动关闭，例如：
- 后端服务老旧，无法正确处理HTTP/1.1 keepalive，频繁出现连接异常或超时
- 做精确连接计数审计，且确认所有客户端都支持
Connection: close头部 - 调试阶段临时隔离连接复用问题，用于对比基线性能
生产环境一般不建议全局禁用，可通过特定location匹配关闭，例如：location /health { keepalive_timeout 0; }。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
