post: 403和503——同一条链路上的两个幽灵(9/10)

content/posts/403-and-503.md

@@ -0,0 +1,109 @@
+---
+title: "403 和 503：同一条链路上的两个幽灵"
+description: "拨测全红，先查 403 再查 503。一个是面板里藏着的白名单开关，一个是反代对并发突刺的熔断。查完发现：这两个问题从头到尾都不在服务端。"
+date: 2026-09-10T18:40:00+08:00
+draft: false
+tags:
+  - 排障
+  - 反向代理
+  - 内网穿透
+  - 事故复盘
+---
+
+## 背景
+
+一条链路：**拨测平台 → 公网反代 → 内网穿透隧道 → 源站应用**。
+
+今天这条链路上的拨测全红了。先报 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 配置全程干净**——两个问题的根因都在链路的前半段。
+
+排查方法沉淀：
+
+1. **先画链路图**：拨测→反代→隧道→源站，每跳都可能返回自己的错误码
+2. **用响应体指纹定位拦截方**：不同层返回的错误页大小/响应头不同（面板页 1321B、nginx 默认页 552B、容器页 190B 带安全头）——比只看状态码准得多
+3. **瞬时故障用压测复现**：抓不到现场就制造现场，阈值自然浮出（20 过 / 40 半 / 60 全挂）
+4. **同秒混合成功失败 = 容量问题**（谁抢到 worker 谁成功）；**确定性全拒 = 规则问题**
+5. **带面板的服务器，面板设置优先级高于 nginx conf**——两套体系，容易漏
+
+## 总结
+
+> 排障最耗时间的不是修，是**确认问题不在你正在看的地方**。
+
+今天在两个错误码上绕了远路，但每一层的排除都是必要的——正因为把服务端三层都验证干净了，才能确定"幽灵"在链路前半段。
+
+以及一个反复出现的道理：**拨测、监控、告警这类"自己人"，永远要先加进白名单**。反爬配置、限流规则、IP 白名单上线前，先想想自家拨测从哪个 IP 来。
+
+---
+
+*本文已脱敏，不含真实域名、IP、客户信息或系统内部标识。*