obsidian-vault/personal/plans/flaresolverr-taiga-deploy.md

FlareSolverr на Тайге + обход блокировок индексеров — план/отчёт

Статус: ✅ ВЫПОЛНЕНО 2026-09-28. Итог 6/6 индексеров, health → [] (пусто). Поиск «matrix» → 256 результатов (RuTor 100, RuTracker 50, NoNaMe 50, Kinozal 50, Byrutor 6). RuTracker впервые valid за всё время стека (с 2026-05-20). Полный разбор, все питфоллы и команды — personal/tech/flaresolverr-taiga. Связано: personal/plans/lidarr-taiga-and-indexer-unblock, family/projects/media-toolbox-taiga, family/how-to/arr-stack-kraken, personal/tech/prowlarr-flaresolverr-cloudflare.

🔴 Главный питфолл: FS-сессия prowlarr, созданная ДО появления PROXY_URL, навсегда остаётся без прокси → ERR_NAME_NOT_RESOLVED → Prowlarr пишет ложное «blocked by CloudFlare» (симптом маскируется под таймаут CF). Лечится sessions.destroy + session:"prowlarr"; пересоздаётся сама.

ФАКТИЧЕСКОЕ СОСТОЯНИЕ (2026-09-28, после деплоя)

Контейнер flaresolverr — ✅ работает

/mnt/RED_2TB/docker/arr/docker-compose.yml (122 строки), сервис flaresolverr:

  flaresolverr:
    image: ghcr.io/flaresolverr/flaresolverr:latest
    container_name: flaresolverr
    restart: unless-stopped
    environment:
      - LOG_LEVEL=warning
      - BROWSER_TIMEOUT=60000
      - TZ=Asia/Novosibirsk
      - PROXY_URL=socks5://vless-proxy:1080   # ← ключ: обход DNS-блока
    ports:
      - "8191:8191"
    networks:
      - media_net
    shm_size: 1gb                              # ← Кра́кен: 64 MB убивал Chrome
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=1

Поднят: cd /mnt/RED_2TB/docker/arr && docker compose up -d flaresolverr → Up, рестартов 0. Логи пусты при LOG_LEVEL=warning — это норма (пароли трекеров не пишутся).

Swap НЕ трогали. Alex отклонил идею: «Назуя тебе свап? Памяти мало что-ли?» — и был прав: RAM 21 GB, FS держит 710 MB / 21 GB, CPU 0.68%. Swap на этом хосте не нужен.

🔑 ГЛАВНОЕ ОТКРЫТИЕ №1: FS нужен PROXY_URL, иначе он бесполезен на Тайге

На Кра́кене DNS-блока нет → FS ходит в трекер напрямую. На Тайге DNS-блок есть → FS сам должен ходить через vless-proxy. Решается глобальной env PROXY_URL (НЕ HTTPS_PROXY):

Что	Значение
Переменная	PROXY_URL (проверено по DeepWiki FlareSolverr §4.2)
Формат	со схемой обязателен: socks5://vless-proxy:1080
Приоритет	request > session > global
Авторизация	не нужна (PROXY_USERNAME/PROXY_PASSWORD пусты)

⚠️ Prowlarr обращается к FS с параметром session; при наличии сессии request-прокси игнорируется → срабатывает именно global PROXY_URL. Схема A (env) — единственный рабочий вариант: у Prowlarr-прокси Socks5 только host/port/user/pass, поля «передать в FS» нет.

🔑 ГЛАВНОЕ ОТКРЫТИЕ №2: FS-сессия НЕ наследует PROXY_URL

Самая дорогая грабля задачи. PROXY_URL применяется к Chrome в момент создания сессии. Сессия, созданная до появления PROXY_URL, остаётся без прокси навсегда и падает с ERR_NAME_NOT_RESOLVED, а Prowlarr трактует это как «blocked by CloudFlare Protection».

Имя сессии Prowlarr — prowlarr. Фикс: sessions.destroy → пересоздастся сама.

⚠️ После ЛЮБОЙ правки PROXY_URL — убить сессию prowlarr. ✅ При обычном перезапуске FS (watchtower/reboot) проблема не повторится.

Prowlarr: прокси-элементы и теги

Элемент	id	Настройки	tags
vless-socks5 (Socks5)	1	host vless-proxy, port 1080	[1]
flaresolverr (FlareSolverr)	2	host http://flaresolverr:8191/, requestTimeout 180	[2]

Теги: proxy = id 1, flaresolverr = id 2.

Индексерам нужны ОБА тега — proxy (DNS-обход через SOCKS5) и flaresolverr (CF-челлендж). Финальное состояние:

id	Индексер	tags	Статус
1	RuTracker	[1, 2]	✅ valid
4	NoNaMe Club	[1, 2]	✅ valid
5	Kinozal	[1, 2]	✅ valid
6	Kinozal (M)	[1, 2]	✅ valid
2	RuTor	[1]	✅ valid
3	Byrutor	[1]	✅ valid

Пруф работы FS (не UI — прямой HTTP)

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!", "solution": {"status": 200, ...}}

Результаты прямых тестов:

URL	Ответ FS
rutracker.org/forum/index.php	ok / Challenge not detected / 200
rutracker.org/forum/login.php	ok / Challenge solved! / 200
kinozal.me/browse.php	ok / Challenge solved! / 200
nnmclub.to/forum/index.php	ok / Challenge not detected / 200
sessions.create	ok / Session created successfully / v3.5.2

🔴 ПИТФОЛЛ: PUT /api/v1/indexer/N падает 400 из-за теста FS

Prowlarr при PUT сразу тестирует индексер. Если FS в этот момент не прошёл — HTTP 400 с validationFailures (HTTP request failed: [500:InternalServerError] [POST] at [http://flaresolverr:8191/v1]). Теги при этом НЕ применяются (откатываются).

Обход — ?forceSave=true:

curl -X PUT -H @/tmp/h.txt -H "Content-Type: application/json" \
  -d @/tmp/ix1-new.json "http://localhost:9696/api/v1/indexer/1?forceSave=true"
# → 202 (сохранил, тест пропущен)

🔴 ПИТФОЛЛ: requestTimeout=60 у FS-прокси МАЛО

Дефолт прокси-элемента — 60 с. CF-челлендж на /forum/login.php и kinozal занимает 78–97 с → Error solving the challenge. Timeout after 60.0 seconds, индексер краснеет. Поднять до 180 (правка PUT-ом прокси-элемента /2). PUT → 202.

🔴 ПИТФОЛЛ: testall параллельный → Chrome захлёбывается

POST /api/v1/indexer/testall тестирует все 6 индексеров одновременно, а Chrome в FS — один. Часть челленджей отваливается по таймауту (ложный «blocked by CloudFlare Protection»). Правило диагностики: если testall показал Cloudflare-блок — перепроверять одиночным request.get с большим maxTimeout, а не верить testall. Это грабля, стоившая времени.

ПЛАН ВЫПОЛНЕН — по фазам

Фаза	Что	Статус
0	Внешняя блокировка / DNS-прокси	✅ была закрыта ранее (2026-09-26)
1	FlareSolverr контейнер + PROXY_URL	✅ выполнено
2	Прокси-элемент + теги [1,2] + карантин	✅ выполнено
3	Проверка поиска	✅ 256 результатов
4	sessions.destroy (не входила в план, найдена по ходу)	✅ выполнено

🔴 Что чуть не стало ложным выводом (методический урок)

Первые прогоны дали «4/6», и вывод «Kinozal упирается в скорость CF-челленджа, не в конфиг» был неверным. Спасло то, что замер падения показал 7 секунд — при 78–97 с у челленджа это физически не таймаут. Отсюда найден ERR_NAME_NOT_RESOLVED и корень. Урок: когда «таймаут» короче самого медленного шага — это не таймаут, а другая ошибка. Смотреть фактическое время, а не текст сообщения.

Бэкапы (перед изменениями)

Файл	Путь
compose (до правки)	~truenas_admin/docker-compose.yml.bak-20260928-flaresolverr (2313 B)
индексеры (до тегов)	~/backup-indexers-20260928-flaresolverr.json (390701 B, на Mac)

Рабочая техника API-вызовов (повтор от грабель)

Ключ Prowlarr в файл внутри контейнера + -H @/tmp/h.txt — иначе кавычки ломаются на уровне ssh/sh, и API отвечает 401 даже с верным ключом:

docker exec prowlarr sh -c 'printf "X-Api-Key: 35c8b3f497114076a6150ea0d9504845" > /tmp/h.txt; \
  printf "Content-Type: application/json" > /tmp/ct.txt'
docker exec prowlarr sh -c 'curl -s -H @/tmp/h.txt http://localhost:9696/api/v1/indexer'

Разбор JSON — на хосте (python3 в контейнере Prowlarr НЕТ: sh: python3: not found). Долгие операции (testall) — через docker exec -d в фон + файл-маркер .done. curl без --max-time виснет, если FS не отвечает — всегда ставить лимит.

Разведка (2026-09-28, что было ДО работы)

Что УЖЕ было сделано (не переделывать!)

Прошлый план (2026-09-26) предполагал два блока. Блокер №2 (DNS) был закрыт, а с ним и большая часть Фазы 0:

Что	Факт 2026-09-28
vless-proxy в media_net	✅ есть, IP 172.16.17.6, резолвится из prowlarr
Прокси в Prowlarr	✅ vless-socks5 (id=1), Socks5, host vless-proxy, port 1080
Тег	✅ proxy (id=1); навешен и на прокси, и на все 6 индексеров
Работоспособность прокси	✅ rutracker.org → 301, nnmclub.to → 200, kinozal.me → 200
URL индексеров	✅ Kinozal/Kinozal(M) уже на kinozal.me (не мёртвый .tv)
Поиск через Prowlarr	✅ RuTor 100 + Byrutor 6 на «matrix»

Что ОСТАВАЛОСЬ (суть задачи)

Остаточная проблема — не DNS, а Cloudflare. Прямой факт:

GET https://rutracker.org/forum/login.php  через socks5h://vless-proxy:1080
  → <title>Just a moment...</title> + challenges.cloudflare.com   ← JS-челлендж

IndexerStatus (без снятия): карантин у id 1 (RuTracker), 5 (Kinozal), 6 (Kinozal M). initialFailure = 2026-05-20 (день деплоя). FlareSolverr на Тайге отсутствовал (docker ps -a | grep flare → пусто).

Риски (грабли Кра́кена — что проверяли заранее)

Из personal/tech/prowlarr-flaresolverr-cloudflare §2026-09-24 — там FlareSolverr ушёл в crash-loop, Chrome не поднимался под chromedriver.

Условие	Кра́кен (сломано)	Тайга	Итог
/dev/shm	64 MB → Chrome падал	64 MB	✅ задали shm_size: 1gb
swap	пуст → пик старта убивал	пуст, Swap=0	✅ не нужен — RAM 21 GB
RAM	мало	21 GB, 5.6 GB free	✅ хватает
IPv6	::1 localhost	—	добавили disable_ipv6=1 (безвредно)

История

• 2026-09-26 — разведка под Lidarr. Найдено: DNS-блок провайдера (NXDOMAIN на 4 трекера), vless-proxy не в media_net. Прокси-маршрут для Prowlarr починен в тот же день (3/6 индексеров). Остаток — Cloudflare. Первоначальный план — personal/plans/lidarr-taiga-and-indexer-unblock.
• 2026-09-28 — разведка: DNS-блокер уже закрыт, остаток — Cloudflare, FS отсутствует. Составлен план, ждал «go». Ничего не изменено.
• 2026-09-28 (тот же день, после «Го») — ВЫПОЛНЕНО. FlareSolverr развёрнут, 6/6 индексеров, health [], поиск 256. Питфоллы: requestTimeout 60→180, ?forceSave=true, гонка testall, и главный — смена PROXY_URL не обновляет существующую FS-сессию.
• 2026-09-28 (вечер, тот же день) — Lidarr дозакрыт до прод-уровня. SkyHook-блокер снят: api.lidarr.audio → 403 прямым, 200 через прокси; env HTTP_PROXY Lidarr НЕ читает, рабочий фикс — встроенный config/host.proxyEnabled → vless-proxy:1081. Проверено end-to-end: lookup → артист → 23 раздачи. Попутно: созданы каталоги Downloads/{radarr,sonarr} (Radarr/Sonarr их ждали), выявлен неверный пароль RuTracker. Детали — family/plans/lidarr-taiga-deploy, personal/tech/flaresolverr-taiga.

Остаток после сессии 2026-09-28 (не блокирует Prowlarr/FlareSolverr)

1. 🔴 Пароль RuTracker неверен — POST-логин через FS возвращает форму логина + «неверные данные» + капча. Нужен верный пароль от Alex. Даёт Auth Failed в testall Prowlarr.
2. Radarr/Sonarr: каталоги Downloads/{radarr,sonarr} созданы, но RemotePathMappingCheck в health держится — нужен docker restart radarr sonarr (кэш проверки). ⏳ не выполнен.
3. Indexer-warnings в Radarr/Sonarr снимаются POST /api/v3/indexer/testall (отдаёт 400 с телом-массивом по индексеру — парсить тело, не код).
4. Приёмка Alex в UI: https://prowlarr.mallexxx.duckdns.org → 6 зелёных; https://lidarr.mallexxx.duckdns.org → поиск артиста работает. Открытый вопрос по swap закрыт Alex (не нужен — RAM 21 GB).