Caddy配置简单，排查却仍要分层。用户到Caddy的HTTPS可能完全正常，而Caddy到上游应用连接失败；自动证书签发成功，也不代表反向代理的Host、路径和上游TLS配置正确。先把“入口证书”和“上游连接”拆开。
请求链路的两段TLS
| 链路 | 证书由谁提供 | 重点检查 |
|---|---|---|
| 客户端到Caddy | Caddy站点证书 | 域名、ACME、监听和TLS策略 |
| Caddy到HTTPS上游 | 上游服务证书 | SNI、CA、主机名和客户端证书 |
| Caddy到HTTP上游 | 无TLS | 仅适合受控网络并评估风险 |
自动HTTPS失败先查什么
确认域名A/AAAA记录指向正确入口，公网可达挑战需要的端口，系统时间正确，并检查CAA记录与证书颁发机构限制。多实例同时申请、频繁删除存储或不断重试可能触发限流。不要因为申请失败就改用来源不明证书。
DNS挑战为什么还需要API权限
DNS-01通常通过DNS提供商API创建TXT记录。凭据应只授予必要区域和记录权限，存放在环境Secret中，不进入Caddyfile或公开日志。DNS传播与权威服务器不一致也会造成验证超时。
502时如何判断上游问题
查看Caddy日志中的上游地址、拨号、TLS和重置错误。从Caddy实际运行的主机或容器测试上游DNS和端口。宿主机能访问不代表Caddy容器能使用相同localhost或内部服务名。
上游Host为何影响路由
部分上游按Host选择虚拟站点。Caddy转发的Host若与上游期望不一致，可能返回404或错误站点；HTTPS上游的SNI和HTTP Host还可能需要协调。应明确上游应用契约，不要一律覆盖。
自签上游证书怎样处理
应为Caddy提供受控内部CA，并保证证书主机名与连接目标匹配。跳过上游TLS验证会让Caddy无法确认服务身份，不适合作为长期方案。证书轮换应验证所有Caddy实例都加载新CA。
健康检查应验证什么
主动检查可帮助摘除故障上游，但检查路径、Host和状态必须正确。过深的检查会因数据库短时抖动把所有上游摘除；只检查TCP又可能把业务失败节点判健康。可以分为轻量Readiness与独立深度监控。
真实客户端IP怎么配置
Caddy前还有CDN或负载均衡时，直接连接来源是上一层代理。只有明确配置可信代理范围，才能使用其Forwarded或XFF信息。应用入口若可被绕过，攻击者可以伪造头。
多层解析原则见Forwarded、X-Forwarded-For与可信代理链。
WebSocket和流式响应看哪些参数
WebSocket连接会长期存在，需协调各层空闲超时和心跳。SSE需要及时把小块数据发给客户端，缓冲和压缩可能增加延迟。主页面正常不代表长连接稳定，应保持测试超过常见空闲时间。
配置变更怎么安全上线
先格式化和验证配置，再使用平滑Reload，保留旧配置和证书存储。多实例环境要同步配置版本，避免一部分节点信任新上游CA、另一部分仍使用旧值，造成随机失败。
排查顺序
- 记录Caddy版本与生效配置；
- 区分入口TLS和上游连接；
- 检查DNS、ACME挑战与证书存储；
- 从Caddy环境验证上游DNS、TCP和TLS；
- 核对Host、SNI和健康检查；
- 验证真实IP、WebSocket和SSE；
- 平滑Reload并观察多实例一致性。
结论
Caddy反向代理的自动化减少了配置量，但没有消除网络层次。入口证书、上游TLS、真实IP和长连接分别验证，才能准确解释自动HTTPS成功后仍出现的502或业务异常。
