nginx负载高主因非worker_connections不足，而是i/o卡顿、d状态进程堆积、php日志写入失败或gzip/缓存配置不当；需优先用top、iotop、ps查%wa和d进程，再清理日志、调优gzip与缓存。
宝塔面板Nginx负载高，真不是worker_connections没调大
直接调 worker_connections 基本无效，甚至会让问题更隐蔽。它只是单个 worker 进程能同时处理的连接数上限，不解决 CPU 被压满、磁盘 I/O 卡死、PHP-FPM 挂起重试这些真实瓶颈。你看到 Nginx 进程 %CPU 高但响应慢，ss -s 显示 established 连接数远低于配置值，就说明连接数根本不是瓶颈。
真正要盯的是：top 里 %wa（I/O wait）是否长期 >30%，iotop -o -P 是否显示某个 php-fpm 或 nginx 进程在狂刷磁盘，以及 ps aux | awk '$8 ~ /D/ {print $0}' 是否有一堆 D 状态进程卡在 I/O 上。
- 宝塔默认
worker_processes auto，低配机器可能派生过多 worker，反而争抢 CPU -
ulimit -n通常卡在 1024，不改系统级文件描述符限制，Nginx 启动会静默降级或报Too many open files - 静态资源没缓存、Gzip 配置漏
gzip_vary on或对图片重复压缩，都会把本可省下的 CPU 和带宽白白耗掉
为什么不用 Lua 模块做 CC 防护？因为宝塔默认不带 lua-nginx-module
宝塔面板安装的 Nginx 是精简版，不编译 lua-nginx-module，直接写 access_by_lua_block 会启动失败，报错 unknown directive "access_by_lua_block"。想用必须重装 Nginx 或手动编译，但代价是失去宝塔一键管理能力，后续升级、SSL 配置、反向代理都可能出问题。
更现实的选择是：用宝塔自带「网站防火墙」开启 CC 防护（基于 Nginx 的 limit_req），或配合 fail2ban 监控 access.log 抓高频 IP 封禁。Lua 方案只适合你明确掌控编译环境、且需要动态白名单/令牌桶等复杂逻辑的场景。
- 宝塔「网站防火墙」→「CC防护」里设的
limit_req zone=ccburst burst=5 nodelay，底层就是 Nginx 原生命令，无需 Lua - 若硬要用 Lua，得先确认
nginx -V 2>&1 | grep -o with-http-lua-module输出非空，否则所有配置都会被忽略 - 即便启用，
lua_shared_dict内存分配不当（如设太大）反而会引发内存碎片和 GC 压力，间接推高 CPU
limit_req 实现限流，参数设错比不设还危险
limit_req 不是加一行就完事。zone 名称拼错、burst 值设得过大、漏掉 nodelay，都可能导致请求排队堆积、超时雪崩，或完全不生效。宝塔后台生成的规则常把 burst 设成 200+，这在中小流量站上等于放行洪水。
一个安全的起点配置（放在 http 块）：
limit_req_zone $binary_remote_addr zone=ccburst:10m rate=10r/s;
server {
location / {
limit_req zone=ccburst burst=20 nodelay;
}
}
-
rate=10r/s表示每秒最多接受 10 个新请求，超出的进队列；burst=20是队列长度，别设超过 50 - 必须加
nodelay，否则排队请求会按固定间隔释放，用户感知为“卡顿”，而非“拒绝” - zone 名称（如
ccburst）必须全局唯一，且大小（10m）要匹配预估 IP 数量，10MB ≈ 支持约 16 万个独立 IP
CC 攻击没打中业务接口，却压垮了 PHP 日志写入
最常被忽略的一点：攻击者扫的是 /wp-login.php、/admin/login 这类不存在路径，Nginx 返回 404，但 PHP-FPM 仍会被触发（尤其开了 PATH_INFO 或伪静态规则），导致大量错误日志写入。单个 php_error.log 超过 100MB 后，每次写日志都要 fseek 定位，file_put_contents 反复失败触发重试循环，CPU 直接拉满。
- 清空日志后负载立刻回落，不是巧合——这是典型症状
- 在宝塔「网站」→ 对应站点 → 「PHP版本」→ 「日志」里，关掉「错误日志」或设为「不记录」，比加防护更立竿见影
- 检查 Nginx 配置里是否有类似
location ~ \.php$ { ... }无差别转发，应改为只匹配真实入口文件（如index.php）
真正卡住系统的，往往不是百万并发，而是几十个 D 状态进程死等磁盘，或一个 PHP 脚本反复打开 200MB 日志文件失败。别急着写 Lua，先跑一遍 ps aux | awk '$8 ~ /D/' 和 iotop -o -P —— 看见 D 进程，就别碰 Nginx 配置了，该查磁盘、该删日志、该修权限。
