> **场景**：OpenClaw（AI Agent 框架）通过飞书接入 Claude API，使用第三方中转站 `100xlabs` 作为代理。配置完成后，curl 直连测试一切正常，但 OpenClaw 实际发消息时却收到 **403 Forbidden**。
>
> **最终根因**：Cloudflare WAF 将 Anthropic SDK 的 User-Agent 加入黑名单。
>
> **阅读时间**：约 8 分钟 | **难度**：中级（需要基本的 HTTP / Linux 基础）

---

## 一、背景与症状

### 架构概览

```
飞书用户 → 飞书服务器 → OpenClaw Gateway → 100xlabs 中转站 → Anthropic API → Claude
                                    ↑
                              这里返回了 403
```

### 配置信息

| 项目 | 值 |
|------|-----|
| 中转站地址 | `https://proxy.example.com` |
| 协议 | Anthropic Messages API |
| 模型 | `claude-opus-4-7` |
| 接入方式 | OpenClaw Gateway + 飞书 Channel |

### 矛盾现象

最让人抓狂的是这个**矛盾**：

```bash
# ✅ curl 直接请求中转站 — 正常返回 200
curl https://proxy.example.com/v1/messages \
  -H "x-api-key: sk-***" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-opus-4-7","max_tokens":100,"messages":[{"role":"user","content":"hi"}]}'

# ❌ 但 OpenClaw 通过同样的中转站发消息 — 返回 403
```

API Key 没问题、模型名没问题、网络没问题……那问题出在哪？

---

## 二、第一步：部署本地代理抓包

既然 curl 能通但 OpenClaw 不能，说明差异在 **HTTP 请求本身**。我们需要看到 OpenClaw 发出的真实请求。

### 方案

在服务器上部署一个极简的 Python HTTP 代理，让 OpenClaw 先打到代理上，代理负责：

1. **原样记录**请求的 headers 和 body（抓包）
2. **转发**到真实的中转站（透传）

### 代理代码

```python
# /tmp/echo_server.py — 本地抓包 + 转发代理
import http.server, json, urllib.request, ssl, urllib.parse

UPSTREAM = "https://proxy.example.com"
SKIP_HEADERS = {'host', 'connection', 'content-length', 'transfer-encoding'}

class Handler(http.server.BaseHTTPRequestHandler):
    def do_POST(self):
        # 1. 读取并保存原始请求体（用于分析）
        length = int(self.headers.get('Content-Length', 0))
        body = self.rfile.read(length)
        fname = f'/tmp/capture_{length}.json'
        with open(fname, 'wb') as f:
            f.write(body)
        print(f"\n[CAPTURED] {length} bytes → {fname}", flush=True)

        # 2. 打印所有请求 Headers（关键！）
        print("--- HEADERS ---")
        for k, v in self.headers.items():
            print(f"  {k}: {v}")
        print("----------------", flush=True)

        # 3. 转发到上游
        fwd_headers = {}
        for k, v in self.headers.items():
            if k.lower() not in SKIP_HEADERS:
                fwd_headers[k] = v
        fwd_headers['Host'] = urllib.parse.urlparse(UPSTREAM).hostname
        fwd_headers['Content-Length'] = str(len(body))

        req = urllib.request.Request(
            UPSTREAM + self.path, data=body,
            headers=fwd_headers, method='POST'
        )
        ctx = ssl.create_default_context()
        try:
            resp = urllib.request.urlopen(req, context=ctx, timeout=120)
            resp_body = resp.read()
            self.send_response(resp.status)
            for k, v in resp.getheaders():
                if k.lower() != 'transfer-encoding':
                    self.send_header(k, v)
            self.end_headers()
            self.wfile.write(resp_body)
            print(f"  ✓ {resp.status} ({len(resp_body)} bytes)", flush=True)
        except urllib.error.HTTPError as e:
            err_body = e.read()
            self.send_response(e.code)
            for k, v in e.getheaders():
                if k.lower() != 'transfer-encoding':
                    self.send_header(k, v)
            self.end_headers()
            self.wfile.write(err_body)
            print(f"  ✗ ERROR {e.code}: {err_body[:300].decode(errors='replace')}", flush=True)

    def log_message(self, *args):
        pass  # 静默默认日志

print("Echo proxy on 127.0.0.1:19999 →", UPSTREAM, flush=True)
http.server.HTTPServer(('127.0.0.1', 19999), Handler).serve_forever()
```

### 启动并修改 OpenClaw 配置

```bash
# 启动代理
python3 /tmp/echo_server.py &

# 修改 openclaw.json，将 baseUrl 从中转站指向本地代理
# "baseUrl": "https://sub.100xlabs.space"
#   ↓ 改为
# "baseUrl": "http://127.0.0.1:19999"

# 重启 OpenClaw Gateway
openclaw gateway restart
```

### 抓到数据了！

通过飞书触发一条消息后，代理成功捕获到请求：

```
[CAPTURED] 107577 bytes → /tmp/capture_107577.json
--- HEADERS ---
  Host: 127.0.0.1:19999
  Content-Type: application/json
  X-API-Key: sk-75e1...f87d
  AnthropiC-Version: 2023-06-01
  User-Agent: Anthropic/JS 0.90.0          ← 👀 注意这个
  Content-Length: 107577
----------------
✗ ERROR 403: {...}
```

**107 KB 的请求体！** 这里面有什么？我们用脚本快速分析一下：

```python
import json
with open('/tmp/capture_107577.json') as f:
    data = json.load(f)

print(f"模型: {data.get('model')}")
print(f"Messages 数量: {len(data.get('messages', []))}")
print(f"Tools 数量: {len(data.get('tools', []))}")

# 统计 tools 大小
tools_json = json.dumps(data.get('tools', []), ensure_ascii=False)
print(f"Tools 总大小: {len(tools_json)} bytes / {len(tools_json)/1024:.1f} KB")

# 搜索 feishu.cn URL
body_str = json.dumps(data, ensure_ascii=False)
feishu_count = body_str.count('feishu.cn')
print(f"feishu.cn 出现次数: {feishu_count}")
```

输出结果：

```
模型: claude-opus-4-7
Messages 数量: 1
Tools 数量: 33
Tools 总大小: 35109 bytes / 34.3 KB
feishu.cn 出现次数: 26
```

现在我们有了完整的嫌疑清单：

| 嫌疑项 | 数据 |
|--------|------|
| 🅰️ 请求体过大（105KB） | 远超普通 API 调用 |
| 🅱️ 26 个 `feishu.cn` URL | 可能触发了内容过滤 |
| 🆎 33 个 tools 定义（35KB） | 工具定义可能包含敏感关键词 |
| 🅳 User-Agent 为 `Anthropic/JS 0.90.0` | SDK 默认标识 |

---

## 三、第二步：二分法逐一排除

有了嫌疑清单，接下来用 **控制变量法** 逐个验证。

### 测试 1：排除 feishu.cn URL

假设 WAF 对飞书域名做了黑名单过滤。用 sed 把请求体中的链接替换掉再发送：

```bash
# 替换所有 feishu.cn 链接为占位符
sed 's|https://[^"]*feishu\.cn[^"]*|[飞书文档链接]|g' \
  /tmp/capture_107577.json > /tmp/test_no_feishu.json

# 用 curl 带 UA 发送到中转站
curl -s -o /dev/null -w "%{http_code}" https://sub.100xlabs.space/v1/messages \
  -H "Content-Type: application/json" \
  -H "x-api-key: sk-xxx" \
  -H "anthropic-version: 2023-06-01" \
  -H "User-Agent: Anthropic/JS 0.90.0" \
  -d @/tmp/test_no_feishu.json
```

结果：**403** ❌ → 排除 URL 因素

### 测试 2：只发送 tools 定义

```bash
# 提取纯 tools 部分
python3 -c "
import json
with open('/tmp/capture_107577.json') as f:
    d = json.load(f)
print(json.dumps({'model':'claude-opus-4-7','max_tokens':10,'tools':d['tools'],'messages':[{'role':'user','content':'hi'}]}))
" > /tmp/test_tools_only.json

curl -s -o /dev/null -w "%{http_code}" [同上 headers...] -d @/tmp/test_tools_only.json
```

结果：**200 OK** ✅ → Tools 本身不触发拦截

### 测试 3：去掉 User-Agent，发送完整 body

```bash
# 同样用完整请求体，但不带 User-Agent header
curl -s -o /dev/null -w "%{http_code}" https://sub.100xlabs.space/v1/messages \
  -H "Content-Type: application/json" \
  -H "x-api-key: sk-xxx" \
  -H "anthropic-version: 2023-06-01"
  # ← 故意不加 User-Agent
  -d @/tmp/capture_107577.json
```

结果：**200 OK** ✅ → 完整的 105KB body 也没问题！

### 测试 4：只加一个 User-Agent header

```bash
# 最精简的请求 + Anthropic UA
curl -s -o /dev/null -w "%{http_code}" https://sub.100xlabs.space/v1/messages \
  -H "Content-Type: application/json" \
  -H "x-api-key: sk-xxx" \
  -H "anthropic-version: 2023-06-01" \
  -H "User-Agent: Anthropic/JS 0.90.0"     # ← 只加了这一行
  -d '{"model":"claude-opus-4-7","max_tokens":10,"messages":[{"role":"user","content":"hello"}]}'
```

结果：**403** ❌❌❌

**找到了！一个 header，仅此而已，就是它。**

### 最终确认矩阵

| 测试条件 | HTTP 状态码 | 结论 |
|---------|------------|------|
| 基线（无特殊 header，完整 105KB body） | **200** ✅ | Body 内容安全 |
| + feishu.cn URL（26个） | **200** ✅ | URL 不触发 |
| + tools 定义（33个，35KB） | **200** ✅ | Tools 不触发 |
| + `User-Agent: Anthropic/JS 0.90.0` | **403** ❌ | **🎯 就是这个！** |
| + 其他 SDK header（如 `dangerous-direct-browser-access`） | **200** ✅ | 只有 UA 被拦 |

---

## 四、根因结论

```
┌─────────────────────────────────────────────────────┐
│                                                     │
│   sub.100xlabs.space (Cloudflare WAF)               │
│                                                     │
│   规则: IF User-Agent contains "Anthropic/"         │
│        THEN → 403 Forbidden (Block)                 │
│                                                     │
│   原因推测:                                          │
│   • 防止未经授权的 SDK 直连                            │
│   • 或检测到大量自动化请求后做的风控策略                  │
│   • 也可能是误杀                                      │
│                                                     │
└─────────────────────────────────────────────────────┘
```

**一句话总结**：中转站的 Cloudflare WAF 将 Anthropic 官方 JavaScript SDK 的默认 User-Agent (`Anthropic/JS 0.90.0`) 列入了黑名单，任何携带该标识的请求都会被直接拒绝——无论你的 API Key 是否有效、请求内容是什么。

这是一个典型的**中间件防御层误判/过严**案例。从 WAF 的视角来看，它可能在防范滥用；但从正常用户的视角来看，这完全是个隐形的坑——curl 能通、Postman 能通、浏览器能通，偏偏官方 SDK 不行。

---

## 五、修复方案

### 方案 A：本地 UA 伪装代理（已采用 ✅）

在 OpenClaw 和中转站之间插入一层轻量代理，**替换 User-Agent 后再转发**：

```python
# /tmp/echo_server.py — UA-spoofed 版本（核心改动）
import http.server, json, urllib.request, ssl, urllib.parse

UPSTREAM = "https://proxy.example.com"
SKIP_HEADERS = {'host', 'connection', 'content-length', 'transfer-encoding'}

CHROME_UA = "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (Chrome/120.0.0.0) Safari/537.36"

class Handler(http.server.BaseHTTPRequestHandler):
    def do_POST(self):
        length = int(self.headers.get('Content-Length', 0))
        body = self.rfile.read(length)

        fwd_headers = {}
        for k, v in self.headers.items():
            if k.lower() not in SKIP_HEADERS:
                # 🔑 核心：将 Anthropic UA 替换为 Chrome
                if k.lower() == 'user-agent':
                    v = CHROME_UA
                fwd_headers[k] = v
        fwd_headers['Host'] = urllib.parse.urlparse(UPSTREAM).hostname
        fwd_headers['Content-Length'] = str(len(body))

        req = urllib.request.Request(UPSTREAM + self.path, data=body,
                                     headers=fwd_headers, method='POST')
        ctx = ssl.create_default_context()
        try:
            resp = urllib.request.urlopen(req, context=ctx, timeout=120)
            resp_body = resp.read()
            self.send_response(resp.status)
            for k, v in resp.getheaders():
                if k.lower() != 'transfer-encoding':
                    self.send_header(k, v)
            self.end_headers()
            self.wfile.write(resp_body)
        except urllib.error.HTTPError as e:
            err_body = e.read()
            self.send_response(e.code)
            for k, v in e.getheaders():
                if k.lower() != 'transfer-encoding':
                    self.send_header(k, v)
            self.end_headers()
            self.wfile.write(err_body)

    def log_message(self, *args):
        pass

print("UA-Spoof Proxy on :19999 →", UPSTREAM, flush=True)
http.server.HTTPServer(('127.0.0.1', 19999), Handler).serve_forever()
```

**配置变更**：只需改 OpenClaw 的 `baseUrl`：

```json
// openclaw.json
{
  "baseUrl": "http://127.0.0.1:19999"   // 指向本地代理
}
```

### 方案 B：systemd 持久化（推荐生产环境使用）

避免手动启动代理进程意外中断：

```ini
# /etc/systemd/system/openclaw-ua-proxy.service
[Unit]
Description=OpenClaw UA Spoofing Proxy for 100xlabs
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/python3 /tmp/echo_server.py
Restart=always
RestartSec=3
StandardOutput=journal
StandardError=journal
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=multi-user.target
```

```bash
sudo systemctl daemon-reload
sudo systemctl enable --now openclaw-ua-proxy
sudo systemctl status openclaw-ua-proxy
# 验证端口
ss -tlnp | grep 19999
```

### 方案 C：联系中转站解封（治本之策）

让 100xlabs 在其 WAF 规则中将 `Anthropic/*` User-Agent 加入白名单。这是最干净的解决方案，但需要对方配合，且等待周期不确定。

### 方案 D：上游支持自定义 UA（长期建议）

向 OpenClaw / Anthropic SDK 反馈，增加 `customUserAgent` 或类似配置项，让用户可以自行指定请求标识，无需依赖外部代理。

---

## 六、经验总结

### 排查方法论

这次排障的核心思路是**二分法 + 控制变量**：

```
1. 先确认矛盾点（curl 通 vs SDK 不通）
2. 部署中间代理抓取真实请求（看到完整 headers + body）
3. 分析数据建立嫌疑清单（URL? Body大小? Tools? UA?）
4. 逐一构造最小测试用例验证每个嫌疑
5. 定位到单个 header 就停——不用继续猜了
```

### 关键经验

| 经验点 | 说明 |
|--------|------|
| **矛盾即线索** | curl 通但程序不通 = 差异在 HTTP 层，不是业务逻辑 |
| **先抓包再猜** | 没看到真实请求之前，所有猜测都是浪费时间 |
| **WAF 黑名单常针对 UA** | Cloudflare 等 CDN/WAF 产品常用 User-Agent 做第一道筛选 |
| **代理是最强调试工具** | 几十行 Python 代码就能实现完整的 MITM 调试能力 |
| **SDK 默认行为不可信** | 官方 SDK 的默认 header、超时、重试策略都可能踩坑 |

### 一个值得思考的问题

> 为什么中转站会屏蔽官方 SDK 的 User-Agent？

可能的原因：
- **防滥用**：大量用户用同一套 SDK 发起高频请求，WAF 按 UA 做限流
- **渠道管控**：希望用户走特定的接入方式（如自己的客户端），而非通用 SDK
- **误配置**：管理员在设置规则时手滑把合法的 SDK UA 加入了黑名单

无论如何，作为 API 使用者，遇到这类问题时，**不要先怀疑自己的代码**——先用工具看到真实的网络请求，让数据说话。

---

## 七、参考资源

- [Cloudflare WAF 文档](https://developers.cloudflare.com/waf/)
- [Anthropic Python/JS SDK](https://github.com/anthropics/anthropic-sdk-python)
- [OpenClaw 项目](https://github.com/openclaw/openclaw)（示例项目名）

---

*本文基于真实排障记录整理。如果你也遇到过类似的 WAF 拦截、API 中转站 403 问题，欢迎在评论区分享你的经历和解决方案！*


场景：OpenClaw（AI Agent 框架）通过飞书接入 Claude API，使用第三方中转站 100xlabs 作为代理。配置完成后，curl 直连测试一切正常，但 OpenClaw 实际发消息时却收到 403 Forbidden。

WorkBuddy 解决了困扰我多天使用多个工具都未解决的OpenClaw接入难题

场景：OpenClaw（AI Agent 框架）通过飞书接入 Claude API，使用第三方中转站 xsite 作为代理。配置完成后，curl 直连测试一切正常，但 OpenClaw 实际发消息时却收到 403 Forbidden。

人工智能

网络与通信

开发工具

OpenClaw接入API中转站时遭遇Cloudflare WAF 403错误，排查发现是Anthropic SDK的User-Agent被拦截。通过本地代理抓包、二分法测试，最终定位到问题根源并提供了UA伪装代理、systemd持久化等解决方案。文章详细记录了从抓包分析到问题解决的全过程，为类似API接入问题提供实用参考。

内容安全

中间件

服务器

OpenClaw

AI Agent

Python

Agent

Linux

JSON

CDN免费试用


热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

OpenClaw接入API中转站时遭遇Cloudflare WAF 403错误，排查发现是Anthropic SDK的User-Agent被拦截。通过本地代理抓包、二分法测试，最终定位到问题根源并提供了UA伪装代理、systemd持久化等解决方案。文章详细记录了从抓包分析到问题解决的全过程，为类似API接入问题提供实用...

WorkBuddy 解决了困扰我多天使用多个工具都未解决的OpenClaw接入难题-腾讯云开发者社区-腾讯云

WorkBuddy 解决了困扰我多天使用多个工具都未解决的OpenClaw接入难题

WorkBuddy 解决了困扰我多天使用多个工具都未解决的OpenClaw接入难题

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐