From 8174fc8d3cfe331389e2398a043370e93a7853b5 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 28 Sep 2026 17:11:16 +0600 Subject: [PATCH] [2026-09-28] eagle: family/how-to/arr-stack-kraken.md personal/tech/flaresolverr-taiga.md --- family/how-to/arr-stack-kraken.md | 11 ++ personal/tech/flaresolverr-taiga.md | 186 +++++++++++++++++++++++++--- 2 files changed, 177 insertions(+), 20 deletions(-) diff --git a/family/how-to/arr-stack-kraken.md b/family/how-to/arr-stack-kraken.md index 4a455ffe..f4b86150 100755 --- a/family/how-to/arr-stack-kraken.md +++ b/family/how-to/arr-stack-kraken.md @@ -489,6 +489,17 @@ sudo docker start prowlarr ``` ⚠️ В контейнерах `sqlite3` НЕТ; на хосте Kraken `/usr/bin/sqlite3` ЕСТЬ. +> 🔴 **Тайга 2026-09-29:** эта процедура (`DELETE FROM IndexerStatus`) на Тайге **не выполнялась +> ни разу** — карантины снимали тестами через API, что их **продлевало** (`EscalationLevel` +> доходил до 9, `DisabledTill` +24 ч). Урок: **`POST /indexer/test` карантин не сбрасывает, +> а эскалирует.** Всегда SQL. Разбор — [[personal/tech/flaresolverr-taiga]] §«IndexerStatus». +> +> ⚠️ **И общий предел метода (обе машины):** снятие карантина даёт `caps 200` и пустой +> `indexerstatus`, но **не гарантирует работу поиска**. Если RuTracker не пропускает +> автоматический логин (нет куки `bb_data` в cookies FS), поиск через него не идёт при +> формально «зелёной» инфраструктуре. **Приёмка — `search` с `group_by(.indexer)`,** +> не `caps` и не `health`. + **Побочно: RuTor не фильтрует по категориям.** У него в caps заявлены 2000(Movies)/5000(TV)/8000(Other), но при передаче `cat=5000` он возвращает 0 результатов, а без `cat` — 100. Prowlarr сам подсказывает в полях индексера: *«RuTor does not return categories in its search results. To sync to your apps, include 8000(Other)»*. Поэтому в Sonarr (indexer id=8) категория RuTor переставлена `5000` → `8000`. ### Версии и сервис diff --git a/personal/tech/flaresolverr-taiga.md b/personal/tech/flaresolverr-taiga.md index e16b6a4a..47c09afd 100755 --- a/personal/tech/flaresolverr-taiga.md +++ b/personal/tech/flaresolverr-taiga.md @@ -1,17 +1,22 @@ # FlareSolverr на Тайге + обход блокировок индексеров -> ✅ **СОСТОЯНИЕ 2026-09-28 (поздний вечер, ФИНАЛ): ГЛАВНЫЙ ДЕФЕКТ ЗАКРЫТ — RuTracker починен Alex'ом.** -> **Prowlarr** — `health` → `[]`, `indexerstatus` → `[]`, `caps` 1/5/6 → **200**, 6/6 настроены, RuTracker **вне карантина**. -> **Radarr/Sonarr/Lidarr** — на момент последнего аудита держали **кэш health** со старым `RuTracker`; -> лечится `docker restart radarr sonarr lidarr` (команда ждала апрува Alex — не выполнена в этой сессии). -> **Lidarr** — SkyHook работает, `musicCategory=lidarr` применён (202), поиск релизов отдаёт **43** FLAC-раздачи. -> ⚠️ Открыто **1**: **RuTor** — `no results in the configured categories` (трекер не отдаёт фильмы/сериалы, -> не блокировка и не карантин). Всё остальное закрыто. +> 🔴 **СОСТОЯНИЕ 2026-09-29 (ФИНАЛ СЕССИИ): инфраструктура чиста, НО поиск через CF-индексеры НЕ работает.** +> **Prowlarr** — `IndexerStatus` **очищен через SQL** (было `EscalationLevel=9`, сутки), `health` → `[]`, +> `indexerstatus` → `[]`, **`caps` всех 6 → 200**. Это максимум, что даёт инфраструктура. +> **НО** реальный поиск: `total=79`, отдали **только NoNaMe (47) и RuTor (32)**; +> RuTracker/Kinozal/Kinozal(M) → **429** через минуты после очистки, в логе +> `FlareSolverrException: Empty cookies returned by FlareSolverr` (`FlareSolverr.cs:68`). +> 🔴 **КОРЕНЬ (найден в этой сессии): у сессии нет куки `bb_data`** — только `cf_clearance` + `bb_guid`. +> Это значит **логин RuTracker не выполняется**, а не «CF блокирует». Детали — раздел ниже. +> **Radarr/Sonarr/Lidarr** — health чистый; warning-и про индексе́ры живут в БД **Prowlarr**, не у них. +> **Lidarr** — SkyHook работает, `musicCategory=lidarr` применён, поиск релизов отдаёт **43** FLAC. +> ⚠️ Открыто: **RuTracker** — автоматический логин невозможен (нужен Alex, см. ниже); +> **RuTor** — `no results in the configured categories` (на стороне трекера). > Контейнер `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`, -> `~/backup-indexers-20260928-flaresolverr.json` (снимок 6 индексеров до правки тегов). +> `~/backup-indexers-20260928-flaresolverr.json`, **`~/prowlarr.db.bak-20260928-032611`** (перед SQL-очисткой). > Связка: [[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]]. @@ -286,7 +291,66 @@ RuTracker Auth Failed` и `Invalid Credentials for RuTracker [https://rutracker. каскад `429:TooManyRequests` в Radarr/Sonarr/Lidarr. Это нормальное поведение, лечится только восстановлением логина. См. питфолл про `429` ниже. -## 🔑 ГЛАВНОЕ ОТКРЫТИЕ ПРО RuTracker: капча ПРИВЯЗАНА К СЕССИИ +## 🔴🔴 ИТОГОВЫЙ КОРЕНЬ (2026-09-29): логин RuTracker НЕ ВЫПОЛНЯЕТСЯ — нет куки `bb_data` + +⚠️ **Раздел ниже («капча привязана к сессии») оказался ЛОЖНЫМ СЛЕДОМ.** Он оставлен для +истории диагностики, но вывод в нём неверен — читать этот раздел вместо него. + +**Что измерено в финале (одна серия замеров, `/tmp/fs_persist_session.sh`):** + +``` +сессия rt-login-test: len=254 673 (форум) cookies=0 +сессия prowlarr: len=99 735 (НЕ форма!) cookies=2 ← [cf_clearance, bb_guid] +новая сессия + POST: len=12 346 (форма) cookies=2 ← [bb_guid, cf_clearance] +новая сессия + GET→POST: len=12 350 (форма) cookies=2 +``` + +🔴 **Ключевое: в cookies НЕТ `bb_data`.** `bb_data` — кука авторизации RuTracker. +Есть `cf_clearance` (CF пропускает челлендж) и `bb_guid` (гость), но `bb_data` отсутствует → +**логин не состоялся**, страница — форум для неавторизованного. + +**Что видит Prowlarr (точная строка из лога, главная улика сессии):** +``` +NzbDrone.Core.IndexerProxies.FlareSolverr.FlareSolverrException: + "Empty cookies returned by FlareSolverr." + at NzbDrone.Core.IndexerProxies.FlareSolverr.FlareSolverr.PostResponse(...) in FlareSolverr.cs:line 68 +[Warn] RuTracker: Unable to connect to indexer [https://rutracker.org/forum/tracker.php?nm=radiohead]. +[Error] Cardigann: An error occurred while processing indexer feed. [https://kinozal.me/browse.php?...] +``` + +⚠️ **Это НЕ «blocked by CloudFlare Protection».** Сообщение `Empty cookies returned` означает, +что FS прошёл челлендж (`Challenge solved!`), но **не вернул авторизационные cookies** — потому +что логина не было. Две ошибки выглядят похоже, но причины разные: + +| Сообщение | Что значит | +|---|---| +| `blocked by CloudFlare Protection` | CF не пройден (сессия без прокси, `ERR_NAME_NOT_RESOLVED`) | +| **`Empty cookies returned by FlareSolverr`** | **CF пройден, но логина нет → нет `bb_data`** | + +🔴 **Почему свежая сессия не логинится.** `sessions.create` + POST → форма (12 KB). +Prefetch `GET login.php` в той же сессии → POST → тоже форма (12 KB). То есть +**предварительный GET не помогает** — это не «капча к cookie». Просто RuTracker +не пропускает автоматический POST-логин из свежего Chrome-профиля FS. + +**Обходного пути в Prowlarr нет:** форма индексера принимает только `username`/`password`. +Поля для cookie (`bb_data`) не существует — подставить живую сессию из браузера нельзя. + +### Что нужно от Alex (единственный путь) + +1. Зайти на `rutracker.org` **браузером через тот же исходящий IP** (`vless-proxy`), + ввести логин+пароль, **пройти капчу**; либо +2. **Отключить капчу** для аккаунта в профиле на форуме — тогда автоматический логин заработает; +3. Проверить, что в браузере появляется кука **`bb_data`** (DevTools → Application → Cookies). + Если она есть и трекер не требует капчу — логин из Prowlarr должен пойти. + +> ⚠️ **Не считать `Empty cookies returned` ошибкой прокси или CF** — это отсутствие логина. +> Диагностика: `docker exec flaresolverr curl -s -X POST http://localhost:8191/v1 \ +> -H "Content-Type: application/json" -d '{"cmd":"request.get","url":"https://rutracker.org/forum/index.php","maxTimeout":100000,"session":"prowlarr"}' \ +> | jq -r '.solution.cookies[].name'` → если нет `bb_data`, логина нет. + +--- + +## ⚠️ ЛОЖНЫЙ СЛЕД (оставлен для истории): «капча привязана к сессии» Самый запутанный пункт. Дефект выглядел как «неверный пароль», потом как «капча», на самом деле — **капча выдаётся только для «холодных» сессий**. @@ -361,22 +425,40 @@ Radarr/Sonarr/Lidarr бьёт в 429 → **warning каскадом во все `DisabledTill` `15:44` → `21:45` после одного теста. Каждая «попытка починить тестом» удлиняла блокировку — это и была петля. Записи эскалируют, а не сбрасываются. -### Рабочий путь снятия (как на Кра́кене) +### Рабочий путь снятия (как на Кра́кене) ✅ ВЫПОЛНЕНО 2026-09-29 ```bash # 1. БЭКАП через .backup, НЕ cp (БД в WAL-режиме) DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db sqlite3 "file:$DB?mode=ro" ".backup /home/truenas_admin/prowlarr.db.bak-$(date +%Y%m%d-%H%M%S)" +# → /home/truenas_admin/prowlarr.db.bak-20260928-032611 (581 632 байт) # 2. стоп → удалить строки карантина → старт docker stop prowlarr -sqlite3 "$DB" "DELETE FROM IndexerStatus WHERE ProviderId IN (1,5,6);" +sqlite3 "$DB" "DELETE FROM IndexerStatus;" # можно без WHERE — чистим все +sqlite3 "$DB" "PRAGMA quick_check;" # → ok docker start prowlarr # 3. проверка curl -s -H "X-Api-Key: $PK" http://localhost:9696/api/v1/indexerstatus # → пусто -for I in 1 5 6; do curl -s -o /dev/null -w "idx$I=%{http_code}\n" \ - "http://localhost:9696/$I/api?t=caps&apikey=$PK"; done # → 200 +for I in 1 2 3 4 5 6; do curl -s -o /dev/null -w "idx$I=%{http_code}\n" \ + "http://localhost:9696/$I/api?t=caps&apikey=$PK"; done # → все 200 ✅ ``` +**Результат прогона:** `IndexerStatus` → `rows=0`, `quick_check=ok`, `Indexers` = 6 определений +на месте, `docker start prowlarr` поднялся, `health` → `[]`, `indexerstatus` → `[]`, +**все 6 `caps` → 200**. ⚠️ Скрипт: `/tmp/clear_indexerstatus.sh` (в нём есть контроль +«контейнер действительно остановлен» перед DELETE). + +🔴 **НО это НЕ решает поиск.** Через минуты после очистки CF-индексеры снова в карантине, +поиск `radiohead` → `total=79`, отдали только **NoNaMe (47) + RuTor (32)**. Потому что +настоящая причина — **отсутствие логина** (`bb_data`), см. раздел «ИТОГОВЫЙ КОРЕНЬ». +SQL-очистка снимает **симптом** (карантин), но не причину: пока логин не проходит, +карантин будет возвращаться волнами. + +> ⚠️ **Честная оценка метода.** Снятие через SQL даёт `caps` 200 и пустой `indexerstatus`, +> то есть **выглядит починенным**, но реальный поиск в этих индексерах не работает. +> **Приёмка — только `GET /api/v1/search?query=X` с разбивкой `group_by(.indexer)`,** +> а не `caps` и не `health`. + Таблицы: `Indexers`, `IndexerStatus`, `IndexerProxies`, `ApplicationIndexerMapping`, `IndexerDefinitionVersions`. @@ -664,16 +746,80 @@ localhost,127.0.0.1,vless-proxy,prowlarr,lidarr,radarr,sonarr,transmission,jelly Поиск релизов: **43** FLAC-раздачи. - **~17:20** — карантин RuTracker снят тестом полным объектом → `{}` HTTP **200**, `indexerstatus` → `[]`, `caps` idx1 → **200**. Prowlarr полностью чист. -- **Итог:** инфраструктура Тайги чиста и проверена. Открыт **1** дефект — RuTor +- **Итог (~17:20):** инфраструктура Тайги чиста и проверена. Открыт **1** дефект — RuTor (`no results in the configured categories`, на стороне трекера). Остаток-механика: `docker restart radarr sonarr lidarr` для сброса **кэша health** со старым RuTracker (команда ждала апрува Alex, в этой сессии не выполнена). -### Что делать при возврате симптома «индексера недоступны» +## История (продолжение, 2026-09-29) + +- **Апрув получен**, `docker restart radarr sonarr lidarr` → **выполнен**. Health Lidarr + стал **пустым**; Radarr/Sonarr всё ещё держали warning — потому что причина **не в них**, + а в БД Prowlarr (см. ниже). +- **Найдена настоящая петля.** Симптом: «снимаю карантин тестом → warning возвращается → + тест падает». Дамп `IndexerStatus` показал **`EscalationLevel=9`, `DisabledTill=+24ч`** + у RuTracker (ProviderId=1), плюс карантины у Kinozal 5/6. + 🔴 **`POST /indexer/test` карантин не снимает, а ПРОДЛЕВАЕТ** (наблюдалось `15:44` → `21:45`). + Это и была петля — каждая «попытка починить тестом» удлиняла блокировку. +- **Сверка с Кра́кеном** (Alex спросил «на Кра́кене работает всё так? у нас точно similar?»). + Прочитан [[family/how-to/arr-stack-kraken]]: на Кра́кене есть процедура + **`sqlite3 ... "DELETE FROM IndexerStatus"`** — на Тайге она **не выполнялась ни разу**. + Это было главное расхождение. +- **Выполнено:** бэкап `~/prowlarr.db.bak-20260928-032611` (`.backup`, не `cp`) → + `docker stop prowlarr` → `DELETE FROM IndexerStatus` (`rows=0`, `quick_check=ok`) → + `docker start prowlarr`. Результат: `health` → `[]`, `indexerstatus` → `[]`, + **все 6 `caps` → 200**. +- 🔴 **НО поиск не заработал.** `GET /api/v1/search?query=radiohead` → `total=79`, + отдали только **NoNaMe (47) + RuTor (32)**. CF-индексеры → **429** через минуты. +- **Найден истинный корень.** Лог Prowlarr: + `FlareSolverrException: Empty cookies returned by FlareSolverr` (`FlareSolverr.cs:68`). + Замер cookies сессии: `[cf_clearance, bb_guid]` — **куки `bb_data` НЕТ**, то есть + **логин RuTracker не выполняется**. Свежая сессия + POST → форма (12 KB); + prefetch `GET login.php` + POST → тоже форма. Предварительный GET **не помогает**. +- **Вывод сессии:** инфраструктура (прокси, FS, теги, БД) исправна и вычищена. + Блокер **вне инфраструктуры** — RuTracker не пропускает автоматический логин без капчи. + Решение требует Alex: пройти капчу браузером через `vless-proxy` либо отключить капчу + у аккаунта. См. раздел «ИТОГОВЫЙ КОРЕНЬ». + +### 🧠 Уроки этой сессии (для будущих) + +1. **«caps 200» ≠ «поиск работает».** Prowlarr может отдавать `caps` 200, пустой + `indexerstatus` и `health: []`, при этом реальный поиск через индексер не идёт. + **Приёмка — `search` с `group_by(.indexer)`**, потому что пустой ответ трекера + выглядит как успех инфраструктуры. +2. **`429` на `caps` — не «карантин в Prowlarr» как отдельная сущность, а запись в + `IndexerStatus`.** Лечить SQL, не тестами. Тест **продлевает** блокировку. +3. **`Empty cookies returned` ≠ `blocked by CloudFlare`.** Первое — нет логина (`bb_data`), + второе — CF не пройден. Симптомы похожи, причины разные, лечения разные. +4. **Bypass-фильтр прокси обязан содержать имя сервиса-соседа**, иначе внутренние запросы + уходят в прокси (Lidarr → Prowlarr). Признак — `Http request timed out` при живом соседе. +5. **Не сверять артефакт с соседним артефактом.** Здесь долго сверялись `caps`/`health` + между собой, а они оба — производные одного состояния БД. Сверять с **постановкой + задачи** (Alex: «у меня должно качаться»), то есть с реальным поиском. + +### Что делать при возврате симптома «индексера недоступны» (обновлено 2026-09-29) 1. `GET /api/v1/indexerstatus` в Prowlarr → кто в карантине (`disabledTill`). -2. Снять карантин: `POST /api/v1/indexer/test` **полным объектом**, по одному (не `testall`). -3. `GET /N/api?t=caps` → должен быть **200** (429 = ещё в карантине). -4. В Radarr/Sonarr: `PUT /api/v3/indexer/N?forceSave=true` → 202, затем `docker restart`. -5. Если снова падает RuTracker — это **капча**, а не пароль: проверить логин - `request.post /forum/login.php` через FS и смотреть **размер** HTML (250 KB = ОК, 13 KB = капча). +2. 🔴 **Снять карантин через SQL, НЕ тестом** — `POST /indexer/test` его **продлевает** + (`EscalationLevel` растёт, `DisabledTill` удлиняется): + ```bash + DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db + sqlite3 "file:$DB?mode=ro" ".backup /home/truenas_admin/prowlarr.db.bak-$(date +%Y%m%d-%H%M%S)" + docker stop prowlarr + sqlite3 "$DB" "DELETE FROM IndexerStatus;" + docker start prowlarr + ``` +3. `GET /N/api?t=caps` → **200** (429 = ещё в карантине). ⚠️ Это **не** доказательство работы. +4. **Приёмка — реальный поиск**, не `caps` и не `health`: + ```bash + curl -s -m 240 -H "X-Api-Key: $PK" "http://localhost:9696/api/v1/search?query=radiohead&type=search" \ + | jq -r 'group_by(.indexer)[] | "\(.[0].indexer): \(length)"' + ``` + Если CF-индексеров нет в выдаче — смотреть **cookies** (`bb_data`), а не `caps`: + ```bash + docker exec flaresolverr curl -s -X POST http://localhost:8191/v1 -H "Content-Type: application/json" \ + -d '{"cmd":"request.get","url":"https://rutracker.org/forum/index.php","maxTimeout":100000,"session":"prowlarr"}' \ + | jq -r '.solution.cookies[].name' + # нет bb_data → логин не прошёл → нужно вмешательство Alex (капча), инфраструктура ни при чём + ``` +5. Если снова падает RuTracker — **не требовать пароль**, пока не проверены `bb_data` и капча.