最近在维护一个电商网站时遇到了经典的“502 BAD GATEWAY”错误用户页面打不开订单提交失败整个业务几乎停摆。这可不是个小问题它直接关系到用户体验和公司收入。今天我就把这次从“崩溃”到“恢复”的完整实战排查过程记录下来希望能给遇到类似问题的朋友一些参考。问题初现与初步判断那天下午监控系统突然告警显示网站首页和核心交易接口的502错误率飙升。502错误意味着作为“网关”或“代理”的服务器比如Nginx在尝试将请求转发给后端的应用服务器时没有得到有效的响应。所以我的第一反应是后端应用服务出问题了。我立刻登录服务器检查了运行电商应用的服务进程发现它还在但CPU和内存使用率异常高响应极其缓慢。构建模拟环境定位根因为了不影响线上用户同时能清晰地复现和排查问题我决定在测试环境用Docker快速搭建一个模拟场景。这个环境包含了Nginx作为反向代理/网关以及多个后端的Web应用容器。我设计了三个典型的故障场景来模拟第一个是直接“杀死”一个后端应用容器模拟服务崩溃第二个是修改Nginx的upstream配置指向一个根本不存在的后端端口模拟配置错误第三个是在应用代码中模拟数据库连接池被耗尽导致新的请求一直等待最终超时。系统性排查“四步法”面对502不能盲目重启服务。我总结了一个排查流程这次实战也是按这个来的。 第一步检查网关日志。这是最直接的线索。我查看了Nginx的error log发现了大量的“connect() failed (111: Connection refused)”和“upstream timed out (110: Connection timed out)”记录。前者立刻让我想到了服务崩溃或端口不对后者则指向了服务进程还在但已经无法响应可能是死锁、资源耗尽。 第二步验证后端服务可达性。通过curl或telnet直接尝试连接后端应用服务器监听的端口。对于连接被拒绝的说明服务没起来或端口错误对于能连接但没响应的进入下一步。 第三步深入检查后端应用状态。登录到应用服务器查看应用进程的日志。在模拟数据库连接池耗尽的场景下我在日志里看到了大量的“Timeout waiting for a database connection”异常。同时使用netstat命令查看发现大量数据库连接处于ESTABLISHED状态但长期不释放验证了连接池耗尽的猜想。 第四步检查依赖服务与资源。数据库连接池问题引出了对数据库本身的检查。我查看了数据库服务器的连接数、负载以及慢查询日志发现确实存在一些未优化的复杂查询拖慢了响应导致应用层连接被长时间占用。针对性解决方案与自动化脚本针对排查出的不同原因修复措施也不同对于服务崩溃首先通过进程管理工具如systemd或supervisor重启服务。更重要的是建立健康检查机制。我在Nginx的upstream配置中增加了health_check指令并让后端应用暴露一个/health端点Nginx会定期检查自动将不健康的节点从负载均衡池中剔除。对于配置错误这属于人为失误。修复配置并重载Nginx即可。为了避免再次发生我们将Nginx配置纳入了版本控制系统任何修改都需要经过代码评审和自动化测试流程。对于数据库连接池耗尽这是最复杂的一个。短期措施是适当调大连接池的最大连接数并设置合理的超时和空闲连接回收策略。长期来看需要优化那部分导致慢查询的代码比如为查询添加合适的索引、重构复杂的联表查询。同时我写了一个简单的自动化检查脚本定时检测数据库连接使用率并在超过阈值时发出告警。经验总结与预防措施这次“救火”经历让我深刻体会到502错误很少是单一原因造成的它往往是系统脆弱性的一个表现。事后我们做了几件事来加固系统第一在所有关键服务上实现了完善的健康检查第二加强了监控不仅监控服务是否存活还要监控响应时间、错误率、数据库连接池使用率等关键指标第三定期进行故障演练就用Docker模拟各种异常场景提升团队的应急响应能力。整个排查过程从分析日志到模拟复现再到实施修复如果有一套顺手的工具和环境效率会高很多。最近体验了一下InsCode(快马)平台感觉它特别适合做这类技术验证和分享。比如我可以把上面提到的Docker模拟环境配置、排查脚本甚至是一个简化版的故障演示应用做成一个项目放在上面。它的在线编辑器可以直接编写和调整配置文件还能通过AI对话区快速咨询一些命令或配置的细节对于梳理排查思路很有帮助。最关键的是如果我想把这个故障模拟环境或者一个修复后的演示应用分享给同事看平台的一键部署功能就非常省心。不需要他们自己在本地安装Docker、配置网络点一下就能看到一个正在运行的服务状态直观地理解502错误产生的上下文和修复后的效果这对于团队技术复盘和新人培训来说太方便了。技术问题的解决思路和过程往往比结果更重要。能把一次棘手的线上故障转化为可复现、可讲解、可共享的经验对于个人和团队成长都是极大的财富。希望这篇笔记对你有用。