# 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:
  ```bash
  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]].