nginx高负载内存溢出需系统层、配置层、上游层协同排查：先用ps、/proc/limits、free等命令确认真溢出；再收紧ssl_session_cache、proxy_buffering、worker_connections等内存放大配置；最后通过open_file_cache、upstream keepalive、日志精简及系统级rlimit和内核参数兜底防护。
Nginx 负载均衡器在高负载下出现内存溢出，通常不是单点配置错误，而是多个资源协同失控的结果。核心要抓住“谁在吃内存”和“为什么不释放”两个问题，从系统层、Nginx 配置层、上游交互层分步收紧。
先确认是不是真内存溢出，而不是误报或假象
别急着调参数，先用三行命令快速定位：
-
ps -o pid,vsz,rss,comm -C nginx—— 看各 worker 进程 RSS 是否持续上涨（比如 2 小时内涨超 300MB 且不回落） -
cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"—— 检查句柄限制是否卡死，避免把“too many open files”误判为内存问题 -
free -h && cat /proc/sys/fs/file-nr—— 对比可用内存和已分配句柄数，若两者都逼近上限，说明是资源全面承压
重点收缩几类高内存消耗配置
这些项在高并发下极易成为“内存放大器”，必须按业务实际重估：
-
ssl_session_cache shared:SSL:XXm：不能拍脑袋设 512m。用公式算——峰值新建 HTTPS 连接数（QPS）× 超时秒数（建议 600–1200）× 0.5KB。例如 QPS=1200 → 约 360MB，设shared:SSL:384m更稳妥；同时确保只在http{}块定义一次，删掉所有server{}内重复声明 -
proxy_buffering on：保持开启，但收紧缓冲尺寸。proxy_buffer_size 8k（够存常规响应头），proxy_buffers 16 8k（128KB 总缓存），大文件导出接口可单独 location 提升，不要全局拉高 -
worker_connections和worker_processes：64 核机器不必设 64 个 worker。推荐worker_processes 12+worker_connections 32768（约 39 万连接），既防上下文切换开销，又避免每个连接预占 30–50KB 内存导致总内存失控
堵住运行时泄漏路径
很多“溢出”其实是资源未及时归还：
-
open_file_cache启用后，inactive时间别设 300s。短生命周期静态请求多的场景，设open_file_cache inactive=30s; open_file_cache_errors on;，让失效句柄快速释放 -
upstream必须配keepalive 200;，并配套proxy_http_version 1.1; proxy_set_header Connection '';。否则每请求建新连接，socket 缓冲 + proxy buffer 双重吃内存，百亿级请求下极易崩 - 关闭非必要模块和日志：
http{}块统一access_log off; log_not_found off;，仅关键域名用location单独开；删掉所有测试路径、if 判断、未用 rewrite，减少指令树内存驻留
配合系统层做兜底防护
Nginx 自身再稳，也得靠系统托底：
-
worker_rlimit_nofile 65536;（写在nginx.conf最外层，events 块之前），数值不超过ulimit -Hn输出值 - systemd 服务里加
LimitNOFILE=65536，/etc/security/limits.conf同步配nginx soft/hard nofile 65536 - 内核参数调优：
net.core.somaxconn = 65535，fs.file-max = 2097152，避免底层限制反向卡住 Nginx
不复杂但容易忽略
