[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
This commit is contained in:
Alexey Martemyanov committed
1 parent
a3e7bddc09
commit
d8313b126f
6 files changed
+225
-2287
No files matched your search
Executable → Regular
+92
-535
@@ -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]].
|
||||
@@ -1,401 +0,0 @@
|
||||
---
|
||||
title: Prowlarr FlareSolverr — Cloudflare-обход и починка индексеров
|
||||
created: '2026-09-20'
|
||||
updated: '2026-09-29'
|
||||
type: tech
|
||||
namespace: personal
|
||||
tags: ["prowlarr", "flaresolverr", "cloudflare", "rutracker", "kinozal", "torrent", "arr", "kraken", "taiga", "infra"]
|
||||
related:
|
||||
- "[[family/how-to/arr-stack-kraken]]"
|
||||
- "[[personal/projects/media-pipeline-pitfalls]]"
|
||||
- "[[personal/plans/flaresolverr-taiga-deploy]]"
|
||||
- "[[family/projects/media-toolbox-taiga]]"
|
||||
---
|
||||
|
||||
# Prowlarr + FlareSolverr — обход Cloudflare
|
||||
|
||||
Зеркало ключевых питфоллов скилла `torrent-agent-pipeline` (§ Питфоллы).
|
||||
Контекст: 2026-09-20, Kraken. RuTracker / Kinozal / Kinozal (M) были «красными» в Prowlarr.
|
||||
|
||||
## 🔴🔴 2026-09-29: «Auth Failed» = СНАЧАЛА ДАННЫЕ, ПОТОМ ИНФРАСТРУКТУРА
|
||||
|
||||
**Самый дорогой урок.** Долгая диагностика «капча RuTracker», собран образ с noVNC — всё зря.
|
||||
Причина: **диагностические тесты шли НЕ ТЕМ аккаунтом.**
|
||||
|
||||
```
|
||||
Prowlarr хранит: username = mallexxx password = m@n*w$uperP@$$w0rD
|
||||
Тесты шли: username = keropjan_88 password = I70aj7Igpr
|
||||
```
|
||||
|
||||
RuTracker на неверный пароль отвечает **формой логина + капчей** — отсюда ложный вывод
|
||||
«трекер требует капчу от человека». С верной парой логин проходит **автоматически, без капчи**.
|
||||
|
||||
🔴 **ПЕРВЫЙ ШАГ при `Auth Failed` — сверить пару из БД, до любых гипотез:**
|
||||
```bash
|
||||
DB=/mnt/RED_2TB/docker/arr/prowlarr/prowlarr.db # Кра́кен: /srv/*/docker/prowlarr/config/prowlarr.db
|
||||
python3 -c "
|
||||
import json,sqlite3,shutil
|
||||
shutil.copy('$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()})
|
||||
"
|
||||
```
|
||||
Тестировать надо **ровно той парой**, что лежит в Prowlarr. Иначе тест измеряет не то.
|
||||
|
||||
### Признак «залогинен» — РАЗМЕР HTML, не подстрока
|
||||
|
||||
| `len` HTML | Что это |
|
||||
|---|---|
|
||||
| **~250 KB** | залогиненный форум ✅ |
|
||||
| **~13 KB** | форма логина вернулась ❌ |
|
||||
|
||||
⚠️ Подстрока `login_username` есть **в обоих** случаях (HTML-шаблон + скрытая форма быстрого
|
||||
входа) — по ней диагноз ставить НЕЛЬЗЯ.
|
||||
Кука авторизации RuTracker — **`bb_session`** (не `bb_data`; в сессии также `cf_clearance`,
|
||||
`bb_guid`, `bb_ssl`). Отсутствие `bb_session` = логина нет.
|
||||
|
||||
### Что НЕ работает (проверено, не повторять)
|
||||
|
||||
| Идея | Почему нет |
|
||||
|---|---|
|
||||
| Капча-солвер (`CAPTCHA_SOLVER`) | **Официально non-functional** (DeepWiki FS, issue #1452 закрыт). Адаптеры удалены из образа |
|
||||
| Вписать cookies в Prowlarr вручную | Индексер принимает только `username`/`password` — поля для cookie нет |
|
||||
| noVNC + свой образ FS для ручного входа | Строилось под ложную гипотезу. **Снесено 2026-09-29.** Журнал отката — [[personal/tech/flaresolverr-taiga]] |
|
||||
| Свой браузер через 3x-ui «по тому же туннелю» | `vless-proxy` — **клиент** xray, не сервер; `cf_clearance` привязан к IP+UA+TLS-fingerprint |
|
||||
| Persistent-профиль Chrome у FS | Не решает ничего: FS логинится сам при каждом старте |
|
||||
|
||||
> 🔴 **Не строить план на посылке «на Кра́кене работает».** На 2026-09-29 у Кра́кена в БД
|
||||
> тот же карантин `EscalationLevel=9` (RuTracker/Kinozal/Kinozal M, с 27 сен) и **нет** капча-солвера.
|
||||
|
||||
> 🔴 **Приёмка — `search`, а НЕ `caps` и НЕ `health`.** `caps` 200 + пустой `indexerstatus` +
|
||||
> `health []` не доказывают, что поиск работает. Разбивка по индексеру обязательна.
|
||||
|
||||
## Схема
|
||||
|
||||
```
|
||||
Prowlarr (Kraken:9696) → FlareSolverr (Kraken:8191) → Cloudflare-защищённый трекер
|
||||
⚠️ прокси применяется ТОЛЬКО при одинаковом tag на прокси И на индексере
|
||||
```
|
||||
|
||||
Все контейнеры — в общей внешней сети `media_net`: radarr, sonarr, prowlarr, transmission, flaresolverr.
|
||||
Проверять фактическую сеть, а не compose-файл:
|
||||
```bash
|
||||
ssh kraken 'sudo docker inspect -f "{{range $k,$v := .NetworkSettings.Networks}}{{$k}} {{end}}" radarr sonarr prowlarr transmission flaresolverr'
|
||||
```
|
||||
|
||||
## 🔴 Главная засада: прокси без tag молча не применяется
|
||||
|
||||
Созданный прокси (`POST /api/v1/indexerproxy`) с `tags: []` **не используется вообще** — в UI и логе Prowlarr об этом ни слова, запросы продолжают идти напрямую в Cloudflare. Прокси применяется к индексерам только когда у прокси И у каждого индексера стоит **один и тот же tag id**.
|
||||
|
||||
```bash
|
||||
KEY=$(grep -oP "(?<=<ApiKey>)[^<]+" /srv/.../docker/prowlarr/config/config.xml)
|
||||
|
||||
# 1. создать тег → получить id (обычно 1)
|
||||
curl -X POST -H "X-Api-Key: $KEY" -H "Content-Type: application/json" \
|
||||
-d '{"label":"flaresolverr"}' http://localhost:9696/prowlarr/api/v1/tag
|
||||
|
||||
# 2. повесить tag на ПРОКСИ: GET целиком → jq .tags=[1] → PUT
|
||||
curl -s -H "X-Api-Key: $KEY" http://localhost:9696/prowlarr/api/v1/indexerproxy/1 | jq ".tags=[1]" > /tmp/p.json
|
||||
curl -X PUT -H "X-Api-Key: $KEY" -H "Content-Type: application/json" -d @/tmp/p.json \
|
||||
http://localhost:9696/prowlarr/api/v1/indexerproxy/1
|
||||
|
||||
# 3. повесить ТОТ ЖЕ tag на индексера (RuTracker=1, Kinozal=5, Kinozal M=6)
|
||||
curl -s -H "X-Api-Key: $KEY" http://localhost:9696/prowlarr/api/v1/indexer/1 | jq ".tags=[1]" > /tmp/i.json
|
||||
curl -X PUT -H "X-Api-Key: $KEY" -H "Content-Type: application/json" -d @/tmp/i.json \
|
||||
http://localhost:9696/prowlarr/api/v1/indexer/1
|
||||
```
|
||||
|
||||
**Пруф работы — только лог FlareSolverr, не лог и не UI Prowlarr:**
|
||||
```bash
|
||||
ssh kraken 'sudo docker logs --tail 30 flaresolverr'
|
||||
# → Challenge detected. Title found: Just a moment...
|
||||
# → Challenge solved!
|
||||
```
|
||||
Непустой `GET /api/v1/indexerproxy` **не означает**, что прокси работает.
|
||||
Требуется Prowlarr ≥ 2.6 (в 2.5.2 прокси-модель только вводилась).
|
||||
|
||||
## 🔴 Блокировка индексера в SQLite — рестарт НЕ снимает
|
||||
|
||||
Prowlarr сам выключает упавший индексер на 24ч (`Temporarily ignoring indexer X till +24h`), состояние в таблице `IndexerStatus` в `prowlarr.db`. `docker restart prowlarr` его **не сбрасывает** — запрос продолжает отдавать `429 Indexer is disabled till ...`.
|
||||
|
||||
```bash
|
||||
# бэкап перед правкой БД
|
||||
cp /srv/.../docker/prowlarr/config/prowlarr.db <backup>/
|
||||
ssh kraken 'sudo docker stop prowlarr'
|
||||
sqlite3 /srv/.../docker/prowlarr/config/prowlarr.db "DELETE FROM IndexerStatus WHERE ProviderId IN (1,5,6);"
|
||||
ssh kraken 'sudo docker start prowlarr'
|
||||
```
|
||||
`ProviderId` = id индексера. **В контейнерах `sqlite3` НЕТ** — на хосте Kraken `/usr/bin/sqlite3` ЕСТЬ.
|
||||
|
||||
## ⚠️ Безопасность: FlareSolverr логирует пароли в plaintext
|
||||
|
||||
На `LOG_LEVEL=info` его лог печатает `postData` запроса, т.е. `login_username=...&login_password=...` **открытым текстом**. Ставить `LOG_LEVEL=warning` в compose.
|
||||
Проверка после понижения: `docker logs --since 5m flaresolverr | grep -c login_password` → `0`.
|
||||
|
||||
```yaml
|
||||
flaresolverr:
|
||||
image: ghcr.io/flaresolverr/flaresolverr:latest
|
||||
environment:
|
||||
- LOG_LEVEL=warning # ← не info: info пишет пароли трекеров
|
||||
- BROWSER_TIMEOUT=60000
|
||||
ports:
|
||||
- 8191:8191
|
||||
networks:
|
||||
- media_net
|
||||
```
|
||||
|
||||
## RuTor не фильтрует по категориям
|
||||
|
||||
В caps заявлены `2000(Movies)/5000(TV)/8000(Other)`, но с `cat=5000` отдаёт **0** результатов, без `cat` — 100. Prowlarr сам пишет в полях индексера: *«RuTor does not return categories in its search results. To sync to your apps, include 8000(Other)»*. В Sonarr/Radarr ставить категорию RuTor = `8000`, не `5000`.
|
||||
|
||||
## 429 в Sonarr/Radarr от упавшего индексера
|
||||
|
||||
`HTTP request failed: [429:TooManyRequests] [GET] at [http://prowlarr:9696/prowlarr/N/api?t=caps...]` — это **не** rate-limit трекера, а самоисключение Prowlarr. Не «ждать и повторять» — снимать `IndexerStatus`.
|
||||
|
||||
## Диагностические грабли
|
||||
|
||||
- **`POST /api/v3/indexer/test` с `{"indexerId": N}` не работает** (Radarr v6.1.1, Sonarr, Prowlarr v2.5.2) → HTTP 400 с `validationFailures` (`'Name' must not be empty`, … `'Priority' must be between 1 and 50`). Эндпоинт валидирует тело как **новый** индексер. Ответ — массив, поэтому `jq '.validationFailures'` падает с `Cannot index array with string`.
|
||||
Рабочая альтернатива — `testall`:
|
||||
```bash
|
||||
curl -s -X POST -H "X-Api-Key: $KEY" "http://localhost:7878/radarr/api/v3/indexer/testall" \
|
||||
| jq -r '.[] | "\(.id)\t\(.isValid)\t\(.validationFailures[0].errorMessage // "")"'
|
||||
# Sonarr: порт 8989, UrlBase /sonarr
|
||||
```
|
||||
- **Prowlarr маскирует упавшие индексеры** — `GET /api/v1/health` и `/api/v1/indexerstatus` могут быть **пустыми**, пока индексер красный. Диагноз снимать из лога `<config>/logs/prowlarr.debug.txt` (НЕ `logs/prowlarr.txt`). Искать: `grep -iE "rutracker|kinozal|Cloudflare|429"`.
|
||||
- **«Кто живой» быстрее всего — поиском**, не caps-тестом:
|
||||
```bash
|
||||
curl -s -H "X-Api-Key: $KEY" "http://localhost:9696/prowlarr/api/v1/search?query=matrix&type=search" \
|
||||
| jq -r 'group_by(.indexer)[] | "\(.[0].indexer): \(length)"'
|
||||
```
|
||||
По умолчанию до 100 результатов на индексер — «156 всего» ≠ «по 26 на каждый».
|
||||
|
||||
## 🔴 2026-09-24: FlareSolverr в crash-loop — Chrome не поднимается под chromedriver
|
||||
|
||||
**Повод:** Alex — «Мастерская сатаны: в торрентах ничего не нашлось, по каким трекерам
|
||||
ищет и можно ли влиять через Prowlarr?» Симптом оказался двухслойным: сверху пустая
|
||||
выдача PidTor, под ней — мёртвый FlareSolverr.
|
||||
|
||||
### Слой 1 (верхний): PidTor отдаёт 503 из кэша, jac.red — 0 результатов
|
||||
|
||||
```
|
||||
GET /lite/pidtor?title=Мастерская сатаны&year=2025
|
||||
→ HTTP 503, Content-Length: 0, X-Invoke-Cache: HIT, t=0.007s ← кэш
|
||||
|
||||
GET http://jac.red/api/v2.0/indexers/all/results?title=Мастерская сатаны&year=2025
|
||||
→ HTTP 200, {"Results":[],"jacred":true} ← ЧЕСТНЫЙ ноль
|
||||
GET …/results?title=Матрица&year=1999
|
||||
→ HTTP 200, 132 раздачи ← контроль: живой
|
||||
```
|
||||
|
||||
**jac.red знает 25 индексеров:** `anibelka anidub anifilm aniliberty animelayer anistar
|
||||
baibako bitru kinozal korsars leproduction lostfilm mazepa megapeer nnmclub rudub rutor
|
||||
rutracker selezen subsplease toloka torrentby ultradox viruseproject`.
|
||||
|
||||
🔴 **Список индексеров jac.red:** `GET http://jac.red/api/v2.0/indexers?configured=true`
|
||||
→ 200, ~4 КБ, массив с `name`. Рабочий способ посмотреть, по каким трекерам реально
|
||||
идёт поиск — не догадываться.
|
||||
|
||||
🔴 **jac.red отдаёт 429 при частых запросах** (nginx): пауза `sleep 2-3` между вызовами
|
||||
обязательна. Формулировка ответа: nginx-страница `429 Too Many Requests`, НЕ JSON.
|
||||
|
||||
🔴 **`title=` должен быть URL-кодирован целиком.** `%20` в значении даёт **HTTP 400** —
|
||||
использовать `curl -G --data-urlencode "title=Мастерская сатаны"`. Ручная сборка
|
||||
query-строки с `%20` в середине ломается.
|
||||
|
||||
**Вывод по «Мастерская сатаны»:** у фильма реально нет раздач на 25 трекерах jac.red.
|
||||
Механизм PidTor исправен (контроль на «Матрице» — 132 раздачи). Диагноз «сломан поиск»
|
||||
был бы неверным.
|
||||
|
||||
⚠️ Одноимённый фильм 2022 года лежит там как **«Мастерская дьявола / Devil's Workshop»**
|
||||
(`Devils Workshop` → 2 раздачи, bitru + kinozal, sid 0-1). Латиница в выдаче — не тот
|
||||
фильм, следить за годом.
|
||||
|
||||
### Слой 2 (первопричина): FlareSolverr crash-loop ⇒ 3 индексера Prowlarr мертвы
|
||||
|
||||
```
|
||||
RuTracker (id=1) disabledTill = 2026-09-25T10:17:51Z
|
||||
Kinozal (id=5) disabledTill = 2026-09-25T10:17:50Z
|
||||
Kinozal (M) (id=6) disabledTill = 2026-09-25T10:17:48Z
|
||||
EscalationLevel = 9 (максимум — блокировка на 24 ч)
|
||||
```
|
||||
|
||||
Проверка: `GET /prowlarr/1/api?t=search&q=…` → `429 Indexer is disabled till …`.
|
||||
Прямой результат несмотря на то, что таблица `IndexerStatus` начиналась 20-го (начальные
|
||||
падения) и докатилась до `EscalationLevel=9` именно **24-го в 10:17**.
|
||||
|
||||
**В логе FlareSolverr:**
|
||||
|
||||
```
|
||||
Error starting Chrome: Message: session not created: cannot connect to chrome at
|
||||
127.0.0.1:48249 from chrome not reachable
|
||||
Exception: Error getting browser User-Agent. …
|
||||
File "/app/flaresolverr.py", line 136, in <module>
|
||||
flaresolverr_service.test_browser_installation()
|
||||
```
|
||||
|
||||
Контейнер `flaresolverr` уходит в **crash-loop** (`Restarting (1)`), HTTP `:8191` не
|
||||
отвечает (`Connection reset by peer`). Успешных решений челленджа в логе (`Challenge
|
||||
solved`) нет — считать их число: `sudo docker logs flaresolverr 2>&1 | grep -c "Challenge solved"`.
|
||||
|
||||
### Что проверено и исключено (не тратить время повторно)
|
||||
|
||||
| Гипотеза | Проверка | Итог |
|
||||
|---|---|---|
|
||||
| Образ обновлён watchtower'ом и сломан | `image inspect` → v3.5.2, `Created=2026-09-12`; в логах watchtower нет строк про flaresolverr | ❌ не при чём |
|
||||
| Нехватка RAM | `free`, суммарный RSS всех процессов = 1.9 GB при MemAvailable ~1.8 GB | ⚠️ фон, не корень |
|
||||
| **swap мёртв** | `/proc/swaps` **пуст** при живом `/var/swap` (512 MB); `SwapFree` падал до 240 kB | ✅ **реальный баг хоста**, починен |
|
||||
| IPv6: `/etc/hosts` отдаёт `::1 localhost` первым, Chrome на IPv6-петле | в контейнере `/etc/hosts` → `::1 localhost` первый; **добавлен `net.ipv6.conf.all.disable_ipv6=1`** (как у prowlarr) → `disable_ipv6=1`, hosts стал `127.0.0.1 localhost` | ❌ **НЕ помогло**, ошибка дословно та же |
|
||||
| `/dev/shm` мал (64 MB) | `docker inspect` → `ShmSize=67108864`; в контейнере `df -h /dev/shm` → 64M | ⚠️ **подозреваемый №1 из оставшихся** |
|
||||
|
||||
🔴 **Chrome запускается вручную, но не под chromedriver.** Проверено:
|
||||
`docker exec flaresolverr sh -c '/usr/lib/chromium/chromium --headless=new --no-sandbox
|
||||
--disable-dev-shm-usage --disable-gpu --dump-dom about:blank'` → работает, отдаёт
|
||||
verbose-лог компонентов; под управлением selenium — `cannot connect to chrome at 127.0.0.1:<port>`.
|
||||
В образе **`chromedriver` не в PATH** (`which chromedriver` → not found) — selenium ≥ 4
|
||||
использует собственный Selenium Manager.
|
||||
|
||||
🔴 **Вывод не делать по одной гипотезе.** IPv6 выглядел убедительно (симптом
|
||||
«не видит chrome на 127.0.0.1» идеально ложится), но после применения ошибка
|
||||
воспроизвелась дословно — то есть причина не в резолве адреса.
|
||||
|
||||
### ✅ Починено в этой сессии
|
||||
|
||||
**1. swap был мёртв — восстановлен.** `/proc/swaps` пуст, а `/var/swap` (512 MB) на диске
|
||||
есть, ядро держало `SwapFree=256 kB` при нулевом активном swap. Без swap Chrome не
|
||||
получает память при пике старта.
|
||||
|
||||
```bash
|
||||
sudo swapon /var/swap # → /proc/swaps: /var/swap file 524272 -2
|
||||
cat /proc/swaps # проверка
|
||||
grep -E "^(SwapTotal|SwapFree)" /proc/meminfo
|
||||
```
|
||||
|
||||
⚠️ **`swapoff -a && swapon -a` НЕ восстанавливает** — даёт `SwapFree: 0 kB`. Помогает
|
||||
только явный `sudo swapon /var/swap`. В `/etc/fstab` строки для swap НЕТ
|
||||
(комментарий `dphys-swapfile`), systemd swap-unit не поднят (`systemctl list-units
|
||||
--type=swap --all` → 0 units). Автоподъём swap на этом хосте **не настроен** — после
|
||||
ребута swap снова может пропасть.
|
||||
|
||||
**2. `disable_ipv6` добавлен сервису `flaresolverr`** (в `docker/prowlarr/docker-compose.yml`,
|
||||
бэкап `docker-compose.yml.bak-20260924-193632`). **Эффекта не дало** — оставлено как
|
||||
проверенная-неудачная попытка; при откате вернуть файл из бэкапа.
|
||||
|
||||
```yaml
|
||||
flaresolverr:
|
||||
image: ghcr.io/flaresolverr/flaresolverr:latest
|
||||
environment:
|
||||
- LOG_LEVEL=warning # ← не info: info пишет пароли трекеров
|
||||
- BROWSER_TIMEOUT=60000
|
||||
ports:
|
||||
- 8191:8191
|
||||
networks:
|
||||
- media_net
|
||||
sysctls:
|
||||
- net.ipv6.conf.all.disable_ipv6=1 # 2026-09-24: не помогло, см. выше
|
||||
shm_size: 1gb # ⏳ НЕ ПРИМЕНЕНО — кандидат на фикс
|
||||
```
|
||||
|
||||
⏳ **Незавершённое:** добавить `shm_size: 1gb` и пересоздать
|
||||
(`docker compose up -d --force-recreate flaresolverr`), затем снять блокировки
|
||||
`IndexerStatus` для id 1/5/6 (см. секцию выше) и проверить
|
||||
`POST http://localhost:8191/v1 {"cmd":"request.get","url":"https://kinozal.me/browse.php?c=0"}`
|
||||
→ ожидается `status: ok`. После этого — поиск «Мастерская сатаны» по всем 6 трекерам.
|
||||
|
||||
### Дополнительные питфоллы сессии
|
||||
|
||||
1. 🔴 **`escape` из контейнера в crash-loop:** `docker exec` отдаёт
|
||||
`OCI runtime exec failed: exec failed: unable to start container process` /
|
||||
`cannot exec in a stopped container`. Это признак рестарт-петли, а не «неверный exec» —
|
||||
сначала `docker ps -a --filter name=<c> --format "{{.Status}} R={{.RestartCount}}"`.
|
||||
2. 🔴 **`sudo docker stats` показывает `0B / 0B` у всех контейнеров.** Метрика врёт
|
||||
(недоступна на этом хосте) — считать память по контейнерам через
|
||||
`/sys/fs/cgroup/system.slice/docker-<id>.scope/memory.current`, а по процессам — `ps -eo rss`.
|
||||
3. 🔴 **`ps aux --sort=-rss | awk` с `%4`/`$6` даёт мусор** — формат `ps aux` на этом
|
||||
хосте отдаёт 11 полей, `%MEM` и RSS нужно читать через `ps -eo user,pid,rss,comm,args`.
|
||||
4. 🔴 **Долгие ssh-команды в crash-loop контейнера вешают терминал на 400+ с** — резать
|
||||
диагностику на короткие скрипты и не ждать готовности контейнера дольше 240 с.
|
||||
5. ⚠️ **`sudo` на Кра́кене требует TTY** — `ssh -t kraken '…'`. Без `-t`:
|
||||
`sudo: a password is required`.
|
||||
|
||||
## Применение на Тайге (2026-09-28) — ключевое отличие от Кра́кена
|
||||
|
||||
Тот же FlareSolverr ставится на Тайгу, но схема **не копия один-в-один**:
|
||||
[[personal/plans/flaresolverr-taiga-deploy]].
|
||||
|
||||
🔴 **На Тайге есть DNS-блок провайдера** (NXDOMAIN на rutracker.org / rutor.info /
|
||||
kinozal.tv / nnmclub.to даже с 8.8.8.8), которого на Кра́кене НЕТ. Поэтому:
|
||||
|
||||
- На Кра́кене FlareSolverr лезет в трекер **напрямую** — и упирается только в Cloudflare.
|
||||
- На Тайге так нельзя: **FS сам получит NXDOMAIN**. Прокси-маршрут уже есть
|
||||
(`vless-proxy` в `media_net`, SOCKS5 `vless-proxy:1080`; `rutracker.org` → 301 через него),
|
||||
но **прокси-элемент `vless-socks5` в Prowlarr FS НЕ покрывает** — он применяется к запросам
|
||||
*самого Prowlarr*. Нужно, чтобы **Chrome внутри FS тоже ходил через `vless-proxy`**
|
||||
(env `HTTP_PROXY`/`HTTPS_PROXY` образа либо `proxy` в теле `request.get`).
|
||||
⏳ Схему проверить до деплоя.
|
||||
|
||||
🔴 **Оба грабля-условия воспроизведены на Тайге** (там Chrome тоже упадёт):
|
||||
|
||||
| Условие | Факт на Тайге 2026-09-28 |
|
||||
|---|---|
|
||||
| `/dev/shm` | **64 MB** (`ShmSize=67108864`) → задать `shm_size: 1gb` |
|
||||
| swap | **`/proc/swaps` ПУСТ, `Swap: 0`** → Chrome не получит память на пике старта |
|
||||
| RAM | 21 GB total / 5.6 GB available — ✅ хватает |
|
||||
| IPv6 | проверить; на Кра́кене `disable_ipv6=1` не помог, но безвреден |
|
||||
|
||||
⚠️ **Наблюдение (Тайга):** `curl` через SOCKS5 к `kinozal.tv` → `000`, к `kinozal.me` → `200`.
|
||||
То есть `.tv` мёртв как домен, а не «заблокирован». Урок общий: **`000` = домен/соединение,
|
||||
`403`/`Just a moment` = Cloudflare** — не смешивать диагнозы.
|
||||
|
||||
## Источники
|
||||
|
||||
- Скилл: `torrent-agent-pipeline` (§ Питфоллы), `lampac-kraken-deploy`
|
||||
- Живой разбор: [[family/how-to/arr-stack-kraken]] — секции про починку индексера 2026-09-20
|
||||
- Слой PidTor/кэш: [[personal/tech/lampac-torrserver]] §«2026-09-24»
|
||||
- Каталог/конфиг lampac: [[personal/tech/lampac-deployment]]
|
||||
|
||||
## 🔵 2026-09-28: перенос схемы на Тайгу — FlareSolverr ЗА DNS-блоком
|
||||
|
||||
Развёрнут FlareSolverr на **Тайге** ([[personal/plans/flaresolverr-taiga-deploy]]) — там
|
||||
к Cloudflare добавляется **DNS-фильтр провайдера** (NXDOMAIN на трекеры). Это меняет схему:
|
||||
|
||||
```
|
||||
Kraken: Prowlarr → FlareSolverr → трекер (DNS-блока нет, прямой выход)
|
||||
Taiga: Prowlarr → FlareSolverr → vless-proxy → трекер (FS сам должен ходить через прокси)
|
||||
```
|
||||
|
||||
🔑 **Ключевая деталь, которой нет в схеме Кра́кена:** FlareSolverr сам должен ходить через
|
||||
прокси, иначе получит NXDOMAIN и не поможет вообще. Задаётся **глобальной env `PROXY_URL`**
|
||||
(НЕ `HTTPS_PROXY`/`HTTP_PROXY` — их FS не читает):
|
||||
|
||||
```yaml
|
||||
flaresolverr:
|
||||
environment:
|
||||
- PROXY_URL=socks5://vless-proxy:1080 # ← схема обязательна; socks5h не нужен, FS резолвит сам
|
||||
- LOG_LEVEL=warning
|
||||
shm_size: 1gb
|
||||
```
|
||||
|
||||
Приоритет прокси у FS: `request` > `session` > `global`. Prowlarr зовёт FS с `session` →
|
||||
request-прокси игнорируется, срабатывает именно global. Передать прокси из Prowlarr нельзя
|
||||
(у Socks5-элемента только host/port/user/pass).
|
||||
|
||||
### Дополнительные питфоллы, найденные на Тайге
|
||||
|
||||
1. 🔴 **`requestTimeout` у FS-прокси в Prowlarr по умолчанию 60 с — МАЛО.** CF-челлендж на
|
||||
`/forum/login.php` не укладывается → `Error solving the challenge. Timeout after 60.0 seconds`.
|
||||
**Ставить 120.** Правка: PUT `/api/v1/indexerproxy/2` с `fields[requestTimeout].value=120`.
|
||||
2. 🔴 **`PUT /api/v1/indexer/N` возвращает 400, если тест FS в этот момент не прошёл** — Prowlarr
|
||||
валидирует сразу при сохранении. Тело: `Unable to connect to indexer ... [500:InternalServerError]
|
||||
[POST] at [http://flaresolverr:8191/v1]`. **Теги при этом НЕ применяются.** Обход —
|
||||
**`?forceSave=true`** → 202. Иначе будет казаться, что тег «не навешивается».
|
||||
3. 🔴 **`POST /api/v1/indexer/testall` идёт ПАРАЛЛЕЛЬНО, а Chrome в FS один** → часть челленджей
|
||||
отваливается, индексер показывает ложный `blocked by CloudFlare Protection`. **Проверять
|
||||
одиночным `request.get` с `maxTimeout=120000`**, а не верить `testall`.
|
||||
4. ⚠️ **Индексеру могут понадобиться ДВА тега** — `proxy` (DNS-обход) **и** `flaresolverr`
|
||||
(CF-челлендж). Один прокси не решает оба блока. На Кра́кене достаточно одного (только CF).
|
||||
5. ⚠️ **Ключ API в файл + `-H @/tmp/h.txt`** внутри контейнера. Прямая передача `-H "X-Api-Key: $K"`
|
||||
через вложенный `ssh`+`sh -c` ломается на кавычках → **401** при верном ключе.
|
||||
6. ⚠️ `python3` в контейнере Prowlarr **нет** — JSON разбирать на хосте. Долгие вызовы —
|
||||
`docker exec -d` в фон + файл-маркер `.done`.
|
||||
Reference in new issue
Block a user