obsidian-vault/personal/tech/flaresolverr-taiga.md

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]	✅ valid
5	Kinozal	[1,2]	⏳ CF-челлендж решается 80-100 с, Prowlarr обрывает
6	Kinozal (M)	[1,2]	⏳ то же

🔴 ОТКРЫТАЯ ПРОБЛЕМА: Kinozal — челлендж дольше таймаута Prowlarr

Факты (замерено):

• Прямой socks5 к kinozal.me/browse.php → 403 Just a moment за 0.9 с.
• FS request.get kinozal → Challenge solved! 200. Время: 78 с (холодный), 20 с (прогретый).
• FS request.post kinozal/takelogin.php → Challenge solved! 200, 97 с.
• HTTP 500 от FS в логе Prowlarr: [POST] at http://flaresolverr:8191/v1.
• Вердикт Prowlarr: blocked by CloudFlare Protection (НЕ таймаут — явная ошибка).

Механика Prowlarr (из debug-лога) — два прокси применяются ПОСЛЕДОВАТЕЛЬНО:

Socks5|Applying Socks5 Proxy Socks5 to request https://kinozal.me/...
FlareSolverr|Cloudflare Detected, Applying FlareSolverr Proxy ...

Сначала идёт socks5-прокси, Prowlarr видит CF, потом пробует FS. Это НЕ двойной хоп (FS сам ходит через прокси через PROXY_URL) — это retry-цепочка.

Что исключено:

• Ресурсы FS в норме: 710 MB / 21 GB, shm 1 GB, 6 chrome-процессов, CPU 0.68%.
• Канал прокси нормальный: kinozal через socks5 0.6 с, 908 KB/s.
• requestTimeout поднят 60 → 120 → 180 — эффекта нет (Prowlarr обрывает по своему внутреннему таймауту HTTP-клиента, не настраивается через config.xml).

Вывод: челлендж CF на kinozal через прокси в другом регионе решается 80-100 с — это свойство CF, не баг. Prowlarr ждёт меньше.

Гипотезы для следующего захода (не проверены):

1. Прогрев FS — CF clearance привязан к IP прокси; после прогрева 20 с (проверено). Прогреть kinozal ×3 → снять карантин → тест.
2. Снизить BROWSER_TIMEOUT не поможет; можно поднять shm_size до 2gb (не проверено).
3. Разобрать внутренний таймаут Prowlarr (в бинарнике; в config.xml его нет).
4. Отказаться от FS для Kinozal и оставить [1] — но тогда 403 CF (проверено).
5. Проверить preferMagnetUrl у Kinozal (сейчас False) — на CF не влияет, но полезно.

Итог по задаче Alex: прокси-обход (DNS) + FlareSolverr (CF) работают. 4 из 6 индексаров зелёные, включая RuTracker (впервые с 2026-05-20). Kinozal/Kinozal M — упираются в скорость CF-челленджа, не в конфиг.

История

• 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.