# 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**:

```bash
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`:

```bash
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

```bash
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.