从一次诡异的 403 说起：如何正确判断是网络问题还是风控问题

从一次诡异的 403 说起：如何正确判断"是网络问题还是风控问题"

一、那个让我查了两小时的 403

前段时间排查一个服务访问异常：某海外 API 在服务器上稳定返回 403，但同一套代码在同事的笔记本上完全正常。

第一反应是"被墙了"，于是开始换节点、换协议、测端口连通性——全部正常，TCP 握手成功，TLS 也能协商，就是返回 403。

后来用 curl 抓了响应体才发现，那不是网络层的拒绝，而是 Cloudflare 返回的 HTML 拦截页：

Sorry, you have been blocked

请求根本没到达目标服务器，是被 CDN 的边缘节点拦下了。

二、403 的三种完全不同的成因

同样是 403，可能来自三个层面，处理方式完全不同：

关键判断方法：看响应体的格式。

• HTML 页面 → CDN/防火墙拦截（不是业务逻辑）

• JSON → 应用层拒绝（看 code/message）

• 无响应 → 网络层问题

三、最容易误判的地方：命令行工具的 TLS 指纹

这里有个大坑：用 curl 测试的结果，不能代表浏览器或 App 的真实体验。

原因是 CDN 会检查 TLS 握手的指纹（JA3/JA4）。curl 用的是标准 OpenSSL，指纹非常"机器化"，很容易被识别为爬虫；而 Chrome 的指纹是真人流量特征。

我实测过同一个 IP：

# curl 访问 → 403
curl -s -o /dev/null -w "%{http_code}" https://目标站/

# 真实浏览器访问 → 200 正常打开

所以排查时如果只用 curl，很容易得出"这个 IP 被墙了"的错误结论，然后白白折腾换 IP。

四、正确的排查顺序

1. 先看响应体：是 HTML 还是 JSON？这一步能砍掉一半的错误方向。

2. 确认出口 IP：用 /cdn-cgi/trace 这类端点看自己的出口 IP 和 ASN。

```bash

curl -s https://目标站/cdn-cgi/trace | grep -E '^(ip|loc|warp)='

```

3. 区分测试工具：curl 的结果只能作为参考，涉及风控时必须用真实浏览器验证。

4. 检查业务层参数：Header 是否带齐（Accept、Accept-Language、Referer）、Token 是否有效。

五、几个实用技巧

用 trace 端点看真实出口

Cloudflare 系列的站点大多支持 /cdn-cgi/trace，能直接看到：

ip=104.28.x.x
loc=SG
warp=on

warp=on 表示流量走了 Cloudflare WARP，loc 是边缘节点所在地，这两个字段对判断链路非常有用。

用 curl 复制浏览器请求头

如果一定要用 curl 测试风控，至少把头伪装完整：

curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36" \
  -H "accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" \
  -H "accept-language: en-US,en;q=0.9" \
  https://目标站/

但要注意：UA 和 Header 可以伪造，TLS 指纹伪造不了，所以结果仍然只能参考。

用真实浏览器做最终验证

自动化场景下，用 Playwright 起一个真实 Chromium 去访问，看页面标题和内容，这才是最接近真实用户的验证：

const resp = await page.goto('https://目标站/');
console.log(resp.status(), await page.title());
// 如果 title 是 "Just a moment..." 就是被 Cloudflare 挑战了

六、小结

排查 403 的核心不是"试更多方法"，而是先分类，再定位：

1. 看响应体格式 → 判断是 CDN 还是应用层

2. 看出口 IP/ASN → 判断是否 IP 信誉问题

3. 用真实浏览器复核 → 避免被 curl 的指纹误导

这三步做完，通常十分钟内就能定位方向，比盲目换 IP、换协议高效得多。