TokenHarbor-ферма: топология rate-limit и дисциплина волн

Проверено в бою 2026-10-12 (полный шторм троттлинга: DC + home + free-пул одновременно).

1. Топология rate-limit TH (free-аккаунты лимитятся ПО СЕТЕВОМУ АДРЕСУ)

Выход	Chat/serving	Signup	Вердикт
DC (сервер)	429 навсегда — «many free accounts are sharing this network address»	429	непригоден by design
Home residential	работает, пока не спален	палит выход	остывает ~1ч после паузы
Free-прокси (GH-листы)	0 из 419 живых смогли chat POST	~5-10% конверсия	только signup
Paid residential (1024proxy DE, свежий IP/запрос)	работает	работает	единственный стабильный путь

Ключевой факт: GET /models проходит на IP, которые ловят 429 на chat POST. Проба пула — только целевым authenticated POST (max_tokens=3), не GET.

2. Разделение трафиков (главное правило)

Signup-волны и serving НИКОГДА не делят выход. Волны жгут прокси-пул, serving держит home/paid.
Recovery (логины в TH) палит home-выход так же, как сайнапы — гонять recovery через прокси или ставить на паузу, пока home нужен для serving. CF 502 HTML на home-леге = выход под челленджем, ждать ~1ч.
Различай тексты 429: «Too many sign-ups from this network» = signup-лимит (~1ч); «many free accounts sharing this network address» = serving-лимит на shared IP (для DC — перманентно); CF 502 HTML = IP под Cloudflare-челленджем.

3. Дисциплина волн

Перед запуском волн — psutil-скан на дубли (cmdline содержит имя скрипта, исключить ' -c '). Дубли волн жрут один mail-сплит → «This email is already on board» фейлы и сожжённые прокси впустую. Из пары дублей оставлять старейший по create_time.
Каждая волна = свой mail-сплит. Сплиты разного размера — запускать сначала крупные.
Отложенный рестарт через sleep N && cmd & в одном background-вызове тихо умирает (цепочка не переживает cleanup сессии терминала). Каждую долгую задачу запускать ОТДЕЛЬНЫМ terminal(background=true) вызовом, лог в свой файл через >>.
Счётчик «SIGNUP OK» в логе волны lag'ает банк на 2-5 мин (verify mail → login → key). Правда — в accounts.jsonl, не в логе.

4. Serving-шим (aiohttp-прокси)

ClientTimeout(total=N) убивает длинные стримы (клиентские сессии стримят минуты). Правильно: ClientTimeout(sock_connect=8-10, sock_read=20-45) — fail-fast на мёртвых прокси, sock_read = зазор между чанками, живой стрим не ограничен по длительности.
Порядок лега: home (быстрый, если не спален) → proxy-пул (2-3 попытки) → 502 быстро. Direct-DC-лег бессмыслен при free-акках (перманентный 429) — не тратить на него таймаут.
Мусорные каналы в one-api.db ломают диагностику: key аномальной длины (сотни+ символов) даёт ValueError: Invalid header value у urllib-проб и рвёт ротацию new-api. При «беспричинных» 503 — первым делом SELECT id,length(key) FROM channels WHERE status=1 AND length(key)>100, дизейблить найденное.
Автопуш ключей в шлюз — cron каждые 15 мин, рестарт new-api только при новых каналах.

5. Бесплатный контур замкнутый (когда paid-прокси нет)

Фидер: каждые 30 мин скачать все живые GH-листы (skill proxy-free-trial) → дедуп против pool-БД → ipify-проба → вставить свежих в пул волн. ~9.5K уникальных за цикл, сотни свежих IP. Serving при этом остаётся на home-остывании — free-пул для чата мёртв, это нужно говорить пользователю прямо, с пруфом (N живых → 0 chat-способных), а не обещать «скоро оживёт».

5.1 KiB Raw Permalink Blame History Unescape Escape