经过 Nginx、网关或 CDN 后访问异常，如何判断问题在哪一层？
简化版
经过代理或 CDN 后访问异常，要把链路拆成客户端、DNS/CDN、边缘节点、回源链路、网关/Nginx、后端服务几层分别验证。看状态码、响应头、请求 ID、代理日志、回源日志和后端日志。关键是区分“边缘直接返回”还是“回源后返回”。
详细版
排查 CDN/代理问题时，先确认 DNS 解析到了哪个节点，再用 curl -v 看响应头和状态码。Via、X-Cache、Server、请求 ID 等头可以帮助判断响应来自 CDN、网关还是后端。
常见问题包括：CDN 缓存旧内容、回源 Host 错误、源站防火墙拒绝 CDN IP、Nginx 超时、请求体过大、Header 被代理丢失、HTTPS 在 CDN 和源站之间配置不一致。排查要拿同一个请求 ID 贯穿边缘日志、网关日志和应用日志。
完整版教学
一、代理链路为什么容易误判
用户访问的地址可能不是直接到应用，而是经过 CDN、WAF、负载均衡、Nginx、API 网关，最后才到服务。每一层都可能返回错误。
browser -> CDN/WAF -> LB -> Nginx/API Gateway -> app用户看到 502，不等于应用一定返回了 502。可能是 CDN 回源失败，也可能是 Nginx 连不上 upstream。
二、先判断响应来自哪一层
用 curl -v 或浏览器 Network 看响应头。很多代理会加 Via、X-Cache、X-Request-Id、Server 等头。虽然这些头不完全可靠，但能提供线索。
curl -v https://www.example.com/apiX-Cache: HIT
Via: cdn-edge
X-Request-Id: abc123如果 X-Cache: HIT，说明请求可能没到源站。此时查应用日志查不到，是正常现象。
三、CDN 缓存问题怎么查
CDN 可能缓存了旧内容、错误状态码或错误的 CORS 响应头。动态接口如果缓存策略错，可能把用户 A 的响应给用户 B。
Cache-Control: public, max-age=3600
Vary: Origin排查时看 Cache-Control、Age、ETag、X-Cache，并尝试带 cache-busting 参数或直接访问源站对比。动态私有接口通常不应被公共缓存。
四、回源问题怎么查
CDN 到源站也需要 DNS、TLS、Host、端口、防火墙和路由。回源 Host 配错时，源站可能返回默认证书、默认站点或 404。
client host: www.example.com
origin host header: origin.example.internal源站安全组还可能只允许部分 CDN 回源 IP。如果 CDN 节点扩容或变更 IP 段，旧白名单可能导致部分地区失败。
五、Nginx 和网关常见错误
Nginx 的 502 常见于 upstream 连接失败、连接被 reset、后端返回非法响应。504 常见于 upstream 超时。413 是请求体过大，414 是 URI 太长。
| 状态码 | 常见代理层含义 |
|---|---|
| 502 | upstream 错误/连接失败 |
| 504 | upstream 超时 |
| 413 | 请求体超过限制 |
| 429 | 网关限流 |
| 403 | WAF/鉴权/规则拒绝 |
这些状态码要结合代理日志判断，不能只看浏览器页面。
六、Header 丢失和协议变化
代理可能修改或丢弃 Header，例如 Host、Authorization、X-Forwarded-For、X-Forwarded-Proto。后端依赖这些头做鉴权、生成回调地址或判断 HTTPS 时，就会出问题。
client HTTPS -> proxy HTTP -> app
missing X-Forwarded-Proto -> app thinks http常见表现是登录态异常、回调 URL 变成 http、真实 IP 获取错误、跨域判断错误。
七、请求 ID 和分层日志
复杂链路必须有请求 ID。客户端报错时，拿同一个 request id 去查 CDN、网关、Nginx 和应用日志，才能知道请求走到了哪一层。
X-Request-Id: abc123
CDN log -> Nginx access log -> app log没有请求 ID，只能靠时间、IP、路径模糊匹配，排查成本会高很多。
记忆钩子：代理链路排查先问“这个响应是谁生成的”，再问“请求有没有到下一层”。
八、常见误区与追问
- 误区：看到 502 就一定是应用代码报错。 502 常常是代理连不上 upstream 或收到非法响应。
- 误区：CDN 命中缓存说明源站没问题。 命中缓存时请求可能根本没到源站。
- 误区：直接访问源站正常就代表 CDN 链路正常。 回源 Host、证书、防火墙、缓存规则仍可能有问题。
- 追问：如何判断请求是否到达应用？ 查应用日志或用请求 ID 串联各层日志。
- 追问：为什么部分地区异常？ 可能是不同 CDN 节点、运营商路径或回源 IP 白名单差异。
- 追问：Header 丢失会导致什么？ 鉴权失败、真实 IP 错误、HTTPS 判断错误、跨域错误。
- 追问：如何绕过 CDN 验证源站？ 直接访问源站 IP/域名并手动设置 Host，但要注意证书和访问控制。
九、加强记忆
CDN/代理链路排查要分层：客户端看到的不是后端真相，响应可能来自 CDN 缓存、WAF、网关、Nginx 或应用。先用响应头和请求 ID 判断响应来源，再查缓存、回源、代理错误码、Header 转发和应用日志。能把“边缘返回”和“回源返回”分清，排查效率会高很多。