FlareSolverr на Тайге + обход блокировок индексеров

✅ СОСТОЯНИЕ 2026-09-28: FlareSolverr РАЗВЁРНУТ и работает end-to-end. Контейнер flaresolverr (v3.5.2), порт 8191, сеть media_net, shm_size: 1gb, LOG_LEVEL=warning, PROXY_URL=socks5://vless-proxy:1080. Compose — /mnt/RED_2TB/docker/arr/docker-compose.yml (6-й сервис). Бэкап: ~truenas_admin/docker-compose.yml.bak-20260928-flaresolverr. Связка: personal/plans/lidarr-taiga-and-indexer-unblock, family/projects/media-toolbox-taiga, personal/tech/prowlarr-flaresolverr-cloudflare, family/how-to/arr-stack-kraken.

🔑 ГЛАВНОЕ ОТЛИЧИЕ ОТ КРА́КЕНА: FlareSolverr сам идёт через прокси

На Кра́кене два механизма независимы: Cloudflare лечится FlareSolverr, DNS-блока нет. На Тайге блоков ДВА (DNS + Cloudflare), и FlareSolverr обязан ходить через vless-proxy — иначе он сам получит NXDOMAIN и не поможет.

Решение: глобальная env-переменная FlareSolverr PROXY_URL=socks5://vless-proxy:1080.

⚠️ Имя переменной — PROXY_URL, НЕ HTTP_PROXY/HTTPS_PROXY (проверено по DeepWiki FlareSolverr §4.2). Формат со схемой обязателен (socks5://host:port); без схемы — urllib.parse не разберёт. Приоритет: request > session > global.

Почему срабатывает именно global: Prowlarr обращается к FS с параметром session, а при наличии сессии request-прокси игнорируется → применяется global (PROXY_URL). Схема совпала случайно-удачно: если бы Prowlarr слал request-прокси, он бы его перебил.

⚠️ ПИТФОЛЛ: `requestTimeout` = 60 с МАЛО, нужно 120

Дефолтный requestTimeout прокси-элемента FlareSolverr в Prowlarr = 60 с. Решение CF-челленджа на /forum/login.php RuTracker занимает больше 60 с → Error solving the challenge. Timeout after 60.0 seconds в логе FS, Prowlarr отдаёт 500 InternalServerError [POST] at http://flaresolverr:8191/v1, а в UI — «blocked by CloudFlare».

Фикс: requestTimeout = 120 (PUT /api/v1/indexerproxy/2). Проверка: docker logs flaresolverr → Challenge solved!, а не Timeout.

⚠️ ПИТФОЛЛ: параллельный `testall` устраивает гонку за Chrome

Prowlarr тестирует все индексеры одновременно, а у FlareSolverr один Chrome. При testall челленджи сыпятся таймаутами; если тестировать по одному (sequential) — проходят. Диагноз: вручную одиночный request.get проходит за секунды, а testall даёт Timeout. Не верить результату параллельного testall — гонять по одному.

⚠️ ПИТФОЛЛ: тег нужен И на прокси, И на индексере — и на ОБА прокси

Индексерам за DNS-блоком нужны два прокси-элемента и два тега:

Прокси	id	Тег	Назначение
`vless-socks5`	1	`proxy` (id=1)	обход DNS-блока провайдера
`flaresolverr`	2	`flaresolverr` (id=2)	обход Cloudflare

Значит на индексер вешаются оба тега: tags=[1,2]. Один прокси не закрывает оба блока.

⚠️ ПИТФОЛЛ: PUT `/api/v1/indexer/N` → 400, нужен `?forceSave=true`

Prowlarr при PUT сразу тестирует индексер. Если FS в этот момент не прошёл (таймаут/гонка) — HTTP 400 с validationFailures. Именно так «потерялись» теги после первого PUT: теги откатились к [1].

Рабочий путь: PUT /api/v1/indexer/N?forceSave=true → 202 (сохраняет, тест пропускает). Тест гонять отдельно, по одному.

Практические замечания

Логи FS пусты при LOG_LEVEL=warning — это правильно: на info он пишет login_password трекеров в plaintext. Не поднимать уровень ради «посмотреть».
sessions.create → ok, version 3.5.2 — быстрый smoke-тест живости FS.

Прямая проверка FS из prowlarr:

docker exec prowlarr sh -c 'curl -s --max-time 150 -X POST http://flaresolverr:8191/v1 \
  -H "Content-Type: application/json" \
  -d "{\"cmd\":\"request.get\",\"url\":\"https://rutracker.org/forum/login.php\",\"maxTimeout\":130000}"'
# ожидается: {"status":"ok","message":"Challenge solved!", ...}

sleep 35 после старта контейнера — Chrome поднимается ~30 с; раньше этого :8191 может не отвечать.
shm_size и sysctls — в блок сервиса compose, не в environment.

Состояние индексеров после деплоя (2026-09-28)

id	Индексер	Теги	Статус
1	RuTracker	`[1,2]`	✅ valid (был красный с 2026-05-20)
2	RuTor	`[1]`	✅ valid (DNS-блок обходится одним прокси)
3	Byrutor	`[1]`	✅ valid (резолвится без прокси)
4	NoNaMe Club	`[1,2]`	✅ тег навешен; CF лечится FS
5	Kinozal	`[1,2]`	⏳ гонка при testall, вручную → `Challenge solved!`
6	Kinozal (M)	`[1,2]`	✅ valid

История

2026-09-26 — разведка под Lidarr. Найдено: DNS-блок провайдера (NXDOMAIN на 4 трекера), vless-proxy не в media_net. Прокси-маршрут для Prowlarr починен в тот же день (3/6 индексеров). Остаток — Cloudflare на RuTracker/Kinozal. personal/plans/lidarr-taiga-and-indexer-unblock
2026-09-28 — FlareSolverr развёрнут по задаче Alex «ставь как на Кра́кене + прокси-контейнер». Ключевое: FS сам ходит через vless-proxy (PROXY_URL) — двойной обход DNS+CF. RuTracker впервые стал valid за всё время существования стека (с 2026-05-20). Питфоллы: requestTimeout 60→120, ?forceSave=true, гонка параллельного testall.

Открытые пункты

Прогнать финальный sequential тест всех 6 → зафиксировать результат.
Kinozal (5): подтвердить valid вне гонки (вручную челлендж решается).
Проверить, что RuTracker реально логинится (не только челлендж на login.php) — тестовый поиск с авторизацией.
Lidarr: метаданные api.lidarr.audio → 403 CF прямым, 200 через vless-proxy. Ранее заготовлен /tmp/add_proxy_env.py (HTTP_PROXY/HTTPS_PROXY) — не применён; теперь у FlareSolverr есть PROXY_URL, но Lidarr ходит в SkyHook сам, не через FS. Разбирать отдельно — family/plans/lidarr-taiga-deploy.

7.9 KiB Raw Blame History Unescape Escape