AWS香港节点 CloudFront 报 502/503 Error？源站（Origin）连接超时与 SSL 证书排查

CloudFront 报 502/503 Error 时，先别急着改缓存

CloudFront 出现 502/503，真正麻烦的地方通常不在前端分发，而在源站（Origin）到 CloudFront 这条链路。实际排查时，最容易踩坑的是把“源站连接超时”和“SSL 证书问题”混在一起看，结果改了半天缓存规则、路径规则，错误还是在。

先判断是“连不上源站”，还是“连上了但握手失败”，再看源站本身是不是已经扛不住请求。

CloudFront 报 502/503 Error 的排查顺序

1. 先确认错误是 CloudFront 生成的，还是源站返回的

看返回头和源站日志。若源站日志里根本没有这次请求，通常说明问题出在 CloudFront 到源站之间；如果源站收到了请求，但回的是 5xx，那就先修源站应用。

• AWS香港节点 查看是否有 x-cache、x-amz-cf-id 等响应头。
• 对照源站访问日志，确认请求有没有真正到达。
• 不要只看浏览器报错页面，页面内容本身往往不够准确。

2. 优先排查“源站连接超时”

503 很多时候不是 CloudFront “坏了”，而是源站响应太慢或直接超时。尤其是迁移到海外机房、跨区域访问、源站前面又套了一层负载均衡时，链路中的任何一环变慢，都会把问题放大。

• 检查源站端口是否真正开放，80/443 是否被安全组、防火墙、WAF 拦住。
• 如果源站前面是 ALB/NLB/反向代理，要看代理到后端的超时设置是否过短。
• 确认后端服务不是“能连上但一直卡住”，这类情况最容易被误判为网络问题。
• 当接口本身就慢时，先压缩数据库查询、外部 API 调用和文件读取，再谈 CDN 配置。

3. 再查 SSL 证书，重点不是“有没有证书”，而是“证书能不能被 CloudFront 接受”

CloudFront 到源站走 HTTPS 时，常见错误不是证书完全没有，而是证书细节不对。很多人以为只要把证书装上去就行，实际上域名、链路、主机名和协议版本都要匹配。

• 证书域名不一致：源站证书签的是 www.example.com，但 Origin 填的是另一个域名或 IP。
• 证书链不完整：少了中间证书，部分环境能访问，CloudFront 侧却握手失败。
• SNI/Host 头不一致：源站有多证书或多站点，CloudFront 发出的主机名和证书绑定域名对不上。
• TLS 版本过低：源站只支持旧协议，握手会直接失败。
• 自签证书或过期证书：这种情况在测试环境常见，上线后很容易直接变成 502。

4. 检查 CloudFront 的 Origin 配置，不要只改源站

AWS香港节点 有些错误其实是配置方向错了，不是源站本身坏了。

• Origin Protocol Policy 是否和源站实际支持的协议一致。
• Origin Domain Name 是否填写了真正应该访问的域名，而不是随手写的内部地址。
• 如果源站依赖 Host 头做虚拟主机路由，CloudFront 是否正确转发了 Host。
• 是否启用了合适的超时设置，避免动态接口刚好压线就被判定失败。

5. 看源站本身是不是已经过载

503 还有一种典型情况，是源站并没有“断”，但已经扛不住请求了。这个问题在活动页、海外促销、图片热链、批量下载这些场景里很常见。CloudFront 只是把源站的真实状态暴露出来。

• CPU、内存、连接数、线程池是否已满。
• 数据库连接池是否打满，导致接口排队。
• 应用是否做了限流，触发后直接返回 503。
• 上游依赖，比如对象存储、缓存、第三方接口，是否在拖慢整体响应。

业务场景里最容易误判的几种情况

AWS香港节点 海外站点刚上线

很多团队会先把 CloudFront 接到新源站，再逐步切 HTTPS。这个阶段最容易出现证书不匹配、DNS 未完全生效、源站防火墙只放行旧入口地址的问题。表现上像 CloudFront 报错，实际是新链路还没收口。

AWS香港节点 从 HTTP 切到 HTTPS

只要切协议，就要同时检查证书、Host 头、源站监听端口和后端回源规则。只改一个地方，往往会出现“浏览器能打开首页，但图片、接口、静态文件随机 502”的情况。

活动页或大促流量上来后

如果平时正常、流量一上来就 503，优先看源站容量，不要先怀疑 CDN。CloudFront 能缓解回源压力，但前提是缓存策略、静态资源拆分和接口限流先做好。

多地区访问同一个源站

跨境业务里，延迟和握手耗时更明显。源站如果部署在离用户过远的区域，或者前面又套了多层代理，超时会被放大成 502/503。

账号、实名认证、企业认证、支付与风控：别让开通阶段卡住排查

AWS香港节点 如果你是在 AWS 国际站或类似国际云环境里新开 CloudFront 环境，很多问题并不是技术故障，而是账号侧没准备好。实际操作里，账号购买、实名认证、企业认证、充值续费、支付方式和风控审核，都会影响你能不能顺利创建分发、申请证书、扩容资源。

• 支付方式：先确认账单卡、预授权和扣款都能正常走通，不然你以为是回源失败，实际是资源创建没成功。
• 企业认证：资料不一致时，审核容易反复；测试环境迁移到正式环境前，先把账单信息和公司主体整理好。
• 风控审核：新账号、异地登录、频繁更换支付方式，都可能触发限制，导致分发、证书或相关资源创建失败。
• 资源限制：分发数量、证书数量、日志存储、流量带宽、源站数都要提前看配额，不然业务一上线就碰到上限。
• 成本控制：CloudFront 本身不是只看“能不能用”，还要看回源次数、日志、跨区域流量和错误重试带来的额外成本。

什么时候先处理账号侧，什么时候先处理技术侧

• 如果你连分发都创建不了，先看支付、风控和权限。
• 如果分发已生效但访问报 502/503，优先查源站与证书。
• 如果只是在测试环境反复失败，先确认配额、证书位置和账单状态，再继续改配置。

常见错误清单

• 把证书装在了错误的域名上，Origin 访问的主机名和证书不一致。
• 只补了服务端证书，忘了中间证书链。
• 源站端口开放了，但负载均衡或反向代理的超时太短。
• 源站应用已经返回 503，却被误判为 CloudFront 故障。
• 刚开通账号就急着上线，结果支付、审核、配额还没完全就绪。
• 为了省成本把缓存时间调得过低，导致回源过于频繁，源站被打满。

FAQ

CloudFront 报 502 和 503，优先怀疑哪个？

如果是 HTTPS 源站、刚切证书、刚改域名，优先怀疑 502；如果是流量上来后、接口变慢、源站压力大，优先怀疑 503。

源站证书是自签名的，能直接给 CloudFront 用吗？

实际排查里，这种配置经常出问题。生产环境建议使用 CloudFront 能接受的受信任证书，并保证域名、链路和主机名一致。

只改缓存规则能解决 502/503 吗？

通常不行。缓存规则只能缓解回源压力，不能修复证书握手失败，也不能让一个已经超时的源站突然变快。

需要先重建 CloudFront 分发吗？

一般不建议一上来就重建。先看源站日志、证书、超时和 Origin 配置。重建往往只会拖慢排查，还可能引入新的成本和配置遗漏。

一个更稳妥的处理顺序

1. 先确认错误是 CloudFront 到源站链路问题，还是源站自己返回的 5xx。
2. 再查 SSL 证书：域名、链、协议、SNI、Host 头是否一致。
3. 然后看超时和负载：源站是否慢、是否满、是否被限流。
4. 最后再回头检查账号、权限、配额、支付和风控状态，避免排查方向跑偏。

如果你现在还在测试阶段，建议先把账号、付款方式、企业资料和配额一次性确认好，再上线 CloudFront。这样一旦出现 502/503，你能把精力集中在源站连接和证书上，而不是在开通流程里来回打转。