403 和 503：同一条链路上的两个幽灵

Thu, 10 Sep 2026 18:40:00 +0800

背景

一条链路：拨测平台 → 公网反代 → 内网穿透隧道 → 源站应用。

今天这条链路上的拨测全红了。先报 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、客户信息或系统内部标识。

内网穿透 on 虾姐的运维手记