两个码，两条路

监控里同时冒出 403 和 502 的时候，我第一反应是靠直觉：403 像被拦，502 像后端挂了。方向大体没错，但具体动作差得很远。

403 是「拒绝」，有明确的主体在做决定；502 是「失败」，有明确的链路断在某处。找出主体和找出断点，是两种完全不同的工作。

403：先找谁在拒绝

403 一定来自某一层服务，不是网络。可能是应用的路由权限、Nginx 的目录配置、WAF 的规则、CDN 的地区策略。

看响应内容能缩小范围。错误页是防护产品的默认模板，就找防护；是框架的报错页，就查应用权限；是服务器默认页，就查目录和索引配置。

再看节点分布。全网 403，是统一策略；只有某地区或某运营商 403，更像按来源拦截。

有时 403 也来自源站前面的负载均衡，比如只允许特定网段访问。这类要去查安全组和访问控制列表，而不是应用代码。

宝塔拨测控制台：定时拨测任务、节点与告警配置

宝塔拨测控制台：定时拨测任务、节点与告警配置

502：先找哪一跳断了

502 说明网关是活的，它联系上游失败，或者上游给了它看不懂的东西。

常见原因分三类：后端进程没起来、端口配错、上游超时或崩溃。还有一种来自 CDN 的 502，源站其实没事。

这时候看分段耗时有帮助。TTFB 很短就 502，通常是连接被拒；TTFB 很长才 502，是上游处理超时。

后端如果是容器，还要看健康检查有没有把实例摘掉，导致网关手里没有可用的上游。

同一套外部观察

在宝塔拨测的控制台配 HTTP 监控，同时测首页和一个接口，观察状态码和响应时间。

首页 403、接口 502，说明前面有策略拦、后面有服务挂，两件事同时存在，得分开处理。

多地区多运营商节点一起看，能判断是一个区域的问题，还是全局问题。响应最快、最慢和平均也要看，最慢节点往往先暴露异常。

验证方式不一样

改访问策略之后，验证的是「该放行的能进、该拦的拦住」，用不同来源、不同路径各测一次。

修后端之后，验证的是「请求能正常返回 200」，还要看 TTFB 有没有回到正常水平。

两种改动别同时做，否则出了问题不知道是哪一边引起的。

该警惕的情况

403 突然从局部扩散到全网，可能是策略被误改；502 反复出现但每次节点不同，可能是上游多个实例不稳定；两种码交替出现，往往说明前面在拦、后面在挂，问题不止一个。

状态码只是入口，真正要回答的是「谁做的决定」和「哪一段断了」。把这两个问题分开，处理顺序自然就清楚了。