标签： 504 Gateway Time-out
-
个人博客出现 504 Gateway Timeout，排查发现服务器因恶意扫描和分布式爬虫导致严重过载。内存被过多的 PHP-FPM 进程耗尽，引发负载飙升。通过降低 PHP-FPM 进程数以适配硬件配置，在 Nginx 层面封禁恶意扫描 IP 及爬虫 IP 段，并重启 ECS 清理积压进程，最终解决了资源耗尽问题，恢复了服务正常响应。
-
本文解决了在前端基于 Nginx 反向代理至后端接口时出现的响应超时问题。在排查中发现前端请求响应时长为 1 分 6 秒并报错超时，而后端接口实际响应时长为 1 分 5 秒且未超时。针对此情况，调整了 Nginx 代理设置，将 3 个与超时相关的参数默认值从 60 秒统一调整为 300 秒。重启 Nginx 后再次请求，前端不再超时，成功获取约 1.4 分钟的响应结果。
-
本文解决了前端通过 Nginx 反向代理请求后端时出现 504 Gateway Time-out 的问题。经排查发现，代理地址为基于 FRP 的内网穿透网址导致请求无法正常到达。文中尝试修改 hosts 文件代理至本地环境验证连通性，随后通过调整 Nginx 配置，使后端监听 8000 端口。最终，Postman 请求与浏览器访问均恢复正常响应，问题得以解决。
-
在 Kubernetes 环境中遇到 504 Gateway Time-out 报错，尽管将相关参数调整为 300 秒，请求依然在 60 秒后超时。经排查，内部服务直接访问正常，但通过 NGINX 入口控制器访问时超时。最终参考官方文档在 Rancher 负载均衡的 YAML 中添加了三个 nginx.ingress 相关配置项，成功延长了超时时间，验证后请求不再报错，问题解决。
-
针对 Nginx 与 FastCGI 环境下日志表数据量达到 GB 级时，查询最后一页出现 504 Gateway Time-out 超时的问题，通过分析定位了本地环境与生产环境的配置差异。在本地增加 fastcgi_read_timeout 并调整 PHP 脚本最大执行时间后问题解决，但在生产环境中排查发现，由于请求经过 Kong 网关，超时原因出在网关层面而非后端服务，最终确认由运维人员处理网关配置。