看到 502 Bad Gateway 时，安全组规则通常不是直接原因，因为该错误意味着请求已经通过了网络边界到达了网关或代理服务器，问题多出在后端服务无响应或代理配置错误。
先说结论：502 是应用层错误，重点排查后端服务状态和代理配置，而非网络连通性。
- 先确认后端服务进程是否存活且监听正确端口
- 先处理代理服务器到后端的连通性及超时设置
- 再验证错误日志中是否有 upstream 连接 refused 或 timed out 记录
命令速用版
以下命令用于快速定位服务状态和日志，根据实际服务名替换占位符：
# 检查后端服务是否运行
systemctl status
# 检查端口监听情况，确认是否监听在 0.0.0.0 而非 127.0.0.1
netstat -tulpn | grep
# 实时查看代理错误日志，观察 502 产生时的具体报错
tail -f /var/log/nginx/error.log 为什么会这样
安全组（Security Group）工作在网卡层面，主要控制 IP 和端口的通断。如果安全组拦截了流量，客户端通常表现为连接超时（Connection Timed Out）或连接被拒绝（Connection Refused），根本拿不到 HTTP 状态码。
502 Bad Gateway 是 HTTP 协议的状态码，意味着请求已经成功到达了你的负载均衡器或反向代理（如 Nginx），但代理服务器无法从后端应用获取有效响应。这通常是后端服务挂了、代理配置的上游地址错了、或者后端处理超时导致的。
分步处理
按照以下顺序排查，避免在安全组规则上浪费时间：
1. 确认后端服务状态
登录到部署应用的服务器，检查服务进程是否存在。如果服务崩溃或重启中，代理无法连接就会报 502。
2. 检查监听地址
使用 netstat 或 ss 命令查看服务监听的 IP。如果服务只监听了 127.0.0.1，而代理服务器尝试通过内网 IP 访问，连接会被拒绝。确保服务监听 0.0.0.0 或代理配置的特定内网 IP。
3. 排查内部安全组或防火墙
虽然外网安全组可能已放行，但服务器内部的防火墙（如 iptables、firewalld）或云厂商的内网安全组可能拦截了代理到后端的流量。在代理服务器上尝试 telnet 或 curl 后端服务的内网 IP 和端口，确认链路通畅。
4. 检查代理超时设置
如果后端处理业务逻辑耗时较长，而代理服务器的读取超时（read_timeout）设置过短，代理会主动断开并返回 502。适当调大代理配置中的超时时间。
怎么验证是否生效
完成调整后，不要只刷新浏览器，建议使用命令行工具验证：
curl -v http://your-domain.com观察返回的 HTTP 状态码是否变为 200。同时查看代理服务器的访问日志（access.log），确认状态码列是否不再出现 502。如果日志中后端响应时间（upstream_response_time）显著增加但未超时，说明服务已恢复但性能可能存在瓶颈。
常见坑
1. 本地防火墙干扰：云控制台的安全组放行了，但操作系统内部的 firewalld 或 ufw 未放行内网通信端口。
2. SELinux 限制：在 CentOS/RHEL 系统中，SELinux 可能禁止代理服务器发起网络连接，导致无法连接后端。
3. 后端重启期间：服务重启过程中端口暂时关闭，此时请求会报 502，属于正常现象，需配合健康检查配置规避。
4. 代理配置错误：检查代理配置中的 upstream 地址是否写错了端口或 IP，这是新手最容易犯的配置错误。