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

family/plans/lidarr-taiga-deploy.md

@@ -4,6 +4,10 @@
 **Статус:** ✅ **РАБОЧИЙ — приёмка закрыта 2026-09-28 (вечер).** SkyHook-блокер снят,
 проверено end-to-end: lookup → добавление артиста → поиск релизов. Бал: 0 артистов → 1,
 0 релизов → 23.
+**Добивка (2026-09-28, поздний вечер):** Radarr и Sonarr вычищены до `health: []`
+(`docker restart` + снятие карантина в Prowlarr + `?forceSave=true`). Найден и исправлен
+последний дефект Lidarr — **`proxyBypassFilter` без внутренних docker-имён** (см. питфолл).
+⏳ Осталось буквально одно: `docker restart lidarr` (апрув истёк).
 **Что было причиной и как починено (главный вывод сессии):**
 `api.lidarr.audio` действительно за Cloudflare, прямой запрос с IP Тайги → **403**, через
 `socks5h://vless-proxy:1080` → **200**. НО **env-переменные `HTTP_PROXY`/`HTTPS_PROXY` Lidarr
@@ -39,8 +43,54 @@
 | **SkyHook (метаданные)** | ✅ `lookup?term=radiohead` → **10 результатов**, 15 397 байт реальных метаданных |
 | **Библиотека** | ✅ **1 артист** (`Radiohead`, id=1, monitored=false) |
 | **Поиск релизов** | ✅ `/release?artistId=1` → **23 раздачи** FLAC (seeders 3–7) через `NoNaMe Club (Prowlarr)` |
-| **Прокси-конфиг Lidarr** | ✅ `proxyEnabled=true`, `proxyType=http`, `vless-proxy:1081`, bypass `localhost,127.0.0.1,vless-proxy` |
-| health Radarr/Sonarr | ⚠️ `RemotePathMappingCheck` + indexer-warnings — см. «Остаток» ниже |
+| **Прокси-конфиг Lidarr** | ✅ `proxyEnabled=true`, `proxyType=http`, `vless-proxy:1081`, bypass **расширен** (см. питфолл ниже) |
+| health Radarr/Sonarr | ✅ **`[]` — ЧИСТО** (рестарт применён 2026-09-28, поздний вечер) |
+| **health Lidarr** | ⚠️ 1 warning `Kinozal (M)` — фикс `proxyBypassFilter` применён, нужен `docker restart lidarr` |
+
+### 🔴 ПИТФОЛЛ (новый): `proxyBypassFilter` без `prowlarr` → таймауты Lidarr к Prowlarr
+
+**Симптом:** в Lidarr `indexer/test` → `Unable to connect to indexer, indexer's server is
+unavailable. Http request timed out`, `/release?artistId=1` → **0 релизов**, хотя в Prowlarr
+тот же индексер отвечает **200**.
+
+**Причина:** встроенный прокси Lidarr (`proxyEnabled=true`) заворачивал **внутренний** запрос
+`http://prowlarr:9696/N/api?t=caps` в HTTP-прокси: в `proxyBypassFilter` было только
+`localhost,127.0.0.1,vless-proxy`, а имя `prowlarr` там отсутствовало (и
+`proxyBypassLocalAddresses` на docker-имена **не действует** — только на IP-литералы).
+
+**Фикс** — дописать все имена стека, затем `docker restart lidarr`:
+```
+localhost,127.0.0.1,vless-proxy,prowlarr,lidarr,radarr,sonarr,transmission,jellyfin,navidrome,caddy,gluetun,taiga
+```
+Скрипт `/tmp/lidarr_bypass.py` (GET → patch → PUT `/api/v1/config/host` → **202** → read-back).
+
+> ⚠️ **Урок для любого arr-сервиса:** включая встроенный прокси — сразу прописать в bypass
+> **все** docker-имена стека. Иначе сервис уходит в прокси и к соседям, и симптом выглядит
+> как «сервер индексера недоступен».
+
+### 🔴 ПИТФОЛЛ (новый): `indexer/test` требует ПОЛНЫЙ объект
+
+`POST /api/v3/indexer/test` и `/api/v1/indexer/test` с телом `{"id":N}` → **400 всегда**.
+Нужно отправить **полный JSON индексера**:
+```bash
+docker exec radarr curl -s -H "X-Api-Key: $K" http://localhost:7878/api/v3/indexer > /tmp/i.json
+docker cp /tmp/i.json radarr:/tmp/i.json
+docker exec radarr curl -s -X POST -H "X-Api-Key: $K" -H "Content-Type: application/json" \
+  --data-binary @/tmp/i.json http://localhost:7878/api/v3/indexer/test
+# {} + http=200 = OK; 400 = реальная ошибка (смотреть validationFailures)
+```
+`POST /indexer/testall` вдобавок **подвешивает** Sonarr (>300 с) — гонять по одному.
+
+### 🔴 ПИТФОЛЛ (новый): `429` на `caps` у Prowlarr = карантин → каскад во все arr
+
+`GET http://prowlarr:9696/5/api?t=caps` → **429**, пока индексер в карантине Prowlarr.
+Radarr/Sonarr/Lidarr показывают `[429:TooManyRequests]` — причина **не в них**.
+**Порядок:** снять карантин в Prowlarr (тест полным объектом) → `caps` 200 →
+`PUT /api/v3/indexer/N?forceSave=true` (**202**) в самом arr → `docker restart`.
+
+### ⚠️ Остаток на конец сессии (не блокирует Lidarr)
+
+1. ✅ **Пароль RuTracker — РАБОЧИЙ (первый диагноз «неверен» был ложным).**
 
 ### 🔴 ПИТФОЛЛ: env `HTTP_PROXY` НЕ работает в Lidarr — только встроенный конфиг
 
@@ -61,9 +111,9 @@ vs **через прокси** в одном ходе.
 ⚠️ **Порт прокси:** `vless-proxy` слушает SOCKS5 на **1080** и HTTP на **1081**.
 Встроенный конфиг Lidarr (`proxyType=http`) требует **1081**; `1080` там не подойдёт.
 
-### ⚠️ Остаток на конец сессии (не блокирует Lidarr)
+### ⚠️ Остаток (обновлён 2026-09-28, поздний вечер)
 
-1. ✅ **Пароль RuTracker — РАБОЧИЙ (первый диагноз «неверен» был ложным).**
+1. ✅ **Пароль RuTracker — РАБОЧИЙ** (первый диагноз «неверен» был ложным).
    Проверено `request.post` на `/forum/login.php` через FlareSolverr: финальный URL
    остаётся `login.php`, но страница **251 792 байта** (полный форум), форма логина
    **не переоткрылась** → сессия установлена. Пара `mallexxx` / 8 символов проходит.
@@ -71,19 +121,21 @@ vs **через прокси** в одном ходе.
    она есть и на залогиненной странице. Проверять по `final_url` + `len`.
    ⚠️ Если Alex сменил пароль на самом rutracker.org — в Prowlarr лежит старый
    (проверено `len=8` через `/api/v1/indexer/1`), обновить в `Indexers → RuTracker`.
-2. ⏳ **Radarr/Sonarr ждут каталоги** `/storage/Downloads/radarr` и `/storage/Downloads/sonarr`
-   (Transmission пишет плоско в `/mnt/storage/Downloads`). Каталоги **созданы**
-   (`/mnt/RED_2TB/storage/Downloads/{radarr,sonarr}`, видны в контейнерах как `abc:abc`),
-   но ошибка `RemotePathMappingCheck` в health **осталась** — Radarr/Sonarr кэшируют
-   результат проверки, нужен `docker restart radarr sonarr`. ⏳ Не выполнен (апрув истёк).
-3. Indexer-warnings (`RuTor`, `Kinozal`, `Kinozal M`) в Radarr/Sonarr — их собственные
-   копии индексеров в карантине, снимаются `POST /api/v3/indexer/testall`.
-   ⚠️ Эндпоинт отдаёт **400**, но это НЕ ошибка: тело содержит массив с `isValid` по каждому
-   индексеру — парсить тело, а не HTTP-код. `GET /indexer/testall` → 404 (метод только POST).
+2. ✅ **Radarr/Sonarr — ЗАКРЫТО 2026-09-28 (поздний вечер).** Каталоги
+   `/storage/Downloads/{radarr,sonarr}` созданы, `docker restart radarr sonarr` выполнен →
+   `RemotePathMappingCheck` **ушла**, `health` обоих → `[]`.
+3. ✅ **Indexer-warnings в Radarr/Sonarr — ЗАКРЫТО.** Сняты: (а) тест карантинных индексе-
+   ров в **Prowlarr** полным объектом → `caps` 200; (б) `PUT /api/v3/indexer/N?forceSave=true`
+   в Radarr/Sonarr → **202**; (в) `docker restart radarr sonarr lidarr`.
+   ⚠️ `POST /api/v3/indexer/testall` **подвешивает** Sonarr (>300 с) и отдаёт 400 — гонять
+   `POST /api/v3/indexer/test` **по одному, полным объектом** (`{"id":N}` → 400 всегда).
    ⚠️ `/indexerstatus` есть **только в Prowlarr**; в Radarr/Sonarr → 404.
-4. RuTor в Radarr: «Query successful, but no results in the configured categories» —
-   не блокировка, а категории (RuTor не фильтрует по категориям — см. питфолл в
-   [[personal/tech/prowlarr-flaresolverr-cloudflare]]).
+4. **RuTor в Radarr/Sonarr:** «Query successful, but no results in the configured categories» —
+   **не блокировка и не карантин**, RuTor не отдаёт результаты в категориях фильмов/сериалов.
+   Проверено тестом полным объектом: caps 200, карантина нет. Оставляем как есть.
+5. ⏳ **1 warning в Lidarr (`Kinozal (M)`) — нужен `docker restart lidarr`.** Фикс
+   `proxyBypassFilter` применён (PUT → 202, read-back подтверждён), но рестарт ушёл в апрув
+   и **истёк**. Команда: `ssh truenas_admin@mallexxx.duckdns.org 'docker restart lidarr'`.
 
 ### Изменённые файлы
 
@@ -92,7 +144,7 @@ vs **через прокси** в одном ходе.
 | `/mnt/RED_2TB/docker/arr/docker-compose.yml` | + сервис `lidarr` (md5 `667f68f23b17a8c899c5a82a453fc754`); env-прокси добавлялся и **откачен** | `/home/truenas_admin/arr-compose.bak-20260927-125755`, `~/docker-compose.yml.bak-20260928-lidarr-proxy` |
 | `/mnt/RED_2TB/storage/Downloads/radarr` | каталог создан 2026-09-28 (Radarr ждал его) | — |
 | `/mnt/RED_2TB/storage/Downloads/sonarr` | каталог создан 2026-09-28 (Sonarr ждал его) | — |
-| Lidarr `config/host` (БД) | `proxyEnabled`/`proxyType`/`proxyHostname`/`proxyPort`/`proxyBypassFilter` | скрипт `/tmp/lidarr_set_proxy.py` идемпотентен |
+| Lidarr `config/host` (БД) | `proxyEnabled`/`proxyType`/`proxyHostname`/`proxyPort`/`proxyBypassFilter` (bypass **расширен** до всех docker-имён) | скрипты `/tmp/lidarr_set_proxy.py`, `/tmp/lidarr_bypass.py` идемпотентны |
 | `/mnt/RED_2TB/docker/caddy/Caddyfile` | + блок `lidarr.mallexxx.duckdns.org` (96 строк) | `/home/truenas_admin/Caddyfile.bak-*` |
 | `/mnt/RED_2TB/storage/Downloads/lidarr` | каталог создан | — |
 | `/mnt/RED_2TB/docker/arr/lidarr/` | конфиг + `lidarr.db` | — |
@@ -322,3 +374,14 @@ Transmission (9091) ──download──┐  │
   (3) **Ложный диагноз «пароль RuTracker неверен» снят** — пара в Prowlarr логинится
   (`final_url`+`len=251792`, форма не переоткрылась). См. [[personal/tech/flaresolverr-taiga]].
   Остаток: `docker restart radarr sonarr` + `indexer/testall` (апрув истёк).
+- **2026-09-28 (поздний вечер, вторая добивка)** — Alex: «я поменял пароль в prowlarr» →
+  пароль в порядке, ложный диагноз не подтвердился. Закрыто:
+  (1) `docker restart radarr sonarr` → `RemotePathMappingCheck` ушла, health обоих `[]`;
+  (2) карантин Kinozal/Kinozal(M) в **Prowlarr** снят тестом **полным объектом**
+  (`{"id":N}` → 400 всегда); `caps` 1/5/6 → 200;
+  (3) `PUT /api/v3/indexer/N?forceSave=true` в Radarr/Sonarr → 202;
+  (4) `docker restart radarr sonarr lidarr`.
+  **Новый дефект Lidarr:** `/release?artistId=1` → 0; причина — `proxyBypassFilter` без
+  `prowlarr` (собственный прокси заворачивал внутренний запрос). Фикс применён (PUT 202,
+  read-back), **рестарт Lidarr — апрув истёк** ⏳.
+  Три новых питфолла — см. выше. RuTor: несовпадение категорий, не блок.

personal/tech/flaresolverr-taiga.md

@@ -1,6 +1,10 @@
 # FlareSolverr на Тайге + обход блокировок индексеров
 
-> ✅ **СОСТОЯНИЕ 2026-09-28: ГОТОВО. Все 6 индексеров рабочие, health чистый.**
+> ✅ **СОСТОЯНИЕ 2026-09-28 (поздний вечер): ГОТОВО на всех четырёх arr-сервисах.**
+> **Prowlarr** — 6/6 индексеров, `health` → `[]`, `indexerstatus` → `[]`.
+> **Radarr** — `health` → `[]`. **Sonarr** — `health` → `[]`.
+> **Lidarr** — работает (SkyHook + 23 релиза); 1 warning `Kinozal (M)` лечится
+> `docker restart lidarr` после правки `proxyBypassFilter` (см. питфолл в конце).
 > Контейнер `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-й сервис).
@@ -229,6 +233,14 @@ CPU 0.68%); канал прокси нормальный (kinozal через soc
   сессии `prowlarr`** — последний блокер (сессия была создана до `PROXY_URL`).
   Итог: **6/6 индексеров, health `[]`, поиск 256 результатов.**
   RuTracker впервые `valid` за всё время существования стека (с 2026-05-20).
+- **2026-09-28 (поздний вечер)** — **добивка Radarr/Sonarr/Lidarr до чистого health.**
+  Закрыто: `docker restart radarr sonarr` (+`lidarr`) → `RemotePathMappingCheck` ушла,
+  health Radarr/Sonarr → `[]`. Снят карантин Kinozal/Kinozal(M) в Prowlarr тестом
+  **полным объектом** (`{"id":N}` → 400 всегда). Новые питфоллы: **`test` требует полный
+  объект**; **429 на `caps` = карантин Prowlarr → каскад во все arr**;
+  **`proxyBypassFilter` Lidarr без `prowlarr`** → таймауты к Prowlarr из-за собственного
+  прокси-конфига. Остаток: RuTor — несовпадение категорий (не блок), и 1 warning в Lidarr
+  до перезапуска с новым bypass.
 
 ## ✅ ЗАКРЫТО: пароль RuTracker — рабочий (первый диагноз был НЕВЕРЕН)
 
@@ -269,13 +281,25 @@ mkdir -p /mnt/RED_2TB/storage/Downloads/radarr /mnt/RED_2TB/storage/Downloads/so
 осталась, нужен `docker restart radarr sonarr` для перепроверки. См.
 [[family/plans/lidarr-taiga-deploy]].
 
-## Открытые пункты
+## ✅ ЗАКРЫТО 2026-09-28 (поздний вечер): Radarr/Sonarr/Lidarr вычищены
 
-- **Приёмка Alex в UI:** `https://prowlarr.mallexxx.duckdns.org` → Indexers → 6 зелёных без карантинов.
-- ⏳ **`docker restart radarr sonarr`** — применить создание каталогов (апрув истёк 2026-09-28).
-- ⏳ **`POST /api/v3/indexer/testall`** в Radarr/Sonarr — снять карантин с их собственных
-  копий индексеров (`RuTor`, `Kinozal`, `Kinozal M`). ⚠️ Отдаёт **400**, но это не ошибка:
-  парсить тело (массив с `isValid`), а не HTTP-код.
+| Что | Итог |
+|---|---|
+| `docker restart radarr sonarr` | ✅ выполнен → `RemotePathMappingCheck` **ушла** |
+| Карантин индексеров в Prowlarr (id 5, 6) | ✅ снят тестом полным объектом → `caps` 200 |
+| `PUT /api/v3/indexer/N?forceSave=true` в Radarr/Sonarr | ✅ 202 |
+| `docker restart radarr sonarr lidarr` | ✅ выполнен |
+| **health Radarr** | ✅ `[]` — чисто |
+| **health Sonarr** | ✅ `[]` — чисто |
+| health Lidarr | ⚠️ 1 warning `Kinozal (M)` — дефект `proxyBypassFilter`, см. питфолл ниже |
+| Библиотека Lidarr | 1 артист (`Radiohead`), 23 релиза |
+
+**Остаток (не блокирует):** RuTor в Radarr/Sonarr — `Query successful, but no results in the
+configured categories`. Это **не блокировка и не карантин**: RuTor не отдаёт результаты в
+категориях фильмов/сериалов. Проверено тестом полным объектом → caps отдаёт, карантина нет.
+
+- **Приёмка Alex в UI:** `https://prowlarr.mallexxx.duckdns.org` → Indexers → 6 зелёных;
+  `https://lidarr.mallexxx.duckdns.org` → артист ищется.
 
 ## ✅ Lidarr ↔ SkyHook: решено 2026-09-28 (встроенный прокси, НЕ env)
 
@@ -315,6 +339,55 @@ compose-env + рестарт → всё тот же **403**. .NET-клиент S
 ⚠️ Откат: env-вариант убран из compose (бэкап
 `~truenas_admin/docker-compose.yml.bak-20260928-lidarr-proxy`).
 
+## 🔴 ПИТФОЛЛ: `test` требует ПОЛНЫЙ объект, не `{id}` → 400
+
+Во **всех** arr-сервисах (`Prowlarr`, `Radarr`, `Sonarr`, `Lidarr`) эндпоинт
+`POST /api/vN/indexer/test` с телом `{"id":N}` отдаёт **400 Bad Request**.
+Правильно — отправить **полный** объект индексера:
+```bash
+curl -s -H "X-Api-Key: $K" http://localhost:PORT/api/v3/indexer > /tmp/idx.json
+docker cp /tmp/idx.json radarr:/tmp/idx.json
+docker exec radarr curl -s -X POST -H "X-Api-Key: $K" -H "Content-Type: application/json" \
+  --data-binary @/tmp/idx.json http://localhost:7878/api/v3/indexer/test
+# → {} с http=200 = тест пройден; 400 + validationFailures = реальная ошибка
+```
+`{}` + **200** = успех (не 204, не «пусто»). `POST /indexer/testall` — тот же класс грабли,
+он ещё и **подвешивает** Sonarr (>300 с) — гонять **по одному**.
+
+## 🔴 ПИТФОЛЛ: `429` на `/N/api?t=caps` у Prowlarr = карантин → каскад во все arr
+
+`GET http://prowlarr:9696/5/api?t=caps&apikey=…` → **429 TooManyRequests**, пока индексер
+в карантине. Следствие: **Radarr/Sonarr/Lidarr не могут синкнуть этот индексер** и показывают
+`Unable to connect to indexer … [429:TooManyRequests]`. Настоящая причина — не в них.
+
+**Порядок лечения (снизу вверх):**
+1. Снять карантин в **Prowlarr** — `POST /api/v1/indexer/test` полным объектом (по одному).
+2. Проверить `GET /api/v1/indexerstatus` → пусто и `caps` → **200**.
+3. Пересохранить проблемный индексер в самом arr: `PUT /api/v3/indexer/N?forceSave=true` → **202**
+   (сбрасывает `FailureCount`).
+4. `docker restart radarr sonarr lidarr` — health пересчитывается только при старте.
+
+## 🔴 ПИТФОЛЛ: `proxyBypassFilter` Lidarr без внутренних имён → таймауты к Prowlarr
+
+**Самый неочевидный дефект сессии.** После включения встроенного прокси Lidarr
+(`proxyEnabled=true`) его запросы к **Prowlarr** ушли в прокси и стали падать
+`Http request timed out`, хотя в Prowlarr тот же индексер отвечал 200.
+
+**Причина:** дефолтный bypass — `localhost,127.0.0.1,vless-proxy`, в нём **НЕТ `prowlarr`**.
+Имя `prowlarr` не попадает под `proxyBypassLocalAddresses` (это не IP-литерал), поэтому
+внутрикластерный `http://prowlarr:9696/…` инкапсулировался в HTTP-прокси и таймаутил.
+
+**Фикс** — дописать в `config/host.proxyBypassFilter` **все внутренние docker-имена**:
+```
+localhost,127.0.0.1,vless-proxy,prowlarr,lidarr,radarr,sonarr,transmission,jellyfin,navidrome,caddy,gluetun,taiga
+```
+Скрипт: `/tmp/lidarr_bypass.py` (GET → patch filter → PUT `/api/v1/config/host` → **202** → read-back).
+⚠️ После правки — `docker restart lidarr`.
+
+> ⚠️ **Правило:** включая приложению прокси-конфиг, **сразу прописать в bypass все имена
+> своего стека**. Иначе сервис «уйдёт» в прокси и к соседям — симптом выглядит как
+> «сервер индексера недоступен», а виноват собственный прокси-конфиг.
+
 ## Общий вывод по прокси на Тайге (три разных механизма!)
 
 На одном хосте понадобились **три независимых способа** прокинуть трафик через `vless-proxy`: