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

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

Статус: ✅ РАЗВЁРНУТ 2026-09-28. Приёмка Alex НЕ закрыта (ждёт проверки в UI). Задача Alex: «Ставь flaresolverr как на Кра́кене, запускай трекеры через прокси контейнер чтобы обойти блокировки». Связано: personal/plans/lidarr-taiga-and-indexer-unblock, family/projects/media-toolbox-taiga, family/how-to/arr-stack-kraken, personal/tech/prowlarr-flaresolverr-cloudflare.

Итог: flaresolverr поднят, обходит и DNS-блок, и Cloudflare. Тест индексеров: RuTracker ✅ RuTor ✅ Byrutor ✅ Kinozal(M) ✅ | NoNaMe ❌ (нет FS-тега) Kinozal ❌ (гонка). Оба дефекта закрываемые, см. §«Осталось».

ФАКТИЧЕСКОЕ СОСТОЯНИЕ (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, логи пусты (при LLOG_LEVEL=warning это норма — пароли не пишутся). Swap НЕ трогали — Хватает RAM (21 GB total). Alex отклонил идею swap: «Памяти мало что-ли?».

🔑 ГЛАВНОЕ ОТКРЫТИЕ: 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) — единственный рабочий вариант, request-прокси через Prowlarr передать нельзя (у Prowlarr-прокси Socks5 только host/port/user/pass, поля «передать в FS» нет).

Пруф работы 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\":120000}"'
# → {"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

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

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

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

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

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

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

Prowlarr при PUT сразу тестирует индексер. Если FS в этот момент таймаутит (или челлендж не решён), приходит HTTP 400 с телом:

[{"isWarning":false,"propertyName":"","severity":"error",
  "errorMessage":"Unable to connect to indexer, indexer's server is unavailable. Try again later.
   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 в него не укладывается → Error solving the challenge. Timeout after 60.0 seconds, индексер краснеет. Поднять до 120 (проверено: с 120 челлендж решается). Правка PUT-ом прокси-элемента /2.

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

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

Результат testall (прогон 2026-09-28)

1 RuTracker    ✅ isValid=true
2 RuTor        ✅ isValid=true
3 Byrutor      ✅ isValid=true
6 Kinozal (M)  ✅ isValid=true
4 NoNaMe Club  ❌ "Unable to access nnmclub.to, blocked by CloudFlare Protection"  ← нет FS-тега
5 Kinozal      ❌ "Unable to access kinozal.me, blocked by CloudFlare Protection"  ← гонка testall

Осталось (для следующей сессии)

1. Навесить тег [1,2] на NoNaMe (id 4) — GET → правка → PUT с ?forceSave=true.
2. Перепроверить Kinozal (5) одиночным тестом — по факту FS на kinozal.me/browse.php даёт Challenge solved!, значит это была гонка testall, а не реальный блок.
3. ПРИЁМКА ALEX: https://prowlarr.mallexxx.duckdns.org → Indexers → Test All → зелёные.

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

Файл	Путь
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.

Разведка (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»

vless-proxy жив (его outbound был мёртв после удаления VPS qentra.top — переключён).

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

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

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

IndexerStatus (без снятия): карантин до 2026-09-29T02:25Z у 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 (ShmSize=67108864)	🔴 задать shm_size: 1gb
swap	/proc/swaps пуст → пик старта убивал	/proc/swaps пуст, Swap=0	🔴 поднять swap или принять риск
RAM	мало	21 GB total, 5.6 GB available	✅ хватает
IPv6	::1 localhost ломал	проверить	добавить disable_ipv6=1 (как на Кра́кене, там не помогло, но безвредно)

🔴 Главное отличие от Кра́кена: на Кра́кене FlareSolverr проксирует через себя и лезет в трекер напрямую — но у Кра́кена нет DNS-блока. На Тайге DNS-блок есть, значит FlareSolverr сам должен ходить через vless-proxy (иначе он получит NXDOMAIN и не поможет). Это ключевой архитектурный пункт: у контейнера flaresolverr должен быть настроен upstream-прокси на vless-proxy:1080.

Проверить, поддерживает ли образ env HTTPS_PROXY/SOCKS_PROXY — у FlareSolverr есть PROXY-настройки через переменные окружения и/или поле в request.get. Если env не работает — передавать proxy: {url: "socks5://vless-proxy:1080"} в теле запроса от Prowlarr (Prowlarr умеет это в настройках прокси-элемента? проверить — у Socks5-прокси в Prowlarr есть только host/port/username/password, поля «передать в FS» нет).

✅ ОТКРЫТЫЙ ВОПРОС №1 ЗАКРЫТ (2026-09-28). Схема A работает. У FlareSolverr глобальный прокси задаётся переменной PROXY_URL (НЕ HTTPS_PROXY), формат со схемой обязателен: socks5://vless-proxy:1080. Приоритет: request > session > global. ⚠️ Важно: Prowlarr обращается к FS с параметром session, а при наличии сессии request-прокси игнорируется → сработает именно global (PROXY_URL). Проверено по DeepWiki FlareSolverr §4.2. PROXY_USERNAME/PROXY_PASSWORD не нужны — vless-proxy без авторизации.

ПЛАН

Фаза 0 — внешняя блокировка: ✅ ЗАКРЫТА (проверено выше)

Ничего делать не нужно. Осталось только снять карантин (Фаза 2).

Фаза 1 — FlareSolverr контейнер

1. Бэкап /mnt/RED_2TB/docker/arr/docker-compose.yml → ~truenas_admin/ (cp docker-compose.yml ~truenas_admin/docker-compose.yml.bak-<ts>). Бэкап самого compose отдаёт сам: /tmp не годится (чистится).
2. Проверить схему проксирования FS (открытый вопрос №1) — до правки compose.
3. Добавить сервис в /mnt/RED_2TB/docker/arr/docker-compose.yml:

   flaresolverr:
     image: ghcr.io/flaresolverr/flaresolverr:latest
     container_name: flaresolverr
     restart: unless-stopped
     environment:
       - LOG_LEVEL=warning          # ← НЕ info: info пишет пароли трекеров в plaintext
       - BROWSER_TIMEOUT=60000
       - TZ=Asia/Novosibirsk
       # + прокси-переменные для обхода DNS (если схема A):
       # - HTTP_PROXY=socks5h://vless-proxy:1080
       # - HTTPS_PROXY=socks5h://vless-proxy:1080
     ports:
       - "8191:8191"
     networks:
       - media_net
     shm_size: 1gb                  # ← Кра́кен: 64 MB убивал Chrome
     sysctls:
       - net.ipv6.conf.all.disable_ipv6=1
   

   ⚠️ shm_size и sysctls — в блок сервиса, не в environment.
4. Поднять из правильной папки: cd /mnt/RED_2TB/docker/arr && docker compose up -d flaresolverr (не через временную копию compose — name-conflict, грабля Кра́кена).
5. Проверка живого FS (не UI, а HTTP):

   docker exec prowlarr sh -c 'curl -s -X POST http://flaresolverr:8191/v1 \
     -H "Content-Type: application/json" \
     -d "{\"cmd\":\"request.get\",\"url\":\"https://rutracker.org/forum/index.php\",\"maxTimeout\":60000}"'
   # ожидается: {"status":"ok", ... "solution":{...}} — НЕ "Challenge detected" в ответе
   

   ⚠️ Первый старт Chrome ~20-60 с. docker logs flaresolverr должен показать Challenge solved!, а НЕ session not created: cannot connect to chrome.

ПРИЁМКА ALEX: docker logs --tail 30 flaresolverr → есть Challenge solved!.

Фаза 2 — прокси-элемент в Prowlarr + снятие карантина

1. Добавить/обновить прокси в Prowlarr: Settings → Indexers → Add Proxy → FlareSolverr, host http://flaresolverr:8191, tag flaresolverr. (vless-socks5 остаётся отдельным прокси для DNS-обхода; один индексер может иметь оба тега — проверить.)
2. Навесить тег flaresolverr на RuTracker(1), Kinozal(5), Kinozal(M)(6) — тем же способом через API, что и proxy (GET → jq .tags=[…] → PUT). 🔴 Без одинакового тега на прокси И индексере прокси молча не применяется.
3. Сбросить карантин: POST /api/v1/indexer/testall.
4. ПРИЁМКА ALEX: https://prowlarr.mallexxx.duckdns.org → Indexers → Test All → зелёные.

Фаза 3 — проверка поиска

docker exec prowlarr sh -c 'printf "X-Api-Key: 35c8b3f497114076a6150ea0d9504845" > /tmp/h.txt'
docker exec prowlarr sh -c 'curl -s -G -H @/tmp/h.txt --data-urlencode "query=matrix" \
  --data-urlencode "type=search" http://localhost:9696/api/v1/search' | \
  python3 -c "import json,sys,collections; d=json.load(sys.stdin); \
    print(collections.Counter(x['indexer'] for x in d))"

Ожидается: появляются RuTracker + Kinozal с ненулевым счётом.

ПРИЁМКА ALEX: поиск в UI Prowlarr по конкретному фильму → результат от RuTracker/Kinozal.

Вопросы к Алексу

1. Схема проксирования FlareSolverr (открытый вопрос №1 выше): проверить env-переменные или proxy в теле запроса — сделаю сам, не требует решения. Решение не нужно, если вариант A сработает.
2. Swap на Тайге (Swap=0). На Кра́кене именно мёртвый swap + 64 MB /dev/shm убили Chrome. Варианты: (A) поднять /var/swap на Тайге (как на Кра́кене) — надёжнее; (B) рискнуть с одним shm_size: 1gb и посмотреть. Рекомендую A+C: поднять swap И дать shm 1gb. ⚠️ Трогать swap — системное изменение, согласовать.

История

• 2026-09-28 — разведка. Обнаружено: DNS-блокер УЖЕ закрыт (прокси настроен 2026-09-26), остаточная проблема — Cloudflare на RuTracker/Kinozal. FlareSolverr отсутствует. Составлен план. Ничего не изменено.