Hermes-Skills/longbridge-python-sdk/references/longportapp-cn-endpoints.md

Python SDK Endpoint Confusion: longportapp.cn vs longbridge.cn

Last verified 2026-07-09: this reference is partially correct on the diagnosis, wrong on the fix.

The trap (correct as written)

LongPort has two parallel sets of endpoints and the Python SDK uses a different one than the CLI:

Tool	Endpoints used	Default geo-block host
longbridge CLI	openapi.longbridge.com / openapi.longbridge.cn	Aliyun Shenzhen (47.106.x.x, 120.77.x.x)
longport Python SDK	openapi.longportapp.cn + openapi-quote.longportapp.cn + openapi-trade.longportapp.cn	Aliyun Shenzhen + Shanghai (139.196.x.x)

Both endpoint families resolve to CN-hosted IPs by default. Both return 602315 from a CN egress IP.

Why LONGBRIDGE_REGION=ap doesn't fully fix Python SDK (correct as written)

Confirmed 2026-07-09: setting os.environ['LONGBRIDGE_REGION'] = 'ap' in the script and tracing the proxychains traffic shows requests still hit openapi.longportapp.cn. The Python wheel appears to either ignore the env var, hardcode the domain, or have a bug where the override doesn't propagate. CLI honors it; SDK does not.

The "hosts rewrite" fix from earlier sessions — DOES NOT WORK

Earlier versions of this reference and the longbridge_hosts_fix2.sh script recommended adding AWS HK IPs (18.166.191.191, 18.163.160.163) as hosts overrides for the three longportapp.cn domains. This was tested on 2026-07-09 and fails:

proxychains4 -f ~/.proxychains/proxychains.conf \
  curl -s --max-time 10 -o /dev/null -w "%{http_code}\n" https://18.166.191.191/
# Returns: 000  (OpenSSL SSL_connect: SSL_ERROR_SYSCALL)

The TCP connection opens but TLS handshake fails. The same result was reproduced with every Clash node tested:

• 🇭🇰 [Lv2] 香港 01/02/03 — all fail AWS HK TLS
• 🇺🇸 [Lv2] 美国 01/02/03 — all fail AWS HK TLS
• 🇨🇳 [Lv2] 台湾 01/02/03 — all fail AWS HK TLS

AWS is blocking egress from these proxy ASNs. Even with the hosts override, the TLS handshake to 18.166.191.191:443 fails, so the Python SDK's API call still errors with client error (Connect). The 602.315 error then surfaces from the gateway as a fallback when the SDK gives up on the *.com path and tries *.cn directly.

The hosts changes were reverted. /etc/hosts is back to default (only localhost / openclaw-Virtual-Machine entries). longbridge.cn rewrite was kept since CLI orders still need it, but it is not the bypass it's described as.

What actually works (as of 2026-07-09)

Path	Recipe	Status
Manual CLI order	LONGBRIDGE_REGION=ap LONGBRIDGE_TRADE_ENABLED=true proxychains4 -f ~/.proxychains/proxychains.conf ~/.local/bin/longbridge --profile lb_real <order>	✅ Works (order 1259547163696824320)
Cron-driven Python SDK order	Same three pieces + os.environ['LONGBRIDGE_REGION']='ap' in script + bash wrapper for proxychains4	❌ Still 602315 (verified 2026-07-09)
Phone app	LongPort app on phone with HK network egress	✅ Confirmed by user
Auto via WireGuard	Not viable (Ubuntu shutdown unreliable, user banned)	❌

How to detect this trap is biting you (correct detection)

Run any cron-scheduled Python script that touches longport, then tail -10 ~/.hermes/cron/output/<job_id>/<latest>.md:

ls -t ~/.hermes/cron/output/<job_id>/ | head -1 | xargs -I {} tail -10 ~/.hermes/cron/output/<job_id>/{}

Look for:

[proxychains] Strict chain ... 127.0.0.1:7890 ... openapi.longportapp.cn:443 ... OK
❌ OpenApiException: ... 602315 ... Mainland China regulatory requirements

→ longportapp.cn route → 602315. Currently the only mitigation that works for this is to disable auto-execution in the script and have it push the signal to QQ for manual confirmation.

If proxychains logs show openapi.longportapp.com:443 ... OK (HTTP 200, not SSL fail), the hosts rewrite is working but you're still likely to get 602315 because the server-side geo-check is based on the source IP, not the domain.

Diagnostic one-liner

proxychains4 -f ~/.proxychains/proxychains.conf \
  python3 -c "
import os; os.environ['LONGBRIDGE_REGION']='ap'
for k in ['LONGPORT_APP_KEY','LONGPORT_APP_SECRET','LONGPORT_ACCESS_TOKEN']:
    os.environ[k] = next(l for l in open('/home/openclaw/.bashrc').read().splitlines() if l.startswith(f'export {k}')).split('=',1)[1].strip()
from longport import openapi
try:
    print(openapi.QuoteContext(config=openapi.Config.from_env()).quote(['RGTI.US'])[0].last_done)
except Exception as e:
    print(f'ERR: {e}')
"

If this returns ERR: ... 602315 ... or ERR: ... client error (Connect), the bypass is not working — fall back to phone app or manual CLI order.

What to recommend to the user when this fails

1. Manual CLI order (three-piece recipe) — works today.
2. Phone LongPort app with HK proxy — works today.
3. Disable auto-execution in cron scripts and have them push signals to QQ with "please place this manually" instructions. This is the current recommended default.
4. Do not propose WG (banned).
5. Do not propose more hosts rewrites — the AWS IP path is not reachable from the available proxy nodes.

Why this stays in skills rather than just memory

• The trap is non-obvious and re-bites future agents if not in a skill.
• The fix requires understanding the server-side IP check (which memory snapshots won't capture cleanly).
• The "what works" answer changes as proxy nodes and AWS policies change; this file should be re-verified when the network setup changes.

History

• 2026-07-08: hosts rewrite to 18.166.191.191 suggested as the fix.
• 2026-07-09: tested, failed (SSL handshake to AWS HK IP fails from every Clash node). Hosts changes reverted (cn domain left in place for CLI, but longportapp.cn rewrite removed).
• 2026-07-09: confirmed CLI recipe works (order 1259547163696824320); confirmed Python SDK recipe does not work in cron path. This reference updated to reflect the corrected state.