nginx共享内存区耗尽时不会报错，而是静默丢弃新key，导致限流失效；需通过debug日志查“zone is full”、核对zone配置格式与大小，并结合$limit_req_status分析access.log确认漏放。
追踪 Nginx 共享内存访问异常，不能只盯着 error_log 里有没有“shared memory”字样——这类问题往往静默发生，错误日志里可能只显示限流失效、连接拒绝或请求被跳过，真正线索藏在日志行为模式、调试输出和配置一致性中。
重点查“limiting requests”但不报错的异常
当 limit_req_zone 或 limit_conn_zone 的共享内存区（zone）耗尽时，Nginx 不会写“zone full”，而是悄悄丢弃新 key，导致本该被限速的请求漏过。这时 error.log 中高频出现类似行：
- “limiting requests, excess: 1.000 by zone "xxx"”——若同一 client 反复出现相同 excess 值，说明它已存在，但 zone 无空间容纳其他 client
- 大量请求命中同一 zone 却无新增 key 记录（比如 IP 数远少于预期），暗示 zone 空间已饱和
必须开启 debug 日志才能看到真实状态
默认 error_log 级别完全不记录 zone 满载事件。临时启用 debug 才能捕获关键提示：
- 在 nginx.conf 中加：error_log /var/log/nginx/error.log debug;（仅诊断用，排查后务必改回 warn 或 error）
- 重载配置：nginx -s reload
- 搜索日志：grep "zone.*is full" /var/log/nginx/error.log，典型输出如：
limit_req: zone "perip" is full, failed to insert key "192.168.1.100"
核对配置中的 zone 定义是否合法且足够
很多“访问异常”其实源于 zone 配置本身无效或过小：
- 运行 nginx -t —— 若配置含 zone=xxx:（冒号后无大小）或 zone=xxx:0m，会报 [emerg] zero size shared memory zone，但该错误不会写入 error_log（发生在日志初始化前）
- 用 nginx -T | grep limit_ 查所有 zone 定义，确认格式为 zone=name:size（如 zone=ip:16m）
- 估算容量：IPv4 地址按 64–128 字节/key 计，10m zone 最多存约 8 万个独立 key；10 万活跃 IP 至少配 16m
联动 access.log 和 $limit_req_status 排查漏放行为
单看 error.log 无法判断限流是否真失效，需结合访问日志验证实际效果：
- 在 log_format 中加入 $limit_req_status，例如：
log_format main '$remote_addr – $request_time $limit_req_status'; - 观察 access.log：正常应有 hit（命中限流）、miss（未命中）、rejected（拒绝）等状态；若大量请求显示 miss 却本该被限，说明 zone 无法插入新 key
- 统计高并发时段的 client IP 分布，对比 zone 容量是否明显不足
