# OKX GFW / proxy 架构真相 (2026-08-31 实测)

**触发场景**: 在国内 VPS 上跑 OKX API (ccxt / raw REST) → 用户问"需要走代理吗 / 有国内节点吗"。

**结论先说**:

| 项 | 值 |
|---|---|
| OKX 有"国内节点"吗? | ❌ **没有** |
| OKX 官方要求代理吗? | ❌ **不要求** |
| 直连国内 VPS 为啥不通? | ✅ **中国 GFW 屏蔽** (DNS 劫持) |
| 必须用代理吗? | ✅ **私有 API 必须,公开 API 可不必须** |

---

## 🔬 实测证据 (2026-08-31)

### 测试 1: DNS 解析

```bash
$ getent hosts www.okx.com
169.254.0.2 awscn.okpool.top www.okx.com

$ dig @114.114.114.114 www.okx.com +short
169.254.0.2

$ dig @8.8.8.8 www.okx.com +short
awscn.okpool.top.
169.254.0.2
```

**真相**: `www.okx.com` → CNAME `awscn.okpool.top` (AWS 中国 CDN) → IP `169.254.0.2` (link-local, 不可路由)。

`169.254.x.x` 是 APIPA (Automatic Private IP Addressing) 保留地址,正常网络不会分配 — **GFW 把 okx.com 的 DNS 解析劫持到不可路由的 IP**,从而"屏蔽"。

### 测试 2: 直连端口

```bash
$ timeout 5 bash -c "echo > /dev/tcp/www.okx.com/443"
bash: connect: No route to host
```

直连 443 不通 — 跟 DNS 劫持一致。

### 测试 3: 走 127.0.0.1:7890 代理

```bash
$ curl --proxy 127.0.0.1:7890 https://www.okx.com/api/v5/public/time
{"code":"0","data":[{"ts":"1788136727384"}],"msg":""}
```

✅ 走代理正常返回。

### 测试 4: 公开 API vs 私有 API 区分

| 端点 | 类型 | 是否需要代理 |
|---|---|---|
| `/api/v5/public/time` | 公开 | 可不必须 (但 VPS 网络阻塞, 实测仍需) |
| `/api/v5/market/tickers` | 公开行情 | 同上 |
| `/api/v5/account/balance` | 私有账户 | ✅ **必须** (API key IP 白名单 + GFW) |
| `/api/v5/trade/order` | 私有交易 | ✅ **必须** |
| `/api/v5/account/positions` | 私有持仓 | ✅ **必须** |

---

## 🛠 实战坑

### 坑 1: ccxt 默认 `trust_env=False`

**症状**: 即使 shell 设置了 `HTTPS_PROXY=http://127.0.0.1:7890`,ccxt 不自动捡 (因为 `session.trust_env=False`)。

**正解 (二选一)**:

```python
# A. 显式传 proxies (推荐)
import ccxt
ex = ccxt.okx({
    'apiKey': key, 'secret': sec, 'password': pwd,
    'proxies': {'http':'http://127.0.0.1:7890','https':'http://127.0.0.1:7890'},
    'options': {'defaultType':'swap'},
})

# B. 让 ccxt 捡 shell env (代码里强制 trust_env)
import ccxt
ex = ccxt.okx({...})
ex.session.trust_env = True  # ccxt 默认 False
```

### 坑 2: 误以为 "curl 直连 OKX 返 200 = 直连 OKX"

**症状**: `curl https://www.okx.com/api/v5/public/time` 返 200, 我以为直连通了。

**真相**: curl 自动捡了 shell 的 `HTTPS_PROXY=http://127.0.0.1:7890` 环境变量, **实际是走代理**。验证:

```bash
# 显式不走代理 (重置 env)
unset HTTPS_PROXY HTTP_PROXY https_proxy http_proxy
curl --max-time 5 https://www.okx.com/api/v5/public/time
# → curl: (7) Failed to connect... No route to host
```

### 坑 3: 国内 VPS 没有 "绕过 GFW 的标准方法"

✅ **可用的解决方案**:

| 方案 | 优点 | 缺点 |
|---|---|---|
| **保留 mihomo/clash 代理** | 简单, 现成 | 依赖代理进程 |
| 改 SOCKS5 代理 | 略快 | 仍需代理 |
| VPN 替代代理 | 整网 VPN | 慢 |
| **搬 VPS 到海外** (AWS 东京/新加坡/香港) | 直连即可, 删 proxies 字段 | **贵** (2-3x 价格) |
| 找 OKX "国内节点" | 不存在 | ❌ |

**推荐**: 国内 VPS **保留代理** (现状); 想砍掉代理依赖 **搬 VPS**。

### 坑 4: 验证脚本别写到 cron 里

`scripts/okx_proxy_test.sh` 是验证脚本 (测直连 vs 走代理 vs ccxt 不同模式),**不是 cron**。手动跑一次:

```bash
bash /home/openclaw/.hermes/scripts/okx_proxy_test.sh
# 输出 4 段测试结果 + 结论
```

---

## 📋 一句话总结

- **国内 VPS 上跑 OKX 必须代理** (不是因为 OKX 限制, 是因为 GFW 屏蔽)  
- 公开 API 直连可能因 VPS 网络也能跑 (走 SSH 出口 IP), 但私有 API 必 proxy
- 不要轻信 "curl 返 200 = 直连" — 检查 env 是否设了 HTTPS_PROXY

---

## 关联

- `~/.hermes/skills/trading/okx-auto-position/SKILL.md` v4.5.66 提到 "proxy 必须保留", 本 reference 给出**为什么必须保留的根因** (GFW 屏蔽, 不是 OKX 限制)
- `~/.hermes/scripts/okx_proxy_test.sh` — 实测脚本
- `references/v4.5.66-2026-08-26-drop-low-rating-and-proxy-modes.md` — v4.5.66 已提到 proxy 必要性