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

personal/tech/flaresolverr-taiga.md

@@ -330,6 +330,93 @@ docker exec prowlarr curl -s -o /dev/null -w "%{http_code}" "http://localhost:96
 ```
 Проверено: `{}` + **200** → `indexerstatus` пуст, `caps` → **200**.
 
+## 🔴🔴 ГЛАВНЫЙ ПИТФОЛЛ ФИНАЛА: `IndexerStatus` в `prowlarr.db` — снимается ТОЛЬКО SQL
+
+Самая долгая петля сессии. Симптом: «снимаю карантин тестом → warning возвращается →
+тест падает заново». Круг не сходился, потому что **причина не в прокси, не в FlareSolverr
+и не в пароле — она в БД Prowlarr.**
+
+**Пруф — дамп таблицы** (`sqlite3` на хосте Тайги ЕСТЬ, в контейнере НЕТ):
+```bash
+DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db
+sqlite3 "file:$DB?mode=ro" \
+  "SELECT Id, ProviderId, InitialFailure, MostRecentFailure, EscalationLevel, DisabledTill FROM IndexerStatus;"
+```
+```
+ProviderId  Индексер     EscalationLevel  DisabledTill
+5           Kinozal      2                2026-09-28 10:08
+6           Kinozal M    2                —
+4           NoNaMe       0                —
+2           RuTor        0                —
+1           RuTracker    9                2026-09-29 09:46   ← СУТКИ
+3           Byrutor      0                —
+```
+
+`EscalationLevel` = степень эскалации (0–9), `9` — максимум, `DisabledTill` = **+24 ч**.
+Пока запись есть: `caps` отдаёт **429** → Prowlarr не пробует снова → фоновый health-чек
+Radarr/Sonarr/Lidarr бьёт в 429 → **warning каскадом во все четыре сервиса**. Отсюда парадокс
+«health Radarr пуст, а warning про индексе́ры живёт» — он живёт не у Radarr, а в БД Prowlarr.
+
+🔴 **`POST /indexer/test` карантин НЕ снимает, а ПРОДЛЕВАЕТ.** Наблюдалось вживую:
+`DisabledTill` `15:44` → `21:45` после одного теста. Каждая «попытка починить тестом»
+удлиняла блокировку — это и была петля. Записи эскалируют, а не сбрасываются.
+
+### Рабочий путь снятия (как на Кра́кене)
+
+```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)"
+# 2. стоп → удалить строки карантина → старт
+docker stop prowlarr
+sqlite3 "$DB" "DELETE FROM IndexerStatus WHERE ProviderId IN (1,5,6);"
+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
+```
+
+Таблицы: `Indexers`, `IndexerStatus`, `IndexerProxies`, `ApplicationIndexerMapping`,
+`IndexerDefinitionVersions`.
+
+> ⚠️ **Урок об источниках истины.** health-эндпоинты arr-сервисов **не авторитет** о блокировках.
+> На Кра́кене это записано прямо: «`GET /api/v1/health` и `/api/v1/indexerstatus` НЕ показывают
+> причины блокировки» — смотреть `prowlarr.debug.txt` и таблицу `IndexerStatus`. На Тайге
+> `indexerstatus` причину показывал, но **снятие через API не срабатывало — только SQL.**
+
+## 🔴 ПИТФОЛЛ: `Auth Failed` = следствие `IndexerStatus`, а НЕ неверный пароль
+
+Диагноз ставился трижды и дважды был неверным — фиксирую окончательно.
+
+Проверка логина через FS (сессия `prowlarr`):
+```
+login  → len=254 410   ✅
+search → len=254 745   ✅   auth_failed_in_html=False   login_form=False
+```
+То есть **логин живой**, а Prowlarr в это же время отдаёт `RuTracker Auth Failed`.
+
+**Правильный признак «залогинен или нет» — РАЗМЕР HTML, не подстрока:**
+
+| `len` HTML | Что это |
+|---|---|
+| **~250 KB** | залогиненный форум ✅ |
+| **~13 KB** | форма логина вернулась ❌ |
+
+Подстрока `login_username` присутствует **в обоих** случаях (HTML-шаблон + скрытая форма
+быстрого входа) — по ней диагноз ставить НЕЛЬЗЯ. Именно это дало ложное «пароль неверен».
+
+⚠️ **И капча тут ни при чём.** Наблюдалось: «холодная» (свежесозданная) FS-сессия получает
+форму с `cap_code` (`len=13 338`), а уже прогретая сессия `prowlarr` — залогиненный форум
+(`len=251 792`). То есть капча отдаётся **не по признаку пароля**, а свежим сессиям.
+Пароль всё время был верный — Alex подтвердил отдельно.
+
+> ⚠️ **Порядок диагностики при `Auth Failed` (не переставлять):**
+> 1. Проверить логин `request.post` на `/forum/login.php` через FS → судить по `len` (~250 KB = ок).
+> 2. Посмотреть `IndexerStatus` в `prowlarr.db` — если есть строка, **это и есть причина**.
+> 3. Только если п.1 показал ~13 KB — вопрос к паролю.
+> **Не требовать у Alex новый пароль, не пройдя п.2.**
+
 ## ✅ ЗАКРЫТО: пароль RuTracker — рабочий (первый диагноз был НЕВЕРЕН)
 
 **Итог 2026-09-28 (позже в тот же вечер):** сохранённая в Prowlarr пара