---
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、客户信息或系统内部标识。*