502、504 与 HTTPS 故障怎么查：从 DNS 到应用的分层排错

先记录现象，别第一步就重启

重启有时能恢复服务，却会清掉最有价值的瞬时状态，也让你不知道问题在哪里。先记录故障时间、域名、状态码、是否所有页面受影响、最近一次发布和不同网络的表现。保存响应头和相关日志，再开始处理。 502 通常表示代理无法从上游获得有效响应，504 更偏向上游在期限内没有完成，TLS 错误则发生在进入 HTTP 应用之前。它们可能互相关联，但排查顺序应从外到内。

第一层：DNS 是否指向正确入口

dig +short A www.example.com
dig +short AAAA www.example.com

核对结果是否为当前服务器。错误或陈旧 AAAA 记录会让一部分用户走到不存在的 IPv6。再从不同网络测试，区分本地 DNS 缓存与权威记录问题。若域名刚变更，查看 TTL，不要频繁来回修改。

第二层：80/443 与 TLS 是否可达

用 curl -Iv https://www.example.com 查看连接、证书主机名、有效期和握手错误。检查云安全组、UFW 和 Caddy 是否监听 80/443。证书签发失败时查看 Caddy 日志中的具体挑战错误，确认 DNS 已到当前服务器且端口没有被另一进程占用。 浏览器显示证书不受信任时，不要让用户继续访问。确认系统时间、完整证书链、域名匹配和代理前是否还有 CDN。已有 HTTPS 常见故障排查 提供更基础步骤。

第三层：Caddy 配置是否把请求送到正确上游

sudo caddy validate --config /etc/caddy/Caddyfile
systemctl status caddy --no-pager
journalctl -u caddy --since '20 minutes ago' --no-pager

核对域名站点块、路径匹配和 reverse_proxy 地址。容器场景中，127.0.0.1 的含义取决于 Caddy 在宿主机还是容器；上游写错网络空间是常见 502 原因。最近刚改配置时，与备份做差异比较，不要继续叠加试探性修改。

第四层：绕过代理直接请求上游

curl -v --max-time 10 http://127.0.0.1:3000/health
ss -lntp | grep ':3000'
systemctl status myapp --no-pager

本地请求也失败，问题在应用或更深层；本地成功而外部 502，则集中检查代理地址、协议、Host、路径和网络。端口没有监听时看服务启动日志，别先改防火墙，因为内部回环请求不经过公网入口。

第五层：应用是崩溃、阻塞还是依赖超时

查看故障时间附近日志、重启次数、CPU、内存、磁盘和 OOM。启动后立即退出通常是配置、权限或端口冲突；进程存在但请求超时可能是事件循环阻塞、连接池耗尽、磁盘 I/O 或下游 API。 504 不应先简单增大代理超时。若请求本来应在一秒完成，延长到一分钟只会让用户等待更久并占满连接。先找慢在哪里，再决定是优化、异步任务还是合理调整超时。

第六层：数据库与磁盘

检查数据库是否可连接、连接数、锁、慢查询和磁盘剩余。SQLite 所在目录无写权限或磁盘满，可能让应用读页面正常、写操作失败；PostgreSQL 连接池耗尽则会让新请求排队。此时保护数据优先，不要在未知状态下强制删除锁文件或数据库文件。

修复后同时验证与记录

从外部 HTTPS、代理、本地健康和关键业务四层重新检查，确认监控恢复。记录根因、触发条件、证据、修复和防复发动作。若只是重启恢复但根因未知，事件仍是未完成状态。 下一篇把部署、监控和排错固化为日常制度：补丁、容量、故障记录与恢复手册。