🦞 香港服务器部署 OpenClaw 实战：飞书 WebSocket 1006、Nginx 101、WireGuard 代理与 OpenAI 限流排查
—— 一次关于 WebSocket、代理与限流的工程级排障全过程
作者：周斌+AI
一、项目目标
在香港服务器上搭建一套稳定的 AI 网关系统，实现：
- OpenClaw（作为 AI 网关）
- 对接 OpenAI / Grok
- 接入飞书机器人
- 通过 HTTPS + WebSocket 对外提供访问
- 保证长期稳定运行
目标架构：
Feishu <-- WebSocket --> OpenClaw <-- HTTPS --> OpenAI
↑
Nginx TLS
↑
XXX.net
看起来简单，真正上线后问题却接踵而至。
二、第一阶段：OpenAI 访问失败
现象
curl https://api.openai.com/v1/models
返回：
unsupported_country_region_territory
根因
香港服务器出口 IP 被 OpenAI 风控限制。
解决方案
通过 WireGuard 建立境外出口代理：
export HTTPS_PROXY=http://10.xxx.xxx.xxx:xxxx
并精细配置 NO_PROXY（示例）：
export NO_PROXY=127.0.0.1,localhost,feishu.cn,larkoffice.com,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
关键经验
- OpenAI 必须走代理
- Feishu 必须不走代理
- 本地回环地址必须不走代理
代理不是"开/关"的问题，而是"流量分流策略"。
三、第二阶段：Nginx WebSocket 101 失败
现象
浏览器报错：
- 1006 closed before connect
OpenClaw 日志类似：
- [ws] closed before connect code=1006
根因
Nginx 配置错误（在 proxy_pass 里拼 token）：
proxy_pass http://127.0.0.1:18789/ws?token=xxxx;
导致握手异常。
正确写法
location /ws {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://127.0.0.1:18789/ws;
}
验证方式
必须用 curl 做握手验证：
curl -skv --http1.1 -H "Connection: Upgrade" -H "Upgrade: websocket" https://xxx.net/ws
看到：
- HTTP/1.1 101 Switching Protocols
才算 WebSocket 层真正打通。
四、第三阶段：飞书 system busy / rate limit
现象
飞书机器人反复提示：
- system busy
- rate limit
真正根因
WebSocket 不稳定 → 飞书不断重连 → 重连风暴 → 飞书触发限流保护
很多"限流"不是 API 调用次数，而是连接层不稳定导致的放大效应。
五、第四阶段：飞书 WebSocket 未真正建立
日志只显示：
- WebSocket client started
但没有出现：
- connected
- recv event
说明飞书后台没有开启"长连接接收事件"。
正确步骤
- 飞书开发者后台
- 自建应用
- 开启"通过长连接接收事件"
- 重新发布应用
之后日志出现：
- [feishu] connected
- [feishu] recv event
系统恢复正常。
六、最终稳定架构
飞书平台
│
│ WebSocket
▼
OpenClaw Gateway
│
Nginx TLS
│
WireGuard 出口代理
│
OpenAI
这是一条完整的：
网络层 → 代理层 → TLS 层 → WebSocket 层 → 网关层 → API 层 全链路排障闭环。
七、关键工程经验总结
- WebSocket 必须 101 验证。
- 代理必须精细分流。
- 飞书必须开启长连接。
- 限流往往来自重连风暴。
- 分层验证、逐层叠加。
八、结语
这不是一次简单的安装。
而是一场工程级的全链路排障。
技术的乐趣不在成功那一刻，而在于你真正理解了系统的边界与耦合。