0 Fork 0

Files

T

Alexey Martemyanov f3dacaaa39 [2026-09-28] eagle: family/plans/lidarr-taiga-deploy.md personal/projects/balda/balda.md personal/tech/adk-hostedagent-openai-mcp.md personal/tech/flaresolverr-taiga.md

2026-09-28 15:24:26 +06:00

44 KiB

Executable File

Raw Blame History

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 (трекер не отдаёт фильмы/сериалы, не блокировка и не карантин). Всё остальное закрыто. Контейнер 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 индексеров до правки тегов). Связка: 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.

✅ РЕЗУЛЬТАТ (поиск «matrix» через `/api/v1/search`, замер 28 сен до капчи)

TOTAL 256
  RuTor      100   ← был живой
  RuTracker   50   ← ВПЕРВЫЕ с 2026-05-20
  NoNaMe      50   ← ВПЕРВЫЕ
  Kinozal     50   ← ВПЕРВЫЕ
  Byrutor      6

⚠️ Это исторический замер, не текущее состояние. На момент ~15:20 RuTracker ещё логинился и давал 50 результатов. Позже трекер стал отдавать капчу (см. раздел про RuTracker), и RuTracker/Kinozal уходят в карантин волнами → в поиске сейчас меньше трекеров. Смотреть indexerstatus перед тем, как повторять этот замер.

GET /api/v1/health → [], GET /api/v1/indexerstatus → [] на момент замера. Было 3/6, стало 6/6 (по выдаче — 5 трекеров; Kinozal (M) — зеркало Kinozal с magnet-приоритетом, в общую выдачу дублируется).

🔑 ГЛАВНОЕ ОТКРЫТИЕ: FS-СЕССИЯ НЕ НАСЛЕДУЕТ `PROXY_URL`

Самый неочевидный пункт всей задачи. Симптом был ложный: Prowlarr писал blocked by CloudFlare Protection, а лог FS — мгновенную ошибку за 7 секунд (не таймаут!).

Причина: PROXY_URL (глобальный прокси) применяется к Chrome в момент создания сессии. Сессия, созданная до появления PROXY_URL, остаётся без прокси навсегда — в ней Chrome получает net::ERR_NAME_NOT_RESOLVED (DNS-блок!). Prowlarr шлёт запросы с параметром session, и global-прокси её не перебивает.

Пруф — прямой вызов с сессией, созданной ДО прокси:

request.get kinozal + session:"prowlarr" (старая)
  → {"status":"error","message":"Error solving the challenge.
     Message: unknown error: net::ERR_NAME_NOT_RESOLVED (chrome=152.0.7977.82)"}

Тот же запрос с сессией, созданной ПОСЛЕ PROXY_URL → Challenge solved! 200.

Имя сессии Prowlarr — prowlarr (обнаружено через sessions.list).

Фикс: удалить устаревшую сессию — sessions.destroy; Prowlarr пересоздаёт её сам при следующем запросе, уже с рабочим PROXY_URL.

docker exec prowlarr sh -c 'curl -s -X POST http://flaresolverr:8191/v1 \
  -H "Content-Type: application/json" \
  -d "{\"cmd\":\"sessions.destroy\",\"session\":\"prowlarr\"}"'

⚠️ Правило на будущее: после ЛЮБОЙ правки PROXY_URL в compose убить сессию prowlarr, иначе старые сессии продолжат ходить без прокси и индексера будут «blocked by CloudFlare» при живом FS. ✅ При обычном перезапуске FS (watchtower/reboot) проблема НЕ повторится — сессия создастся заново уже с PROXY_URL.

🔑 ВТОРОЕ ОТКРЫТИЕ: FlareSolverr сам идёт через прокси (`PROXY_URL`)

На Кра́кене два механизма независимы: Cloudflare лечится FlareSolverr, DNS-блока нет. На Тайге блоков ДВА (DNS + Cloudflare), и FlareSolverr обязан ходить через vless-proxy — иначе он сам получит NXDOMAIN и не поможет.

Решение: глобальная env-переменная FlareSolverr PROXY_URL=socks5://vless-proxy:1080.

⚠️ Имя переменной — PROXY_URL, НЕ HTTP_PROXY/HTTPS_PROXY (проверено по DeepWiki FlareSolverr §4.2 «Proxy Configuration»). Формат со схемой обязателен (socks5://host:port); без схемы urllib.parse не разберёт. Приоритет: request > session > global. PROXY_USERNAME/PROXY_PASSWORD не нужны — vless-proxy без авторизации.

Почему срабатывает именно global: Prowlarr обращается к FS с параметром session, а при наличии сессии request-прокси игнорируется → применяется global (PROXY_URL).

⚠️ ПИТФОЛЛ: `requestTimeout` = 60 с МАЛО, поднят до 180

Дефолтный requestTimeout прокси-элемента FlareSolverr в Prowlarr = 60 с. Решение CF-челленджа на /forum/login.php RuTracker и на kinozal занимает 80–100 с → Error solving the challenge. Timeout after 60.0 seconds в логе FS, Prowlarr отдаёт 500 InternalServerError [POST] at http://flaresolverr:8191/v1, в UI — «blocked by CloudFlare».

Фикс: requestTimeout = 180 (PUT /api/v1/indexerproxy/2). Проверка: docker logs flaresolverr → Challenge solved!, а не Timeout.

Замеры времени челленджа (kinozal.me/browse.php через FS): 78 с холодный, 20 с прогретый (CF-клэренс привязан к IP прокси), POST-логин — 97 с.

⚠️ ПИТФОЛЛ: параллельный `testall` устраивает гонку за Chrome

Prowlarr тестирует все индексеры одновременно, а у FlareSolverr один Chrome. При testall челленджи сыпятся таймаутами; если тестировать по одному (sequential) — проходят. Не верить результату параллельного testall — гонять по одному. Дополнительно: curl без --max-time виснет, если FS не отвечает — всегда ставить лимит.

⚠️ ПИТФОЛЛ: тег нужен И на прокси, И на индексере — и на ОБА прокси

Индексерам за DNS-блоком нужны два прокси-элемента и два тега:

Прокси	id	Тег	Назначение
`vless-socks5`	1	`proxy` (id=1)	обход DNS-блока провайдера
`flaresolverr`	2	`flaresolverr` (id=2)	обход Cloudflare

Значит на индексер вешаются оба тега: tags=[1,2]. Один прокси не закрывает оба блока. Фактически навешено: id 1, 4, 5, 6 → [1,2]; id 2, 3 → [1] (RuTor/Byrutor живут на одном прокси).

⚠️ ПИТФОЛЛ: PUT `/api/v1/indexer/N` → 400, нужен `?forceSave=true`

Prowlarr при PUT сразу тестирует индексер. Если FS в этот момент не прошёл (таймаут/гонка) — HTTP 400 с validationFailures. Именно так «потерялись» теги после первого PUT: они откатились к [1].

Рабочий путь: PUT /api/v1/indexer/N?forceSave=true → 202 (сохраняет, тест пропускает). Тест гонять отдельно, по одному. То же для /indexerproxy/N.

⚠️ ПИТФОЛЛ: `Auth Failed` ≠ неверный пароль

RuTracker Auth Failed в indexer/testall Prowlarr не доказывает неверный пароль. Проверять логин отдельным request.post на /forum/login.php через FS и смотреть final_url + длину HTML: залогиненная страница форума ≈ 250 KB и форма login_username в ней ВСЁ РАВНО присутствует (шаблон) — по подстроке диагноз ставить нельзя. Скрипт-проверка: /tmp/rt_login.py (см. personal/tech/flaresolverr-taiga).

⚠️ ПИТФОЛЛ: health Radarr/Sonarr кэшируется — нужен restart

RemotePathMappingCheck (и подобные) в health Radarr/Sonarr кэшируется: создание недостающих каталогов /storage/Downloads/{radarr,sonarr} ошибку не снимает. Нужен docker restart radarr sonarr, чтобы проверка прогналась заново. PUT через API кеш health тоже не сбрасывает.

Практические замечания

Логи FS пусты при LOG_LEVEL=warning — это правильно: на info он пишет login_password трекеров в plaintext. Не поднимать уровень ради «посмотреть».
sessions.create → ok, version 3.5.2 — быстрый smoke-тест живости FS.

Прямая проверка FS из prowlarr:

docker exec prowlarr sh -c 'curl -s --max-time 150 -X POST http://flaresolverr:8191/v1 \
  -H "Content-Type: application/json" \
  -d "{\"cmd\":\"request.get\",\"url\":\"https://rutracker.org/forum/login.php\",\"maxTimeout\":130000}"'
# ожидается: {"status":"ok","message":"Challenge solved!", ...}

sleep 35 после старта контейнера — Chrome поднимается ~30 с; раньше этого :8191 может не отвечать.
shm_size и sysctls — в блок сервиса compose, не в environment.
ERR_NAME_NOT_RESOLVED в ответе FS = сессия без прокси (см. открытие выше), а не «FS сломан».
Ключ API в -H ломается многоуровневым экранированием (ssh → docker → sh). Рабочий приём: printf "X-Api-Key: <KEY>" > /tmp/h.txt внутри контейнера, затем curl -H @/tmp/h.txt.
python3 внутри контейнера prowlarr НЕТ — разбирать JSON хостовым python3 (на Тайге есть python3, нет curl и sqlite3).

Состояние индексеров после деплоя (2026-09-28, финал)

id	Индексер	Теги	Статус
1	RuTracker	`[1,2]`	✅ valid (был красный с 2026-05-20)
2	RuTor	`[1]`	✅ valid
3	Byrutor	`[1]`	✅ valid
4	NoNaMe Club	`[1,2]`	✅ valid
5	Kinozal	`[1,2]`	✅ valid
6	Kinozal (M)	`[1,2]`	✅ valid

✅ ЗАКРЫТО: Kinozal — «blocked by CloudFlare» при живом FS

Самая долгая часть задачи. Симптом маскировался под таймаут, причина оказалась другой.

Что замерено (история диагностики):

Прямой socks5 к kinozal.me/browse.php → 403 Just a moment за 0.9 с (CF реален).
FS request.get kinozal → Challenge solved! 200: 78 с холодный, 20 с прогретый.
FS request.post kinozal/takelogin.php → Challenge solved! 200, 97 с.
Prowlarr: blocked by CloudFlare Protection, в логе FS — падение за 7 с (не таймаут!).

Ложный след: HTTP request failed: [500:InternalServerError] [POST] at http://flaresolverr:8191/v1 и Error solving the challenge. Timeout after 60/120/180 seconds — выглядело как «челлендж дольше таймаута». Поднятие requestTimeout 60→120→180 не помогло.

Настоящая причина: FS-сессия без прокси (см. главное открытие выше). Сессия prowlarr, созданная до появления PROXY_URL, падала с ERR_NAME_NOT_RESOLVED за 7 с, Prowlarr интерпретировал это как «CF блокирует» и уходил в retry → карантин.

Фикс: sessions.destroy сессии prowlarr → пересоздана с прокси → Kinozal (5) и Kinozal (M) (6) прошли с первого раза ({}).

Что исключено (не тратить время повторно): ресурсы FS в норме (710 MB / 21 GB, shm 1 GB, CPU 0.68%); канал прокси нормальный (kinozal через socks5 0.6 с, 908 KB/s); внутренний таймаут Prowlarr в config.xml не настраивается.

Compose-сервис (вставлен в `/mnt/RED_2TB/docker/arr/docker-compose.yml`)

  flaresolverr:
    image: ghcr.io/flaresolverr/flaresolverr:latest
    container_name: flaresolverr
    restart: unless-stopped
    environment:
      - LOG_LEVEL=warning          # НЕ info — info пишет пароли трекеров в plaintext
      - BROWSER_TIMEOUT=60000
      - TZ=Asia/Novosibirsk
      - PROXY_URL=socks5://vless-proxy:1080
    ports:
      - "8191:8191"
    networks:
      - media_net
    shm_size: 1gb                  # Кра́кен: 64 MB убивал Chrome
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=1

Порядок деплоя: бэкап compose → правка локально (не sed на сервере) → scp → cp → cd /mnt/RED_2TB/docker/arr && docker compose up -d flaresolverr. ⚠️ docker compose up -d только из своего каталога, иначе name-conflict (грабля Кра́кена).

⚠️ Swap на Тайге = 0 (/proc/swaps пуст). На Кра́кене мёртвый swap + 64 MB /dev/shm убили Chrome в crash-loop. Здесь обошлось без swap: RAM 21 GB, доступно 5.6 GB, FS держит 710 MB, CPU 0.68%. Swap не трогали — не нужен при таком объёме памяти.

История

2026-09-26 — разведка под Lidarr. Найдено: DNS-блок провайдера (NXDOMAIN на 4 трекера), vless-proxy не в media_net. Прокси-маршрут для Prowlarr починен в тот же день (3/6 индексеров). Остаток — Cloudflare на RuTracker/Kinozal. personal/plans/lidarr-taiga-and-indexer-unblock
2026-09-28 — FlareSolverr развёрнут по задаче Alex «ставь как на Кра́кене + прокси-контейнер». Решено последовательно: (1) FS сам ходит через vless-proxy (PROXY_URL) — двойной обход DNS+CF; (2) requestTimeout 60→180; (3) теги [1,2] на все CF-индексеры; (4) sessions.destroy сессии 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.

🔴 ОТКРЫТО 2026-09-28 (финал сессии): RuTracker отдаёт КАПЧУ на логин

Хронология одного вечера — пароль один и тот же, результат разный:

Время	Проверка	`len` HTML	Итог
~15:20	`request.post /forum/login.php`	251 792	✅ залогинен
~16:40	`request.post /forum/login.php`	13 335	❌ форма вернулась

Пароль в Prowlarr при этом не менялся (сверено: username/password из /api/v1/indexer/1 совпадают с локальной копией). Причина смены результата — трекер выдаёт капчу: в HTML найден блок cap_code + метка Код:. Пишется это в лог Prowlarr как NzbDrone.Core.Indexers.Exceptions.IndexerAuthException: RuTracker Auth Failed и Invalid Credentials for RuTracker [https://rutracker.org/forum/tracker.php?nm=...&f=...].

🔴 Правильный признак «залогинен/нет» — РАЗМЕР страницы, а не подстрока.

~250 KB = залогиненный форум.
~13 KB = форма логина (вернулась).

Подстрока login_username присутствует в обоих случаях (HTML-шаблон + скрытая форма быстрого входа) — по ней диагноз ставить НЕЛЬЗЯ, это дало ложное «Auth Failed» двумя диагнозами подряд.

Обходного пути в Prowlarr нет: форма индексера RuTracker принимает только username/password — поля для cookie-сессии (bb_data) не существует, вписать живую сессию из браузера нельзя.

Что делать (нужен Alex): зайти на rutracker.org браузером с этого же исходящего IP (через тот же vless-proxy), ввести логин+пароль и пройти капчу один раз. После успешного входа капча обычно снимается. Если не поможет — сменить пароль на трекере и вписать новый в Prowlarr (Indexers → RuTracker), либо поискать у RuTracker обход капчи (в Cardigann-определении поддержки нет).

⚠️ Следствие: RuTracker в карантине в Prowlarr, поэтому его caps отдаёт 429 → каскад 429:TooManyRequests в Radarr/Sonarr/Lidarr. Это нормальное поведение, лечится только восстановлением логина. См. питфолл про 429 ниже.

🔑 ГЛАВНОЕ ОТКРЫТИЕ ПРО RuTracker: капча ПРИВЯЗАНА К СЕССИИ

Самый запутанный пункт. Дефект выглядел как «неверный пароль», потом как «капча», на самом деле — капча выдаётся только для «холодных» сессий.

Замеры в одном ходе (скрипты /tmp/fs_session_cmp.py, /tmp/fs_search_check.py):

A: request.post /forum/login.php БЕЗ session      → len=13 335    ❌ форма логина вернулась
B: request.post /forum/login.php С session=prowlarr → len=251 792 ✅ ЗАЛОГИНЕН
C: request.get tracker.php?nm=...&f=... в той же сессии → len=254 745 ✅ выдача
     auth_failed_in_html=False, login_form=False

🔴 Вывод: логин через сессию prowlarr РАБОТАЕТ. Капча отдаётся только новым (безымянным) сессиям — то есть PROXY_URL + переиспользование сессии prowlarr её обходят. Мой одиночный тест без сессии давал 13 KB и порождал ложный диагноз «капча блокирует всё».

Как проверить состояние RuTracker правильно:

# ВСЕГДА с session=prowlarr, иначе получишь ложную капчу
{"cmd":"request.post","url":"https://rutracker.org/forum/login.php",
 "postData":"login_username=...&login_password=...&login=...",
 "session":"prowlarr","maxTimeout":240000}

Признак «залогинен» — len ≈ 250 KB, формы нет. 13 KB = сессия холодная, а не «пароль плох».

⚠️ Не делать вывод о пароле по тесту БЕЗ сессии. Всегда session=prowlarr.

Как снялся карантин RuTracker (рабочая процедура)

health/indexerstatus держат кэш (disabledTill), даже когда трекер уже отвечает. Снятие — тем же тестом полным объектом, что и для Kinozal:

docker exec prowlarr curl -s -H "X-Api-Key: $PK" http://localhost:9696/api/v1/indexer/1 > /tmp/p1.json
docker cp /tmp/p1.json prowlarr:/tmp/p1.json
docker exec prowlarr curl -s -X POST -H "X-Api-Key: $PK" -H "Content-Type: application/json" \
  --data-binary @/tmp/p1.json http://localhost:9696/api/v1/indexer/test
# → {} с HTTP=200  = карантин снят
docker exec prowlarr curl -s -H "X-Api-Key: $PK" http://localhost:9696/api/v1/indexerstatus   # → []
docker exec prowlarr curl -s -o /dev/null -w "%{http_code}" "http://localhost:9696/1/api?t=caps&apikey=$PK"  # → 200

Проверено: {} + 200 → indexerstatus пуст, caps → 200.

✅ ЗАКРЫТО: пароль 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). Каталоги созданы:

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.

✅ ЗАКРЫТО 2026-09-28 (финал): Radarr/Sonarr/Lidarr вычищены

Что	Итог
`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`	✅ выполнен (+ отдельный `docker restart lidarr` после правки bypass)
health Radarr	✅ `[]` — чисто
health Sonarr	✅ `[]` — чисто
health Lidarr	✅ дефект `proxyBypassFilter` закрыт; остаток — общий карантин Prowlarr
Библиотека Lidarr	1 артист (`Radiohead`), 23 релиза

✅ proxyBypassFilter расширен и рестарт выполнен. Проверка после рестарта показала: прежний симптом Http request timed out (запрос к Prowlarr уходил в прокси) ушёл — на его месте осталась честная ошибка 429:TooManyRequests от Prowlarr, потому что Kinozal 5/6 снова ушли в карантин (из-за капчи/CF). То есть дефект bypass закрыт, а остаток теперь общий со всей инфраструктурой и лечится снятием карантина в Prowlarr.

Остаток (не блокирует, вне инфраструктуры): RuTor в Radarr/Sonarr — Query successful, but no results in the configured categories. Это не блокировка и не карантин: RuTor не отдаёт результаты в категориях фильмов/сериалов. Проверено тестом полным объектом → caps отдаёт, карантина нет. Оставляем как есть — дефект самого трекера.

⚠️ Карантин имеет свойство возвращаться. После снятия Kinozal 5/6 и RuTracker снова оказались в карантине (карточки disabledTill), потому что их периодически тестирует сам Prowlarr, и тест снова падает (капча RuTracker / CF kinozal). Пока капча RuTracker не пройдена, карантин будет возвращаться волнами — это не регресс инфраструктуры.

Приёмка Alex в UI: https://prowlarr.mallexxx.duckdns.org → Indexers → 6 зелёных; https://radarr.mallexxx.duckdns.org / sonarr → System → Health пусто; https://lidarr.mallexxx.duckdns.org → артист ищется.

✅ 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 (применяется без рестарта):

# 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,prowlarr,lidarr,radarr,sonarr,transmission,jellyfin,navidrome,caddy,gluetun,taiga"
#   proxyBypassLocalAddresses: true

🔴 proxyBypassFilter ОБЯЗАН содержать prowlarr и ВСЕ docker-имена стека. Дефолт (localhost,127.0.0.1,vless-proxy) не покрывает имя prowlarr, и тогда внутренний запрос Lidarr → Prowlarr заворачивается в прокси и падает Http request timed out, хотя сам Prowlarr отвечает 200. proxyBypassLocalAddresses=true на docker-имена не действует — только на IP-литералы. Отсюда же следствие: после правки bypass нужен docker restart lidarr. Скрипт правки bypass: /tmp/lidarr_bypass.py (GET → patch → PUT → 202 → read-back). Скрипт: /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).

✅ ЗАКРЫТО: Lidarr — путь загрузки настроен (`musicCategory`)

Отдельный дефект, найден позже в тот же вечер. Вопрос Alex: «Lidarr при добавлении будет качать в музыку?» — ответ был нет, и это подтвердилось фактами.

Было (сломано):

musicCategory        = ""        ← пусто!
musicDirectory       = ""
musicImportedCategory= null

Следствие: Transmission получил бы задачу без категории, положил файл плоско в /mnt/storage/Downloads, а Lidarr ждал бы его в /storage/Downloads/<категория>. Скачивание прошло бы — импорт в библиотеку упал.

Стало (рабочий путь, проверено):

Lidarr musicCategory = lidarr                                   ← PUT ?forceSave=true → 202
Transmission: /mnt/storage/Downloads/lidarr                     ✅ существует (abc:abc)
Lidarr:       /storage/Downloads/lidarr                         ✅ существует
RemotePathMapping: /mnt/storage/Downloads/ → /storage/Downloads/ ✅
rootFolder:   /storage/Music  (978 GB free, accessible)          ✅
Скачается в:  /storage/Music/<Artist>/                           ✅
Поиск релизов: 43 FLAC-раздачи (seeders 6/5/7)                    ✅

🔴 musicCategory — дефолт lidarr (не music!). Проверять по schema (downloadclient/schema → implementation Transmission) и сверять с реально существующим каталогом в Transmission. Radarr по той же схеме использует radarr, Sonarr — sonarr; каталоги /mnt/storage/Downloads/{lidarr,radarr,sonarr} уже созданы.

Скрипт: /tmp/lidarr_category.py (GET downloadclient/1 → правка musicCategory → PUT ?forceSave=true → 202 → read-back). ⚠️ У полей бывает нет ключа value (musicDirectory = '' без value) — не падать на f['value'], использовать f.get('value').

⚠️ monitored=false у добавленного артиста — Lidarr не начнёт качать, пока у артиста не включён мониторинг альбомов (Lidarr → Artist → Monitor).

🔴 ПИТФОЛЛ: `test` требует ПОЛНЫЙ объект, не `{id}` → 400

Во всех arr-сервисах (Prowlarr, Radarr, Sonarr, Lidarr) эндпоинт POST /api/vN/indexer/test с телом {"id":N} отдаёт 400 Bad Request. Правильно — отправить полный объект индексера:

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 НЕ РАБОТАЕТ в Radarr/Sonarr — отдаёт 400, а Sonarr ещё и подвешивается >300 с (в Prowlarr testall тоже вреден: один Chrome → гонка, см. питфолл про параллельный тест). Единственный рабочий путь — POST /indexer/test по одному, полным объектом. Проверено на всех четырёх сервисах.

🔴 GET /indexerstatus есть ТОЛЬКО в Prowlarr — в Radarr/Sonarr эндпоинт → 404. Карантин в Radarr/Sonarr иначе: смотреть health (warning «Indexers unavailable due to failures») и обнулять PUT /api/v3/indexer/N?forceSave=true.

🔴 ПИТФОЛЛ: `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]. Настоящая причина — не в них.

Порядок лечения (снизу вверх):

Снять карантин в Prowlarr — POST /api/v1/indexer/test полным объектом (по одному).
Проверить GET /api/v1/indexerstatus → пусто и caps → 200.
Пересохранить проблемный индексер в самом arr: PUT /api/v3/indexer/N?forceSave=true → 202 (сбрасывает FailureCount).
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:

Кто	Механизм	Ключ
Prowlarr (индексеры)	SOCKS5-прокси в Prowlarr + FlareSolverr	теги `[1,2]`, `PROXY_URL` у FS
FlareSolverr (Chrome)	глобальный прокси образа	env `PROXY_URL=socks5://...` (НЕ HTTP_PROXY)
Lidarr (SkyHook)	встроенный конфиг приложения	`config/host.proxyEnabled` (env НЕ работает)

⚠️ Не переносить рецепт одного сервиса на другой. arr-сервисы внешне похожи, но механизм прокси у каждого свой; проверять фактическим запросом, а не по аналогии.

История (финал сессии 2026-09-28)

~15:20 — RuTracker логинится (len 251 792), поиск «matrix» → 256 результатов, health всех arr пуст. Замер зафиксирован в разделе «РЕЗУЛЬТАТ».
~16:00 — Lidarr: /release?artistId=1 → 0. Найдена причина — proxyBypassFilter без prowlarr; внутренний запрос Lidarr→Prowlarr уходил в прокси и таймаутил. Фикс: filter расширен до всех docker-имён (PUT config/host → 202, read-back).
~16:10 — docker restart lidarr. Симптом-таймаут ушёл, но всплыла настоящая причина: 429:TooManyRequests от Prowlarr → Kinozal 5/6 снова в карантине.
~16:20 — карантин Kinozal/Kinozal(M) снят тестом полным объектом → caps 1/5/6 → 200. Radarr/Sonarr: PUT ?forceSave=true → 202, docker restart → health [].
~16:40 — RuTracker перестал логиниться: HTML сжался 251 KB → 13 KB, в форме найден cap_code + метка Код: → диагноз «трекер требует капчу». Пара в Prowlarr не менялась (сверено байт-в-байт с локальной копией) — «пароль неверен» ложный.
~17:00 — Alex сам починил логин на трекере. Проверка выявила ключевое: логин БЕЗ сессии → 13 KB (капча), логин С session=prowlarr → 251 792 ✅. Капча привязана к «холодной» сессии; сессия Prowlarr её обходит. См. раздел «ГЛАВНОЕ ОТКРЫТИЕ ПРО RuTracker».
~17:10 — найден отдельный дефект Lidarr: musicCategory пустая → импорт скачанного упал бы. Исправлено на lidarr (202); сверены каталоги, маппинг, root folder. Поиск релизов: 43 FLAC-раздачи.
~17:20 — карантин RuTracker снят тестом полным объектом → {} HTTP 200, indexerstatus → [], caps idx1 → 200. Prowlarr полностью чист.
Итог: инфраструктура Тайги чиста и проверена. Открыт 1 дефект — RuTor (no results in the configured categories, на стороне трекера). Остаток-механика: docker restart radarr sonarr lidarr для сброса кэша health со старым RuTracker (команда ждала апрува Alex, в этой сессии не выполнена).

Что делать при возврате симптома «индексера недоступны»

GET /api/v1/indexerstatus в Prowlarr → кто в карантине (disabledTill).
Снять карантин: POST /api/v1/indexer/test полным объектом, по одному (не testall).
GET /N/api?t=caps → должен быть 200 (429 = ещё в карантине).
В Radarr/Sonarr: PUT /api/v3/indexer/N?forceSave=true → 202, затем docker restart.
Если снова падает RuTracker — это капча, а не пароль: проверить логин request.post /forum/login.php через FS и смотреть размер HTML (250 KB = ОК, 13 KB = капча).

44 KiB Executable File Raw Blame History Unescape Escape