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 自动封禁，而不是裸跑等出事。
Linux 服务器运维、部署与线上故障排查
如果你的网站或后端服务部署在 Linux 服务器上，遇到访问异常、Nginx 配置问题、MySQL / Redis 异常、Docker 服务不可用、磁盘占满、CPU / 内存过高等问题，可以联系我做一次远程排查。
适合以下场景：
✅ 网站打不开或访问不稳定
✅ Nginx / PHP-FPM 配置异常
✅ MySQL / Redis 性能或连接问题
✅ Docker 服务部署与维护
✅ 服务器迁移与环境配置
✅ CPU / 内存 / 磁盘异常排查
服务内容：
✅ Linux 环境检查
✅ 网站部署与迁移
✅ Nginx / PHP-FPM / MySQL / Redis 排查
✅ Docker 配置与维护
✅ 服务器性能分析
✅ 长期远程运维支持
如需咨询，请联系我，并注明：Linux 运维咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
评论
2 条对“我的个人博客，今天突然响应 504 的排查解决流程”的回复
[…] 我的站点 http://www.shuijingwanwq.com 是一个基于 WordPress 的内容站，网页数量约 2 万篇，日均访问量逐步上升。服务器采用阿里云 ECS（1核2GB），Web环境使用 OneinStack（Nginx + PHP-FPM + Redis + 阿里云 RDS MySQL）。网站一直运行平稳，直到某天晚上突然出现大面积 504 Gateway Time-out，后台尤其缓慢，几乎无法操作。其实前段时间也遇见过同样的问题，也做了初步的优化：我的个人博客，今天突然响应 504 的排查解决流程 […]
[…] My site http://www.shuijingwanwq.com is a WordPress-based content site with about 20,000 pages, and its daily traffic has been gradually increasing. The server uses Alibaba Cloud ECS (1 core, 2GB), and the web environment uses OneinStack (Nginx + PHP-FPM + Redis + Alibaba Cloud RDS MySQL). The site had been running smoothly until one night when widespread 504 Gateway Time-out errors suddenly occurred. The backend was particularly slow and almost impossible to operate. I had actually encountered the same issue a while ago and performed some initial optimization: Troubleshooting process for my personal blog suddenly responding with 504 today […]