# IP rotation for per-network reg limits — SSH SOCKS tunnel via own VPS

When an autoreg target returns a per-network daily cap (e.g. Haze 429 "Too many accounts were created from this network today"), rotating free proxies is unreliable — batch-test 400+ free proxies (proxyscrape/TheSpeedX/proxy_bot SQLite pool) against the real target endpoint first and expect near-zero yield. The dependable fallback is tunneling through your OWN VPS.

## Recipe (no ssh.exe needed — paramiko SOCKS5 forwarder)

Working script: `C:/Users/User/tmp/socks_ssh.py` — local SOCKS5 listener that forwards `direct-tcpip` channels over a paramiko SSH transport.

1. Pick a live VPS (verify with paramiko exec `curl -s ifconfig.me`).
2. Bind the local listener to a HIGH port (28999+). Low ports like 10999 fail on Windows with `WinError 10013` — they fall inside reserved/excluded port ranges.
3. Run it backgrounded; verify exit IP through the tunnel:
   `curl -s --socks5-hostname 127.0.0.1:28999 ifconfig.me` → must print the VPS IP.
4. Add `--socks5-hostname 127.0.0.1:PORT` to every curl in the reg flow (bootstrap AND verify) — keep the WHOLE flow on one exit IP; anti-bot systems reject register/confirm pairs coming from different IPs.

## Pitfalls

- write_file masks secrets: a `password=***` literal in the script gets rewritten to broken text. Load credentials at runtime from an external file (e.g. `tmp/.gwpass`), and after any write_file run `python -c "import ast; ast.parse(open(f).read())"` before executing.
- Free-proxy testing must be concurrent (ThreadPoolExecutor 25-40) with short `--proxy-connect-timeout`; count only responses with an HTTP code (200/429 both prove reachability, 000 = dead).
- The VPS IP is now YOUR new reg identity — it also burns its daily quota; have multiple VPS or accept the 24h window.
- IMAP OTP fetching does NOT need the tunnel (t-online.de doesn't care), only the target API calls do.