0 Fork 0

Files

T

Alexey Martemyanov ec9a9eabf9 [2026-09-28] eagle: family/index.md family/plans/lidarr-artist-watchlist.md family/plans/lidarr-taiga-deploy.md personal/tech/flaresolverr-taiga.md

2026-09-28 23:31:48 +06:00

38 KiB

Executable File

Raw Blame History

FlareSolverr на Тайге + обход блокировок индексеров

🔴 НОВОЕ 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. 🔴 GET /api/v1/health при этом отдаёт [] — health-кэш врёт. Ориентироваться на логи. 🔴 Внешний IP дома = 90.189.160.148 И у хоста Тайги тоже (curl api.ipify.org с хоста) — вся сеть 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:
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 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 пересоздаёт сессию чистой при следующем запросе.

🔴 ПРИЧИНА ВСЕХ ПРОБЛЕМ: путаница аккаунтов (не капча, не прокси, не CF)

Долгая диагностика упиралась в «капчу RuTracker» — причины такой не было.

Prowlarr:  username = mallexxx       password = m@n*w$uperP@$$w0rD
Мой тест:  username = keropjan_88    password = I70aj7Igpr          ← ЛЕВЫЙ аккаунт

RuTracker на неверный пароль отвечает формой логина + капчей. Отсюда ложный вывод «капча блокирует». С правильными данными Prowlarr логинится без капчи.

🔴 Прежде чем диагностировать капчу/CF/прокси — сверить пару логин/пароль в Prowlarr:

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"}

Фикс: удалить сессию — Prowlarr пересоздаст её сам уже с прокси.

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 проблемы не создаёт: сессия создастся заново с прокси.

🔑 Имя переменной — `PROXY_URL` (не `HTTP_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

Почему FS обязан ходить через прокси: на Тайге блоков два — DNS провайдера + Cloudflare. Без прокси FS сам получает NXDOMAIN и не помогает. На Кра́кене DNS-блока нет, поэтому там PROXY_URL не нужен.

🔴 `IndexerStatus` снимается ТОЛЬКО через SQL — тест его ПРОДЛЕВАЕТ

POST /indexer/test карантин не снимает, а эскалирует: наблюдалось DisabledTill 15:44 → 21:45 после одного теста. Пока запись есть, caps отдаёт 429, и warning каскадом идёт во все arr.

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 [] не доказывают, что поиск работает.

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.

# Правильная проверка логина — по 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-сервис

  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)

🔴 ЧЕКЛИСТ «не всё зелёное» (восстановление RuTracker)

Когда RuTracker даёт 0, а FS жив — выполнить в этом порядке:

# 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

⚠️ Переживёт ли reboot: IndexerStatus и сломанная сессия переживают — без шагов 1–2 после перезагрузки RuTracker останется в 0. Сессия живёт в памяти FS и выдерживает docker restart flaresolverr.

🔴 Чего НЕ делать (проверено, не работает)

Идея	Почему нет
Капча-солвер (`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 логинится сам

🔴 Не строить план на посылке «на Кра́кене работает». На 2026-09-29 у Кра́кена в БД тот же карантин EscalationLevel=9 (RuTracker/Kinozal/Kinozal M, с 27 сен) и нет капча-солвера. «Как на Кра́кене» ≠ «починить».

📋 ЖУРНАЛ ОТКАТА (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/`	удалён

⚠️ ПИТФОЛЛЫ отката (стоили времени)

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.
Каталог профиля от root не удаляется по ssh-пользователем — Operation not permitted (внутренний chromium/ создан root'ом внутри контейнера). Обход:
```
docker run --rm -v /mnt/RED_2TB/docker/arr:/work alpine sh -c "rm -rf /work/flaresolverr-config"
```
docker rmi конфликтует, пока образ держит любой контейнер (fs-debug из отладки): conflict: unable to remove repository reference (must force) - container ... is using. Сначала docker rm -f fs-debug, потом rmi.
Имя каталога бэкапа рядом с оригиналом → Permission denied (каталог root) — бэкап класть в ~. (Здесь не применялось: Alex запретил лишние бэкапы.)

Порядок отката, который сработал

# 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!)

✅ Приёмка после отката (факты)

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. Причина отравления не установлена — открытый вопрос для следующей сессии.

🔴🔴 КОРЕНЬ НАЙДЕН (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» и НЕ «капча»:

curl -s ... -d @/tmp/login.json | jq -r ".solution.response" \
  | grep -oE "ERR_[A-Z_]+" | sort -u       # → ERR_TIMED_OUT

🔴 Признак «прокси реально работает» = внешний IP ОТЛИЧАЕТСЯ от домашнего. Проверять api.ipify.org через Chrome FS и сравнивать с curl api.ipify.org напрямую с хоста. Домашний IP, вернувшийся через «прокси», ДОКАЗЫВАЕТ, что прокси не проксирует.

✅ Что сделано в этой сессии (факты)

sessions.list → [], лишние сессии убиты (sessions.destroy); FS чист.
Бэкап БД: /home/truenas_admin/prowlarr.db.bak-preclear-20260929 (618 496 B) — через .backup, не cp.
Снят карантин: docker stop prowlarr → DELETE FROM IndexerStatus; → 0 записей, PRAGMA quick_check → ok → docker start prowlarr (ping 200).
Таблица IndexerStatus — колонка ProviderId, НЕ IndexerId. Записи были: id1 RuTracker Esc=1, id2 RuTor Esc=0, id4 NoNaMe Esc=1, id5/id6.
Очистка карантина не лечит: без рабочего туннеля RuTracker снова даст 0 и снова уйдёт в карантин.

🔴 ЧТО ЧИНИТЬ (уточнено Alex 2026-09-29: VPS НЕТ, есть прокси-КОНТЕЙНЕР)

⚠️ Ошибочная версия (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 НЕ применяется.

Доказательство — командная строка живого процесса 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):

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 на Тайге:

# Тест: 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 на выходе.

38 KiB Executable File Raw Blame History Unescape Escape