Nginx error_log 不直接记录“共享内存溢出”，但可通过 TLS 握手退化、缓存失效、限流绕过、debug 日志中的 shm_alloc failed 或 zone "XXX" is full 等间接线索识别，并需结合 ipcs、nginx -T 和系统指标交叉验证。
Nginx 的 error_log 本身不会直接记录“共享内存溢出”字样，但它能反映共享内存区（如 ssl_session_cache、proxy_cache、limit_conn_zone 等）因满载导致的异常行为链。关键不是等它报错，而是识别它留下的“间接证据”，再结合其他手段交叉验证。
error_log 中需重点捕获的共享内存溢出线索
-
TLS 握手退化相关日志
当ssl_session_cache满时，新会话无法缓存，强制走全握手（full handshake），这会显著增加 CPU 和内存开销，并可能在日志中留下痕迹：- 反复出现
SSL_do_handshake() failed或SSL_write() failed（尤其伴随Resource temporarily unavailable） - 大量
client SSL certificate verify error（非证书问题，而是握手流程异常中断所致） -
*xxx SSL_read() failed (SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca)类错误集中爆发，但客户端证书实际有效
- 反复出现
-
缓存模块拒绝服务信号
proxy_cache或fastcgi_cache共享内存满时，Nginx 无法新建缓存条目，但通常不报错；可观察：-
upstream cache miss频率异常升高（需配合$upstream_cache_status记录到 access_log） -
cache manager process X exited with code 0频繁重启（cache manager 负责清理，若反复退出可能因共享内存写入失败）
-
-
限流/连接限制失效表现
limit_conn_zone或limit_req_zone共享内存满后，新连接/请求将绕过限制：-
limiting requests, excess: X.XX日志突然消失，且并发连接数激增（需比对 stub_status 或/proc/PID/fd/数量） -
accept() failed (24: Too many open files)与limiting connections by zone日志并存 → 提示句柄耗尽 且 限流机制已失能
-
-
debug 日志中的内存分配异常
开启error_log ... debug;后，搜索以下关键词：-
shm_alloc failed（极少见，但一旦出现即明确指向共享内存分配失败） -
zone "XXX" is full（部分模块如nginx-module-vts或 OpenResty 的resty.limit.count会显式打印） -
ngx_slab_alloc_locked大量重复调用 +failed或超时返回
-
如何让 error_log 更有效地暴露问题
-
统一启用 debug 级别（临时）
error_log /var/log/nginx/error.log debug;
注意：仅用于排查期，日志量剧增，需控制时长并确保磁盘空间充足。
-
在 http 块中定义全局变量用于命中率统计
log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' 'ssl_reused="$ssl_session_reused" cache_status="$upstream_cache_status"'; access_log /var/log/nginx/access.log main;通过分析 access.log 中
ssl_reused="."（点号表示未复用）占比是否持续 >80%，反推ssl_session_cache是否长期满载。 -
配合 kill -USR1 触发共享内存状态输出（需 debug 日志支持）
执行kill -USR1 $(cat /var/run/nginx.pid)后，主进程会在 error.log 中输出类似：2026/07/09 02:15:22 [notice] 12345#12345: signal 30 (SIGUSR1) received from 67890 2026/07/09 02:15:22 [notice] 12345#12345: reconfiguring 2026/07/09 02:15:22 [notice] 12345#12345: using the "epoll" event method 2026/07/09 02:15:22 [notice] 12345#12345: start worker processes 2026/07/09 02:15:22 [notice] 12345#12345: start worker process 12346 2026/07/09 02:15:22 [debug] 12345#12345: SHM zone "SSL" used: 99.8% (10485760/10485760)
这类日志需开启 debug 级别才可见，是判断共享内存使用率最直接的依据。
必须联动的验证手段（单靠 error_log 不够）
-
检查共享内存实际使用情况
ipcs -m | grep nginx # 查看 key、size、nattch（附着进程数）、lpid（最后操作 PID）
确认是否多个 server 块重复定义同名 zone
运行nginx -T 2>/dev/null | grep -A2 "ssl_session_cache\|limit_conn_zone"，避免配置冲突导致共享内存被多次初始化或覆盖。对比系统级指标
若error_log中 TLS 相关错误激增，同时ps -o pid,rss,comm -C nginx显示 RSS 持续上涨、dmesg | grep -i "killed process nginx"出现 OOM 记录，则大概率是ssl_session_cache设置过大或命中率过低，引发堆内存持续分配而无法回收。
不复杂但容易忽略
