Hermes-Skills/longbridge-cli/references/longbridge-602315-bypass.md

LongPort 602315 Mainland-China Geo-Block Bypass

Verified working 2026-07-09 (order ID 1259547163696824320: RGTI.US buy 15 @ $15.50).

Root cause

LongPort SDK auto-detects CN via HTTP probe to geotest.lbkrs.com (200 → assume CN → route to *.longbridge.cn = Aliyun Shenzhen), then server-side geo-blocks the request (code 602315: Due to Mainland China regulatory requirements...). The Rust SDK has is_cn() in crates/geo/src/lib.rs with this priority:

1. LONGBRIDGE_REGION env var (highest)
2. LONGPORT_REGION env var (alias)
3. Cached probe result
4. Live probe to https://geotest.lbkrs.com (200 → CN)

The fix: override (1) to force the SDK to skip the probe and use the international *.longbridge.com endpoint (AWS HK). Then route the Rust binary through a HK exit so .com is actually reachable.

Three-piece recipe (ALL required)

LONGBRIDGE_REGION=ap \
LONGBRIDGE_TRADE_ENABLED=true \
proxychains4 -f ~/.proxychains/proxychains.conf \
  ~/.local/bin/longbridge --profile lb_real <command>

Piece	What it does	What fails without it
LONGBRIDGE_REGION=ap	Force SDK to use *.longbridge.com (international)	SDK probes → detects CN → uses .cn → 602315
proxychains4	OS-level hook makes Rust binary's outbound HTTP go through Clash proxy	Rust binary connects directly → AWS HK unreachable from CN
Clash on HK node	Exit IP is 154.83.87.231 (HK)	CN node exit still triggers geo-block at gateway

The CLI uses --profile lb_real to load credentials from ~/.lb_real.env, avoiding terminal secret-masking that breaks source ~/.bashrc for long tokens (1053 chars).

Setup

Clash

• Mihomo running, mixed-port: 7890
• GLOBAL selector set to 🇭🇰 [Lv2] 香港 01 (or 02/03) — NOT a CN node
• Verify: curl -x http://127.0.0.1:7890 https://api.ipify.org should return HK IP (154.83.x.x)

proxychains4

apt install -y proxychains4
mkdir -p ~/.proxychains
# /etc/proxychains4.conf is read-only; copy and edit user-owned copy
cp /etc/proxychains4.conf ~/.proxychains/proxychains.conf
# Replace `socks4 127.0.0.1 9050` with `http 127.0.0.1 7890`
python3 -c "
import re
p = '/home/openclaw/.proxychains/proxychains.conf'
with open(p) as f: t = f.read()
t = re.sub(r'^socks4\s+127\.0\.0\.1\s+9050', 'http 127.0.0.1 7890', t, flags=re.M)
with open(p,'w') as f: f.write(t)
"

Profile file

cat > ~/.lb_real.env << EOF
LONGBRIDGE_APP_KEY=$(grep -oP 'LONGPORT_APP_KEY=\K\S+' ~/.bashrc)
LONGBRIDGE_APP_SECRET=$(grep -oP 'LONGPORT_APP_SECRET=\K\S+' ~/.bashrc)
LONGBRIDGE_ACCESS_TOKEN=$(grep -oP 'LONGPORT_ACCESS_TOKEN=\K\S+' ~/.bashrc)
LONGBRIDGE_TRADE_ENABLED=true
EOF

Cron jobs that submit orders

The 4 cron jobs that call submit_order() need both pieces in their invocation:

# Option A: wrap the python invocation in proxychains4 (cron script field)
proxychains4 -f /home/openclaw/.proxychains/proxychains.conf \
  python3 /home/openclaw/.hermes/scripts/us_intraday_monitor.py

# Option B: set LONGBRIDGE_REGION inside the Python script (already done for the 4 intraday scripts)
# At the very top of the script, before any longport import:
import os
os.environ['LONGBRIDGE_REGION'] = 'ap'

Both layers are recommended — env var in the script guarantees the value even if cron loses it; proxychains wrapper handles the network routing.

The 4 affected scripts (already updated 2026-07-09):

• ~/.hermes/scripts/us_intraday_monitor.py
• ~/.hermes/scripts/hk_intraday_monitor.py
• ~/.hermes/scripts/us_intraday_close.py
• ~/.hermes/scripts/hk_intraday_close.py

Failure modes & diagnosis

Symptom	Cause	Fix
error sending request: client error (Connect)	.com endpoint unreachable from CN	Add proxychains4 wrapper; verify HK exit IP
602315 Mainland China regulatory	SDK still using .cn	Set LONGBRIDGE_REGION=ap; verify env var actually passed
4001: token empty	Token not loaded into CLI	Use --profile lb_real; verify ~/.lb_real.env has full 1053-char token
401004 token invalid	Token truncated by terminal masking	Same as above — --profile bypasses the masking
HK exit suddenly returns CN IP	Clash node selector fell back to auto	Re-pin GLOBAL to 🇭🇰 香港 01 via API
Cron order succeeds but no QQ push	Script ran print() only; didn't call push_to_qq.sh	no_agent scripts must subprocess.run(['bash', '~/.hermes/scripts/push_to_qq.sh', msg])

Do NOT use WireGuard

User explicitly forbade WG on Ubuntu (spent 1h recovering from a half-shutdown that left 0.0.0.0/1 + 128.0.0.0/1 residual routes and broke all network). WG scripts were deleted (wg_on.sh, wg_off.sh, longbridge_with_wg.sh, cron_with_wg.sh, setup_wg_sudo.sh). If any future session suggests WG, the user will be upset — this is a class-level ban for this account.