Hermes-Skills/okx-auto-position/references/okx-gfw-proxy-architecture-2026-08-31.md

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

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

结论先说:

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

---

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

测试 1: DNS 解析

$ 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: 直连端口

$ 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 代理

$ 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)。

正解 (二选一):

# 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 环境变量, 实际是走代理。验证:

# 显式不走代理 (重置 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 /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 必要性