公众号旧文
一次 HTTP 503 排障：最后竟然是代理背锅
很多人在看到 HTTP 503 时，第一反应通常是：
- Nginx 挂了
- 后端服务没启动
- 服务器资源耗尽
但胖子这次 503，问题根本不在服务器。
今天的情况非常典型：
服务是好的，端口是开的，但访问就是失败。
最后发现，真正的原因居然是：浏览器代理。
一、故障现象
我有一台 NAT VPS，端口映射如下：
65001 → 22（SSH）
65002 → 8080（Web）访问 Web 服务：
http://45.204.206.6:65002浏览器返回：
该网页无法正常运作
45.204.206.6 目前无法处理此请求。
HTTP ERROR 503二、第一反应：服务器是不是挂了？
先从最基础的检查开始。
第一步：本机测试服务
curl -I http://127.0.0.1:8080返回：
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.12说明：
- Web 服务正常
- 程序正在运行
第二步：检查端口监听
ss -lntp看到：
0.0.0.0:8080 python3说明：
- 端口正常监听
- 没有端口冲突
第三步：怀疑 NAT 转发
NAT VPS 的端口是通过网关转发的。
我做了一个本机测试：
curl http://127.0.0.1:65002结果连接失败。
这个结果是正常的，因为 65002 是网关端口，本机并不会监听它。
第四步：抓包（关键一步）
为了确认流量是否进入服务器，我使用 tcpdump 抓包：
tcpdump -i any port 8080然后在浏览器访问：
http://45.204.206.6:65002结果非常奇怪：
0 packets captured也就是说：
服务器完全没有收到任何请求。
三、矛盾出现了
为了确认端口状态，我又测试了一次：
nc -zv 45.204.206.6 65002返回：
open这说明：
- 端口是开放的
- 有服务响应
但同时服务器却没有收到请求。
这就出现了一个逻辑矛盾。
四、排障思路一度走偏
当时我的判断是：
- NAT 转发是不是失效了
- 端口是不是被别人占用了
- 服务商是不是配置错了
甚至都已经准备提交工单。
但问题始终解释不通：
端口 open，但服务器抓不到流量。
五、关键转折
后来我突然想到一件事：
我的浏览器一直开着代理。
于是做了一个简单测试：
关闭代理，再访问一次。
结果页面秒开。
六、真正的原因
问题终于明确：
服务商拦截了来自代理节点的访问。
访问路径实际上是这样的：
使用代理时：
浏览器（代理IP）
↓
NAT 网关
↓
被拦截（未转发到服务器）
关闭代理后：
真实IP
↓
NAT 网关
↓
正常转发 → 8080也就是说流量在网关层就被丢弃了。
服务器根本没有收到请求。
七、为什么会这样
很多 NAT VPS 商家都会做一些访问限制，例如：
1、防滥用策略
禁止用户运行：
- Web 面板
- 反向代理
- 对公网开放的 Web 服务
2、屏蔽机房 IP
拦截来源包括：
- VPS
- Cloudflare
- 扫描器
3、端口差异策略
不同端口策略不同：
22（SSH） → 放行
Web端口 → 严格限制SSH 可以正常连接，但 Web 访问可能被拦截。
八、为什么 tcpdump 抓不到包
原因很简单：
客户端
↓
商家 NAT 网关
↓
（被丢弃）
↓
服务器流量在 网关层就被丢弃了。
因此服务器完全看不到请求。
九、整个排障路径复盘
| 步骤 | 结论 |
|---|---|
| 本机 curl | 服务正常 |
| 端口监听 | 正常 |
| tcpdump 抓包 | 没有流量 |
| nc 测试 | 端口 open |
| 最终定位 | 代理被拦截 |
十、最后的总结
HTTP 503 并不一定意味着服务故障。
有时候真正的问题是：
你根本没有被允许访问这台服务器。
在使用 NAT VPS 时，这类问题其实很常见：
表面看起来是：
- 端口问题
- 服务问题
但本质往往是网络被限制。
所以以后如果遇到类似情况，可以先问自己一个问题：
流量真的进入我的服务器了吗？