[2026-09-28] eagle: family/how-to/arr-stack-kraken.md personal/tech/flaresolverr-taiga.md

2026-09-28 17:11:16 +06:00
1 parent f1964019f3
commit 8174fc8d3c
@@ -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` и капча.