[2026-09-29] eagle: family/how-to/arr-stack-taiga.md family/plans/lidarr-taiga-deploy.md personal/plans/flaresolverr-taiga-deploy.md personal/plans/lidarr-taiga-and-indexer-unblock.md personal/tech/flaresolverr-taiga.md personal/tech/prowlarr-flaresolverr-cloudflare.md

personal/tech/flaresolverr-taiga.md

@@ -1,580 +1,137 @@
-# FlareSolverr на Тайге + обход блокировок индексеров
-
-> ✅ **АКТУАЛЬНОЕ СОСТОЯНИЕ 2026-09-29:** arr-стек проверен после полного force-recreate.
-> FlareSolverr автоматически создаёт авторизованную сессию `prowlarr` через
-> `socks5://vless-proxy:1080`; Prowlarr → RuTracker test возвращает HTTP 200.
-> Lidarr → SkyHook возвращает 10 результатов через `vless-proxy:1081`.
-> Lidarr → Transmission test проходит; локальный Transmission исключён из внешнего proxy.
-> Все контейнеры arr и Jellyfin после рестарта `running`, `docker compose config -q` проходит.
-> В Lidarr остаётся только исторический health-warning по Kinozal/RuTracker; текущий
-> Prowlarr `indexerstatus` пуст. Не использовать старые блоки ниже как инструкцию.
-
-> ⚠️ **СОСТОЯНИЕ 2026-09-28 (конец сессии): FS жив, но RuTracker/Kinozal снова в таймауте.**
-> Проверено: `docker exec flaresolverr curl -s http://localhost:8191/health` → `{"status": "ok"}`,
-> версия **3.5.2**, `sessions.list` → `["prowlarr"]` (сессия существует).
-> Prowlarr: `health: []`, `indexerstatus` → `[]` (карантина НЕТ), теги `[1,2]` на id 1/5/6 расставлены
-> **верно**. НО `POST /api/v1/indexer/test` полным объектом для **id 1 (RuTracker), 5 (Kinozal),
-> 6 (Kinozal M)** → **пустой ответ даже при таймауте 90 с**; работают **NoNaMe(4), RuTor(2), Byrutor(3)**.
-> ⇒ Сессия существует, но, **вероятно, создана без proxy** (контейнеры пересоздавались — все `Up 3 minutes`).
-> 🔴 **ПЕРВЫЙ шаг диагностики (не сессии, не карантин):**
-> ```bash
-> ssh truenas_admin@mallexxx.duckdns.org "docker exec flaresolverr ps aux | grep chromium | head -3"
-> ```
-> Ищем `--proxy-server=socks5://vless-proxy:1080`. **Нет флага** → `sessions.destroy` +
-> `sessions.create` с proxy (см. §«ПРОКСИ-СЛОЙ ИСПРАВЛЕН» ниже).
-> Полный аудит стека — [[family/plans/lidarr-taiga-deploy]] §«АУДИТ ВСЕГО СТЕКА».
-
-> 🔴 **НОВОЕ 2026-09-28 (вечер): ТОТ ЖЕ КЛАСС ДЕФЕКТА У LIDARR — свой `ProxyCheck` не проходит.**
-> ⚠️ **УСТАРЕЛО, оставлено как история:** SkyHook (`api.lidarr.audio`) отдавал **403 Cloudflare**;
-> в теле ответа — `Your IP: 90.189.160.148` (домашний). Встроенный прокси Lidarr
-> `proxyEnabled=true, proxyType=http, vless-proxy:1081` **записан, но не применялся** —
-> `docker logs lidarr | grep -i proxy` давал **`[Error] ProxyCheck: Proxy Health Check failed`**.
-> ✅ **К концу сессии 2026-09-28 SkyHook ЗАРАБОТАЛ** (Alex починил): `lookup Astrix` → **10 результатов**.
-> ⇒ **Правило остаётся валидным для ЛЮБОГО сервиса на Тайге, который ходит в интернет сам**
-> (Lidarr → SkyHook, FS → Chrome): по умолчанию он выходит с **домашнего IP**. Проверять не
-> «настроен ли прокси», а **«какой внешний IP у самого сервиса»**.
-> 🔴 **`GET /api/v1/health` у Lidarr отдаёт `[]`, даже когда `ProxyCheck` падает** — health-кэш врёт,
-> ориентироваться на логи. 🔴 **Внешний IP дома = `90.189.160.148` И у хоста Тайги тоже** — вся сеть
-> NAS идёт через домашний аплинк; VPS-выход даёт **только** `vless-proxy`
-> (`104.28.211.192` через 1080 и 1081 — обе рабочие).
-> ⇒ Практическое правило: **любой сервис на Тайге, который ходит в интернет сам** (Lidarr → SkyHook,
-> FS → Chrome), по умолчанию выходит с домашнего IP. Проверять не «настроен ли прокси», а
-> **«какой внешний IP у самого сервиса»**.
-> `docker restart lidarr` **выполнен — не помог**. Подробности — [[family/plans/lidarr-artist-watchlist]] §БЛОКЕР.
-
-> ✅ **ПРОКСИ-СЛОЙ ИСПРАВЛЕН 2026-09-29:** причина была не в `vless-proxy`.
-> FlareSolverr 3.5.2 **игнорирует `proxy` у `request.get/request.post`, если указан `session`**.
-> `PROXY_URL` подставляется в тело запроса, но при уже заданной сессии драйвер берётся из старой
-> сессии. Prowlarr создавал `prowlarr` без proxy, поэтому Chrome ходил напрямую с `90.189.160.148`.
-> `vless-proxy` исправен: SOCKS даёт внешний IP `104.28.209.115`/`187.15.56.1`.
->
-> **Рабочий фикс на TrueNAS (выполнен):** удалить сессию `prowlarr` и создать её заново с proxy:
-> ```bash
-> curl -sS -X POST http://localhost:8191/v1 -H 'Content-Type: application/json' \
->   -d '{"cmd":"sessions.destroy","session":"prowlarr"}'
-> curl -sS -X POST http://localhost:8191/v1 -H 'Content-Type: application/json' \
->   -d '{"cmd":"sessions.create","session":"prowlarr","proxy":{"url":"socks5://vless-proxy:1080"}}'
-> ```
-> Проверка: `docker exec flaresolverr ps aux | grep chromium` должен содержать
-> `--proxy-server=socks5://vless-proxy:1080`; запрос через session `prowlarr` к `api.ipify.org`
-> должен вернуть IP, отличный от `90.189.160.148`.
->
-> ⚠️ После пересоздания/рестарта контейнера FlareSolverr эту сессию нужно создать снова.
-> `PROXY_URL` оставляем в compose, но одного его недостаточно для постоянной сессии Prowlarr.
-> **Устойчивый прокси-фикс применён:** `/mnt/RED_2TB/docker/arr/flaresolverr-entrypoint.sh` ждёт `/health`,
-> пересоздаёт `prowlarr` с proxy и затем запускает основной процесс. В compose добавлены
-> `entrypoint` и read-only bind mount этого скрипта. После `docker compose up -d --force-recreate
-> flaresolverr` проверка должна показать `sessions: ["prowlarr"]` и `--proxy-server=...`.
->
-> ⚠️ **Остаточный блокер end-to-end:** прямой запрос через FS к
-> `https://rutracker.org/forum/tracker.php?nm=radiohead` проходит (`HTTP 200`, ~274 KB,
-> `bb_session`), но поиск через Prowlarr всё ещё получает timeout примерно через 101 с.
-> Prowlarr не добавляет новую запись `IndexerStatus` после очистки только до следующей попытки.
-> Текущая конфигурация для продолжения: RuTracker тег `[2]` (только FlareSolverr),
-> `rutracker.org` в `extra_hosts`, `BROWSER_TIMEOUT=180000`.
-
-> 🔴🔴 **ОБНОВЛЕНИЕ 2026-09-29 (поздняя сессия): ДЕФЕКТ ЛОКАЛИЗОВАН — Chrome FS стартует БЕЗ `--proxy-server=`.**
-> Прокси-контейнер `vless-proxy` **жив и работает** (логи: `tunneling request ... via vpn.mallexxx.duckdns.org:443`).
-> `PROXY_URL=socks5://vless-proxy:1080` в env FS есть, но **к Chrome не применяется** — в командной строке
-> Chrome флага `--proxy-server` нет вообще, и контрольный Chrome-запрос **не оставил следа в логе `vless-proxy`**.
-> ⇒ Chrome ходит напрямую, выходит с домашнего `90.189.160.148`. Следствие: RuTracker `ERR_TIMED_OUT` → карантин.
-> Диагностику начинать НЕ с карантина и НЕ с сессий, а с: `docker exec flaresolverr ps aux | grep chromium`.
-> Подробности — раздел «КОРЕНЬ НАЙДЕН» в конце. VPS **нет**, версия про DuckDNS **отвергнута Alex**.
->
-> 🟡 **СОСТОЯНИЕ 2026-09-29 (ранее, до находки): FS настроен верно, НО RuTracker снова упал в 0.**
-> Поиск: `search?query=radiohead` → RuTracker **0** ❌, NoNaMe **47** ✅, RuTor **33** ✅.
-> Причина падения найдена — **сломанная сессия `prowlarr`** (см. раздел «ДВЕ ЛОВУШКИ ДИАГНОСТИКИ»).
-> `IndexerStatus` содержит RuTracker (`disabledTill 2026-09-28T15:47`).
-> Health: Prowlarr 1 warning (RuTor), Radarr 1, Sonarr 2, Lidarr 2 — все про RuTracker/Kinozal/RuTor.
-> Контейнер `flaresolverr` — штатный образ, `PROXY_URL=socks5://vless-proxy:1080`, порт `8191`, сеть `media_net`,
-> `shm_size: 1gb`, `LOG_LEVEL=warning`. Compose: `/mnt/RED_2TB/docker/arr/docker-compose.yml`.
-> Тайга: `192.168.2.197`, внешний IP дома `90.189.160.148`, DNS роутера `192.168.2.2`.
-> Связка: [[family/projects/media-toolbox-taiga]], [[family/plans/lidarr-taiga-deploy]],
-> [[personal/tech/prowlarr-flaresolverr-cloudflare]], [[family/how-to/arr-stack-kraken]].
-
-## 🔴🔴 ДВЕ ЛОВУШКИ ДИАГНОСТИКИ (главное этой сессии)
-
-Обе стоили часов и обе — про то, что **артефакт врёт**, если смотреть не то поле.
-
-### Ловушка 1: `len≈250 KB` ≠ «залогинен». Это может быть Chrome-страница ОШИБКИ
-
-Прошлый вывод «~250 KB = залогиненный форум» **опровергнут**. В сломанной сессии 251 792 байта —
-это **встроенная страница ошибки Chromium**, а не форум:
-
-```html
-<html dir="ltr" lang="en"><head><meta name="color-scheme" content="light dark">
-<title>rutracker.org</title>
-<style>/* Copyright 2017 The Chromium Authors */</style>
-```
-
-Диагностические маркеры в такой странице: `logged-in=0`, `logout=0`, `IS_GUEST=0/1` — **ни одного**,
-`cap_code=0`, `неверное/неактивное=0`, `challenge-platform=0`. То есть **судить по размеру нельзя**.
-
-🔴 **Правильный признак «залогинен» — наличие cookies, а не длина HTML:**
-
-| Проверка | Залогинен | Не залогинен |
-|---|---|---|
-| `solution.cookies` | есть **`bb_session`** ✅ | пусто / только `cf_clearance`+`bb_guid` |
-| Маркер в HTML | `IS_GUEST: !!'0'` | нет ни одного маркера |
-| `len` | **~105 KB** (свежая сессия) | 13 KB форма / 251 KB ошибка Chrome |
-
-> ⚠️ **Всегда проверять `solution.cookies[].name` — наличие `bb_session` единственный надёжный признак.**
-> Замеры одной сессии: сессия `prowlarr` → `len=251792, cookies=[]` (ошибка);
-> свежая `cmp-fresh` → `len=105507, cookies=[bb_session, bb_ssl, bb_guid, cf_clearance]` ✅.
-
-### Ловушка 2: сессия FS может быть «отравлена» и переживает рестарт FS
-
-Сессия `prowlarr` залипла в сломанном Chrome: **любой** запрос через неё возвращает 251 KB
-страницы ошибки и **пустые cookies**. При этом:
-- `sessions.list` показывает её живой;
-- она **переживает `docker restart flaresolverr`** (наблюдалось: жила 2 часа через рестарты);
-- Prowlarr получает `Empty cookies returned` → `RuTracker Auth Failed` → карантин.
-
-```
-сессия prowlarr (сломанная):  POST login → len=251792, cookies=ПУСТЫЕ  ❌
-свежая сессия:                POST login → len=105507, cookies=[bb_session...] ✅
-```
-
-🔴 **Диагностика обязана включать `sessions.list` + убийство сессии `prowlarr`.** Именно это
-снимает дефект — Prowlarr пересоздаёт сессию чистой при следующем запросе.
-
+---
+title: FlareSolverr на TrueNAS Taiga
+created: '2026-09-20'
+updated: '2026-09-29'
+type: tech
+namespace: personal
+tags: [flaresolverr, prowlarr, rutracker, taiga, truenas]
+related:
+  - "[[family/how-to/arr-stack-taiga]]"
+  - "[[personal/tech/prowlarr-flaresolverr-cloudflare]]"
 ---
 
-## 🔴 ПРИЧИНА ВСЕХ ПРОБЛЕМ: путаница аккаунтов (не капча, не прокси, не CF)
+# FlareSolverr на TrueNAS Taiga
 
-Долгая диагностика упиралась в «капчу RuTracker» — **причины такой не было**.
+Рабочая документация FlareSolverr для arr-стека Taiga. Общая эксплуатация стека находится в [[family/how-to/arr-stack-taiga]]. Kraken здесь не описывается.
 
-```
-Prowlarr:  username = mallexxx       password = m@n*w$uperP@$$w0rD
-Мой тест:  username = keropjan_88    password = I70aj7Igpr          ← ЛЕВЫЙ аккаунт
+## Рабочая схема
+
+```text
+Prowlarr
+  └─ tags [proxy, flaresolverr]
+       └─ FlareSolverr :8191
+            └─ Chrome session prowlarr
+                 └─ socks5://vless-proxy:1080
+                      └─ RuTracker
 ```
 
-RuTracker на неверный пароль отвечает **формой логина + капчей**. Отсюда ложный вывод «капча блокирует».
-С правильными данными Prowlarr логинится **без капчи**.
+Файлы на TrueNAS:
 
-> 🔴 **Прежде чем диагностировать капчу/CF/прокси — сверить пару логин/пароль в Prowlarr:**
-> ```bash
-> python3 -c "
-> import json,sqlite3,shutil
-> shutil.copy('/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db','/tmp/o.db')
-> c=sqlite3.connect('/tmp/o.db')
-> for r in c.execute('SELECT Name,Settings FROM Indexers'):
->     s=json.loads(r[1])
->     print(r[0], {k:v for k,v in s.items() if 'user' in k.lower() or 'pass' in k.lower()})
-> "
-> ```
-
-## 🔑 FS-СЕССИЯ НЕ НАСЛЕДУЕТ `PROXY_URL` — убить сессию после правки
-
-`PROXY_URL` применяется к Chrome **в момент создания сессии**. Сессия, созданная до появления
-`PROXY_URL`, навсегда остаётся **без прокси** → `net::ERR_NAME_NOT_RESOLVED` → Prowlarr
-интерпретирует это как `blocked by CloudFlare Protection` и уходит в retry → карантин.
-
-```
-request.get + session:"prowlarr" (старая)
-  → {"status":"error","message":"unknown error: net::ERR_NAME_NOT_RESOLVED"}
+```text
+/mnt/RED_2TB/docker/arr/docker-compose.yml
+/mnt/RED_2TB/docker/arr/flaresolverr-entrypoint.sh
+/mnt/RED_2TB/docker/arr/prowlarr/
 ```
 
-**Фикс:** удалить сессию — Prowlarr пересоздаст её сам уже с прокси.
-```bash
-docker exec prowlarr sh -c 'curl -s --max-time 60 -X POST http://flaresolverr:8191/v1 \
-  -H "Content-Type: application/json" -d "{\"cmd\":\"sessions.destroy\",\"session\":\"prowlarr\"}"'
-```
-> ⚠️ **После ЛЮБОЙ правки `PROXY_URL`** — убить сессию `prowlarr`.
-> ✅ Обычный перезапуск FS проблемы не создаёт: сессия создастся заново с прокси.
+## Почему нужен entrypoint
 
-## 🔑 Имя переменной — `PROXY_URL` (не `HTTP_PROXY`)
+Одного `PROXY_URL` недостаточно. FlareSolverr применяет proxy при создании browser session. Если session создана до настройки proxy, последующие `request.get` с той же session продолжают работать без proxy.
 
-`PROXY_URL=socks5://vless-proxy:1080` — **схема обязательна**. Приоритет: request > session > global.
-Prowlarr обращается к FS с параметром `session`, поэтому работает именно global.
-Проверка, что прокси применён (нужен `LOG_LEVEL=debug`):
-```
-INFO  Using proxy URL ENV
-DEBUG Using webdriver proxy: socks5://vless-proxy:1080
-```
+Entrypoint при каждом старте:
 
-**Почему FS обязан ходить через прокси:** на Тайге блоков **два** — DNS провайдера + Cloudflare.
-Без прокси FS сам получает NXDOMAIN и не помогает. На Кра́кене DNS-блока нет, поэтому там
-`PROXY_URL` не нужен.
+1. ждёт FlareSolverr `/health`;
+2. удаляет старую session `prowlarr`, если она есть;
+3. создаёт `prowlarr` с `socks5://vless-proxy:1080`;
+4. читает credentials RuTracker из `prowlarr.db` через SQLite URI `mode=ro&immutable=1`;
+5. делает pre-login через FlareSolverr;
+6. оставляет основной процесс FlareSolverr работать.
 
-## 🔴 `IndexerStatus` снимается ТОЛЬКО через SQL — тест его ПРОДЛЕВАЕТ
+SQLite монтируется read-only. Обычный `sqlite3.connect('/prowlarr.db')` на read-only mount может упасть с `unable to open database file`; нужен именно `immutable=1`.
 
-`POST /indexer/test` карантин **не снимает, а эскалирует**: наблюдалось `DisabledTill` 15:44 → 21:45
-после одного теста. Пока запись есть, `caps` отдаёт **429**, и warning каскадом идёт во все arr.
+## Compose-настройки
 
-```bash
-DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db
-# 1. бэкап через .backup, НЕ cp (WAL-режим)
-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;"
-sqlite3 "$DB" "PRAGMA quick_check;"          # → ok
-docker start prowlarr
-```
-Поля: `EscalationLevel` 0–9 (9 = сутки блокировки), `DisabledTill`.
-`sqlite3` на хосте Тайги **есть**, в контейнерах — нет.
-
-## 🔴 ПРИЁМКА — `search`, а НЕ `caps` и НЕ `health`
-
-`caps` 200 + пустой `indexerstatus` + `health []` **не доказывают**, что поиск работает.
-```bash
-PK=$(grep -o "<ApiKey>[^<]*" /mnt/RED_2TB/docker/arr/prowlarr/config.xml | cut -d">" -f2)
-for I in 1 2 4 5 6; do
-  echo "idx$I=$(curl -s --max-time 200 "http://localhost:9696/api/v1/search?query=radiohead&type=search&indexerIds=$I" \
-    -H "X-Api-Key: $PK" | python3 -c 'import json,sys
-try:
-  d=json.load(sys.stdin); print(len(d) if isinstance(d,list) else "ERR")
-except: print("EMPTY")')"
-done
-```
-
-## Прокси-элементы и теги (в Prowlarr)
-
-| Прокси | id | Тег | Закрывает |
-|---|---|---|---|
-| `vless-socks5` | 1 | `proxy` (1) | DNS-блок провайдера |
-| `flaresolverr` | 2 | `flaresolverr` (2) | Cloudflare |
-
-CF-индексеры получают **оба** тега: `tags=[1,2]`. RuTor/Byrutor живут на одном (`[1]`).
-`requestTimeout` прокси-элемента flareSolverr = **180** (дефолт 60 мало: челлендж занимает 80–100 с).
-
-## ⚠️ ПИТФОЛЛЫ API
-
-- **`PUT /api/v1/indexer/N` → 400**, нужен `?forceSave=true` → **202**. Без него теги откатываются:
-  Prowlarr при PUT сразу тестирует индексер, и при падении FS откатывает сохранение.
-- **`POST /indexer/test` требует ПОЛНЫЙ объект**, не `{"id":N}` (иначе 400). `{}` + **200** = успех.
-- **`testall` вреден:** один Chrome у FS → гонка за него, челленджи сыпятся таймаутами. Тестировать по одному.
-- **`GET /indexerstatus` есть только в Prowlarr** — в Radarr/Sonarr → 404.
-- **`429` на `/N/api?t=caps`** = карантин Prowlarr → каскад `429:TooManyRequests` во все arr.
-  Лечить снизу вверх: SQL-очистка в Prowlarr → `PUT ?forceSave=true` в arr → `docker restart` arr.
-- **Ключ API в `-H` ломается экранированием** (ssh → docker → sh): `printf "X-Api-Key: KEY" > /tmp/h.txt`,
-  затем `curl -H @/tmp/h.txt`.
-- **`python3` в контейнере prowlarr НЕТ** (на хосте Тайги есть; `curl` и `sqlite3` на хосте — нет).
-
-## ⚠️ ПИТФОЛЛЫ FlareSolverr
-
-- `sessions.create` → `{"status":"ok","version":"3.5.2"}` — быстрый smoke-тест живости.
-- **`LOG_LEVEL=warning` (не info!)** — `info` пишет `login_password` трекеров в **plaintext** в лог.
-- `sleep ~30` после старта контейнера: Chrome поднимается, до этого `:8191` может не отвечать.
-- `sessions.destroy` несуществующей сессии → **HTTP 500**, не «ok/not found» (оборачивать в try).
-- `shm_size`/`sysctls` — в блок сервиса compose, не в `environment`.
-- Порт `8191` с Mac наружу **не проброшен** — скрипты запускать на хосте Тайги (`scp` + `ssh python3`).
-
-## ⚠️ ПИТФОЛЛ: `Auth Failed` — порядок диагностики (обновлён 2026-09-29)
-
-`RuTracker Auth Failed` / `Invalid Credentials` в Prowlarr имеет **три разные причины**, и
-симптом у них одинаковый. Проверять **строго в этом порядке**:
-
-| # | Проверка | Признак причины |
-|---|---|---|
-| 1 | `sessions.list` → есть ли сессия `prowlarr`, и что она отдаёт | сессия «отравлена» → **убить её** |
-| 2 | `solution.cookies` после логина | нет **`bb_session`** → логин не прошёл |
-| 3 | `SELECT Settings FROM Indexers WHERE Id=1` в `prowlarr.db` | пара логин/пароль не та, что в тесте |
-| 4 | `IndexerStatus` в БД | есть запись → карантин (снимать SQL, не тестом) |
-
-🔴 **НИКОГДА не судить о логине по длине HTML.** Ранее в этом доке было записано
-«~250 KB = залогинен, ~13 KB = форма» — **это неверно** (см. «ДВЕ ЛОВУШКИ ДИАГНОСТИКИ»):
-250 KB бывает страницей ошибки Chrome, а залогиненная свежая сессия даёт ~105 KB.
-
-```bash
-# Правильная проверка логина — по cookies
-curl -s --max-time 220 -X POST http://localhost:8191/v1 -H "Content-Type: application/json" \
-  -d '{"cmd":"request.post","url":"https://rutracker.org/forum/login.php",
-       "session":"prowlarr",
-       "postData":"login_username=<U>&login_password=<P>&login=%D0%92%D1%85%D0%BE%D0%B4",
-       "maxTimeout":200000}' | jq -r '.solution.cookies[].name'
-# видим bb_session → залогинен. Пусто → сессия сломана, убить и повторить.
-```
-
-## ⚠️ Кэш health в arr-сервисах
-
-`RemotePathMappingCheck` и подобные **кэшируются**: создание каталогов ошибку не снимает,
-`PUT` по API тоже не сбрасывает. Нужен `docker restart radarr sonarr lidarr`.
-
-## Три механизма прокси на одном хосте — не путать
-
-| Кто | Механизм | Ключ |
-|---|---|---|
-| Prowlarr (индексеры) | SOCKS5-прокси в Prowlarr + FlareSolverr | теги `[1,2]`, `PROXY_URL` у FS |
-| FlareSolverr (Chrome) | глобальный прокси образа | env `PROXY_URL` (**НЕ** `HTTP_PROXY`) |
-| Lidarr (SkyHook) | встроенный конфиг приложения | `config/host.proxyEnabled` (**env НЕ работает**) |
-
-> ⚠️ **Не переносить рецепт одного сервиса на другой** — проверять фактическим запросом.
-
-## Compose-сервис
+Минимально необходимые параметры:
 
 ```yaml
-  flaresolverr:
-    image: ghcr.io/flaresolverr/flaresolverr:latest
-    container_name: flaresolverr
-    restart: unless-stopped
-    environment:
-      - LOG_LEVEL=warning          # НЕ info — пишет пароли в plaintext
-      - BROWSER_TIMEOUT=60000
-      - TZ=Asia/Novosibirsk
-      - PROXY_URL=socks5://vless-proxy:1080
-    ports:
-      - "8191:8191"
-    networks:
-      - media_net
-    shm_size: 1gb
-    sysctls:
-      - net.ipv6.conf.all.disable_ipv6=1
-```
-Деплой: правка **локально** (не sed) → `scp` → `cd /mnt/RED_2TB/docker/arr && docker compose up -d flaresolverr`.
-⚠️ `docker compose up -d` **только из своего каталога**, иначе name-conflict.
-
-> ⚠️ **Swap на Тайге = 0** — не мешает: RAM 21 GB, FS держит ~710 MB, CPU 0.68%. **Swap не трогать.**
-> ⚠️ У FS **нет** persistent-профиля Chrome: он живёт в контейнере и умирает при пересоздании.
-> Это **не проблема** — FS логинится в RuTracker при каждом старте без капчи.
-
-## Состояние индексеров (2026-09-29, конец сессии)
-
-| id | Индексер | Теги | Поиск |
-|---|---|---|---|
-| 1 | RuTracker | `[1,2]` | ❌ **0** — сессия `prowlarr` сломана, в карантине |
-| 2 | RuTor | `[1]` | ✅ 33 |
-| 3 | Byrutor | `[1]` | — |
-| 4 | NoNaMe Club | `[1,2]` | ✅ 47 |
-| 5 | Kinozal | `[1,2]` | ⚠️ CF, периодически в карантине |
-| 6 | Kinozal (M) | `[1,2]` | ⚠️ зеркало Kinozal (5) |
-
-**Health по сервисам (2026-09-29):**
-```
-Prowlarr  1 warning  RuTor (no results in categories — дефект трекера)
-Radarr    1 warning  RuTracker unavailable > 6 hours
-Sonarr    2 warning  RuTracker + RuTor
-Lidarr    2 warning  RuTracker + Kinozal (M)
+environment:
+  - LOG_LEVEL=warning
+  - BROWSER_TIMEOUT=180000
+  - PROXY_URL=socks5://vless-proxy:1080
+  - TZ=Asia/Novosibirsk
+shm_size: 1gb
+restart: unless-stopped
 ```
 
-## 🔴 ЧЕКЛИСТ «не всё зелёное» (восстановление RuTracker)
+Entrypoint и Prowlarr config directory подключаются read-only. Не хранить credentials или API keys в compose и Obsidian.
 
-Когда RuTracker даёт 0, а FS жив — выполнить **в этом порядке**:
+В Prowlarr для RuTracker:
+
+```text
+proxy tag = [1]
+flaresolverr tag = [2]
+RuTracker tags = [1,2]
+FlareSolverr requestTimeout = 180 seconds
+```
+
+Один tag `[2]` не решает DNS-блок Taiga. Один tag `[1]` не решает browser challenge.
+
+## Правильная проверка
+
+Проверка session:
 
 ```bash
-# 1. Убить сессии FS (главный шаг — сессия переживает рестарт FS!)
-for S in prowlarr cmp-fresh; do
-  curl -s --max-time 60 -X POST http://localhost:8191/v1 \
-    -H "Content-Type: application/json" \
-    -d "{\"cmd\":\"sessions.destroy\",\"session\":\"$S\"}" -o /dev/null
-done
-curl -s -X POST http://localhost:8191/v1 -H "Content-Type: application/json" \
-  -d '{"cmd":"sessions.list"}'          # → sessions: [] (ждём пусто)
-
-# 2. Снять карантин SQL (тест его ПРОДЛЕВАЕТ, не снимает)
-DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db
-docker stop prowlarr
-sqlite3 "$DB" "DELETE FROM IndexerStatus;"
-docker start prowlarr && sleep 20
-
-# 3. ПРИЁМКА — реальный поиск (НЕ caps, НЕ health)
-PK=$(grep -o "<ApiKey>[^<]*" /mnt/RED_2TB/docker/arr/prowlarr/config.xml | cut -d">" -f2)
-curl -s --max-time 150 "http://localhost:9696/api/v1/search?query=radiohead&type=search&indexerIds=1" \
-  -H "X-Api-Key: $PK" | python3 -c "import json,sys; print(len(json.load(sys.stdin)))"
-# ждём > 0
+curl -fsS -H 'Content-Type: application/json' \
+  -d '{"cmd":"sessions.list"}' http://127.0.0.1:8191/v1
 ```
 
-> ⚠️ **Переживёт ли reboot:** `IndexerStatus` и сломанная сессия **переживают** — без шагов 1–2
-> после перезагрузки RuTracker останется в 0. Сессия живёт в памяти FS и **выдерживает
-> `docker restart flaresolverr`**.
+Должны быть `status=ok` и `prowlarr`.
 
-## 🔴 Чего НЕ делать (проверено, не работает)
+Проверка login должна смотреть cookies, а не размер HTML:
 
-| Идея | Почему нет |
-|---|---|
-| Капча-солвер (`CAPTCHA_SOLVER`) | **Официально non-functional** (DeepWiki FS, issue #1452 закрыт). Адаптеры удалены из образа. И по факту капча не нужна — см. главный раздел |
-| Вписать cookies в Prowlarr вручную | Индексер принимает только `username`/`password`, поля для cookie нет |
-| noVNC/свой образ FS для ручного входа | Строилось под ложную гипотезу «капча». **Снесено 2026-09-29.** Не воссоздавать |
-| Браузер Alex через 3x-ui | `vless-proxy` — **клиент**, не сервер; `cf_clearance` привязан к IP+UA+fingerprint |
-| Persistent-профиль Chrome у FS | Не решает ничего: FS логинится сам |
+```text
+solution.cookies содержит bb_session
+```
 
-> 🔴 **Не строить план на посылке «на Кра́кене работает».** На 2026-09-29 у Кра́кена в БД
-> тот же карантин `EscalationLevel=9` (RuTracker/Kinozal/Kinozal M, с 27 сен) и **нет** капча-солвера.
-> «Как на Кра́кене» ≠ «починить».
+Большая HTML-страница может быть страницей ошибки Chromium и не означает login.
 
-## 📋 ЖУРНАЛ ОТКАТА (2026-09-29) — что снесено и как вернуть
-
-Эксперимент «ручная капча через VNC» построен под ложную гипотезу и полностью откачен.
-Записано, чтобы не воссоздавать и чтобы понимать, что удалено.
-
-| Артефакт | Было | Стало |
-|---|---|---|
-| Compose `image:` | `flaresolverr-vnc:latest` (свой образ) | `ghcr.io/flaresolverr/flaresolverr:latest` |
-| Compose порт | `8191:8191` + `6080:6080` | только `8191:8191` |
-| Compose volume | `/mnt/RED_2TB/docker/arr/flaresolverr-config:/config` | убран |
-| Каталог сборки | `/mnt/RED_2TB/docker/arr/fs-vnc/{Dockerfile,supervisord.conf,entrypoint-vnc.sh}` | удалён |
-| Образ | `flaresolverr-vnc:latest` | удалён (`docker rmi`) |
-| Отладочный контейнер | `fs-debug` | удалён (`docker rm -f`) |
-| Caddyfile | блок `vnc.mallexxx.duckdns.org` (basic_auth + reverse_proxy) | блок убран, config валиден |
-| Сеть Caddy | подключён к `media_net` | `docker network disconnect media_net caddy` |
-| Каталог профиля | `/mnt/RED_2TB/docker/arr/flaresolverr-config/` | удалён |
-
-### ⚠️ ПИТФОЛЛЫ отката (стоили времени)
-
-1. **`docker compose up -d --force-recreate` падает**, если bind-source уже удалён:
-   `invalid mount config for type "bind": bind source path does not exist`.
-   Контейнер держит старый маунт в памяти → нужно **`docker rm -f flaresolverr`**, потом up.
-2. **Каталог профиля от root не удаляется по ssh-пользователем** — `Operation not permitted`
-   (внутренний `chromium/` создан root'ом внутри контейнера). Обход:
-   ```bash
-   docker run --rm -v /mnt/RED_2TB/docker/arr:/work alpine sh -c "rm -rf /work/flaresolverr-config"
-   ```
-3. **`docker rmi` конфликтует**, пока образ держит любой контейнер (`fs-debug` из отладки):
-   `conflict: unable to remove repository reference (must force) - container ... is using`.
-   Сначала `docker rm -f fs-debug`, потом `rmi`.
-4. **Имя каталога бэкапа рядом с оригиналом** → `Permission denied` (каталог root) — бэкап класть в `~`.
-   (Здесь не применялось: Alex запретил лишние бэкапы.)
-
-### Порядок отката, который сработал
+Функциональная приёмка — реальный search Prowlarr:
 
 ```bash
-# 1. Caddyfile — убрать блок vnc, залить, проверить, перезагрузить
-scp Caddyfile.clean truenas_admin@...:/mnt/RED_2TB/docker/caddy/Caddyfile
-docker exec caddy caddy validate --config /etc/caddy/Caddyfile   # → Valid configuration
-docker exec caddy caddy reload --config /etc/caddy/Caddyfile
-docker network disconnect media_net caddy
-# 2. compose — вернуть штатный образ, убрать порт 6080 и volume
-#    править ЛОКАЛЬНО → scp → docker compose config -q → up -d
-# 3. снести образ/каталог/контейнеры (см. питфоллы выше)
-# 4. ПРИЁМКА: логин + поиск (не caps!)
+curl -H "X-Api-Key: $PROWLARR_KEY" \
+  'http://127.0.0.1:9696/api/v1/search?query=radiohead&type=search&indexerIds=1'
 ```
 
-### ✅ Приёмка после отката (факты)
+`POST /api/v1/indexer/test` не использовать как единственное доказательство: при передаче объекта из API password может быть `********`, что даёт ложный `Auth Failed`.
 
-```
-API FS:                {"status":"ok","version":"3.5.2"}
-indexerstatus:         []   ← сразу после снятия карантина
-search:  idx1=50  idx2=33  idx4=47  idx5=EMPTY  idx6=0     ← НА МОМЕНТ ОТКАТА
-```
-⚠️ Через ~2 часа `idx1` упал в **0** — сессия `prowlarr` сломалась. `len=251792` тогда был принят
-за «залогиненный форум», но это **Chrome-страница ошибки**. См. «ДВЕ ЛОВУШКИ ДИАГНОСТИКИ».
+## Диагностика
 
-**Вывод сессии:** откат выполнен верно (FS на штатном образе, `PROXY_URL`, noVNC/капча-солвер
-снесены как ненужные). Но **логин RuTracker нестабилен**: сессия FS `prowlarr` периодически
-«отравляется» и переживает рестарт FS — лечится `sessions.destroy` + снятие карантина SQL.
-**Причина отравления не установлена** — открытый вопрос для следующей сессии.
+1. `docker compose ps` — контейнеры живы.
+2. `curl /health` — FlareSolverr отвечает.
+3. `sessions.list` — session существует.
+4. Проверить `bb_session` в `solution.cookies`.
+5. Проверить логи `vless-proxy` на `rutracker.org:443`.
+6. Выполнить одиночный реальный search, не `testall`.
 
----
+Параллельный `testall` перегружает один Chrome и создаёт ложные timeout. Challenge может занимать больше минуты, поэтому timeout 60 секунд недостаточен.
 
-# 🔴🔴 КОРЕНЬ НАЙДЕН (2026-09-29, поздняя сессия): DNS-запись `vpn.mallexxx.duckdns.org` указывает НА ДОМ
+## Перезапуск
 
-**Гипотеза «отравленная сессия FS» — СЛЕДСТВИЕ, а не причина.** Настоящая причина в том,
-что **VLESS-туннель не работает вообще**, потому что VPN-хост резолвится в домашний IP.
-
-## Доказательства (факты, не догадки)
-
-```
-vpn.mallexxx.duckdns.org @8.8.8.8   → 90.189.160.148   ❌ (домашний Ростелеком, Новосибирск)
-vpn.mallexxx.duckdns.org @1.1.1.1   → 90.189.160.148   ❌
-vpn.mallexxx.duckdns.org @локальный → 192.168.0.10     ❌ (роутер дома, DNS 192.168.2.2)
-```
-
-`90.189.160.148` = **внешний IP домашней сети Тайги** (Тайга сама `192.168.2.197`), Rostelecom
-AS12389. Проверка: `ip-api.com/line/90.189.160.148` → Russia / Novosibirsk / Rostelecom.
-
-**Куда уходит трафик при «рабочем» прокси:**
-```
-Chrome FS (PROXY_URL) → vless-proxy → dial vpn.mallexxx.duckdns.org:443 → 90.189.160.148 (ДОМ!)
-   → выход через тот же Ростелеком → api.ipify.org отдаёт 90.189.160.148
-```
-То есть прокси-цепочка формально проходит, но **выходной узел = домашний IP** ⇒ обхода
-блокировки НЕТ. Прокси не падает с ошибкой — он **молча не проксирует**.
-
-```
-docker logs vless-proxy:
-  accepted tcp:rutracker.org:443
-  tunneling request to tcp:rutracker.org:443 via vpn.mallexxx.duckdns.org:443
-  ... failed to transfer response payload > websocket: close 1000 (normal)   ← рвётся
-```
-
-## Как это выглядело в FS (ложный след)
-
-| Тест | Результат | Правда |
-|---|---|---|
-| `curl --socks5-hostname vless-proxy:1080 rutracker` из FS | `http=200, 1.16s` | шёл **напрямую**, DNS на хосте, не через туннель |
-| `curl --socks5-hostname ... api.ipify.org` из FS | **пусто** | VLESS-цепочка умирает на удалённом конце |
-| Chrome FS `api.ipify.org` | `90.189.160.148` | **домашний IP** → туннеля нет |
-| POST login RuTracker через FS | `len=254410, cookies=[]` | `ERR_TIMED_OUT` (не капча, не CF!) |
-
-🔴 **`ERR_TIMED_OUT` в Chrome-странице ошибки = «сайт не ответил», а НЕ «блок Cloudflare» и НЕ «капча»:**
 ```bash
-curl -s ... -d @/tmp/login.json | jq -r ".solution.response" \
-  | grep -oE "ERR_[A-Z_]+" | sort -u       # → ERR_TIMED_OUT
+ssh truenas_admin@mallexxx.duckdns.org \
+  'cd /mnt/RED_2TB/docker/arr && docker compose config -q && docker compose up -d --force-recreate flaresolverr'
 ```
-🔴 **Признак «прокси реально работает» = внешний IP ОТЛИЧАЕТСЯ от домашнего.** Проверять
-`api.ipify.org` через Chrome FS и сравнивать с `curl api.ipify.org` напрямую с хоста.
-Домашний IP, вернувшийся через «прокси», ДОКАЗЫВАЕТ, что прокси не проксирует.
 
-## ✅ Что сделано в этой сессии (факты)
+После restart session должна восстановиться автоматически. Если она не появилась, смотреть `docker logs flaresolverr`; credentials не выводить в лог.
 
-1. `sessions.list` → `[]`, лишние сессии убиты (`sessions.destroy`); FS чист.
-2. Бэкап БД: `/home/truenas_admin/prowlarr.db.bak-preclear-20260929` (618 496 B) — через `.backup`, не `cp`.
-3. Снят карантин: `docker stop prowlarr` → `DELETE FROM IndexerStatus;` → **0 записей**, `PRAGMA quick_check` → `ok` → `docker start prowlarr` (ping 200).
-4. Таблица `IndexerStatus` — колонка **`ProviderId`**, НЕ `IndexerId`. Записи были: id1 RuTracker Esc=1, id2 RuTor Esc=0, id4 NoNaMe Esc=1, id5/id6.
-5. Очистка карантина **не лечит**: без рабочего туннеля RuTracker снова даст 0 и снова уйдёт в карантин.
+## Восстановление quarantine
 
-## 🔴 ЧТО ЧИНИТЬ (уточнено Alex 2026-09-29: VPS НЕТ, есть прокси-КОНТЕЙНЕР)
+Если Prowlarr показывает старый `IndexerStatus`, сначала сделать backup SQLite. Остановить только Prowlarr, удалить только записи `IndexerStatus`, проверить `PRAGMA quick_check`, запустить и выполнить реальный search. Не удалять `prowlarr.db` и не считать health единственным тестом.
 
-⚠️ **Ошибочная версия (VPS + DuckDNS) отвергнута Alex.** Никакого VPS нет — есть контейнер
-`vless-proxy` на самой Тайге. Логи это подтверждают: контейнер **жив** (`Up 2 days`), туннель
-устанавливается (`tunneling request ... via vpn.mallexxx.duckdns.org:443`), SOCKS5-порты принимаются.
+## Итоговый рабочий результат
 
-🔴 **НАСТОЯЩИЙ ДЕФЕКТ: Chrome FlareSolverr стартует БЕЗ `--proxy-server=` — `PROXY_URL` к Chrome НЕ применяется.**
+На 2026-09-29 после полного рестарта Taiga:
 
-Доказательство — командная строка живого процесса Chrome в контейнере FS:
-```
-/usr/lib/chromium/chromium ... --headless=new --window-size=1920,1080 --start-maximized ...
-   ← флага --proxy-server= НЕТ ВООБЩЕ
-```
-И контрольный опыт: чистый Chrome-запрос через FS (`request.get api.ipify.org`) **не оставил
-ни одной записи** в логе `vless-proxy` (лог до теста = лог после теста, оба кончались на `00:10:17`).
-⇒ Chrome **не обращался к прокси**, ходил напрямую, вернул домашний `90.189.160.148`.
-
-При этом в коде FS прокси подставляется (проверено грепом `/app/flaresolverr.py`):
-```python
-16: env_proxy_url = os.environ.get('PROXY_URL', None)
-58: if (('proxy' not in data or not data.get('proxy')) and env_proxy_url is not None
-        and (env_proxy_username is None and env_proxy_password is None)):
-59:     logging.info('Using proxy URL ENV')
-60:     data['proxy'] = {"url": env_proxy_url}
-```
-🔴 **Ключ: env `PROXY_URL` подставляется ТОЛЬКО если в запросе нет своего поля `proxy`.**
-Значит либо Prowlarr присылает свой (пустой) `proxy`, либо Chrome при старте получает прокси
-не от env, а прокси должен передаваться **явным полем `proxy` в каждом запросе**.
-
-## 🔴 СЛЕДУЮЩИЙ ШАГ (одно действие, не сделано — сессия прервана)
-
-Для полного контейнера `vless-proxy` на Тайге:
-```bash
-# Тест: Chrome с ЯВНЫМ proxy в payload (обход условия «proxy not in data»)
-cat > /tmp/ipt.json <<'EOF'
-{"cmd":"request.get","url":"https://api.ipify.org","session":"iptestX",
- "proxy":{"url":"socks5://vless-proxy:1080"},"maxTimeout":80000}
-EOF
-curl -s --max-time 90 -X POST http://localhost:8191/v1 \
-  -H "Content-Type: application/json" -d @/tmp/ipt.json | jq -r ".solution.response" \
-  | grep -oE "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+"
-# ждём IP ≠ 90.189.160.148. Плюс сверить лог vless-proxy: появилась ли строка accepted tcp:api.ipify.org
-```
-- IP **отличается** от домашнего → прокси работает, дефект в способе передачи (`proxy` в payload);
-  фикс — прописать `proxy.url` в прокси-элементе Prowlarr / в запросах.
-- IP **тот же** → прокси не проксирует на уровне туннеля, копать `vless-proxy` (куда dial).
-
-⚠️ **Порядок диагностики «RuTracker = 0» ОБНОВЛЁН** (старый порядок — `sessions.list` первый — ведёт по ложному следу):
-
-⚠️ **Порядок диагностики «RuTracker = 0» ОБНОВЛЁН** (старый порядок из раздела выше —
-`sessions.list` первый — ведёт по ложному следу):
-
-| # | Проверка | Признак |
-|---|---|---|
-| **0** | `docker exec flaresolverr ps aux \| grep chromium` → есть ли `--proxy-server=` | **НЕТ флага → Chrome идёт мимо прокси, это и есть причина** |
-| 1 | IP через Chrome FS vs IP хоста напрямую | совпадают → прокси не проксирует |
-| 2 | след Chrome-запроса в `docker logs vless-proxy` | пусто → Chrome к прокси не обращался |
-| 3 | `ERR_[A-Z_]+` в Chrome-странице ошибки | `ERR_TIMED_OUT` ≠ капча ≠ CF |
-| 4 | `sessions.list` + `bb_session` в cookies | только после 0–3 |
-| 5 | `IndexerStatus` в БД | снимать SQL, тест ПРОДЛЕВАЕТ |
-
-> 🔴 **Урок:** «прокси настроен (`PROXY_URL` в env)» ≠ «прокси работает». Конфиг верный,
-> сеть `media_net` верная, FS живой — а трафика через туннель нет. Единственное доказательство
-> работы прокси — **внешний IP на выходе**.
+- FlareSolverr session `prowlarr` создаётся с proxy и pre-login.
+- Прямой запрос через session получает `bb_session`.
+- Реальный Prowlarr search RuTracker возвращает результаты.
+- Ошибки Lidarr/SkyHook не относятся к FlareSolverr; их routing описан в [[family/how-to/arr-stack-taiga]].