Files
autoreg-skills-max/skills/ai-provider-autoreg/references/free-proxy-pool-decay-and-validation.md

4.6 KiB
Raw Blame History

Free-proxy pool decay & per-target validation (рецепт батч-проверки)

Расширение pitfall 22 (валидировать прокси ПО ЦЕЛЕВОМУ САЙТУ) и pitfall 36 (вендор может блочить домен).

Правила

  1. Флаг alive=1 в локальной БД прокси-пула (proxy_bot sqlite, SELECT proxy FROM pool WHERE alive=1) УСТАРЕВАЕТ. Батч 0/N живых против реального целевого эндпоинта = пул протух целиком; вывод «сайт блочит прокси» делать нельзя, пока не проверены СВЕЖИЕ списки.
  2. Фри-списки (proxyscrape v4 API, TheSpeedX http.txt) деградируют за часы. Тянуть свежие прямо перед прогоном; вчерашний px_good.txt не переиспользовать без ре-валидации.
  3. Валидация = реальный целевой запрос через прокси, не CONNECT-тест и не ipify. Правильный чек: тот же POST (signup/bootstrap эндпоинт) через -x <proxy>; коды ответа целевого API (200/429/4xx с телом) = прокси живой; 000/timeout = мёртвый. 429 от цели — тоже «прокси работает» (запрос дошёл).
  4. «Too many accounts were created from this network today» (429 с network-формулировкой) = дневной лимит на exit-IP. Прямой коннект бесполезен до следующего дня; обход только ротацией exit-IP. Один рабочий прокси может найтись даже когда пул БД мёртв — сканировать батчами по 100-400, ThreadPoolExecutor(25-40), timeout на прокси ≤20с.
  5. Порядок: сначала функциональный пром сервиса на СУЩЕСТВУЮЩИХ токенах, потом инвестиции в рег-инфру. Если чат/gateway мёртв изнутри (502/upstream_rate_limited на всех моделях), свежие аккаунты ничего не оживят — не жечь час на прокси-скан ради регистраций в мёртвый сервис.

Рецепт батч-скана (проверен, curl-based, stdlib-only)

import subprocess, json
from concurrent.futures import ThreadPoolExecutor

# источники: sqlite proxy_bot pool (alive=1) + свежие фри-списки:
#   curl "https://api.proxyscrape.com/v4/free-proxy-list/get?request=display_proxies&country=all&proxy_type=http&timeout=10000"
#   curl https://raw.githubusercontent.com/TheSpeedX/SOCKS-List/master/http.txt
# формат строки списка: ip:port -> "http://"+строка

def probe(px, target_post):
    try:
        r = subprocess.run(["curl","-s","--max-time","18","-x",px,
            "--proxy-connect-timeout","8","-X","POST",target_post["url"],
            "-H","Content-Type: application/json","-H","User-Agent: "+UA,
            "-d",json.dumps(target_post["payload"]),"-w","\n%{http_code}"],
            capture_output=True, text=True, timeout=26)
        body,_,code = r.stdout.rpartition("\n")
        return px, code.strip(), body[:80]
    except Exception:
        return px, "000", ""

good = []
with ThreadPoolExecutor(max_workers=40) as ex:
    for px, code, body in ex.map(lambda p: probe(p, TARGET), proxies):
        if code in ("200","201","429"):   # 429 = дошёл до цели = живой
            good.append(px)

Питфол: curl -x http://ip:port на SOCKS-порту (1080) висит на CONNECT — из http-списков брать только http-порты; смешанные списки фильтровать.

Кейс-данные (калибровка ожиданий)

  • 2026-10-11, цель usehaze.ai bootstrap: 152 alive-прокси из proxy_bot БД → 0 живых; 400 свежих proxyscrape+TheSpeedX → 0 живых; при этом часом ранее одиночный прокси из той же БД дал 200. Yield фри-проксей под CF-защищённые API — единицы на сотни, закладывать именно так.
  • Рега через найденный прокси проходит (200 verification_required), но сервис оказался мёртв по чату — см. правило 5: пром ПЕРЕД сканом.