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

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

🟢 СОСТОЯНИЕ 2026-09-29: всё работает. Prowlarr логинится в RuTracker сам, поиск отдаёт результаты. Проверено: search?query=radiohead → RuTracker 50, NoNaMe 47, RuTor 33. indexerstatus → [], health → []. Контейнер flaresolverr — штатный образ, PROXY_URL=socks5://vless-proxy:1080, порт 8191, сеть media_net, shm_size: 1gb, LOG_LEVEL=warning. Compose: /mnt/RED_2TB/docker/arr/docker-compose.yml. Связка: family/projects/media-toolbox-taiga, family/plans/lidarr-taiga-deploy, personal/tech/prowlarr-flaresolverr-cloudflare, family/how-to/arr-stack-kraken.

🔴 ПРИЧИНА ВСЕХ ПРОБЛЕМ: путаница аккаунтов (не капча, не прокси, не CF)

Долгая диагностика упиралась в «капчу RuTracker» — причины такой не было.

Prowlarr:  username = mallexxx       password = m@n*w$uperP@$$w0rD
Мой тест:  username = keropjan_88    password = I70aj7Igpr          ← ЛЕВЫЙ аккаунт

RuTracker на неверный пароль отвечает формой логина + капчей. Отсюда ложный вывод «капча блокирует». С правильными данными Prowlarr логинится без капчи: len=251 792, wrong_password=0.

🔴 Прежде чем диагностировать капчу/CF/прокси — сверить пару логин/пароль в Prowlarr:

python3 -c "
import json,sqlite3,shutil
shutil.copy('/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db','/tmp/o.db')
c=sqlite3.connect('/tmp/o.db')
for r in c.execute('SELECT Name,Settings FROM Indexers'):
    s=json.loads(r[1])
    print(r[0], {k:v for k,v in s.items() if 'user' in k.lower() or 'pass' in k.lower()})
"

🔑 FS-СЕССИЯ НЕ НАСЛЕДУЕТ PROXY_URL — убить сессию после правки

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

request.get + session:"prowlarr" (старая)
  → {"status":"error","message":"unknown error: net::ERR_NAME_NOT_RESOLVED"}

Фикс: удалить сессию — Prowlarr пересоздаст её сам уже с прокси.

docker exec prowlarr sh -c 'curl -s --max-time 60 -X POST http://flaresolverr:8191/v1 \
  -H "Content-Type: application/json" -d "{\"cmd\":\"sessions.destroy\",\"session\":\"prowlarr\"}"'

⚠️ После ЛЮБОЙ правки PROXY_URL — убить сессию prowlarr. ✅ Обычный перезапуск FS проблемы не создаёт: сессия создастся заново с прокси.

🔑 Имя переменной — PROXY_URL (не HTTP_PROXY)

PROXY_URL=socks5://vless-proxy:1080 — схема обязательна. Приоритет: request > session > global. Prowlarr обращается к FS с параметром session, поэтому работает именно global. Проверка, что прокси применён (нужен LOG_LEVEL=debug):

INFO  Using proxy URL ENV
DEBUG Using webdriver proxy: socks5://vless-proxy:1080

Почему FS обязан ходить через прокси: на Тайге блоков два — DNS провайдера + Cloudflare. Без прокси FS сам получает NXDOMAIN и не помогает. На Кра́кене DNS-блока нет, поэтому там PROXY_URL не нужен.

🔴 IndexerStatus снимается ТОЛЬКО через SQL — тест его ПРОДЛЕВАЕТ

POST /indexer/test карантин не снимает, а эскалирует: наблюдалось DisabledTill 15:44 → 21:45 после одного теста. Пока запись есть, caps отдаёт 429, и warning каскадом идёт во все arr.

DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db
# 1. бэкап через .backup, НЕ cp (WAL-режим)
sqlite3 "file:$DB?mode=ro" ".backup /home/truenas_admin/prowlarr.db.bak-$(date +%Y%m%d-%H%M%S)"
# 2. стоп → чистка → старт
docker stop prowlarr
sqlite3 "$DB" "DELETE FROM IndexerStatus;"
sqlite3 "$DB" "PRAGMA quick_check;"          # → ok
docker start prowlarr

Поля: EscalationLevel 0–9 (9 = сутки блокировки), DisabledTill. sqlite3 на хосте Тайги есть, в контейнерах — нет.

🔴 ПРИЁМКА — search, а НЕ caps и НЕ health

caps 200 + пустой indexerstatus + health [] не доказывают, что поиск работает.

PK=$(grep -o "<ApiKey>[^<]*" /mnt/RED_2TB/docker/arr/prowlarr/config.xml | cut -d">" -f2)
for I in 1 2 4 5 6; do
  echo "idx$I=$(curl -s --max-time 200 "http://localhost:9696/api/v1/search?query=radiohead&type=search&indexerIds=$I" \
    -H "X-Api-Key: $PK" | python3 -c 'import json,sys
try:
  d=json.load(sys.stdin); print(len(d) if isinstance(d,list) else "ERR")
except: print("EMPTY")')"
done

Прокси-элементы и теги (в Prowlarr)

Прокси	id	Тег	Закрывает
vless-socks5	1	proxy (1)	DNS-блок провайдера
flaresolverr	2	flaresolverr (2)	Cloudflare

CF-индексеры получают оба тега: tags=[1,2]. RuTor/Byrutor живут на одном ([1]). requestTimeout прокси-элемента flareSolverr = 180 (дефолт 60 мало: челлендж занимает 80–100 с).

⚠️ ПИТФОЛЛЫ API

• PUT /api/v1/indexer/N → 400, нужен ?forceSave=true → 202. Без него теги откатываются: Prowlarr при PUT сразу тестирует индексер, и при падении FS откатывает сохранение.
• POST /indexer/test требует ПОЛНЫЙ объект, не {"id":N} (иначе 400). {} + 200 = успех.
• testall вреден: один Chrome у FS → гонка за него, челленджи сыпятся таймаутами. Тестировать по одному.
• GET /indexerstatus есть только в Prowlarr — в Radarr/Sonarr → 404.
• 429 на /N/api?t=caps = карантин Prowlarr → каскад 429:TooManyRequests во все arr. Лечить снизу вверх: SQL-очистка в Prowlarr → PUT ?forceSave=true в arr → docker restart arr.
• Ключ API в -H ломается экранированием (ssh → docker → sh): printf "X-Api-Key: KEY" > /tmp/h.txt, затем curl -H @/tmp/h.txt.
• python3 в контейнере prowlarr НЕТ (на хосте Тайги есть; curl и sqlite3 на хосте — нет).

⚠️ ПИТФОЛЛЫ FlareSolverr

• sessions.create → {"status":"ok","version":"3.5.2"} — быстрый smoke-тест живости.
• LOG_LEVEL=warning (не info!) — info пишет login_password трекеров в plaintext в лог.
• sleep ~30 после старта контейнера: Chrome поднимается, до этого :8191 может не отвечать.
• sessions.destroy несуществующей сессии → HTTP 500, не «ok/not found» (оборачивать в try).
• shm_size/sysctls — в блок сервиса compose, не в environment.
• Порт 8191 с Mac наружу не проброшен — скрипты запускать на хосте Тайги (scp + ssh python3).

⚠️ ПИТФОЛЛ: Auth Failed ≠ неверный пароль

RuTracker Auth Failed в Prowlarr не доказывает неверный пароль (см. главный раздел — причина была в чужом аккаунте). Диагностический порядок:

1. request.post на /forum/login.php с session=prowlarr → судить по длине HTML.
2. Если ~13 KB — смотреть IndexerStatus в БД (может быть карантин, а не пароль).
3. Только потом — вопрос к паре логин/пароль.

🔴 Признак «залогинен» — РАЗМЕР страницы, а не подстрока:

len HTML	Что это
~250 KB	залогиненный форум ✅
~13 KB	форма логина вернулась ❌

⚠️ Подстрока login_username присутствует в обоих случаях (HTML-шаблон + скрытая форма быстрого входа). По ней диагноз ставить нельзя — именно это давало ложное «пароль неверен».

⚠️ Кэш health в arr-сервисах

RemotePathMappingCheck и подобные кэшируются: создание каталогов ошибку не снимает, PUT по API тоже не сбрасывает. Нужен docker restart radarr sonarr lidarr.

Три механизма прокси на одном хосте — не путать

Кто	Механизм	Ключ
Prowlarr (индексеры)	SOCKS5-прокси в Prowlarr + FlareSolverr	теги [1,2], PROXY_URL у FS
FlareSolverr (Chrome)	глобальный прокси образа	env PROXY_URL (НЕ HTTP_PROXY)
Lidarr (SkyHook)	встроенный конфиг приложения	config/host.proxyEnabled (env НЕ работает)

⚠️ Не переносить рецепт одного сервиса на другой — проверять фактическим запросом.

Compose-сервис

  flaresolverr:
    image: ghcr.io/flaresolverr/flaresolverr:latest
    container_name: flaresolverr
    restart: unless-stopped
    environment:
      - LOG_LEVEL=warning          # НЕ info — пишет пароли в plaintext
      - BROWSER_TIMEOUT=60000
      - TZ=Asia/Novosibirsk
      - PROXY_URL=socks5://vless-proxy:1080
    ports:
      - "8191:8191"
    networks:
      - media_net
    shm_size: 1gb
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=1

Деплой: правка локально (не sed) → scp → cd /mnt/RED_2TB/docker/arr && docker compose up -d flaresolverr. ⚠️ docker compose up -d только из своего каталога, иначе name-conflict.

⚠️ Swap на Тайге = 0 — не мешает: RAM 21 GB, FS держит ~710 MB, CPU 0.68%. Swap не трогать. ⚠️ У FS нет persistent-профиля Chrome: он живёт в контейнере и умирает при пересоздании. Это не проблема — FS логинится в RuTracker при каждом старте без капчи.

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

id	Индексер	Теги	Поиск
1	RuTracker	[1,2]	✅ 50
2	RuTor	[1]	✅ 33
3	Byrutor	[1]	—
4	NoNaMe Club	[1,2]	✅ 47
5	Kinozal	[1,2]	⚠️ CF, периодически в карантине
6	Kinozal (M)	[1,2]	⚠️ зеркало Kinozal (5)

🔴 Чего НЕ делать (проверено, не работает)

Идея	Почему нет
Капча-солвер (CAPTCHA_SOLVER)	Официально non-functional (DeepWiki FS, issue #1452 закрыт). Адаптеры удалены из образа. И по факту капча не нужна — см. главный раздел
Вписать cookies в Prowlarr вручную	Индексер принимает только username/password, поля для cookie нет
noVNC/свой образ FS для ручного входа	Строилось под ложную гипотезу «капча». Снесено 2026-09-29. Не воссоздавать
Браузер Alex через 3x-ui	vless-proxy — клиент, не сервер; cf_clearance привязан к IP+UA+fingerprint
Persistent-профиль Chrome у FS	Не решает ничего: FS логинится сам

🔴 Не строить план на посылке «на Кра́кене работает». На 2026-09-29 у Кра́кена в БД тот же карантин EscalationLevel=9 (RuTracker/Kinozal/Kinozal M, с 27 сен) и нет капча-солвера. «Как на Кра́кене» ≠ «починить».