148 lines
11 KiB
Markdown
Executable File
148 lines
11 KiB
Markdown
Executable File
# 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]].
|