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

2026-09-28 14:27:53 +06:00
1 parent bbdc3c3785
commit d599a8bf72
@@ -215,27 +215,100 @@ CPU 0.68%); канал прокси нормальный (kinozal через soc
  Итог: **6/6 индексеров, health `[]`, поиск 256 результатов.**
  RuTracker впервые `valid` за всё время существования стека (с 2026-05-20).

+## ✅ ЗАКРЫТО: пароль RuTracker — рабочий (первый диагноз был НЕВЕРЕН)
+
+**Итог 2026-09-28 (позже в тот же вечер):** сохранённая в Prowlarr пара
+(`mallexxx` / 8 символов) **логинится успешно**. Проверено `request.post` через FlareSolverr
+на `/forum/login.php`:
+```
+final_url = https://rutracker.org/forum/login.php   ← НО форма не вернулась
+len       = 251 792                                 ← полная страница форума (~250 KB)
+login_form_back = False                             ← форма логина НЕ переоткрылась
+```
+`login_form_back=False` + страница 251 KB = **сессия установлена**, это залогиненный форум.
+Скрипт проверки: `/tmp/rt_login.py` (копия на Тайге; `python3 /tmp/rt_login.py "$U" "$P"`).
+
+🔴 **Почему первый диагноз был ложным.** Ранее вывод «пароль неверен» сделан по признаку
+`login_username` в HTML, но эта строка присутствует **и на залогиненной странице** (скрытая
+форма быстрого входа / HTML-шаблон). Признак «форма вернулась» надо проверять по
+**`final_url` + длине страницы**, а не по наличию подстроки `login_username` —
+это дало ложное «Auth Failed».
+
+> ⚠️ **Урок:** `Auth Failed` в `indexer/testall` Prowlarr **не означает неверный пароль**.
+> Прежде чем требовать новый пароль у Alex — проверить логин отдельным `request.post`
+> с `final_url` + `len` в ответе. Признак-подстрока ненадёжен.
+
+⚠️ **Если Alex всё-таки сменил пароль на самом rutracker.org** — в Prowlarr лежит СТАРЫЙ
+(проверено: `username len=8`, `password len=8` через `/api/v1/indexer/1`), его надо
+обновить в `Indexers → RuTracker`, иначе после смены на трекере логин отвалится.
+
+## ✅ ЗАКРЫТО: Radarr/Sonarr — каталоги категорий созданы
+
+Radarr/Sonarr ждали `/storage/Downloads/radarr` и `/storage/Downloads/sonarr`
+(Transmission пишет **плоско** в `/mnt/storage/Downloads`). Каталоги созданы:
+```bash
+mkdir -p /mnt/RED_2TB/storage/Downloads/radarr /mnt/RED_2TB/storage/Downloads/sonarr
+```
+В контейнерах видны как `/storage/Downloads/{radarr,sonarr}`, владелец `abc:abc`.
+⚠️ `RemotePathMappingCheck` в health **кэшируется** — после создания каталогов ошибка
+осталась, нужен `docker restart radarr sonarr` для перепроверки. См.
+[[family/plans/lidarr-taiga-deploy]].
+
 ## Открытые пункты

 - **Приёмка 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) — **не применена**;
-  Lidarr ходит в SkyHook сам, НЕ через FS. Разбирать отдельно —
-  [[family/plans/lidarr-taiga-deploy]].
-  🔴 **Проверено 2026-09-28:** домен `api.lidarr.audio` **резолвится** из контейнера
-  (`2606:4700:3031::ac43:df35`) — значит это **чисто Cloudflare, НЕ DNS** (в отличие от
-  трекеров, где был NXDOMAIN). Следствие важное: **`PROXY_URL`/FlareSolverr здесь бесполезны** —
-  FS обслуживает только Prowlarr, а SkyHook зовёт сам Lidarr. Нужен отдельный прокси
-  на уровне процесса Lidarr (env `HTTP_PROXY`/`HTTPS_PROXY` в `arr/docker-compose.yml` +
-  `NO_PROXY` для внутренних имён, иначе сломается связь с Transmission/Prowlarr).
-  Состояние: в библиотеке **0 артистов** (`GET /api/v1/artist` → `[]`), приёмка не закрыта.
+- ⏳ **`docker restart radarr sonarr`** — применить создание каталогов (апрув истёк 2026-09-28).
+- ⏳ **`POST /api/v3/indexer/testall`** в Radarr/Sonarr — снять карантин с их собственных
+  копий индексеров (`RuTor`, `Kinozal`, `Kinozal M`). ⚠️ Отдаёт **400**, но это не ошибка:
+  парсить тело (массив с `isValid`), а не HTTP-код.

-  **План фикса (2 шага, ~5 мин, ждёт «go» Alex):**
-  1. `HTTP_PROXY=socks5h://vless-proxy:1080`, `HTTPS_PROXY=socks5h://vless-proxy:1080`,
-     `NO_PROXY=localhost,127.0.0.1,lidarr,prowlarr,radarr,sonarr,transmission,jellyfin,navidrome,caddy`
-     → бэкап compose → правка **локально** → `scp` → `docker compose up -d lidarr` (конфиг в
-     `/config` не трогается).
-  2. Проверка: `GET /api/v1/artist/lookup?term=radiohead` → должен вернуть массив, не 403.
-  - Fallback, если .NET Lidarr не поймёт `socks5h`: `socks5://` либо HTTP-прокси `vless-proxy:1081`.
+## ✅ Lidarr ↔ SkyHook: решено 2026-09-28 (встроенный прокси, НЕ env)
+
+Смежная задача, решена в этой же сессии. Полный разбор — [[family/plans/lidarr-taiga-deploy]].
+
+`api.lidarr.audio` (метаданные SkyHook) за Cloudflare:
+- прямой запрос из контейнера → **403**;
+- через `socks5h://vless-proxy:1080` → **200**;
+- домен **резолвится** (`2606:4700:3031::ac43:df35`) — это **чисто CF, НЕ DNS-блок**.
+
+⚠️ **FlareSolverr здесь бесполезен** — он обслуживает Prowlarr, а SkyHook зовёт сам Lidarr.
+
+🔴 **ГЛАВНЫЙ ПИТФОЛЛ: env `HTTP_PROXY`/`HTTPS_PROXY` Lidarr НЕ ЧИТАЕТ.** Проверено:
+compose-env + рестарт → всё тот же **403**. .NET-клиент SkyHook игнорирует env.
+
+**Рабочее решение — встроенный прокси-конфиг Lidarr** (применяется без рестарта):
+```bash
+# GET /api/v1/config/host  ->  proxyEnabled:false
+# PUT  /api/v1/config/host/1  c полями:
+#   proxyEnabled:        true
+#   proxyType:           "http"
+#   proxyHostname:       "vless-proxy"
+#   proxyPort:           1081                    # ← HTTP-порт, НЕ 1080 (SOCKS5)
+#   proxyBypassFilter:   "localhost,127.0.0.1,vless-proxy"
+#   proxyBypassLocalAddresses: true
+```
+Скрипт: `/tmp/lidarr_set_proxy.py` (на хосте Тайги; там `python3` **есть**, `curl` — нет).
+
+**Результат:** `lookup?term=radiohead` → 10 результатов; артист добавлен; поиск релизов →
+23 раздачи FLAC. Библиотека: 0 артистов → 1.
+
+⚠️ **Ложный след при диагностике:** `api.lidarr.audio` отдаёт 403 **не всегда** — при
+исчерпанном CF-лимите 403 бывает и у `curl`, что выглядит как «прокси не работает».
+Различать: заголовок `x-rate-limit-remaining` присутствует только при живом ответе;
+и сравнивать **прямой** vs **через прокси** запрос в одном ходе.
+
+⚠️ Откат: env-вариант убран из compose (бэкап
+`~truenas_admin/docker-compose.yml.bak-20260928-lidarr-proxy`).
+
+## Общий вывод по прокси на Тайге (три разных механизма!)
+
+На одном хосте понадобились **три независимых способа** прокинуть трафик через `vless-proxy`:
+
+| Кто | Механизм | Ключ |
+|---|---|---|
+| Prowlarr (индексеры) | SOCKS5-прокси в Prowlarr + FlareSolverr | теги `[1,2]`, `PROXY_URL` у FS |
+| FlareSolverr (Chrome) | глобальный прокси образа | env `PROXY_URL=socks5://...` (**НЕ** HTTP_PROXY) |
+| Lidarr (SkyHook) | встроенный конфиг приложения | `config/host.proxyEnabled` (**env НЕ работает**) |
+
+⚠️ **Не переносить рецепт одного сервиса на другой.** `arr`-сервисы внешне похожи, но
+механизм прокси у каждого свой; проверять фактическим запросом, а не по аналогии.