Files
autoreg-skills-max/skills/github-oauth-automation/references/newapi-panel-mass-reg.md

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

  1. 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.
  2. Probe each host GET /api/status (concurrent, gzip-aware). New-API panel = JSON with data.github_oauth / data.version. Extract github_client_id (starts Ov23li...) — it IS the OAuth client_id for the GH authorize step. Note register_enabled, password_register_enabled, email_verification.
  3. Register per panel via GH OAuth: panel /api/user/register → get state → GH login+TOTP → oauth_code(client_id, state) → panel callback → key. Force bind=False (source-address bind fails; direct egress works).
  4. Verify value BEFORE scaling: fetch /v1/models with the key, then smoke POST /v1/chat/completions {model, max_tokens:10} on 2-3 promising models. Only panels where a real completion returns are worth waves.
  5. 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.
  6. 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/subscription for soft/hard limits.
  • quota=0 or micro (<1000) panels = garbage, drop from queue even if /v1/models lists 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.com through 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 _req so 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, table pool, 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 &amp; 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

  1. Don't write parallel waves to one OUT file — PermissionError loses records; OUTNAME env per wave.
  2. Don't taskkill /F /IM python.exe to clear waves — kills unrelated bots; filter by CommandLine match via PowerShell Get-CimInstance (wmic absent on this Python toolchain).
  3. Serialize waves: parallel GitHub logins multiply the 429 and drop yield to near zero.
  4. entities-style bugs aside: always re-check panel aliveness (/api/status) at wave start — panels die between discovery and wave.
  5. Smoke-test with max_tokens:10 and reply 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.
  6. kimi/nemotron-class models can 504 Gateway Timeout even with quota — retry once, then judge from pricing endpoint instead.