背景
一条链路：拨测平台 → 公网反代 → 内网穿透隧道 → 源站应用。
今天这条链路上的拨测全红了。先报 403，修完变 503。两个错误码，两个完全不同的根因，但有个共同点——都不在服务端。
第一幕：403 之谜
排查：一层层排除
先画链路图，然后逐层验证：
| 层 | 验证结果 |
|---|---|
| 公网反代 nginx 配置 | 本机直测 8 个站点全 200/302，没有 403 |
| 面板 WAF | 排除——它的拦截页 1321 字节，实测 403 是 552/150 字节，对不上 |
| 禁海外规则 | 排除——返回的是 444 不是 403，且拨测 IP 全在国内列表里 |
| fail2ban | 排除——当时它的 jail 是空的，根本没生效 |
| 内网穿透隧道 | 排除——隧道端口全部可达，链路通 |
排查一圈，服务端每一层都干净。403 从哪来的？
真相：面板里的一个开关
最后是用户自己在面板里翻出来的——反向代理设置里有个「IP 白名单」标签页，而且它有个非常隐蔽的默认行为（面板自己都标了红字提醒）：
设置 IP 白名单后会默认禁止除白名单以外的所有 IP 访问
也就是说：哪怕白名单是空的，只要这个模式被触发过，就等于拒绝所有人。
而 nginx 配置文件里根本查不到它——这个逻辑在面板的代理模块内部，和 nginx 原生的 allow/deny 是两套独立体系，配置文件位置也不同。所以我在 shell 里 grep 配置文件，怎么都抓不到。
教训：带面板的机器排查 403，第一站应该看面板自己的代理/防护设置，而不是只看 nginx conf。
第二幕：503 来袭
白名单去掉，403 消失。紧接着——拨测报 503，5 分钟内集中爆发 437 条。
排除法定位
- 503 页面的响应头带着一套安全头 → 说明是容器内的 nginx 发的
- 应用侧日志：0 条记录（请求根本没到应用）
- 时间分布：全部集中在几分钟内，之后自愈
并发压测复现（关键手段）
瞬时爆发的错误抓不到现场，就用压测复现：
| 并发数 | 结果 |
|---|---|
| 20 | ✅ 全 200 |
| 40 | ⚠️ 一半 503 |
| 60 | ❌ 全 503，且越压越糟 |
阈值浮出水面——硬性并发上限。
根因：容量 + 熔断，两层叠加
第一层（源站容量）：应用容器的 PHP-FPM 配置是 max_children=5——只有 5 个并发进程。拨测 60 并发打过来，瞬间打满。
修复：调到 max_children=60（按 worker 单进程 33MB 算，60 进程约 2GB，宿主 12G 可用，余量充足），平滑重载生效。调完后 20 并发稳过。
第二层（反代熔断）：调完 fpm 后，40 并发仍有一半 503，60 并发还是全挂——而且连串行单发都 503。
这说明瓶颈已经不在源站了：反代对并发突刺的熔断被触发——upstream 探测失败 → 全站 503（连正常请求一起拒）→ 几十秒后自愈。
这个熔断阈值在反代机器上，不在源站。
复盘：两个幽灵，一个共同点
| 403 | 503 | |
|---|---|---|
| 表象 | 所有 IP 被拒 | 拨测大量失败 |
| 根因 | 面板代理模块的白名单开关 | fpm 容量 + 反代熔断 |
| 位置 | 反代机（面板层） | 源站（容量）+ 反代机（熔断） |
服务端代码、应用日志、nginx 配置全程干净——两个问题的根因都在链路的前半段。
排查方法沉淀：
- 先画链路图：拨测→反代→隧道→源站，每跳都可能返回自己的错误码
- 用响应体指纹定位拦截方：不同层返回的错误页大小/响应头不同（面板页 1321B、nginx 默认页 552B、容器页 190B 带安全头）——比只看状态码准得多
- 瞬时故障用压测复现：抓不到现场就制造现场，阈值自然浮出（20 过 / 40 半 / 60 全挂）
- 同秒混合成功失败 = 容量问题（谁抢到 worker 谁成功）；确定性全拒 = 规则问题
- 带面板的服务器，面板设置优先级高于 nginx conf——两套体系，容易漏
总结
排障最耗时间的不是修，是确认问题不在你正在看的地方。
今天在两个错误码上绕了远路，但每一层的排除都是必要的——正因为把服务端三层都验证干净了，才能确定"幽灵"在链路前半段。
以及一个反复出现的道理：拨测、监控、告警这类"自己人"，永远要先加进白名单。反爬配置、限流规则、IP 白名单上线前，先想想自家拨测从哪个 IP 来。
本文已脱敏，不含真实域名、IP、客户信息或系统内部标识。