git_admin/obsidian-vault
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[2026-09-28] eagle: family/projects/media-toolbox-taiga.md personal/plans/flaresolverr-taiga-deploy.md personal/tech/flaresolverr-taiga.md

Browse Source
This commit is contained in:
Alexey Martemyanov committed 2026-09-28 13:26:36 +06:00
1 parent 6dfedbc142
commit 0ac3efb2f5
3 files changed
+254 -260
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

personal/tech/flaresolverr-taiga.md
+142 -63
View File
@@ -1,14 +1,66 @@
# FlareSolverr на Тайге + обход блокировок индексеров
> ✅ **СОСТОЯНИЕ 2026-09-28: FlareSolverr РАЗВЁРНУТ и работает end-to-end.**
> ✅ **СОСТОЯНИЕ 2026-09-28: ГОТОВО. Все 6 индексеров рабочие, health чистый.**
> Контейнер `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]].
> Бэкапы: `~truenas_admin/docker-compose.yml.bak-20260928-flaresolverr`,
> `~/backup-indexers-20260928-flaresolverr.json` (снимок 6 индексеров до правки тегов).
> Связка: [[personal/plans/flaresolverr-taiga-deploy]], [[personal/plans/lidarr-taiga-and-indexer-unblock]],
> [[family/projects/media-toolbox-taiga]], [[personal/tech/prowlarr-flaresolverr-cloudflare]],
> [[family/how-to/arr-stack-kraken]].
## 🔑 ГЛАВНОЕ ОТЛИЧИЕ ОТ КРА́КЕНА: FlareSolverr сам идёт через прокси
## ✅ РЕЗУЛЬТАТ (поиск «matrix» через `/api/v1/search`)
```
TOTAL 256
RuTor 100 ← был живой
RuTracker 50 ← ВПЕРВЫЕ с 2026-05-20
NoNaMe 50 ← ВПЕРВЫЕ
Kinozal 50 ← ВПЕРВЫЕ
Byrutor 6
```
`GET /api/v1/health` → `[]`, `GET /api/v1/indexerstatus` → `[]`. **Ни одной ошибки,
ни одного карантина.** Было 3/6, стало 6/6 (по выдаче — 5 трекеров; Kinozal (M) — зеркало
Kinozal с magnet-приоритетом, в общую выдачу дублируется).
## 🔑 ГЛАВНОЕ ОТКРЫТИЕ: FS-СЕССИЯ НЕ НАСЛЕДУЕТ `PROXY_URL`
Самый неочевидный пункт всей задачи. Симптом был **ложный**: Prowlarr писал
`blocked by CloudFlare Protection`, а лог FS — мгновенную ошибку за **7 секунд** (не таймаут!).
**Причина:** `PROXY_URL` (глобальный прокси) применяется к Chrome **в момент создания сессии**.
Сессия, созданная **до** появления `PROXY_URL`, остаётся **без прокси** навсегда —
в ней Chrome получает `net::ERR_NAME_NOT_RESOLVED` (DNS-блок!). Prowlarr шлёт запросы
с параметром `session`, и global-прокси её не перебивает.
Пруф — прямой вызов с сессией, созданной ДО прокси:
```
request.get kinozal + session:"prowlarr" (старая)
→ {"status":"error","message":"Error solving the challenge.
Message: unknown error: net::ERR_NAME_NOT_RESOLVED (chrome=152.0.7977.82)"}
```
Тот же запрос с сессией, созданной **ПОСЛЕ** `PROXY_URL` → `Challenge solved! 200`.
**Имя сессии Prowlarr — `prowlarr`** (обнаружено через `sessions.list`).
**Фикс:** удалить устаревшую сессию — `sessions.destroy`; Prowlarr пересоздаёт её сам
при следующем запросе, уже с рабочим `PROXY_URL`.
```bash
docker exec prowlarr sh -c 'curl -s -X POST http://flaresolverr:8191/v1 \
-H "Content-Type: application/json" \
-d "{\"cmd\":\"sessions.destroy\",\"session\":\"prowlarr\"}"'
```
> ⚠️ **Правило на будущее:** после ЛЮБОЙ правки `PROXY_URL` в compose **убить сессию
> `prowlarr`**, иначе старые сессии продолжат ходить без прокси и индексера будут
> «blocked by CloudFlare» при живом FS.
> ✅ При обычном перезапуске FS (watchtower/reboot) проблема НЕ повторится — сессия
> создастся заново уже с `PROXY_URL`.
## 🔑 ВТОРОЕ ОТКРЫТИЕ: FlareSolverr сам идёт через прокси (`PROXY_URL`)
На Кра́кене два механизма независимы: Cloudflare лечится FlareSolverr, DNS-блока нет.
**На Тайге блоков ДВА (DNS + Cloudflare), и FlareSolverr обязан ходить через `vless-proxy`** —
@@ -17,29 +69,33 @@
**Решение:** глобальная 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.
> FlareSolverr §4.2 «Proxy Configuration»). Формат **со схемой обязателен**
> (`socks5://host:port`); без схемы `urllib.parse` не разберёт.
> Приоритет: request > session > global. `PROXY_USERNAME`/`PROXY_PASSWORD` не нужны —
> `vless-proxy` без авторизации.
**Почему срабатывает именно global:** Prowlarr обращается к FS с параметром `session`,
а при наличии сессии request-прокси **игнорируется** → применяется global (`PROXY_URL`).
Схема совпала случайно-удачно: если бы Prowlarr слал request-прокси, он бы его перебил.
## ⚠️ ПИТФОЛЛ: `requestTimeout` = 60 с МАЛО, нужно 120
## ⚠️ ПИТФОЛЛ: `requestTimeout` = 60 с МАЛО, поднят до 180
Дефолтный `requestTimeout` прокси-элемента FlareSolverr в Prowlarr = **60 с**.
Решение CF-челленджа на `/forum/login.php` RuTracker занимает **больше 60 с** →
Решение CF-челленджа на `/forum/login.php` RuTracker и на kinozal занимает **80–100 с** →
`Error solving the challenge. Timeout after 60.0 seconds` в логе FS, Prowlarr отдаёт
`500 InternalServerError [POST] at http://flaresolverr:8191/v1`, а в UI — «blocked by CloudFlare».
`500 InternalServerError [POST] at http://flaresolverr:8191/v1`, в UI — «blocked by CloudFlare».
**Фикс:** `requestTimeout` = **120** (PUT `/api/v1/indexerproxy/2`).
**Фикс:** `requestTimeout` = **180** (PUT `/api/v1/indexerproxy/2`).
Проверка: `docker logs flaresolverr` → `Challenge solved!`, а не `Timeout`.
> Замеры времени челленджа (kinozal.me/browse.php через FS): **78 с** холодный,
> **20 с** прогретый (CF-клэренс привязан к IP прокси), POST-логин — **97 с**.
## ⚠️ ПИТФОЛЛ: параллельный `testall` устраивает гонку за Chrome
Prowlarr тестирует все индексеры **одновременно**, а у FlareSolverr **один** Chrome.
При `testall` челленджи сыпятся таймаутами; если тестировать **по одному** (sequential) —
проходят. Диагноз: вручную одиночный `request.get` проходит за секунды, а `testall` даёт
`Timeout`. **Не верить результату параллельного `testall`** — гонять по одному.
проходят. **Не верить результату параллельного `testall`** — гонять по одному.
Дополнительно: `curl` без `--max-time` виснет, если FS не отвечает — всегда ставить лимит.
## ⚠️ ПИТФОЛЛ: тег нужен И на прокси, И на индексере — и на ОБА прокси
@@ -51,15 +107,16 @@ Prowlarr тестирует все индексеры **одновременно
| `flaresolverr` | 2 | `flaresolverr` (id=2) | обход **Cloudflare** |
Значит на индексер вешаются **оба** тега: `tags=[1,2]`. Один прокси не закрывает оба блока.
Фактически навешено: id 1, 4, 5, 6 → `[1,2]`; id 2, 3 → `[1]` (RuTor/Byrutor живут на одном прокси).
## ⚠️ ПИТФОЛЛ: PUT `/api/v1/indexer/N` → 400, нужен `?forceSave=true`
Prowlarr при PUT **сразу тестирует** индексер. Если FS в этот момент не прошёл
(таймаут/гонка) — `HTTP 400` с `validationFailures`. Именно так «потерялись» теги
после первого PUT: теги откатились к `[1]`.
после первого PUT: они откатились к `[1]`.
**Рабочий путь:** `PUT /api/v1/indexer/N?forceSave=true` → **202** (сохраняет, тест пропускает).
Тест гонять отдельно, по одному.
Тест гонять отдельно, по одному. То же для `/indexerproxy/N`.
## Практические замечания
@@ -75,55 +132,76 @@ Prowlarr при PUT **сразу тестирует** индексер. Если
```
- `sleep 35` после старта контейнера — Chrome поднимается ~30 с; раньше этого `:8191` может не отвечать.
- `shm_size` и `sysctls` — **в блок сервиса** compose, не в `environment`.
- **`ERR_NAME_NOT_RESOLVED` в ответе FS = сессия без прокси** (см. открытие выше), а не «FS сломан».
- **Ключ API в `-H` ломается многоуровневым экранированием** (ssh → docker → sh).
Рабочий приём: `printf "X-Api-Key: <KEY>" > /tmp/h.txt` внутри контейнера, затем `curl -H @/tmp/h.txt`.
- **`python3` внутри контейнера prowlarr НЕТ** — разбирать JSON хостовым `python3`
(на Тайге есть `python3`, нет `curl` и `sqlite3`).
## Состояние индексеров после деплоя (2026-09-28)
## Состояние индексеров после деплоя (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]` | ⏳ то же |
| 1 | RuTracker | `[1,2]` | ✅ valid (был красный с 2026-05-20) |
| 2 | RuTor | `[1]` | ✅ valid |
| 3 | Byrutor | `[1]` | ✅ valid |
| 4 | NoNaMe Club | `[1,2]` | ✅ valid |
| 5 | Kinozal | `[1,2]` | ✅ valid |
| 6 | Kinozal (M) | `[1,2]` | ✅ valid |
## 🔴 ОТКРЫТАЯ ПРОБЛЕМА: Kinozal — челлендж дольше таймаута Prowlarr
## ✅ ЗАКРЫТО: Kinozal — «blocked by CloudFlare» при живом FS
**Факты (замерено):**
- Прямой socks5 к `kinozal.me/browse.php` → **403 Just a moment** за **0.9 с**.
- FS `request.get` kinozal → `Challenge solved! 200`. Время: **78 с** (холодный), **20 с** (прогретый).
Самая долгая часть задачи. Симптом маскировался под таймаут, причина оказалась другой.
**Что замерено (история диагностики):**
- Прямой socks5 к `kinozal.me/browse.php` → **403 Just a moment** за **0.9 с** (CF реален).
- 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: `blocked by CloudFlare Protection`, в логе FS — падение за **7 с** (не таймаут!).
**Механика Prowlarr (из debug-лога) — два прокси применяются ПОСЛЕДОВАТЕЛЬНО:**
**Ложный след:** `HTTP request failed: [500:InternalServerError] [POST] at http://flaresolverr:8191/v1`
и `Error solving the challenge. Timeout after 60/120/180 seconds` — выглядело как «челлендж
дольше таймаута». Поднятие `requestTimeout` 60→120→180 **не помогло**.
**Настоящая причина:** FS-сессия без прокси (см. главное открытие выше). Сессия `prowlarr`,
созданная до появления `PROXY_URL`, падала с `ERR_NAME_NOT_RESOLVED` за 7 с, Prowlarr
интерпретировал это как «CF блокирует» и уходил в retry → карантин.
**Фикс:** `sessions.destroy` сессии `prowlarr` → пересоздана с прокси →
Kinozal (5) и Kinozal (M) (6) прошли с первого раза (`{}`).
**Что исключено (не тратить время повторно):** ресурсы FS в норме (710 MB / 21 GB, shm 1 GB,
CPU 0.68%); канал прокси нормальный (kinozal через socks5 **0.6 с**, 908 KB/s); внутренний
таймаут Prowlarr в `config.xml` не настраивается.
## Compose-сервис (вставлен в `/mnt/RED_2TB/docker/arr/docker-compose.yml`)
```yaml
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
- PROXY_URL=socks5://vless-proxy:1080
ports:
- "8191:8191"
networks:
- media_net
shm_size: 1gb # Кра́кен: 64 MB убивал Chrome
sysctls:
- net.ipv6.conf.all.disable_ipv6=1
```
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).
Порядок деплоя: бэкап compose → правка **локально** (не sed на сервере) → `scp` → `cp` →
`cd /mnt/RED_2TB/docker/arr && docker compose up -d flaresolverr`.
⚠️ `docker compose up -d` **только из своего каталога**, иначе name-conflict (грабля Кра́кена).
**Вывод:** челлендж 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-челленджа, не в конфиг.
> ⚠️ **Swap на Тайге = 0** (`/proc/swaps` пуст). На Кра́кене мёртвый swap + 64 MB `/dev/shm`
> убили Chrome в crash-loop. Здесь обошлось без swap: RAM 21 GB, доступно 5.6 GB, FS держит
> 710 MB, CPU 0.68%. **Swap не трогали** — не нужен при таком объёме памяти.
## История
@@ -131,17 +209,18 @@ Kinozal/Kinozal M — упираются в скорость CF-челлендж
`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`.
Решено последовательно: (1) FS сам ходит через `vless-proxy` (`PROXY_URL`) — двойной обход DNS+CF;
(2) `requestTimeout` 60→180; (3) теги `[1,2]` на все CF-индексеры; (4) **`sessions.destroy`
сессии `prowlarr`** — последний блокер (сессия была создана до `PROXY_URL`).
Итог: **6/6 индексеров, health `[]`, поиск 256 результатов.**
RuTracker впервые `valid` за всё время существования стека (с 2026-05-20).
## Открытые пункты
- Прогнать финальный **sequential** тест всех 6 → зафиксировать результат.
- Kinozal (5): подтвердить `valid` вне гонки (вручную челлендж решается).
- **Приёмка Alex в UI:** `https://prowlarr.mallexxx.duckdns.org` → Indexers → 6 зелёных без карантинов.
- Проверить, что RuTracker реально **логинится** (не только челлендж на login.php) —
тестовый поиск с авторизацией.
выдача 50 результатов намекает, что да.
- 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]].
Заготовка `/tmp/add_proxy_env.py` (HTTP_PROXY/HTTPS_PROXY) — **не применена**;
Lidarr ходит в SkyHook сам, НЕ через FS. Разбирать отдельно —
[[family/plans/lidarr-taiga-deploy]].