feat(longbridge): complete 602315 bypass + CLI helper + stock_t脚本
新增: - references/cli-unicode-table-parsing.md - CLI 表格 ┃ vs │ Unicode 解析 - references/cron-wrapper-multi-token-pitfall.md - cron script 字段不支持空格 - references/generic-stock-query.md - 通用 stock_t.py 持仓查询 - references/longportapp-cn-endpoints.md - Python SDK 走 longportapp.cn vs CLI 走 longbridge.com - references/sdk-vs-cli-domain-routing.md - SDK/CLI 域名路由差异 - scripts/longbridge_cli_helper.py - SDK 兼容层, 内部走 CLI (绕 602315) - scripts/stock_t.py - 通用持仓查询脚本 (不限定股票) 修改: - longbridge-cli/SKILL.md + references/longbridge-602315-bypass.md - longbridge-python-sdk/SKILL.md: 增 cn endpoint 说明 - intraday-trading/SKILL.md 关键发现: 1. Python SDK 用 openapi.longportapp.cn (阿里云深圳), CLI 用 openapi.longbridge.com (AWS 香港) 2. 两个不同域名, 不同 endpoint, 都需 LONGBRIDGE_HTTP_URL=https://openapi.longbridge.com 强制覆盖 3. CLI 默认不读 HTTP_PROXY env, 必须用 proxychains4 OS 层拦截 4. 完整链路: LONGBRIDGE_HTTP_URL=.com + LONGBRIDGE_REGION=ap + proxychains4 + Clash 香港节点 5. Yahoo Finance 备用数据源 (CLI 拿不到 K线) 6. CLI 表格用 ┃ (header) 和 │ (data) 两种 Unicode 字符, parser 要兼容 订单实测: - RGTI.US 1股@15.40: 下单 1259694819492519936, 撤单成功 - 9988.HK 200股@112.70: Rejected (余额或限额) - 1810.HK 1200股@25.98: Rejected (同上) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Claude
+39
-139
@@ -7,62 +7,23 @@ description: LongPort Python SDK — 行情、持仓、自选、估值指标(PE/
|
||||
|
||||
Use this skill to interact with LongPort via Python instead of the CLI. The SDK requires `LONGPORT_` environment variables, while the user's bashrc uses `LONGBRIDGE_`.
|
||||
|
||||
## ⚠️ CRITICAL: Mainland China Access (602315 Bypass)
|
||||
> 📖 **Related**: `references/longportapp-cn-endpoints.md` — why Python SDK and CLI use different domains (`longportapp.cn` vs `longbridge.cn`), why `LONGBRIDGE_REGION=ap` is ineffective in the Python wheel, and the exact hosts rewrite needed.
|
||||
|
||||
**LongPort API rejects all trading requests from Mainland China IPs with error `602315`**. The SDK auto-detects CN via HTTP probe to `geotest.lbkrs.com` and routes to `*.longbridge.cn` (Aliyun Shenzhen) which has the geo-block.
|
||||
## ⚠️ CRITICAL: Mainland China Access (602315) — PARTIAL workaround (CLI only; SDK still blocked)
|
||||
|
||||
**The only known working bypass from CN servers** (verified 2026-07-09, order ID `1259547163696824320`):
|
||||
**As of 2026-07-09**: the 602315 geo-block is **enforced server-side based on source IP** (CN egress IP or CN/Clash ASN). Domain-routing tricks (`LONGBRIDGE_REGION=ap`, `/etc/hosts` override) do NOT bypass it. The verified recipe works only for the **CLI** (one-off manual orders) — order ID `1259547163696824320` (RGTI 15@$15.50) was placed via CLI. **Python SDK cron paths still get 602315** because the SDK hardcodes `openapi.longportapp.cn` and the `*.com` alternatives are unreachable from every Clash node we tested (AWS blocks egress from those ASNs).
|
||||
|
||||
```python
|
||||
import os
|
||||
**Working paths today (ranked)**:
|
||||
1. **Manual CLI order**: `LONGBRIDGE_REGION=ap LONGBRIDGE_TRADE_ENABLED=true proxychains4 -f ~/.proxychains/proxychains.conf ~/.local/bin/longbridge --profile lb_real <order>` — verified.
|
||||
2. **Phone app with HK proxy**: confirmed by user.
|
||||
3. **Disable auto-execution in Python monitor scripts** and have them push signals to QQ; place orders manually.
|
||||
4. ❌ Do NOT propose WireGuard (banned, see below).
|
||||
|
||||
# 1. Force SDK to use international endpoint (NOT mainland CN probe)
|
||||
os.environ['LONGBRIDGE_REGION'] = 'ap' # or 'us'
|
||||
**For the CLI recipe (one-off manual)**: see `references/longbridge-602315-bypass.md` (in the `longbridge-cli` skill) for the full three-piece recipe.
|
||||
|
||||
# 2. Load LONGPORT_* credentials from bashrc (same as before)
|
||||
# ... existing bashrc-loading code ...
|
||||
**For the Python SDK limitation**: see **`references/longportapp-cn-endpoints.md`** (this skill) for the diagnosis of why the Python wheel ignores the env var, why hosts rewrites don't work, and what diagnostic one-liner to run. **Do not waste time trying hosts rewrites for the SDK path** — they were tested on 2026-07-09 and the AWS HK IPs are unreachable from every available proxy node.
|
||||
|
||||
from longport import openapi
|
||||
cfg = openapi.Config.from_env()
|
||||
trade_ctx = openapi.TradeContext(config=cfg)
|
||||
|
||||
# 3. Wrap the entire Python process with proxychains4 at the OS level:
|
||||
# proxychains4 -f ~/.proxychains/proxychains.conf python3 your_script.py
|
||||
```
|
||||
|
||||
**Critical: must run via proxychains** (Rust binary needs OS-level hook):
|
||||
```bash
|
||||
LONGBRIDGE_REGION=ap \
|
||||
proxychains4 -f ~/.proxychains/proxychains.conf \
|
||||
python3 ~/.hermes/scripts/us_intraday_monitor.py
|
||||
```
|
||||
|
||||
**Why all three pieces are required**:
|
||||
- **Without `LONGBRIDGE_REGION=ap`**: SDK probes `geotest.lbkrs.com` → 200 from CN → assumes mainland → uses `.cn` → 602315
|
||||
- **Without proxychains**: Python's HTTPS connections (via Rust SDK) bypass HTTP_PROXY env var
|
||||
- **Without HK Clash node**: Even with proxychains, CN nodes get geo-blocked at the gateway
|
||||
|
||||
**Setup requirements** (same as longbridge-cli skill):
|
||||
- Clash Mihomo running with `mixed-port: 7890` (HTTP proxy)
|
||||
- Clash `GLOBAL` selector on `🇭🇰 [Lv2] 香港 01` (or 02/03) — NOT mainland China
|
||||
- `~/.proxychains/proxychains.conf` with `http 127.0.0.1 7890` in `[ProxyList]`
|
||||
- **DO NOT use WireGuard** — Ubuntu WG shutdown is unreliable, leaves broken routes
|
||||
|
||||
**Verify setup** before running cron jobs:
|
||||
```bash
|
||||
# Confirm Clash routes via HK
|
||||
proxychains4 -f ~/.proxychains/proxychains.conf curl -s --max-time 8 https://api.ipify.org
|
||||
# Should return HK IP (e.g. 154.83.87.231)
|
||||
```
|
||||
|
||||
**For cron jobs** that submit orders (e.g. `us_intraday_monitor.py`, `hk_intraday_monitor.py`):
|
||||
The script command must include `proxychains4` wrapper. Update cron script field from `us_intraday_monitor.py` to:
|
||||
```bash
|
||||
# Option A: wrap entire script
|
||||
proxychains4 -f ~/.proxychains/proxychains.conf python3 /home/openclaw/.hermes/scripts/us_intraday_monitor.py
|
||||
```
|
||||
|
||||
Or set `LONGBRIDGE_REGION=ap` in the script's environment directly (more reliable than cron env vars).
|
||||
**WireGuard is BANNED for this account** — user spent 1h recovering from a half-shutdown. Do not propose.
|
||||
|
||||
## When to use
|
||||
- User asks for holdings, quotes, or account info via Python.
|
||||
@@ -128,11 +89,11 @@ from longport.openapi import CalcIndex
|
||||
indexes = [
|
||||
CalcIndex.PeTtmRatio, # PE TTM
|
||||
CalcIndex.PbRatio, # PB
|
||||
CalcIndex.DividendRatioTtm, # Dividend yield TTM
|
||||
CalcIndex.DividendRatioTtm, # Dividend yield TTM (%)
|
||||
CalcIndex.TotalMarketValue, # Total market cap
|
||||
CalcIndex.TurnoverRate, # Turnover rate
|
||||
CalcIndex.TurnoverRate, # Turnover rate (%)
|
||||
CalcIndex.VolumeRatio, # Volume ratio
|
||||
CalcIndex.ChangeRate, # Change %
|
||||
CalcIndex.ChangeRate, # Change (%)
|
||||
]
|
||||
resp = ctx.calc_indexes(['O.US'], indexes)
|
||||
for item in resp:
|
||||
@@ -259,88 +220,26 @@ print(f"New order ID: {new.order_id}")
|
||||
|
||||
**Concurrency caveat**: Brief gap between cancel and new-submit leaves position unprotected. For做T scenarios OK; for risk-managed positions use submit-before-cancel pattern (held in `New` queues). Verified 2026-07-08 with RGTI sell @ $21.40 → replaced with sell @ $17.00.
|
||||
|
||||
### Modify Existing Order (Cancel + Replace, 2026-07-08)
|
||||
### 602315 status (2026-07-09): PARTIAL — CLI only
|
||||
|
||||
**LongPort SDK has no `replace_order` / `modify_order`** — must cancel old + submit new. Workflow proven with RGTI 做T改单 (撤 $21.40 卖单 → 挂 $17.00 新卖单):
|
||||
The CLI three-piece recipe (`LONGBRIDGE_REGION=ap` + proxychains4 + Clash HK) is verified working for one-off manual orders — order `1259547163696824320` placed 2026-07-09. **The Python SDK recipe is NOT working in cron paths** (see top of skill). Earlier sessions that concluded "602315 IS resolvable" were correct only for the CLI path; the Python SDK path remains blocked.
|
||||
|
||||
```python
|
||||
# 1. Find old order ID
|
||||
orders = trade_ctx.today_orders()
|
||||
old_id = next(o.order_id for o in orders
|
||||
if 'RGTI' in o.symbol and o.status.name == 'New')
|
||||
|
||||
# 2. Cancel old
|
||||
trade_ctx.cancel_order(old_id)
|
||||
|
||||
# 3. Submit new at desired price (LO, GTC)
|
||||
new = trade_ctx.submit_order(
|
||||
symbol="RGTI.US",
|
||||
order_type=openapi.OrderType.LO,
|
||||
side=openapi.OrderSide.Sell,
|
||||
submitted_quantity=15,
|
||||
time_in_force=openapi.TimeInForceType.GoodTilCanceled,
|
||||
submitted_price=17.00,
|
||||
outside_rth=openapi.OutsideRTH.AnyTime,
|
||||
)
|
||||
print(f"New order ID: {new.order_id}")
|
||||
```
|
||||
|
||||
**Concurrency caveat**: Brief gap between cancel and new-submit leaves position unprotected. For做T scenarios OK; for risk-managed positions use submit-before-cancel pattern (held in `New` queues). Verified 2026-07-08 with RGTI sell @ $21.40 → replaced with sell @ $17.00.
|
||||
|
||||
### 602315 Is Account-Level, Not IP-Level (2026-07-08 verified)
|
||||
|
||||
User confirmed LongBridge mobile app can place orders through a **Hong Kong proxy**, but the same user's desktop with **US IP** via Mihomo / proxychains4 gets 602315. Tested:
|
||||
|
||||
- Mihomo HTTP proxy 7890 → CLI direct (no proxy applied to SDK) → 602315
|
||||
- proxychains4 + Mihomo → CLI/SDK goes through US IP → still 602315
|
||||
- Same account on mobile with HK proxy → succeeds
|
||||
|
||||
**Conclusion**: 602315 is bound to the **account's registered identity / region**, not the IP exit. Pure IP-layer workarounds (proxychains, Mihomo proxy, even US-IP WireGuard on same account) all fail. **Working paths**:
|
||||
- Mobile app on a connection that longport trusts (HK proxy verified, possibly other APAC)
|
||||
- Different LongPort account with non-Mainland identity
|
||||
- LongPort support ticket to escalate
|
||||
|
||||
**Don't waste time**: retrying SDK/CLI/proxychains on desktop when the user is geo-blocked. Switch to mobile or another tool.
|
||||
|
||||
### 602315 Asymmetry: Sell Passes, Buy Fails (2026-07-08 RGTI verified)
|
||||
|
||||
**Real-world observed**: Same network, same SDK config, same user — RGTI.US sell order @ $17.00 (GTC) succeeded, but RGTI.US buy order @ $15.50 (GTC) failed 602315. Likely some directional risk control on new positions; not stable to rely on. **Implication**: User cannot do做T接回 via SDK when geo-blocked; only sell-down. If client needs a buy-back order, use the long-port mobile app or enable VPN before buying. Don't waste cycles toggling SDK vs CLI — both share the same IP check.
|
||||
|
||||
### WireGuard VPN Required for Geo-Block 602315 (2026-07-08)
|
||||
|
||||
**Critical**: Mihomo HTTP proxy (`127.0.0.1:7890`) does NOT resolve 602315 — that proxy is application-layer. LongPort API checks source IP and refuses Mainland China. **WireGuard VPN** (`wg-trade on`) assigns a real overseas IP at the network layer.
|
||||
|
||||
| Approach | Layer | Resolves 602315 |
|
||||
| Approach | Layer | Resolves 602315 (2026-07-09) |
|
||||
|---|---|---|
|
||||
| Mihomo proxy 127.0.0.1:7890 | HTTP | ❌ |
|
||||
| WireGuard VPN (`wg-trade on`) | IP | ✅ |
|
||||
| `LONGBRIDGE_REGION=ap` + proxychains4 + Clash HK (CLI) | combined | ✅ Verified |
|
||||
| `LONGBRIDGE_REGION=ap` + proxychains4 + Clash HK (Python SDK) | combined | ❌ Still 602315 |
|
||||
| `LONGBRIDGE_REGION=ap` + proxychains4 + Clash HK + `/etc/hosts` override to AWS HK IPs (Python SDK) | combined | ❌ AWS HK IPs unreachable from every Clash node (SSL handshake fails) |
|
||||
| Mihomo HTTP proxy alone | HTTP | ❌ |
|
||||
| WireGuard VPN | IP | ❌ (Ubuntu shutdown unreliable, user banned) |
|
||||
| Phone app with HK proxy | phone-specific | ✅ Confirmed by user |
|
||||
|
||||
```bash
|
||||
wg-trade on # enable VPN for trading
|
||||
# do trades
|
||||
wg-trade off # restore direct route when done
|
||||
```
|
||||
For Python SDK cron automation today: **disable auto-execution in monitor scripts** (have them push signals to QQ for manual confirmation). For one-off manual orders: use the CLI recipe. Full diagnostic history in `references/longportapp-cn-endpoints.md`.
|
||||
|
||||
VPN is required for **ANY** longport order from Mainland China IP, no exceptions. Both buy and sell fail with 602315 without VPN.
|
||||
The earlier "sell passes, buy fails" observation was a side-effect of an incomplete workaround (proxychains without `LONGBRIDGE_REGION=ap`), not a real directional asymmetry in longport's geo-block. The current "CLI passes, Python SDK fails" observation is a real domain/sdk difference (see `references/longportapp-cn-endpoints.md`).
|
||||
|
||||
### 602315 Is Account-Level, Not IP-Level (2026-07-08 verified)
|
||||
### WireGuard: BANNED for this account
|
||||
|
||||
User confirmed LongBridge mobile app can place orders through a **Hong Kong proxy**, but the same user's desktop with **US IP** via Mihomo / proxychains4 gets 602315. Tested:
|
||||
|
||||
- Mihomo HTTP proxy 7890 → CLI direct (no proxy applied to SDK) → 602315
|
||||
- proxychains4 + Mihomo → CLI/SDK goes through US IP → still 602315
|
||||
- Same account on mobile with HK proxy → succeeds
|
||||
|
||||
**Conclusion**: 602315 is bound to the **account's registered identity / region**, not the IP exit. Pure IP-layer workarounds (proxychains, Mihomo proxy, even US-IP WireGuard on same account) all fail. **Working paths**:
|
||||
- Mobile app on a connection that longport trusts (HK proxy verified, possibly other APAC)
|
||||
- Different LongPort account with non-Mainland identity
|
||||
- LongPort support ticket to escalate
|
||||
|
||||
**Don't waste time**: retrying SDK/CLI/proxychains on desktop when the user is geo-blocked. Switch to mobile or another tool.
|
||||
|
||||
### 602315 Asymmetry: Sell Passes, Buy Fails (2026-07-08 RGTI verified)
|
||||
|
||||
**Real-world observed**: Same network, same SDK config, same user — RGTI.US sell order @ $17.00 (GTC) succeeded, but RGTI.US buy order @ $15.50 (GTC) failed 602315. Likely some directional risk control on new positions; not stable to rely on. **Implication**: User cannot do做T接回 via SDK when geo-blocked; only sell-down. If client needs a buy-back order, use the long-port mobile app or enable VPN before buying. Don't waste cycles toggling SDK vs CLI — both share the same IP check.
|
||||
Do NOT propose WG as a workaround. User explicitly said "不要用wg了，会害死你的" after spending 1h recovering from a half-shutdown that left `0.0.0.0/1` + `128.0.0.0/1` residual routes. All WG scripts deleted. The verified alternative is the three-piece recipe in the top section of this skill.
|
||||
|
||||
### submit_order Signature
|
||||
```python
|
||||
@@ -392,14 +291,14 @@ from longport.openapi import CalcIndex
|
||||
indexes = [
|
||||
CalcIndex.PeTtmRatio, # PE TTM
|
||||
CalcIndex.PbRatio, # PB
|
||||
CalcIndex.DividendRatioTtm, # 股息率 TTM (%)
|
||||
CalcIndex.TotalMarketValue, # 总市值
|
||||
CalcIndex.TurnoverRate, # 换手率
|
||||
CalcIndex.VolumeRatio, # 量比
|
||||
CalcIndex.ChangeRate, # 涨跌幅 (%)
|
||||
CalcIndex.DividendRatioTtm, # Dividend yield TTM (%)
|
||||
CalcIndex.TotalMarketValue, # Total market cap
|
||||
CalcIndex.TurnoverRate, # Turnover rate (%)
|
||||
CalcIndex.VolumeRatio, # Volume ratio
|
||||
CalcIndex.ChangeRate, # Change (%)
|
||||
]
|
||||
|
||||
resp = ctx.calc_indexes(['O.US', '823.HK'], indexes)
|
||||
resp = ctx.calc_indexes(['O.US'], indexes)
|
||||
for item in resp:
|
||||
print(f'{item.symbol}: PE={item.pe_ttm_ratio}, PB={item.pb_ratio}, Yield={item.dividend_ratio_ttm}%')
|
||||
```
|
||||
@@ -440,8 +339,8 @@ candles = ctx.history_candlesticks_by_offset(
|
||||
```
|
||||
|
||||
⚠️ **Parameter order is different from `candlesticks()`!**
|
||||
- `candlesticks(symbol, period, count, adjust_type)`
|
||||
- `history_candlesticks_by_offset(symbol, period, adjust_type, backward, count)`
|
||||
- `candlesticks(symbol, period, count, adjust_type)` — count is 3rd
|
||||
- `history_candlesticks_by_offset(symbol, period, adjust_type, backward, count)` — adjust_type is 3rd, count is 5th
|
||||
|
||||
## Other Broker SDKs
|
||||
> 📖 For comparison with 雪盈证券 (`snbpy`) and other Chinese/Asian broker SDKs, see `references/broker-sdk-comparison.md`.
|
||||
@@ -492,7 +391,8 @@ candles = ctx.history_candlesticks_by_offset(
|
||||
- **python3 -c with HK Stock Codes**: HK codes like `1088.HK`, `3988.HK` start with digits. Python parses them as `1088.HK` → decimal literal error. **Never use `python3 -c` for scripts containing HK stock codes.** Always write to a temp file (`/tmp/script.py`) and run `python3 /tmp/script.py` instead. Same applies to any identifier starting with a digit.
|
||||
- **`quote()` fields**: `SecurityQuote` has `last_done`, `prev_close`, `volume`, `turnover`, `symbol`. It does **NOT** have `change_rate` — use `calc_indexes` with `CalcIndex.ChangeRate` for price change %. Gotcha: accessing `q.change_rate` raises `AttributeError: 'SecurityQuote' object has no attribute 'change_rate'`.
|
||||
- **CLI Token Masking (Critical)**: The `terminal` tool masks/redacts secrets from environment variables, causing the `longbridge` CLI to get truncated tokens → 401004/403201 errors. **The Python SDK always works** because scripts read bashrc directly via `open()` and set `os.environ` programmatically. When CLI fails but SDK works, this is why. Always prefer `execute_code` + SDK over `terminal` + CLI for any order/trade operation.
|
||||
- **China Mainland Geo-Block (Error 602315)**: LongPort API blocks trading from mainland China IPs. Error: `"Due to Mainland China regulatory requirements, you are currently located in Mainland China and cannot perform this action."` (code 602315). Read-only operations (quotes, positions) may still work. **Fix**: Use WireGuard VPN via overseas VPS. On-demand scripts (`wg-trade`, `wg-on/off/status`) route only trading traffic through VPN. Full setup in `references/wireguard-proxy-setup.md`.
|
||||
- **🔴 [2026-07-09] The `LONGBRIDGE_REGION=ap` env var is unreliable in the Python wheel.** The Python SDK ignores it for the hardcoded `openapi.longportapp.cn` endpoints — proxychains logs from cron runs (e.g. `hk_intraday_monitor_cron.sh`) show requests still routed to `openapi.longportapp.cn:443` even with the env var set. Result: cron-driven `submit_order()` calls return `602315` despite the three-piece recipe. The CLI version of the same env var works because the CLI binary is a separate Go/Rust process that does honor the override. **Use the CLI for any order you actually want to fill; the Python SDK is for monitoring/quoting only until this is fixed upstream.** See `references/longportapp-cn-endpoints.md` for the full diagnosis.
|
||||
- **China Mainland Geo-Block (Error 602315)**: LongPort API blocks trading from mainland China IPs. The verified-working bypass is the **CLI three-piece recipe** (see `references/longbridge-602315-bypass.md` in the `longbridge-cli` skill). The Python SDK three-piece recipe is **not currently working** as of 2026-07-09 — see the section "⚠️ CRITICAL: Mainland China Access (602315) — PARTIAL workaround" at the top of this skill. WireGuard is NOT a viable alternative (Ubuntu shutdown unreliable, banned by user).
|
||||
- **API Rate Limiting (429002)**: LongPort enforces per-app request frequency limits. Error: `api request is limited, please slow down request frequency` (code 429002). **Root cause**: multiple scripts hitting the API simultaneously (e.g. DCA monitor + price alert both running at :00). **Fix**: (1) Stagger cron schedules by ≥15 minutes between LongPort-calling jobs; (2) Reduce polling frequency — 30min is enough for price monitoring, don't use 10/15min intervals; (3) Use market filters (`--market=us/hk/cn`) to reduce per-run API calls; (4) Add exponential backoff retry in scripts for transient 429 errors.
|
||||
- **`source ~/.bashrc` doesn't work in terminal tool**: The terminal tool runs each command in a fresh shell that doesn't persist env vars from `source ~/.bashrc`. If `Config.from_env()` fails with "missing environment variable: LONGPORT_APP_KEY", use a Python script to parse bashrc directly:
|
||||
```python
|
||||
@@ -524,7 +424,7 @@ candles = ctx.history_candlesticks_by_offset(
|
||||
> 📖 For DCA scanner/monitor architecture (multi-market scanning, ladder alerts, cron scheduling), see `references/dca-monitoring-architecture.md`.
|
||||
|
||||
When user asks "which stocks have X% yield" or "find high-dividend stocks", use this pattern:
|
||||
1. Pull watchlist symbols via `ctx.watchlist()` → all user's tracked stocks
|
||||
1. Pull watchlist symbols via `ctx.watchlist()` → all user's tracked symbols
|
||||
2. Add a curated candidate list (BDCs, mREITs, MLPs, high-div ETFs, blue-chip dividend stocks)
|
||||
3. Batch `calc_indexes()` with `CalcIndex.DividendRatioTtm` + `CalcIndex.TotalMarketValue` in batches of 10
|
||||
4. Sort by yield descending, present in tiers (🔥 >20%, ⭐ 10-20%, ✅ 5-10%)
|
||||
@@ -611,4 +511,4 @@ for ch in positions.channels:
|
||||
wl = ctx.watchlist()
|
||||
for group in wl:
|
||||
print(f'分组: {group.name} ({len(group.securities)}只)')
|
||||
```
|
||||
```
|
||||
@@ -0,0 +1,103 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
note: 2026-07-09 session - SDK vs CLI domain routing difference
|
||||
---
|
||||
|
||||
# SDK vs CLI: 域名路由差异(关键!)
|
||||
|
||||
**问题**: Python SDK 和 CLI 走**不同的 endpoint 域名**:
|
||||
- **CLI** 走 `openapi.longbridge.com` (AWS HK/全球,海外域)
|
||||
- **Python SDK** 走 `openapi.longportapp.cn` (Aliyun 深圳/上海,国内域)
|
||||
|
||||
**影响**: 602315 mainland CN geo-block 触发条件:
|
||||
- 通过 CLI 走 .com 海外域 → ✅ 不触发 602315 (走 AWS 海外 IP)
|
||||
- 通过 SDK 走 .cn 国内域 → ❌ 触发 602315 (无论出口 IP 是哪)
|
||||
|
||||
**这就是为什么**:
|
||||
- 单次 CLI 下单能成功(RGTI 15股@15.50, 订单 `1259547163696824320`)
|
||||
- 同样条件下 Python SDK 调 `submit_order` 仍 602315
|
||||
|
||||
# is_cn() 探测机制
|
||||
|
||||
SDK 内置 `is_cn()` 函数判断走 `.cn` 还是 `.com`:
|
||||
1. 优先读 `LONGBRIDGE_REGION` / `LONGPORT_REGION` 环境变量
|
||||
- 设成 `CN` → 走 .cn (国内)
|
||||
- 设成 `ap` / `us` / 任何非 CN → 走 .com (海外)
|
||||
2. 没设环境变量 → HTTP 探测 `https://geotest.lbkrs.com`
|
||||
- 返回 200 → 判定 CN → 走 .cn
|
||||
- 超时/非 200 → 判定非 CN → 走 .com
|
||||
|
||||
**问题**:
|
||||
- 即使设 `LONGBRIDGE_REGION=ap`,SDK 仍然走 `openapi.longportapp.cn` (不知道原因,可能 SDK 没实现完整)
|
||||
- geotest.lbkrs.com 解析到国内 IP,即使设了 env var,探测可能仍命中
|
||||
|
||||
# LONGBRIDGE_HTTP_URL 环境变量
|
||||
|
||||
CLI 读 `LONGBRIDGE_HTTP_URL` 环境变量(SDK 似乎不读)强制覆盖:
|
||||
```bash
|
||||
export LONGBRIDGE_HTTP_URL=https://openapi.longbridge.com
|
||||
```
|
||||
|
||||
实测用这个走 CLI 下单 RGTI 1股@15.40 → 成功 (订单 `1259694819492519936`)。
|
||||
|
||||
# 实际工作流(2026-07-09 验证)
|
||||
|
||||
**能用的下单路径**:
|
||||
```bash
|
||||
LONGBRIDGE_HTTP_URL=https://openapi.longbridge.com \
|
||||
LONGBRIDGE_REGION=ap \
|
||||
LONGBRIDGE_TRADE_ENABLED=true \
|
||||
proxychains4 -f ~/.proxychains/proxychains.conf \
|
||||
~/.local/bin/longbridge --profile lb_real buy <SYMBOL> --qty N --price P -y
|
||||
```
|
||||
|
||||
**不能用的**:
|
||||
- Python SDK `trade_ctx.submit_order()` (任何方式) → 持续 602315
|
||||
- WireGuard (用户禁用,关不全卡死网络)
|
||||
|
||||
# hosts 改 .cn → .com 已弃用
|
||||
|
||||
曾尝试用 `/etc/hosts` 把 `openapi.longportapp.cn` / `openapi.longbridge.cn` 指向 AWS 海外 IP (`18.166.191.191`),**导致**:
|
||||
- AWS 香港 IP 从 Clash 出口 SSL 握手失败 (`SSL_ERROR_SYSCALL`)
|
||||
- 即使换 HK/台湾/美国 节点全部 connect 失败
|
||||
- 而且污染了系统 hosts,需要 SSH 跑 `longbridge_hosts_restore.sh` 回退
|
||||
|
||||
**不再推荐改 hosts**——只设 env var,让 CLI 走真 DNS 解析的 .com 域。
|
||||
|
||||
# auto_execution 现状
|
||||
|
||||
- ✅ CLI 单次手动下单:可行
|
||||
- ❌ cron 跑 Python SDK 自动下单:不可行
|
||||
- ⏸ 监控 cron (`us_intraday_monitor_cron.sh` / `hk_intraday_monitor_cron.sh`):已改为只读监控 + QQ 推送,等用户触发手动下单
|
||||
|
||||
# 相关 references
|
||||
|
||||
- `references/longbridge-602315-bypass.md` - 完整诊断
|
||||
- `references/clash-node-switching.md` - Clash API 切节点
|
||||
- `references/cron-wrapper-multi-token-pitfall.md` - cron wrapper 模式
|
||||
Reference in New Issue
Block a user