37 lines
3.3 KiB
Markdown
37 lines
3.3 KiB
Markdown
# 1024proxy: Balance Top-Up Flow + Silent Traffic Watcher
|
||
|
||
Cheap DE residential provider (hk.1024proxy.io:3000, sticky sessions `user-region-de-sess<N>`, pass in profile memory). Powers the gateway TH-shim and farm signup waves — traffic budget is the single point of failure; when it hits 0, every channel behind the shim 503s.
|
||
|
||
## API auth
|
||
|
||
All API calls: `POST https://api.1024proxy.com<route>` with form data `{lang:'zh', token:<zero_sid>}` + headers `origin/referer: https://dashboard.1024proxy.com`, via `curl_cffi impersonate='chrome'`. `zero_sid` cookie lives in `tmp/proxy-harvester/1024proxy_cookies.json`.
|
||
|
||
- Status: `/v1/member` → `data.balance` ($), `data.traffic` (MB left), `data.alltraffic` (MB total bought).
|
||
- Order: `/v1/1024/orderFlow` `{sn:'flowmax100', num:'<GB>'}` → `data.url` = checkout page. $1.2/GB, min 2GB. Bare `/orderFlow` and `/v1/orderFlow` = CF 403 — only the `/v1/1024/` prefix works.
|
||
|
||
## CF WAF blocks ALL pay routes for non-browser clients
|
||
|
||
Any route containing `pay` (`/balancePay`, `/v1/balancePay`, `/v1/1024/balancePay`, flowPay/payFlow/...) returns a Cloudflare 403 HTML challenge to curl_cffi — while `/v1/member` and orderFlow pass fine. Do NOT burn time probing route-name variants; the WAF keys on the pay endpoints themselves.
|
||
|
||
Working payment path (headless chromium passes CF):
|
||
|
||
1. Create the order via curl (`/v1/1024/orderFlow`) → checkout URL (valid ~20 min countdown).
|
||
2. Launch playwright chromium headless, `add_cookies` with `zero_sid` + `zero_lang=zh` on `.1024proxy.com`, goto checkout URL.
|
||
3. Click the balance radio: elements are NOT `<button>` — find the shortest visible node whose text matches `余额`, click its inner `input[type=radio]` or dispatch a MouseEvent on it.
|
||
4. Click `立即购买` (shortest visible matching node, closest button).
|
||
5. Verify: page body contains `支付成功`. Balance/traffic re-check via `/v1/member`.
|
||
|
||
Reference implementation: `tmp/px1024_pay2.py` (interactive), `tmp/px1024_watch.py` (watcher with `pay_in_browser()`).
|
||
|
||
## Silent watcher pattern (cron, no_agent)
|
||
|
||
Watch mode must print NOTHING when healthy — empty stdout = no Telegram delivery (watchdog pattern). Print only on: low traffic + purchase attempt (`LOW TRAFFIC... buying`), success (`PURCHASED`), failure (`PAY_FAILED`/`ORDER_FAIL`), or `INSUFFICIENT_BALANCE: X < Y` (balance below one 2GB order — user must top up with real money; the watcher can't fix this).
|
||
|
||
- Threshold: buy when `traffic_mb < 300` (burn can spike to ~13MB/min when several signup waves share the account — 300MB is ~25 min of headroom at worst burn).
|
||
- Wrapper `.sh` in hermes/scripts pins the right interpreter: `PYTHONPATH="" Python311/python.exe px1024_watch.py watch` (system python lacks curl_cffi/playwright).
|
||
- Cron: `no_agent=true`, `script=px1024_watch.sh`, every 2h, deliver to the ops thread. Test the wrapper once after creating — it must exit 0 silently on healthy traffic.
|
||
|
||
## Budget accounting pitfall
|
||
|
||
`alltraffic` grows on purchase but `traffic` (remaining) is what matters; waves and shim share ONE account budget. Before launching new proxy-hungry waves, compute: remaining MB ÷ (per-signup MB × target accounts). Estimate burn from two `/v1/member` reads 10 min apart, not from guesses — signup waves dominated the burn (~13MB/min) while the gateway shim was negligible (~0.5MB/min).
|