AWS EC2部署的Magento1.9出现524超时错误常规排查无效求解决方案

Cloudflare侧排查 #

• 确认Cloudflare源站超时配置：默认触发524错误的阈值为100秒，可临时调至最高300秒观察是否缓解，同时检查WAF规则、速率限制规则是否存在误拦截，导致正常请求被丢弃
• 查看Cloudflare流量分析日志：确认是否存在未被拦截的CC攻击、恶意爬虫流量，大量异常请求占满源站连接池
• 本地绑定hosts跳过Cloudflare直接访问EC2公网IP，验证是否仍出现超时问题，快速定位故障发生在Cloudflare到源站链路还是源站本身

EC2基础设施与网络层排查 #

• 检查AWS安全组、NACL规则的丢包情况，查看CloudWatch metrics中的网络入站/出站丢弃包计数，确认是否存在异常连接拒绝
• 执行ss -s查看服务器当前TCP连接总数量、TIME_WAIT/ESTABLISHED状态占比，确认是否出现连接耗尽的情况
• 若使用了AWS ELB，查看负载均衡的健康检查状态、后端连接数指标，确认是否为负载均衡层连接耗尽导致超时
• 查看AWS Personal Health Dashboard，确认EC2所在可用区是否存在官方通报的网络故障

服务与应用层深层排查 #

• 排查Apache配置：查看maxRequestWorkers参数是否设置过低，导致大量请求排队超时，同时查看错误日志/var/log/httpd/error_log定位具体报错
• 排查MySQL性能：执行show processlist查看当前运行的所有查询，是否有慢查询持续累积；开启慢查询日志记录执行时长超过2秒的查询，排查是否存在Magento未优化的索引、统计类查询
• 检查Magento消息队列执行状态，确认是否有大量堆积任务持续占用数据库连接
• 若使用PHP-FPM，检查pm.max_children配置是否足够，进程耗尽会导致请求排队超时
• 执行iostat -x 1 5查看磁盘IO使用率，即使磁盘剩余空间充足，也可能出现IO阻塞导致响应超时

临时缓解验证方案 #

• 临时开启Cloudflare「我已遭受攻击」模式，过滤大部分恶意流量观察业务是否恢复
• 临时配置Cloudflare全页缓存规则，降低源站请求压力
• 临时调大Apache、MySQL的最大连接数配置，避免连接被占满

内容的提问来源于stack exchange，提问作者Anj