5.5 KiB
5.5 KiB
New-API Relay Panel Mass Registration (GitHub OAuth + proxy rotation)
Class of task: mass-register accounts on New-API / one-api relay panels (api.* LLM gateways) that grant signup quota, harvest OpenAI-compatible API keys, verify which models actually respond. Working stack: C:/Users/User/tmp/regfarm/ (github_oauth/reg_http.py + gh_http.py + newapi_lib.py + proxy_patch.py, runners reg_proxy100.py / reg_welfare.py / gh_master.py).
Pipeline
- Discover panels from GitHub navigator repos (raw README fetch): free-newapi lists, ai-relay-welfare, free-api-keys catalogs. Parse all hosts, filter infra/badge/social links, dedupe.
- Probe each host
GET /api/status(concurrent, gzip-aware). New-API panel = JSON withdata.github_oauth/data.version. Extractgithub_client_id(startsOv23li...) — it IS the OAuth client_id for the GH authorize step. Noteregister_enabled,password_register_enabled,email_verification. - Register per panel via GH OAuth: panel
/api/user/register→ get state → GH login+TOTP →oauth_code(client_id, state)→ panel callback → key. Forcebind=False(source-address bind fails; direct egress works). - Verify value BEFORE scaling: fetch
/v1/modelswith the key, then smokePOST /v1/chat/completions{model, max_tokens:10}on 2-3 promising models. Only panels where a real completion returns are worth waves. - Wave: serialize panels (one at a time, sleep 90-180 between), separate OUTNAME per panel to avoid file collisions, incremental JSON dump after every account so kills don't lose records.
- Aggregate: dedupe keys by (panel, api_key) across all out/*.json, export CSV panel/base/uid/quota/api_key/ts.
Quota economics & triage
- New-API quota units: 500,000 = $1. Signup grants vary: 125K ($0.25) to 100M ($200, e.g. bluesminds with model_ratio 0.5 → effectively 2x value). Check
/v1/dashboard/billing/subscriptionfor soft/hard limits. - quota=0 or micro (<1000) panels = garbage, drop from queue even if
/v1/modelslists hundreds of models. - Storefront is deceptive: panels list opus/gpt-6 catalogs but live chat returns 402 "out of credits" / 403 "insufficient Super balance" / «额度不足 $0». A model list proves nothing — only a smoke completion does.
- Some panels show 200 + model list but the free tier is empty (orcarouter pattern). Others (flushapi) require a paid 'Super balance' group.
Proxy rotation (critical, hard-won)
- Panel requests: DIRECT, no proxy. Free/datacenter proxies get 403/429 from panel WAFs — routing panels through proxies turned a working flow into 0/150.
- GitHub requests: through proxies — GitHub rate-limits the home IP (429 E45002,
state fail: POST 429) during waves. - Re-verify the proxy list against github.com itself before EVERY wave (concurrent
GET https://github.comthrough each, keep 200s). Lists validated against ip-api or days ago go stale fast (37 → 11 alive observed); stale list = wall of URLError -10060 timeouts. - Patch GHSession with auto-rotation: wrap
_reqso any network error (status -1) retries up to 3 times, each rebuilding the opener with the next proxy from the cycle. CookieJar must survive the rebuild (same jar object) or login state is lost mid-flow. - Source of proxies: ProxyGrabReform_bot DB (
Desktop/proxy_bot/proxies.db, tablepool, columns proxy/alive/checked_at).
Account pool management
- GH accounts are reusable across panels (each panel = separate OAuth app). Only per-panel usage matters: compute free indexes per panel by excluding logins with a success record for THAT panel.
- Pool:
C:/Users/User/tmp/gh_accounts.json(login/password/totp). Backup before merges. - Panels rejecting fresh accounts with «oauth account is too new to register» / «github账号不符合注册要求» need aged accounts — no fix, skip panel.
- Success rate under GitHub rate limit is ~10-25% of attempts; expect most failures as 429, not account death. Don't burn the pool on quota=0 panels.
- Some panels close registration mid-campaign (chuan pattern: all records
disabled) — detect and drop.
Non-New-API GitHub OAuth services (xkiro pattern)
- Express-style OAuth initiators return 302 with the Location ALSO in the body as
Redirecting to <url>with&entities — parse the body fallback, not just headers; state cookie (__xt_oauth_state) is set on the initiating call and must be reused for the callback. - Cloudflare error code 1010 = urllib fingerprint block; full browser header set (Sec-Fetch-*, Sec-Ch-Ua, Upgrade-Insecure-Requests) passed it on the initiator, but the callback still 403'd — such SPA services need the browser path (camoufox/patchright), not urllib.
Pitfalls
- Don't write parallel waves to one OUT file — PermissionError loses records; OUTNAME env per wave.
- Don't
taskkill /F /IM python.exeto clear waves — kills unrelated bots; filter by CommandLine match via PowerShell Get-CimInstance (wmic absent on this Python toolchain). - Serialize waves: parallel GitHub logins multiply the 429 and drop yield to near zero.
entities-style bugs aside: always re-check panel aliveness (/api/status) at wave start — panels die between discovery and wave.- Smoke-test with
max_tokens:10andreply exactly: pong— some models return 200 with empty content (deepseek-v4-flash, gpt-oss-20b on some panels) = effectively dead for chat use; mark ⚠️ not PASS. - kimi/nemotron-class models can 504 Gateway Timeout even with quota — retry once, then judge from pricing endpoint instead.