我的个人博客，今天突然响应 504 的排查解决流程
1、我的个人博客，今天突然响应 504 的排查解决流程。如图1
2、504 Gateway Timeout 说明 Nginx（或其他反向代理）等待后端（PHP-FPM）响应超时了。按以下顺序排查：
3、执行 top 命令，结果显示如下：问题很明确了，服务器严重过载。关键数据：负载 19.77（正常应该在 1-2 以下）、21 个进程在跑（太多了）、CPU 占用 87.4%、内存 1968MB 只剩 96MB 可用。这台是 2G 内存的小机器，已经被压垮了。如图2
top - 15:21:01 up 993 days, 3:25, 1 user, load average: 18.68, 19.55, 19.55 Tasks: 139 total, 20 running, 119 sleeping, 0 stopped, 0 zombie %Cpu(s): 88.0 us, 9.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 1.3 hi, 1.7 si, 0.0 st MiB Mem : 1968.6 total, 76.8 free, 1481.2 used, 410.6 buff/cache MiB Swap: 2048.0 total, 1816.6 free, 231.4 used. 262.7 avail Mem
3、退出 top，执行：ps aux –sort=-%cpu | head -20，看是什么进程在吃资源。原因找到了。15+ 个 PHP-FPM 子进程同时运行，每个占 110MB 内存，光 PHP-FPM 就吃掉了将近 1.6GB，服务器总共才 2GB 内存，直接撑爆了。
[root@iZ23wv7v5ggZ ~]# ps aux --sort=-%cpu | head -20 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND www 2097069 5.6 5.4 583184 109280 ? S 14:41 2:29 php-fpm: pool www www 2097086 5.6 5.3 583376 108720 ? R 14:43 2:23 php-fpm: pool www www 2097087 5.6 5.5 585100 111712 ? R 14:43 2:22 php-fpm: pool www www 2097088 5.6 5.4 583136 109108 ? S 14:43 2:22 php-fpm: pool www www 2097093 5.6 5.4 583132 109292 ? R 14:44 2:18 php-fpm: pool www www 2097094 5.6 5.4 583132 109344 ? R 14:44 2:18 php-fpm: pool www www 2097109 5.6 5.4 583372 109752 ? R 14:45 2:16 php-fpm: pool www www 2097125 5.6 5.4 583116 109200 ? R 14:47 2:09 php-fpm: pool www www 2097162 5.6 5.4 583324 109732 ? R 14:49 2:01 php-fpm: pool www www 2097187 5.6 5.4 583244 109848 ? R 14:53 1:48 php-fpm: pool www www 2097281 5.6 5.4 583124 109308 ? R 15:03 1:17 php-fpm: pool www www 2097299 5.6 5.4 583052 109328 ? R 15:05 1:09 php-fpm: pool www www 2097341 5.6 5.4 583116 109408 ? S 15:10 0:52 php-fpm: pool www www 2097671 5.6 5.5 583052 112304 ? R 15:18 0:24 php-fpm: pool www www 2097746 5.5 5.5 582836 111876 ? S 15:24 0:02 php-fpm: pool www www 2097747 5.4 5.5 582852 111988 ? R 15:25 0:01 php-fpm: pool www root 1007745 3.2 1.0 154220 20344 ? Ssl 2025 7458:44 /usr/local/aegis/aegis_client/aegis_12_81/AliYunDunMonitor root 2097357 0.5 7.7 516416 156836 ? RNs 15:11 0:04 /usr/libexec/platform-python /usr/bin/dnf makecache --timer root 1007719 0.3 0.3 99308 6048 ? Ssl 2025 756:25 /usr/local/aegis/aegis_client/aegis_12_81/AliYunDun [root@iZ23wv7v5ggZ ~]#
4、先紧急恢复，再查根因。先看看一共有多少个 PHP-FPM 进程。总计 17 个。
[root@iZ23wv7v5ggZ ~]# ps aux | grep php-fpm | grep -v grep | wc -l 17
5、编辑 PHP-FPM 配置，服务器只有 2GB 内存，修改为跑 5 个子进程，编辑文件 /usr/local/php/etc/php-fpm.conf。如图3
修改前：
pm = dynamic pm.max_children = 16 pm.start_servers = 10 pm.min_spare_servers = 8 pm.max_spare_servers = 16 pm.max_requests = 2048
修改后：
pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 pm.max_requests = 500
6、保存后重启：执行命令：如图4
[root@iZ23wv7v5ggZ ~]# service php-fpm restart [root@iZ23wv7v5ggZ ~]# sudo systemctl restart php-fpm
7、执行 top 命令，结果显示如下。内存恢复了，从 96MB 空闲涨到 1214MB，PHP-FPM 调整生效了。负载也在下降（19.77 → 7.97）。但 CPU 还是 85.4%，还有 8 个进程在跑，不正常。
top - 15:55:11 up 993 days, 3:59, 1 user, load average: 7.97, 11.01, 15.32 Tasks: 124 total, 8 running, 116 sleeping, 0 stopped, 0 zombie %Cpu(s): 85.4 us, 9.9 sy, 0.0 ni, 1.0 id, 0.0 wa, 1.0 hi, 2.6 si, 0.0 st MiB Mem : 1968.6 total, 1214.1 free, 302.7 used, 451.8 buff/cache MiB Swap: 2048.0 total, 1878.8 free, 169.2 used. 1469.1 avail Mem
8、 看看是什么在吃 CPU：执行命令：ps aux –sort=-%cpu | head -10 ，5 个 PHP-FPM 进程全部跑满了，说明有持续的大量请求在打我的服务器。
[root@iZ23wv7v5ggZ ~]# ps aux --sort=-%cpu | head -10 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND www 2098124 17.0 3.1 452724 63280 ? R 15:57 0:06 php-fpm: pool www www 2098123 16.8 2.9 452404 59716 ? R 15:57 0:06 php-fpm: pool www www 2098122 16.7 3.0 452868 61800 ? R 15:57 0:06 php-fpm: pool www www 2098125 16.7 2.9 452404 59712 ? R 15:57 0:06 php-fpm: pool www www 2098126 16.6 3.0 452732 60772 ? R 15:57 0:06 php-fpm: pool www root 1007745 3.2 1.0 154220 20160 ? Ssl 2025 7460:16 /usr/local/aegis/aegis_client/aegis_12_81/AliYunDunMonitor root 1007719 0.3 0.2 99308 5772 ? Ssl 2025 756:31 /usr/local/aegis/aegis_client/aegis_12_81/AliYunDun www 2040873 0.2 1.4 186640 29872 ? R Feb17 24:56 nginx: worker process root 754 0.1 0.2 555732 4480 ? Ssl 2023 2189:58 /usr/libexec/platform-python -Es /usr/sbin/tuned -l -P [root@iZ23wv7v5ggZ ~]#
9、查我的博客的虚拟主机的访问日志，博客的单个 IP 访问量不大，但 IP 段很集中（222.167.251.x、143.20.219.x、66.92.14.x），看起来像是分布式爬虫。但每个 IP 才 2 次请求，不太可能是它们把服务器打爆。
[root@iZ23wv7v5ggZ ~]# tail -200 /data/wwwlogs/www.shuijingwanwq.com_nginx.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
2 66.92.14.197
2 222.167.251.94
2 222.167.251.83
2 222.167.251.69
2 222.167.251.248
2 222.167.251.161
2 222.167.251.155
2 222.167.251.100
2 143.20.219.38
2 143.20.219.227
2 143.20.219.208
2 143.20.219.199
2 136.0.94.36
2 13.53.45.144
1 66.92.14.92
1 66.92.14.90
1 66.92.14.85
1 66.92.14.8
1 66.92.14.77
1 66.92.14.75
10、可能是其他虚拟主机的流量导致的。 查一下：看哪个日志文件最近写入最频繁。主要流量集中在我的博客（21MB 日志）和 access_nginx.log（7MB）。
<h1>看哪个日志文件最近写入最频繁</h1> ls -lt /data/wwwlogs/*.log | head -10 -rw-r--r-- 1 www root 21765969 Feb 25 16:01 /data/wwwlogs/www.shuijingwanwq.com_nginx.log -rw-r--r-- 1 www root 7330312 Feb 25 16:01 /data/wwwlogs/access_nginx.log -rw-r--r-- 1 www root 2189 Feb 25 15:47 /data/wwwlogs/error_nginx.log -rw-r--r-- 1 www root 48532 Feb 25 15:40 /data/wwwlogs/learn-php-app-0605-prod.wangqiang.store_nginx.log -rw-r--r-- 1 www root 213953 Feb 25 11:03 /data/wwwlogs/tym-jammerall.shuijingwanwq.com_nginx.log -rw-r--r-- 1 www root 0 Jun 16 2023 /data/wwwlogs/learn-php-app-0605-prod.shuijingwanwq.com_nginx.log -rw-r--r-- 1 www root 0 Jun 8 2023 /data/wwwlogs/fanxiapp-wangqiang-larabbs.shuijingwanwq.com_nginx.log
11、看 access_nginx.log 的流量来源，找到了！183.129.189.60 这个 IP 在疯狂刷我的服务器，200 条日志里它占了 177 条。先封掉这个 IP：
[root@iZ23wv7v5ggZ ~]# tail -200 /data/wwwlogs/access_nginx.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
177 183.129.189.60
10 121.196.223.20
2 77.83.39.167
2 45.153.34.187
2 38.46.221.123
2 204.76.203.69
1 47.99.50.249
1 43.156.202.34
1 43.130.31.17
1 43.130.16.212
1 205.210.31.11
12、在阿里云控制台的安全组里加一条规则：登录阿里云控制台 → ECS → 安全组 → 找到我实例对应的安全组 → 添加规则 → 方向选”入方向”、策略选”拒绝”、源地址填 183.129.189.60、端口范围填 -1/-1（全部端口）。如图5
13、看现在还有谁在大量请求，183.129.189.60 还在刷！安全组 规则可能没生效。立即用 iptables 封禁。如图6
[root@iZ23wv7v5ggZ ~]# tail -500 /data/wwwlogs/access_nginx.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10
473 183.129.189.60
10 121.196.223.20
3 81.29.142.6
2 77.83.39.167
2 45.153.34.187
2 38.46.221.123
2 204.76.203.69
1 47.99.50.249
1 43.156.202.34
1 43.130.31.17
[root@iZ23wv7v5ggZ ~]#
14、执行以下命令，返回 0，说明封禁成功了。
[root@iZ23wv7v5ggZ ~]# sleep 30 && tail -100 /data/wwwlogs/access_nginx.log | grep "183.129.189.60" | wc -l 73
15、由于 iptables 不管用，在 Nginx 层面封。直接在 access_nginx.log 对应的那个虚拟主机配置里封。先找到是哪个虚拟主机。然后直接编辑 nginx.conf，保存后，重启 Nginx。如图7
[root@iZ23wv7v5ggZ ~]# grep -rl "access_nginx.log" /usr/local/nginx/conf/ /usr/local/nginx/conf/nginx.conf [root@iZ23wv7v5ggZ ~]# vi /usr/local/nginx/conf/nginx.conf [root@iZ23wv7v5ggZ ~]# service nginx restart Redirecting to /bin/systemctl restart nginx.service [root@iZ23wv7v5ggZ ~]#
16、实时监控，等30秒看有没有新的。如果没有任何输出，说明封禁已经生效了。确认已经生效。但是，负载仍然很高，博客仍然响应 504
[root@iZ23wv7v5ggZ ~]# timeout 30 tail -f /data/wwwlogs/access_nginx.log | grep "183.129.189.60"
17、负载稳在 7.6，没有继续下降。还有其他东西在吃资源。看看现在的情况：
<h1>当前 PHP-FPM 进程状态</h1>
[root@iZ23wv7v5ggZ ~]# ps aux | grep "php-fpm" | grep -v grep | wc -l
6
<h1>实时看有没有那个 IP 的新请求</h1>
[root@iZ23wv7v5ggZ ~]# tail -20 /data/wwwlogs/access_nginx.log | awk '{print $4, $1}'
[25/Feb/2026:15:26:57 121.196.223.20
[25/Feb/2026:15:26:57 121.196.223.20
[25/Feb/2026:15:26:57 121.196.223.20
[25/Feb/2026:15:26:57 121.196.223.20
[25/Feb/2026:15:27:07 121.196.223.20
[25/Feb/2026:15:27:07 121.196.223.20
[25/Feb/2026:15:27:17 121.196.223.20
[25/Feb/2026:15:27:17 121.196.223.20
[25/Feb/2026:15:28:33 47.99.50.249
[25/Feb/2026:15:34:01 45.153.34.187
[25/Feb/2026:15:49:35 43.156.202.34
[25/Feb/2026:15:56:04 38.46.221.123
[25/Feb/2026:16:01:12 38.46.221.123
[25/Feb/2026:16:12:08 81.29.142.6
[25/Feb/2026:16:12:12 81.29.142.6
[25/Feb/2026:16:12:16 81.29.142.6
[25/Feb/2026:16:20:52 185.242.226.113
[25/Feb/2026:16:45:12 34.158.168.101
[25/Feb/2026:16:45:13 34.158.168.101
[25/Feb/2026:16:45:14 34.158.168.101
<h1>博客最近的请求</h1>
[root@iZ23wv7v5ggZ ~]# tail -20 /data/wwwlogs/www.shuijingwanwq.com_nginx.log | awk '{print $4, $1, $7}' | tail -10
[25/Feb/2026:16:56:34 143.20.219.229 /robots.txt
[25/Feb/2026:16:56:34 143.20.219.183 /tag/develop
[25/Feb/2026:16:56:34 222.167.251.252 /robots.txt
[25/Feb/2026:16:56:34 66.92.14.190 /robots.txt
[25/Feb/2026:16:56:34 222.167.251.15 /robots.txt
[25/Feb/2026:16:56:34 66.92.14.195 /robots.txt
[25/Feb/2026:16:56:34 136.0.94.155 /robots.txt
[25/Feb/2026:16:56:34 66.92.14.151 /robots.txt
[25/Feb/2026:16:56:35 143.20.219.77 /robots.txt
[25/Feb/2026:16:56:35 136.0.94.158 /robots.txt
<h1>我的服务器是几核的</h1>
[root@iZ23wv7v5ggZ ~]# nproc
1
[root@iZ23wv7v5ggZ ~]#
18、找到根因了。单核 CPU + 大量分布式爬虫。我的博客同一秒内被十几个不同 IP 同时请求，这些 IP 段（143.20.219.x、222.167.251.x、66.92.14.x、136.0.94.x）是分布式爬虫。单核机器根本扛不住。在 Nginx 里批量封这些爬虫 IP 段：
deny 183.129.189.60; deny 143.20.219.0/24; deny 222.167.251.0/24; deny 66.92.14.0/24; deny 136.0.94.0/24;
19、最后重启 ECS，然后在最近几天观察一下情况了。是否 504 还会出现不。问题已经解决了。总结一下我做的事情：
PHP-FPM max_children 从 16 降到了 5（适配单核 2GB）
Nginx 封了 5 个恶意 IP 段
重启 ECS 清掉了积压的进程
20、这次事故总结如下：
直接原因
IP 183.129.189.60 对服务器发起了恶意安全扫描，暴力探测 /core/static/ 路径下的敏感文件（settings.ini、secret.sql、database.json 等）。同时四个分布式爬虫 IP 段（143.20.219.x、222.167.251.x、66.92.14.x、136.0.94.x）在同一秒内大量并发请求我的博客。这些请求全部经过 PHP-FPM 处理。
根本原因
我的服务器是单核 CPU、2GB 内存，但 PHP-FPM 配置了 max_children = 16、start_servers = 10。每个 PHP-FPM 子进程占用约 110MB 内存，16 个进程 = 1.76GB，几乎吃光了全部 2GB 内存。这个配置在过去 993 天里刚好能撑住正常流量，但一直处于”临界状态”，没有任何余量应对突发流量。
雪崩过程
恶意扫描 + 爬虫流量涌入 → 16 个 PHP-FPM 进程全部被占满 → 内存耗尽，系统开始使用 swap → swap 在磁盘上，IO 变慢 → 每个请求处理时间变长 → 进程无法及时释放 → 新请求排队等待 → Nginx 等待 PHP-FPM 响应超时 → 返回 504 Gateway Timeout。CPU 负载从正常的 0.5 飙到 19.77，形成恶性循环。
解决措施
PHP-FPM max_children 从 16 降到 5，适配单核 2GB 的硬件配置。Nginx 层面封禁了恶意扫描 IP 和四个爬虫 IP 段，被封的请求直接返回 403，不再占用 PHP-FPM 进程。重启 ECS 清掉了积压的卡死进程。
经验教训
PHP-FPM 的进程数必须匹配服务器的硬件资源，单核 2GB 的机器最多跑 5 个进程。993 天未重启、未调整配置，长期处于资源临界状态是最大的隐患。服务器应该有基本的防护措施，比如 Nginx 限流（limit_req_zone）和恶意 IP 自动封禁，而不是裸跑等出事。
![执行命令：nginx -s reload，重新加载，报错：nginx: [emerg] could not build server_names_hash, you should increase server_names_hash_bucket_size: 32](https://www.shuijingwanwq.com/wp-content/uploads/2016/10/2-520x245.png)
近期评论