[2026-09-28] eagle: family/projects/media-toolbox-taiga.md personal/plans/flaresolverr-taiga-deploy.md personal/tech/flaresolverr-taiga.md
This commit is contained in:
Alexey Martemyanov committed
1 parent
6dfedbc142
commit
0ac3efb2f5
3 files changed
+254
-260
No files matched your search
@@ -20,15 +20,6 @@ status: deployed
|
||||
---
|
||||
# *arr Stack на Тайге — Setup & Config
|
||||
|
||||
> 🔴 **STATE 2026-09-28 (вечер): FlareSolverr — ПЛАН СОСТАВЛЕН, ждёт «go». НЕ УСТАНОВЛЕН.**
|
||||
> Разведка подтвердила: **DNS-блокер УЖЕ ЗАКРЫТ** (прокси-маршрут настроен 2026-09-26,
|
||||
> `vless-proxy` → 301/200 на трекеры, поиск RuTor 100 + Byrutor 6). Остаточная проблема —
|
||||
> **Cloudflare JS-челлендж** на RuTracker / Kinozal / Kinozal (M); `IndexerStatus` карантин
|
||||
> id 1/5/6. Решение — FlareSolverr. Compose `arr` **не менялся**.
|
||||
> 🔴 Ключевое отличие от Кра́кена: у Тайги есть DNS-блок → **FlareSolverr сам должен ходить
|
||||
> через `vless-proxy`**. Плюс два риска CrashChrome: `ShmSize=64MB` и **`Swap=0`** (`/proc/swaps` пуст).
|
||||
> План, команды и открытые вопросы — [[personal/plans/flaresolverr-taiga-deploy]].
|
||||
|
||||
> ✅ **STATE 2026-09-28: LIDARR РАЗВЁРНУТ — 7-й сервис стека, music-менеджер.**
|
||||
> Live: **`https://lidarr.mallexxx.duckdns.org`** → HTTP 200, TLS Let's Encrypt, **health ЧИСТЫЙ**.
|
||||
> Контейнер `lidarr` **v3.1.0.4875-ls42**, порт 8686, uid 950, `media_net` + `caddy_default`.
|
||||
@@ -38,12 +29,26 @@ status: deployed
|
||||
> Prowlarr: Application `Lidarr` id=3 `fullSync`, `syncCategories=[3000…3060]`.
|
||||
> ⏳ **Приёмка НЕ закрыта:** `api.lidarr.audio` (метаданные SkyHook) → **403 Cloudflare**
|
||||
> прямым запросом, через `vless-proxy` → **200**. Заготовка `/tmp/add_proxy_env.py` (HTTP_PROXY/
|
||||
> HTTPS_PROXY + NO_PROXY) — НЕ применена.
|
||||
> HTTPS_PROXY + NO_PROXY) — НЕ применена. ⚠️ FlareSolverr тут НЕ помогает: Lidarr ходит
|
||||
> в SkyHook сам, не через FS → нужен именно `HTTP(S)_PROXY`-подход.
|
||||
> 🔴 **Индексеры для музыки (проверено 2026-09-28):** аудио отдают только **RuTracker(1)**,
|
||||
> **NoNaMe(4)**, **Kinozal(5,6)**. **RuTor и Byrutor — `music-search available="no"`, музыки НЕТ.**
|
||||
> ✅ Все 4 аудио-индексера разблокированы 2026-09-28 (FlareSolverr) — [[personal/tech/flaresolverr-taiga]].
|
||||
> В Lidarr проброшен `NoNaMe Club (Prowlarr)`. Полный разбор, 7 питфоллов и креды Transmission —
|
||||
> [[family/plans/lidarr-taiga-deploy]] §ФАКТИЧЕСКОЕ СОСТОЯНИЕ.
|
||||
|
||||
> ✅ **STATE 2026-09-28 (вечер): ИНДЕКСЕРЫ 6/6 РАБОЧИЕ — FlareSolverr развёрнут.**
|
||||
> Все блокеры сняты. Было 3/6, стало 6/6, `health` и `indexerstatus` → `[]` (пусто).
|
||||
> Поиск «matrix» → **256 результатов** (RuTor 100, RuTracker 50, NoNaMe 50, Kinozal 50, Byrutor 6).
|
||||
> **RuTracker впервые `valid` за всё время стека (с 2026-05-20).** Карантины id 1/5/6 сняты.
|
||||
> Схема: два прокси-элемента в Prowlarr — `vless-socks5` (DNS-блок) + `flaresolverr` (Cloudflare),
|
||||
> теги `[1,2]` на CF-индексеры. FlareSolverr сам ходит через `vless-proxy` (`PROXY_URL`).
|
||||
> Контейнер `flaresolverr` в `arr/docker-compose.yml`, `8191`, `shm_size: 1gb`, `LOG_LEVEL=warning`.
|
||||
> 🔴 Главный питфолл: FS-сессия `prowlarr`, созданная ДО появления `PROXY_URL`, навсегда
|
||||
> остаётся без прокси → `ERR_NAME_NOT_RESOLVED` → ложное «blocked by CloudFlare».
|
||||
> Лечится `sessions.destroy`. Swap НЕ нужен (RAM 21 GB) — Alex отклонил.
|
||||
> Полный разбор, все питфоллы и команды — [[personal/tech/flaresolverr-taiga]].
|
||||
|
||||
> 🔴 **ПИТФОЛЛ 2026-09-28: `429 TooManyRequests` от Prowlarr ≠ rate limit.** Это **карантин**
|
||||
> (`disabledTill`) — Prowlarr отдаёт 429 на ЛЮБОЙ запрос к индексеру, пока тот в карантине.
|
||||
> Лечится `POST /api/v1/indexer/testall` (сбрасывает `disabledTill`), **не ожиданием**.
|
||||
|
||||
@@ -1,14 +1,17 @@
|
||||
# FlareSolverr на Тайге + обход блокировок индексеров — план
|
||||
# FlareSolverr на Тайге + обход блокировок индексеров — план/отчёт
|
||||
|
||||
> **Статус: ✅ РАЗВЁРНУТ 2026-09-28. Приёмка Alex НЕ закрыта (ждёт проверки в UI).**
|
||||
> Задача Alex: «Ставь flaresolverr как на Кра́кене, запускай трекеры через прокси контейнер
|
||||
> чтобы обойти блокировки». Связано: [[personal/plans/lidarr-taiga-and-indexer-unblock]],
|
||||
> **Статус: ✅ ВЫПОЛНЕНО 2026-09-28. Итог 6/6 индексеров, `health` → `[]` (пусто).**
|
||||
> Поиск «matrix» → **256 результатов** (RuTor 100, RuTracker 50, NoNaMe 50, Kinozal 50, Byrutor 6).
|
||||
> **RuTracker впервые `valid` за всё время стека (с 2026-05-20).**
|
||||
> Полный разбор, все питфоллы и команды — [[personal/tech/flaresolverr-taiga]].
|
||||
> Связано: [[personal/plans/lidarr-taiga-and-indexer-unblock]],
|
||||
> [[family/projects/media-toolbox-taiga]], [[family/how-to/arr-stack-kraken]],
|
||||
> [[personal/tech/prowlarr-flaresolverr-cloudflare]].
|
||||
>
|
||||
> **Итог:** `flaresolverr` поднят, обходит и DNS-блок, и Cloudflare. Тест индексеров:
|
||||
> RuTracker ✅ RuTor ✅ Byrutor ✅ Kinozal(M) ✅ | NoNaMe ❌ (нет FS-тега) Kinozal ❌ (гонка).
|
||||
> Оба дефекта закрываемые, см. §«Осталось».
|
||||
> 🔴 **Главный питфолл:** FS-сессия `prowlarr`, созданная ДО появления `PROXY_URL`,
|
||||
> навсегда остаётся без прокси → `ERR_NAME_NOT_RESOLVED` → Prowlarr пишет ложное
|
||||
> «blocked by CloudFlare» (симптом маскируется под таймаут CF). Лечится
|
||||
> `sessions.destroy` + `session:"prowlarr"`; пересоздаётся сама.
|
||||
|
||||
## ФАКТИЧЕСКОЕ СОСТОЯНИЕ (2026-09-28, после деплоя)
|
||||
|
||||
@@ -35,11 +38,13 @@
|
||||
- net.ipv6.conf.all.disable_ipv6=1
|
||||
```
|
||||
|
||||
Поднят: `cd /mnt/RED_2TB/docker/arr && docker compose up -d flaresolverr` → `Up`, рестартов 0,
|
||||
логи пусты (при `LLOG_LEVEL=warning` это норма — пароли не пишутся).
|
||||
**Swap НЕ трогали** — Хватает RAM (21 GB total). Alex отклонил идею swap: «Памяти мало что-ли?».
|
||||
Поднят: `cd /mnt/RED_2TB/docker/arr && docker compose up -d flaresolverr` → `Up`, рестартов 0.
|
||||
Логи пусты при `LOG_LEVEL=warning` — это норма (пароли трекеров не пишутся).
|
||||
|
||||
### 🔑 ГЛАВНОЕ ОТКРЫТИЕ: FS нужен `PROXY_URL`, иначе он бесполезен на Тайге
|
||||
**Swap НЕ трогали.** Alex отклонил идею: «Назуя тебе свап? Памяти мало что-ли?» — и был прав:
|
||||
RAM 21 GB, FS держит 710 MB / 21 GB, CPU 0.68%. Swap на этом хосте не нужен.
|
||||
|
||||
### 🔑 ГЛАВНОЕ ОТКРЫТИЕ №1: FS нужен `PROXY_URL`, иначе он бесполезен на Тайге
|
||||
|
||||
На Кра́кене DNS-блока нет → FS ходит в трекер напрямую. **На Тайге DNS-блок есть** → FS сам
|
||||
должен ходить через `vless-proxy`. Решается глобальной env **`PROXY_URL`** (НЕ `HTTPS_PROXY`):
|
||||
@@ -52,16 +57,47 @@
|
||||
| Авторизация | не нужна (`PROXY_USERNAME`/`PROXY_PASSWORD` пусты) |
|
||||
|
||||
⚠️ Prowlarr обращается к FS с параметром `session`; при наличии сессии request-прокси
|
||||
**игнорируется** → срабатывает именно global `PROXY_URL`. То есть схема A (env) — единственный
|
||||
рабочий вариант, request-прокси через Prowlarr передать нельзя (у Prowlarr-прокси `Socks5`
|
||||
только host/port/user/pass, поля «передать в FS» нет).
|
||||
**игнорируется** → срабатывает именно global `PROXY_URL`. Схема A (env) — единственный
|
||||
рабочий вариант: у Prowlarr-прокси `Socks5` только host/port/user/pass, поля «передать в FS» нет.
|
||||
|
||||
### 🔑 ГЛАВНОЕ ОТКРЫТИЕ №2: FS-сессия НЕ наследует `PROXY_URL`
|
||||
|
||||
Самая дорогая грабля задачи. `PROXY_URL` применяется к Chrome **в момент создания сессии**.
|
||||
Сессия, созданная **до** появления `PROXY_URL`, остаётся без прокси навсегда и падает
|
||||
с `ERR_NAME_NOT_RESOLVED`, а Prowlarr трактует это как «blocked by CloudFlare Protection».
|
||||
|
||||
**Имя сессии Prowlarr — `prowlarr`.** Фикс: `sessions.destroy` → пересоздастся сама.
|
||||
|
||||
> ⚠️ После ЛЮБОЙ правки `PROXY_URL` — убить сессию `prowlarr`.
|
||||
> ✅ При обычном перезапуске FS (watchtower/reboot) проблема не повторится.
|
||||
|
||||
### Prowlarr: прокси-элементы и теги
|
||||
|
||||
| Элемент | id | Настройки | tags |
|
||||
|---|---|---|---|
|
||||
| `vless-socks5` (Socks5) | 1 | host `vless-proxy`, port `1080` | `[1]` |
|
||||
| `flaresolverr` (FlareSolverr) | 2 | host `http://flaresolverr:8191/`, **requestTimeout 180** | `[2]` |
|
||||
|
||||
Теги: `proxy` = id 1, `flaresolverr` = id 2.
|
||||
|
||||
**Индексерам нужны ОБА тега** — `proxy` (DNS-обход через SOCKS5) **и** `flaresolverr`
|
||||
(CF-челлендж). Финальное состояние:
|
||||
|
||||
| id | Индексер | tags | Статус |
|
||||
|---|---|---|---|
|
||||
| 1 | RuTracker | **[1, 2]** | ✅ valid |
|
||||
| 4 | NoNaMe Club | **[1, 2]** | ✅ valid |
|
||||
| 5 | Kinozal | **[1, 2]** | ✅ valid |
|
||||
| 6 | Kinozal (M) | **[1, 2]** | ✅ valid |
|
||||
| 2 | RuTor | [1] | ✅ valid |
|
||||
| 3 | Byrutor | [1] | ✅ valid |
|
||||
|
||||
### Пруф работы FS (не UI — прямой HTTP)
|
||||
|
||||
```bash
|
||||
docker exec prowlarr sh -c 'curl -s --max-time 150 -X POST http://flaresolverr:8191/v1 \
|
||||
-H "Content-Type: application/json" \
|
||||
-d "{\"cmd\":\"request.get\",\"url\":\"https://rutracker.org/forum/login.php\",\"maxTimeout\":120000}"'
|
||||
-d "{\"cmd\":\"request.get\",\"url\":\"https://rutracker.org/forum/login.php\",\"maxTimeout\":130000}"'
|
||||
# → {"status": "ok", "message": "Challenge solved!", "solution": {"status": 200, ...}}
|
||||
```
|
||||
|
||||
@@ -74,40 +110,13 @@ docker exec prowlarr sh -c 'curl -s --max-time 150 -X POST http://flaresolverr:8
|
||||
| `nnmclub.to/forum/index.php` | ok / Challenge not detected / 200 |
|
||||
| `sessions.create` | ok / Session created successfully / v3.5.2 |
|
||||
|
||||
### Prowlarr: прокси-элемент и теги
|
||||
|
||||
| Элемент | id | Настройки | tags |
|
||||
|---|---|---|---|
|
||||
| `vless-socks5` (Socks5) | 1 | host `vless-proxy`, port `1080` | `[1]` |
|
||||
| `flaresolverr` (FlareSolverr) | 2 | host `http://flaresolverr:8191/`, **requestTimeout 120** | `[2]` |
|
||||
|
||||
Теги: `proxy` = id 1, `flaresolverr` = id 2.
|
||||
|
||||
**Индексерам нужны ОБА тега** — `proxy` (DNS-обход через SOCKS5) **и** `flaresolverr` (CF-челлендж).
|
||||
Навешено:
|
||||
|
||||
| id | Индексер | tags |
|
||||
|---|---|---|
|
||||
| 1 | RuTracker | **[1, 2]** ✅ |
|
||||
| 5 | Kinozal | **[1, 2]** ✅ |
|
||||
| 6 | Kinozal (M) | **[1, 2]** ✅ |
|
||||
| 2 | RuTor | [1] |
|
||||
| 3 | Byrutor | [1] |
|
||||
| 4 | NoNaMe Club | [1] ⏳ **нужен [1,2]** |
|
||||
|
||||
### 🔴 ПИТФОЛЛ: `PUT /api/v1/indexer/N` падает 400 из-за теста FS
|
||||
|
||||
Prowlarr при PUT **сразу тестирует** индексер. Если FS в этот момент таймаутит (или челлендж
|
||||
не решён), приходит **HTTP 400** с телом:
|
||||
|
||||
```json
|
||||
[{"isWarning":false,"propertyName":"","severity":"error",
|
||||
"errorMessage":"Unable to connect to indexer, indexer's server is unavailable. Try again later.
|
||||
HTTP request failed: [500:InternalServerError] [POST] at [http://flaresolverr:8191/v1]"}]}
|
||||
```
|
||||
|
||||
Теги при этом **НЕ применяются** (остаются старые). Обход — **`?forceSave=true`**:
|
||||
Prowlarr при PUT **сразу тестирует** индексер. Если FS в этот момент не прошёл — **HTTP 400**
|
||||
с `validationFailures` (`HTTP request failed: [500:InternalServerError] [POST] at
|
||||
[http://flaresolverr:8191/v1]`). Теги при этом **НЕ применяются** (откатываются).
|
||||
|
||||
Обход — **`?forceSave=true`**:
|
||||
```bash
|
||||
curl -X PUT -H @/tmp/h.txt -H "Content-Type: application/json" \
|
||||
-d @/tmp/ix1-new.json "http://localhost:9696/api/v1/indexer/1?forceSave=true"
|
||||
@@ -116,35 +125,34 @@ curl -X PUT -H @/tmp/h.txt -H "Content-Type: application/json" \
|
||||
|
||||
### 🔴 ПИТФОЛЛ: `requestTimeout=60` у FS-прокси МАЛО
|
||||
|
||||
Дефолт прокси-элемента — 60 с. CF-челлендж на `/forum/login.php` в него не укладывается →
|
||||
Дефолт прокси-элемента — 60 с. CF-челлендж на `/forum/login.php` и kinozal занимает **78–97 с** →
|
||||
`Error solving the challenge. Timeout after 60.0 seconds`, индексер краснеет.
|
||||
**Поднять до 120** (проверено: с 120 челлендж решается). Правка PUT-ом прокси-элемента `/2`.
|
||||
**Поднять до 180** (правка PUT-ом прокси-элемента `/2`). PUT → **202**.
|
||||
|
||||
### 🔴 ПИТФОЛЛ: `testall` параллельный → Chrome захлёбывается
|
||||
|
||||
`POST /api/v1/indexer/testall` тестирует все 6 индексеров **одновременно**, а Chrome в FS — один.
|
||||
Часть челленджей отваливается по таймауту (ложный «blocked by CloudFlare Protection»).
|
||||
Прямой одиночный вызов того же URL через секунды даёт `Challenge solved!`.
|
||||
**Правило диагностики:** если `testall` показал Cloudflare-блок — перепроверять **одиночным**
|
||||
`request.get` с `maxTimeout=120000`, а не верить `testall`. Это грабля, стоившая времени.
|
||||
`request.get` с большим `maxTimeout`, а не верить `testall`. Это грабля, стоившая времени.
|
||||
|
||||
### Результат `testall` (прогон 2026-09-28)
|
||||
### ПЛАН ВЫПОЛНЕН — по фазам
|
||||
|
||||
```
|
||||
1 RuTracker ✅ isValid=true
|
||||
2 RuTor ✅ isValid=true
|
||||
3 Byrutor ✅ isValid=true
|
||||
6 Kinozal (M) ✅ isValid=true
|
||||
4 NoNaMe Club ❌ "Unable to access nnmclub.to, blocked by CloudFlare Protection" ← нет FS-тега
|
||||
5 Kinozal ❌ "Unable to access kinozal.me, blocked by CloudFlare Protection" ← гонка testall
|
||||
```
|
||||
| Фаза | Что | Статус |
|
||||
|---|---|---|
|
||||
| 0 | Внешняя блокировка / DNS-прокси | ✅ была закрыта ранее (2026-09-26) |
|
||||
| 1 | FlareSolverr контейнер + `PROXY_URL` | ✅ выполнено |
|
||||
| 2 | Прокси-элемент + теги `[1,2]` + карантин | ✅ выполнено |
|
||||
| 3 | Проверка поиска | ✅ 256 результатов |
|
||||
| 4 | `sessions.destroy` (не входила в план, найдена по ходу) | ✅ выполнено |
|
||||
|
||||
### Осталось (для следующей сессии)
|
||||
### 🔴 Что чуть не стало ложным выводом (методический урок)
|
||||
|
||||
1. **Навесить тег `[1,2]` на NoNaMe (id 4)** — GET → правка → PUT с `?forceSave=true`.
|
||||
2. **Перепроверить Kinozal (5)** одиночным тестом — по факту FS на `kinozal.me/browse.php`
|
||||
даёт `Challenge solved!`, значит это была гонка testall, а не реальный блок.
|
||||
3. **ПРИЁМКА ALEX:** https://prowlarr.mallexxx.duckdns.org → Indexers → Test All → зелёные.
|
||||
Первые прогоны дали «4/6», и вывод «Kinozal упирается в скорость CF-челленджа, не в конфиг»
|
||||
был **неверным**. Спасло то, что замер падения показал **7 секунд** — при 78–97 с у челленджа
|
||||
это физически не таймаут. Отсюда найден `ERR_NAME_NOT_RESOLVED` и корень.
|
||||
**Урок:** когда «таймаут» короче самого медленного шага — это не таймаут, а другая ошибка.
|
||||
Смотреть фактическое время, а не текст сообщения.
|
||||
|
||||
### Бэкапы (перед изменениями)
|
||||
|
||||
@@ -164,14 +172,15 @@ docker exec prowlarr sh -c 'printf "X-Api-Key: 35c8b3f497114076a6150ea0d9504845"
|
||||
docker exec prowlarr sh -c 'curl -s -H @/tmp/h.txt http://localhost:9696/api/v1/indexer'
|
||||
```
|
||||
|
||||
Разбор JSON — **на хосте** (`python3` в контейнере НЕТ у Prowlarr: `sh: python3: not found`).
|
||||
Разбор JSON — **на хосте** (`python3` в контейнере Prowlarr НЕТ: `sh: python3: not found`).
|
||||
Долгие операции (`testall`) — через `docker exec -d` в фон + файл-маркер `.done`.
|
||||
`curl` без `--max-time` виснет, если FS не отвечает — всегда ставить лимит.
|
||||
|
||||
## Разведка (2026-09-28, всё проверено на живой машине)
|
||||
## Разведка (2026-09-28, что было ДО работы)
|
||||
|
||||
### Что УЖЕ сделано (не переделывать!)
|
||||
### Что УЖЕ было сделано (не переделывать!)
|
||||
|
||||
Прошлый план (2026-09-26) предполагал два блока. **Блокер №2 (DNS) уже закрыт**, а с ним
|
||||
Прошлый план (2026-09-26) предполагал два блока. **Блокер №2 (DNS) был закрыт**, а с ним
|
||||
и большая часть Фазы 0:
|
||||
|
||||
| Что | Факт 2026-09-28 |
|
||||
@@ -183,9 +192,7 @@ docker exec prowlarr sh -c 'curl -s -H @/tmp/h.txt http://localhost:9696/api/v1/
|
||||
| URL индексеров | ✅ Kinozal/Kinozal(M) уже на `kinozal.me` (не мёртвый `.tv`) |
|
||||
| Поиск через Prowlarr | ✅ RuTor 100 + Byrutor 6 на «matrix» |
|
||||
|
||||
`vless-proxy` **жив** (его outbound был мёртв после удаления VPS qentra.top — переключён).
|
||||
|
||||
### Что ОСТАЛОСЬ (суть задачи)
|
||||
### Что ОСТАВАЛОСЬ (суть задачи)
|
||||
|
||||
Остаточная проблема — **не DNS, а Cloudflare**. Прямой факт:
|
||||
|
||||
@@ -194,127 +201,30 @@ GET https://rutracker.org/forum/login.php через socks5h://vless-proxy:1080
|
||||
→ <title>Just a moment...</title> + challenges.cloudflare.com ← JS-челлендж
|
||||
```
|
||||
|
||||
`IndexerStatus` (без снятия): карантин до `2026-09-29T02:25Z` у id **1 (RuTracker)**, **5 (Kinozal)**,
|
||||
**6 (Kinozal M)**. `initialFailure = 2026-05-20` (день деплоя).
|
||||
`IndexerStatus` (без снятия): карантин у id **1 (RuTracker)**, **5 (Kinozal)**, **6 (Kinozal M)**.
|
||||
`initialFailure = 2026-05-20` (день деплоя).
|
||||
**FlareSolverr на Тайге отсутствовал** (`docker ps -a | grep flare` → пусто).
|
||||
|
||||
**FlareSolverr на Тайге ОТСУТСТВУЕТ** (`docker ps -a | grep flare` → пусто).
|
||||
|
||||
### Риски, которые надо закрыть ЗАРАНЕЕ (грабли Кра́кена)
|
||||
### Риски (грабли Кра́кена — что проверяли заранее)
|
||||
|
||||
Из [[personal/tech/prowlarr-flaresolverr-cloudflare]] §2026-09-24 — там FlareSolverr ушёл
|
||||
в **crash-loop**, Chrome не поднимался под chromedriver. Две причины хоста:
|
||||
в **crash-loop**, Chrome не поднимался под chromedriver.
|
||||
|
||||
| Условие | Кра́кен (сломано) | Тайга (сейчас) | Действие |
|
||||
| Условие | Кра́кен (сломано) | Тайга | Итог |
|
||||
|---|---|---|---|
|
||||
| `/dev/shm` | 64 MB → Chrome падал | **64 MB** (`ShmSize=67108864`) | 🔴 задать `shm_size: 1gb` |
|
||||
| swap | `/proc/swaps` пуст → пик старта убивал | **`/proc/swaps` пуст, Swap=0** | 🔴 поднять swap или принять риск |
|
||||
| RAM | мало | 21 GB total, **5.6 GB available** | ✅ хватает |
|
||||
| IPv6 | `::1 localhost` ломал | проверить | добавить `disable_ipv6=1` (как на Кра́кене, там не помогло, но безвредно) |
|
||||
|
||||
🔴 **Главное отличие от Кра́кена:** на Кра́кене FlareSolverr **проксирует через себя** и лезет
|
||||
в трекер напрямую — но у Кра́кена нет DNS-блока. На Тайге **DNS-блок есть**, значит
|
||||
**FlareSolverr сам должен ходить через `vless-proxy`** (иначе он получит NXDOMAIN и не поможет).
|
||||
Это ключевой архитектурный пункт: у контейнера `flaresolverr` должен быть настроен upstream-прокси
|
||||
на `vless-proxy:1080`.
|
||||
|
||||
Проверить, поддерживает ли образ env `HTTPS_PROXY`/`SOCKS_PROXY` — у FlareSolverr есть
|
||||
`PROXY`-настройки через переменные окружения и/или поле в `request.get`. Если env не работает —
|
||||
передавать `proxy: {url: "socks5://vless-proxy:1080"}` в теле запроса от Prowlarr (Prowlarr
|
||||
умеет это в настройках прокси-элемента? проверить — у Socks5-прокси в Prowlarr есть только
|
||||
host/port/username/password, поля «передать в FS» нет).
|
||||
|
||||
> ✅ **ОТКРЫТЫЙ ВОПРОС №1 ЗАКРЫТ (2026-09-28).** Схема A работает. У FlareSolverr
|
||||
> глобальный прокси задаётся переменной **`PROXY_URL`** (НЕ `HTTPS_PROXY`), формат со схемой
|
||||
> обязателен: **`socks5://vless-proxy:1080`**. Приоритет: request > session > global.
|
||||
> ⚠️ Важно: Prowlarr обращается к FS с параметром `session`, а при наличии сессии
|
||||
> request-прокси **игнорируется** → сработает именно global (`PROXY_URL`). Проверено по
|
||||
> DeepWiki FlareSolverr §4.2.
|
||||
> `PROXY_USERNAME`/`PROXY_PASSWORD` не нужны — `vless-proxy` без авторизации.
|
||||
|
||||
## ПЛАН
|
||||
|
||||
### Фаза 0 — внешняя блокировка: ✅ ЗАКРЫТА (проверено выше)
|
||||
|
||||
Ничего делать не нужно. Осталось только снять карантин (Фаза 2).
|
||||
|
||||
### Фаза 1 — FlareSolverr контейнер
|
||||
|
||||
1. **Бэкап** `/mnt/RED_2TB/docker/arr/docker-compose.yml` → `~truenas_admin/`
|
||||
(`cp docker-compose.yml ~truenas_admin/docker-compose.yml.bak-<ts>`).
|
||||
Бэкап **самого compose** отдаёт сам: `/tmp` не годится (чистится).
|
||||
2. Проверить схему проксирования FS (открытый вопрос №1) — **до** правки compose.
|
||||
3. Добавить сервис в `/mnt/RED_2TB/docker/arr/docker-compose.yml`:
|
||||
```yaml
|
||||
flaresolverr:
|
||||
image: ghcr.io/flaresolverr/flaresolverr:latest
|
||||
container_name: flaresolverr
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
- LOG_LEVEL=warning # ← НЕ info: info пишет пароли трекеров в plaintext
|
||||
- BROWSER_TIMEOUT=60000
|
||||
- TZ=Asia/Novosibirsk
|
||||
# + прокси-переменные для обхода DNS (если схема A):
|
||||
# - HTTP_PROXY=socks5h://vless-proxy:1080
|
||||
# - HTTPS_PROXY=socks5h://vless-proxy:1080
|
||||
ports:
|
||||
- "8191:8191"
|
||||
networks:
|
||||
- media_net
|
||||
shm_size: 1gb # ← Кра́кен: 64 MB убивал Chrome
|
||||
sysctls:
|
||||
- net.ipv6.conf.all.disable_ipv6=1
|
||||
```
|
||||
⚠️ `shm_size` и `sysctls` — **в блок сервиса**, не в `environment`.
|
||||
4. Поднять из правильной папки:
|
||||
`cd /mnt/RED_2TB/docker/arr && docker compose up -d flaresolverr`
|
||||
(не через временную копию compose — name-conflict, грабля Кра́кена).
|
||||
5. **Проверка живого FS** (не UI, а HTTP):
|
||||
```bash
|
||||
docker exec prowlarr sh -c 'curl -s -X POST http://flaresolverr:8191/v1 \
|
||||
-H "Content-Type: application/json" \
|
||||
-d "{\"cmd\":\"request.get\",\"url\":\"https://rutracker.org/forum/index.php\",\"maxTimeout\":60000}"'
|
||||
# ожидается: {"status":"ok", ... "solution":{...}} — НЕ "Challenge detected" в ответе
|
||||
```
|
||||
⚠️ Первый старт Chrome ~20-60 с. `docker logs flaresolverr` должен показать
|
||||
`Challenge solved!`, а НЕ `session not created: cannot connect to chrome`.
|
||||
|
||||
**ПРИЁМКА ALEX:** `docker logs --tail 30 flaresolverr` → есть `Challenge solved!`.
|
||||
|
||||
### Фаза 2 — прокси-элемент в Prowlarr + снятие карантина
|
||||
|
||||
1. Добавить/обновить прокси в Prowlarr: Settings → Indexers → Add Proxy → **FlareSolverr**,
|
||||
host `http://flaresolverr:8191`, tag `flaresolverr`. (`vless-socks5` остаётся отдельным
|
||||
прокси для DNS-обхода; один индексер может иметь **оба** тега — проверить.)
|
||||
2. Навесить тег `flaresolverr` на RuTracker(1), Kinozal(5), Kinozal(M)(6) — **тем же способом
|
||||
через API**, что и `proxy` (GET → jq `.tags=[…]` → PUT). 🔴 Без одинакового тега на прокси
|
||||
И индексере прокси молча не применяется.
|
||||
3. Сбросить карантин: `POST /api/v1/indexer/testall`.
|
||||
4. **ПРИЁМКА ALEX:** https://prowlarr.mallexxx.duckdns.org → Indexers → Test All → зелёные.
|
||||
|
||||
### Фаза 3 — проверка поиска
|
||||
|
||||
```bash
|
||||
docker exec prowlarr sh -c 'printf "X-Api-Key: 35c8b3f497114076a6150ea0d9504845" > /tmp/h.txt'
|
||||
docker exec prowlarr sh -c 'curl -s -G -H @/tmp/h.txt --data-urlencode "query=matrix" \
|
||||
--data-urlencode "type=search" http://localhost:9696/api/v1/search' | \
|
||||
python3 -c "import json,sys,collections; d=json.load(sys.stdin); \
|
||||
print(collections.Counter(x['indexer'] for x in d))"
|
||||
```
|
||||
Ожидается: появляются RuTracker + Kinozal с ненулевым счётом.
|
||||
|
||||
**ПРИЁМКА ALEX:** поиск в UI Prowlarr по конкретному фильму → результат от RuTracker/Kinozal.
|
||||
|
||||
## Вопросы к Алексу
|
||||
|
||||
1. **Схема проксирования FlareSolverr** (открытый вопрос №1 выше): проверить env-переменные
|
||||
или `proxy` в теле запроса — сделаю сам, не требует решения. Решение не нужно, если вариант A сработает.
|
||||
2. **Swap на Тайге (Swap=0).** На Кра́кене именно мёртвый swap + 64 MB `/dev/shm` убили Chrome.
|
||||
Варианты: (A) поднять `/var/swap` на Тайге (как на Кра́кене) — надёжнее; (B) рискнуть с одним
|
||||
`shm_size: 1gb` и посмотреть. **Рекомендую A+C:** поднять swap И дать shm 1gb.
|
||||
⚠️ Трогать swap — системное изменение, согласовать.
|
||||
| `/dev/shm` | 64 MB → Chrome падал | 64 MB | ✅ задали `shm_size: 1gb` |
|
||||
| swap | пуст → пик старта убивал | пуст, Swap=0 | ✅ **не нужен** — RAM 21 GB |
|
||||
| RAM | мало | 21 GB, 5.6 GB free | ✅ хватает |
|
||||
| IPv6 | `::1 localhost` | — | добавили `disable_ipv6=1` (безвредно) |
|
||||
|
||||
## История
|
||||
|
||||
- **2026-09-28** — разведка. Обнаружено: DNS-блокер УЖЕ закрыт (прокси настроен 2026-09-26),
|
||||
остаточная проблема — Cloudflare на RuTracker/Kinozal. FlareSolverr отсутствует. Составлен план.
|
||||
Ничего не изменено.
|
||||
- **2026-09-26** — разведка под Lidarr. Найдено: DNS-блок провайдера (NXDOMAIN на 4 трекера),
|
||||
`vless-proxy` не в `media_net`. Прокси-маршрут для Prowlarr починен в тот же день (3/6 индексеров).
|
||||
Остаток — Cloudflare. Первоначальный план — [[personal/plans/lidarr-taiga-and-indexer-unblock]].
|
||||
- **2026-09-28** — разведка: DNS-блокер уже закрыт, остаток — Cloudflare, FS отсутствует.
|
||||
Составлен план, ждал «go». Ничего не изменено.
|
||||
- **2026-09-28 (тот же день, после «Го»)** — **ВЫПОЛНЕНО.** FlareSolverr развёрнут, 6/6 индексеров,
|
||||
health `[]`, поиск 256. Питфоллы: `requestTimeout` 60→180, `?forceSave=true`, гонка `testall`,
|
||||
и главный — **смена `PROXY_URL` не обновляет существующую FS-сессию**.
|
||||
Открытый вопрос по swap закрыт Alex (не нужен).
|
||||
@@ -1,14 +1,66 @@
|
||||
# FlareSolverr на Тайге + обход блокировок индексеров
|
||||
|
||||
> ✅ **СОСТОЯНИЕ 2026-09-28: FlareSolverr РАЗВЁРНУТ и работает end-to-end.**
|
||||
> ✅ **СОСТОЯНИЕ 2026-09-28: ГОТОВО. Все 6 индексеров рабочие, health чистый.**
|
||||
> Контейнер `flaresolverr` (v3.5.2), порт `8191`, сеть `media_net`, `shm_size: 1gb`,
|
||||
> `LOG_LEVEL=warning`, **`PROXY_URL=socks5://vless-proxy:1080`**.
|
||||
> Compose — `/mnt/RED_2TB/docker/arr/docker-compose.yml` (6-й сервис).
|
||||
> Бэкап: `~truenas_admin/docker-compose.yml.bak-20260928-flaresolverr`.
|
||||
> Связка: [[personal/plans/lidarr-taiga-and-indexer-unblock]], [[family/projects/media-toolbox-taiga]],
|
||||
> [[personal/tech/prowlarr-flaresolverr-cloudflare]], [[family/how-to/arr-stack-kraken]].
|
||||
> Бэкапы: `~truenas_admin/docker-compose.yml.bak-20260928-flaresolverr`,
|
||||
> `~/backup-indexers-20260928-flaresolverr.json` (снимок 6 индексеров до правки тегов).
|
||||
> Связка: [[personal/plans/flaresolverr-taiga-deploy]], [[personal/plans/lidarr-taiga-and-indexer-unblock]],
|
||||
> [[family/projects/media-toolbox-taiga]], [[personal/tech/prowlarr-flaresolverr-cloudflare]],
|
||||
> [[family/how-to/arr-stack-kraken]].
|
||||
|
||||
## 🔑 ГЛАВНОЕ ОТЛИЧИЕ ОТ КРА́КЕНА: FlareSolverr сам идёт через прокси
|
||||
## ✅ РЕЗУЛЬТАТ (поиск «matrix» через `/api/v1/search`)
|
||||
|
||||
```
|
||||
TOTAL 256
|
||||
RuTor 100 ← был живой
|
||||
RuTracker 50 ← ВПЕРВЫЕ с 2026-05-20
|
||||
NoNaMe 50 ← ВПЕРВЫЕ
|
||||
Kinozal 50 ← ВПЕРВЫЕ
|
||||
Byrutor 6
|
||||
```
|
||||
|
||||
`GET /api/v1/health` → `[]`, `GET /api/v1/indexerstatus` → `[]`. **Ни одной ошибки,
|
||||
ни одного карантина.** Было 3/6, стало 6/6 (по выдаче — 5 трекеров; Kinozal (M) — зеркало
|
||||
Kinozal с magnet-приоритетом, в общую выдачу дублируется).
|
||||
|
||||
## 🔑 ГЛАВНОЕ ОТКРЫТИЕ: FS-СЕССИЯ НЕ НАСЛЕДУЕТ `PROXY_URL`
|
||||
|
||||
Самый неочевидный пункт всей задачи. Симптом был **ложный**: Prowlarr писал
|
||||
`blocked by CloudFlare Protection`, а лог FS — мгновенную ошибку за **7 секунд** (не таймаут!).
|
||||
|
||||
**Причина:** `PROXY_URL` (глобальный прокси) применяется к Chrome **в момент создания сессии**.
|
||||
Сессия, созданная **до** появления `PROXY_URL`, остаётся **без прокси** навсегда —
|
||||
в ней Chrome получает `net::ERR_NAME_NOT_RESOLVED` (DNS-блок!). Prowlarr шлёт запросы
|
||||
с параметром `session`, и global-прокси её не перебивает.
|
||||
|
||||
Пруф — прямой вызов с сессией, созданной ДО прокси:
|
||||
```
|
||||
request.get kinozal + session:"prowlarr" (старая)
|
||||
→ {"status":"error","message":"Error solving the challenge.
|
||||
Message: unknown error: net::ERR_NAME_NOT_RESOLVED (chrome=152.0.7977.82)"}
|
||||
```
|
||||
Тот же запрос с сессией, созданной **ПОСЛЕ** `PROXY_URL` → `Challenge solved! 200`.
|
||||
|
||||
**Имя сессии Prowlarr — `prowlarr`** (обнаружено через `sessions.list`).
|
||||
|
||||
**Фикс:** удалить устаревшую сессию — `sessions.destroy`; Prowlarr пересоздаёт её сам
|
||||
при следующем запросе, уже с рабочим `PROXY_URL`.
|
||||
|
||||
```bash
|
||||
docker exec prowlarr sh -c 'curl -s -X POST http://flaresolverr:8191/v1 \
|
||||
-H "Content-Type: application/json" \
|
||||
-d "{\"cmd\":\"sessions.destroy\",\"session\":\"prowlarr\"}"'
|
||||
```
|
||||
|
||||
> ⚠️ **Правило на будущее:** после ЛЮБОЙ правки `PROXY_URL` в compose **убить сессию
|
||||
> `prowlarr`**, иначе старые сессии продолжат ходить без прокси и индексера будут
|
||||
> «blocked by CloudFlare» при живом FS.
|
||||
> ✅ При обычном перезапуске FS (watchtower/reboot) проблема НЕ повторится — сессия
|
||||
> создастся заново уже с `PROXY_URL`.
|
||||
|
||||
## 🔑 ВТОРОЕ ОТКРЫТИЕ: FlareSolverr сам идёт через прокси (`PROXY_URL`)
|
||||
|
||||
На Кра́кене два механизма независимы: Cloudflare лечится FlareSolverr, DNS-блока нет.
|
||||
**На Тайге блоков ДВА (DNS + Cloudflare), и FlareSolverr обязан ходить через `vless-proxy`** —
|
||||
@@ -17,29 +69,33 @@
|
||||
**Решение:** глобальная env-переменная FlareSolverr **`PROXY_URL=socks5://vless-proxy:1080`**.
|
||||
|
||||
> ⚠️ Имя переменной — **`PROXY_URL`**, НЕ `HTTP_PROXY`/`HTTPS_PROXY` (проверено по DeepWiki
|
||||
> FlareSolverr §4.2). Формат **со схемой обязателен** (`socks5://host:port`); без схемы —
|
||||
> `urllib.parse` не разберёт. Приоритет: request > session > global.
|
||||
> FlareSolverr §4.2 «Proxy Configuration»). Формат **со схемой обязателен**
|
||||
> (`socks5://host:port`); без схемы `urllib.parse` не разберёт.
|
||||
> Приоритет: request > session > global. `PROXY_USERNAME`/`PROXY_PASSWORD` не нужны —
|
||||
> `vless-proxy` без авторизации.
|
||||
|
||||
**Почему срабатывает именно global:** Prowlarr обращается к FS с параметром `session`,
|
||||
а при наличии сессии request-прокси **игнорируется** → применяется global (`PROXY_URL`).
|
||||
Схема совпала случайно-удачно: если бы Prowlarr слал request-прокси, он бы его перебил.
|
||||
|
||||
## ⚠️ ПИТФОЛЛ: `requestTimeout` = 60 с МАЛО, нужно 120
|
||||
## ⚠️ ПИТФОЛЛ: `requestTimeout` = 60 с МАЛО, поднят до 180
|
||||
|
||||
Дефолтный `requestTimeout` прокси-элемента FlareSolverr в Prowlarr = **60 с**.
|
||||
Решение CF-челленджа на `/forum/login.php` RuTracker занимает **больше 60 с** →
|
||||
Решение CF-челленджа на `/forum/login.php` RuTracker и на kinozal занимает **80–100 с** →
|
||||
`Error solving the challenge. Timeout after 60.0 seconds` в логе FS, Prowlarr отдаёт
|
||||
`500 InternalServerError [POST] at http://flaresolverr:8191/v1`, а в UI — «blocked by CloudFlare».
|
||||
`500 InternalServerError [POST] at http://flaresolverr:8191/v1`, в UI — «blocked by CloudFlare».
|
||||
|
||||
**Фикс:** `requestTimeout` = **120** (PUT `/api/v1/indexerproxy/2`).
|
||||
**Фикс:** `requestTimeout` = **180** (PUT `/api/v1/indexerproxy/2`).
|
||||
Проверка: `docker logs flaresolverr` → `Challenge solved!`, а не `Timeout`.
|
||||
|
||||
> Замеры времени челленджа (kinozal.me/browse.php через FS): **78 с** холодный,
|
||||
> **20 с** прогретый (CF-клэренс привязан к IP прокси), POST-логин — **97 с**.
|
||||
|
||||
## ⚠️ ПИТФОЛЛ: параллельный `testall` устраивает гонку за Chrome
|
||||
|
||||
Prowlarr тестирует все индексеры **одновременно**, а у FlareSolverr **один** Chrome.
|
||||
При `testall` челленджи сыпятся таймаутами; если тестировать **по одному** (sequential) —
|
||||
проходят. Диагноз: вручную одиночный `request.get` проходит за секунды, а `testall` даёт
|
||||
`Timeout`. **Не верить результату параллельного `testall`** — гонять по одному.
|
||||
проходят. **Не верить результату параллельного `testall`** — гонять по одному.
|
||||
Дополнительно: `curl` без `--max-time` виснет, если FS не отвечает — всегда ставить лимит.
|
||||
|
||||
## ⚠️ ПИТФОЛЛ: тег нужен И на прокси, И на индексере — и на ОБА прокси
|
||||
|
||||
@@ -51,15 +107,16 @@ Prowlarr тестирует все индексеры **одновременно
|
||||
| `flaresolverr` | 2 | `flaresolverr` (id=2) | обход **Cloudflare** |
|
||||
|
||||
Значит на индексер вешаются **оба** тега: `tags=[1,2]`. Один прокси не закрывает оба блока.
|
||||
Фактически навешено: id 1, 4, 5, 6 → `[1,2]`; id 2, 3 → `[1]` (RuTor/Byrutor живут на одном прокси).
|
||||
|
||||
## ⚠️ ПИТФОЛЛ: PUT `/api/v1/indexer/N` → 400, нужен `?forceSave=true`
|
||||
|
||||
Prowlarr при PUT **сразу тестирует** индексер. Если FS в этот момент не прошёл
|
||||
(таймаут/гонка) — `HTTP 400` с `validationFailures`. Именно так «потерялись» теги
|
||||
после первого PUT: теги откатились к `[1]`.
|
||||
после первого PUT: они откатились к `[1]`.
|
||||
|
||||
**Рабочий путь:** `PUT /api/v1/indexer/N?forceSave=true` → **202** (сохраняет, тест пропускает).
|
||||
Тест гонять отдельно, по одному.
|
||||
Тест гонять отдельно, по одному. То же для `/indexerproxy/N`.
|
||||
|
||||
## Практические замечания
|
||||
|
||||
@@ -75,55 +132,76 @@ Prowlarr при PUT **сразу тестирует** индексер. Если
|
||||
```
|
||||
- `sleep 35` после старта контейнера — Chrome поднимается ~30 с; раньше этого `:8191` может не отвечать.
|
||||
- `shm_size` и `sysctls` — **в блок сервиса** compose, не в `environment`.
|
||||
- **`ERR_NAME_NOT_RESOLVED` в ответе FS = сессия без прокси** (см. открытие выше), а не «FS сломан».
|
||||
- **Ключ API в `-H` ломается многоуровневым экранированием** (ssh → docker → sh).
|
||||
Рабочий приём: `printf "X-Api-Key: <KEY>" > /tmp/h.txt` внутри контейнера, затем `curl -H @/tmp/h.txt`.
|
||||
- **`python3` внутри контейнера prowlarr НЕТ** — разбирать JSON хостовым `python3`
|
||||
(на Тайге есть `python3`, нет `curl` и `sqlite3`).
|
||||
|
||||
## Состояние индексеров после деплоя (2026-09-28)
|
||||
## Состояние индексеров после деплоя (2026-09-28, финал)
|
||||
|
||||
| id | Индексер | Теги | Статус |
|
||||
|---|---|---|---|
|
||||
| 1 | RuTracker | `[1,2]` | ✅ **valid** (был красный с 2026-05-20) |
|
||||
| 2 | RuTor | `[1]` | ✅ valid (DNS-блок обходится одним прокси) |
|
||||
| 3 | Byrutor | `[1]` | ✅ valid (резолвится без прокси) |
|
||||
| 4 | NoNaMe Club | `[1,2]` | ✅ **valid** |
|
||||
| 5 | Kinozal | `[1,2]` | ⏳ CF-челлендж решается 80-100 с, Prowlarr обрывает |
|
||||
| 6 | Kinozal (M) | `[1,2]` | ⏳ то же |
|
||||
| 1 | RuTracker | `[1,2]` | ✅ valid (был красный с 2026-05-20) |
|
||||
| 2 | RuTor | `[1]` | ✅ valid |
|
||||
| 3 | Byrutor | `[1]` | ✅ valid |
|
||||
| 4 | NoNaMe Club | `[1,2]` | ✅ valid |
|
||||
| 5 | Kinozal | `[1,2]` | ✅ valid |
|
||||
| 6 | Kinozal (M) | `[1,2]` | ✅ valid |
|
||||
|
||||
## 🔴 ОТКРЫТАЯ ПРОБЛЕМА: Kinozal — челлендж дольше таймаута Prowlarr
|
||||
## ✅ ЗАКРЫТО: Kinozal — «blocked by CloudFlare» при живом FS
|
||||
|
||||
**Факты (замерено):**
|
||||
- Прямой socks5 к `kinozal.me/browse.php` → **403 Just a moment** за **0.9 с**.
|
||||
- FS `request.get` kinozal → `Challenge solved! 200`. Время: **78 с** (холодный), **20 с** (прогретый).
|
||||
Самая долгая часть задачи. Симптом маскировался под таймаут, причина оказалась другой.
|
||||
|
||||
**Что замерено (история диагностики):**
|
||||
- Прямой socks5 к `kinozal.me/browse.php` → **403 Just a moment** за **0.9 с** (CF реален).
|
||||
- FS `request.get` kinozal → `Challenge solved! 200`: **78 с** холодный, **20 с** прогретый.
|
||||
- FS `request.post` kinozal/takelogin.php → `Challenge solved! 200`, **97 с**.
|
||||
- HTTP 500 от FS в логе Prowlarr: `[POST] at http://flaresolverr:8191/v1`.
|
||||
- Вердикт Prowlarr: `blocked by CloudFlare Protection` (НЕ таймаут — явная ошибка).
|
||||
- Prowlarr: `blocked by CloudFlare Protection`, в логе FS — падение за **7 с** (не таймаут!).
|
||||
|
||||
**Механика Prowlarr (из debug-лога) — два прокси применяются ПОСЛЕДОВАТЕЛЬНО:**
|
||||
**Ложный след:** `HTTP request failed: [500:InternalServerError] [POST] at http://flaresolverr:8191/v1`
|
||||
и `Error solving the challenge. Timeout after 60/120/180 seconds` — выглядело как «челлендж
|
||||
дольше таймаута». Поднятие `requestTimeout` 60→120→180 **не помогло**.
|
||||
|
||||
**Настоящая причина:** FS-сессия без прокси (см. главное открытие выше). Сессия `prowlarr`,
|
||||
созданная до появления `PROXY_URL`, падала с `ERR_NAME_NOT_RESOLVED` за 7 с, Prowlarr
|
||||
интерпретировал это как «CF блокирует» и уходил в retry → карантин.
|
||||
|
||||
**Фикс:** `sessions.destroy` сессии `prowlarr` → пересоздана с прокси →
|
||||
Kinozal (5) и Kinozal (M) (6) прошли с первого раза (`{}`).
|
||||
|
||||
**Что исключено (не тратить время повторно):** ресурсы FS в норме (710 MB / 21 GB, shm 1 GB,
|
||||
CPU 0.68%); канал прокси нормальный (kinozal через socks5 **0.6 с**, 908 KB/s); внутренний
|
||||
таймаут Prowlarr в `config.xml` не настраивается.
|
||||
|
||||
## Compose-сервис (вставлен в `/mnt/RED_2TB/docker/arr/docker-compose.yml`)
|
||||
|
||||
```yaml
|
||||
flaresolverr:
|
||||
image: ghcr.io/flaresolverr/flaresolverr:latest
|
||||
container_name: flaresolverr
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
- LOG_LEVEL=warning # НЕ info — info пишет пароли трекеров в plaintext
|
||||
- BROWSER_TIMEOUT=60000
|
||||
- TZ=Asia/Novosibirsk
|
||||
- PROXY_URL=socks5://vless-proxy:1080
|
||||
ports:
|
||||
- "8191:8191"
|
||||
networks:
|
||||
- media_net
|
||||
shm_size: 1gb # Кра́кен: 64 MB убивал Chrome
|
||||
sysctls:
|
||||
- net.ipv6.conf.all.disable_ipv6=1
|
||||
```
|
||||
Socks5|Applying Socks5 Proxy Socks5 to request https://kinozal.me/...
|
||||
FlareSolverr|Cloudflare Detected, Applying FlareSolverr Proxy ...
|
||||
```
|
||||
Сначала идёт socks5-прокси, Prowlarr видит CF, **потом** пробует FS. Это НЕ двойной хоп
|
||||
(FS сам ходит через прокси через `PROXY_URL`) — это retry-цепочка.
|
||||
|
||||
**Что исключено:**
|
||||
- Ресурсы FS в норме: 710 MB / 21 GB, shm 1 GB, 6 chrome-процессов, CPU 0.68%.
|
||||
- Канал прокси нормальный: kinozal через socks5 **0.6 с**, 908 KB/s.
|
||||
- `requestTimeout` поднят 60 → 120 → **180** — эффекта нет (Prowlarr обрывает по своему
|
||||
внутреннему таймауту HTTP-клиента, не настраивается через config.xml).
|
||||
Порядок деплоя: бэкап compose → правка **локально** (не sed на сервере) → `scp` → `cp` →
|
||||
`cd /mnt/RED_2TB/docker/arr && docker compose up -d flaresolverr`.
|
||||
⚠️ `docker compose up -d` **только из своего каталога**, иначе name-conflict (грабля Кра́кена).
|
||||
|
||||
**Вывод:** челлендж CF на kinozal через прокси в другом регионе решается 80-100 с —
|
||||
это свойство CF, не баг. Prowlarr ждёт меньше.
|
||||
|
||||
**Гипотезы для следующего захода (не проверены):**
|
||||
1. **Прогрев FS** — CF clearance привязан к IP прокси; после прогрева 20 с (проверено).
|
||||
Прогреть kinozal ×3 → снять карантин → тест.
|
||||
2. Снизить `BROWSER_TIMEOUT` не поможет; можно поднять **`shm_size` до 2gb** (не проверено).
|
||||
3. Разобрать внутренний таймаут Prowlarr (в бинарнике; в `config.xml` его нет).
|
||||
4. Отказаться от FS для Kinozal и оставить `[1]` — но тогда 403 CF (проверено).
|
||||
5. **Проверить `preferMagnetUrl`** у Kinozal (сейчас `False`) — на CF не влияет, но полезно.
|
||||
|
||||
**Итог по задаче Alex:** прокси-обход (DNS) + FlareSolverr (CF) **работают**.
|
||||
4 из 6 индексаров зелёные, включая RuTracker (впервые с 2026-05-20).
|
||||
Kinozal/Kinozal M — упираются в скорость CF-челленджа, не в конфиг.
|
||||
> ⚠️ **Swap на Тайге = 0** (`/proc/swaps` пуст). На Кра́кене мёртвый swap + 64 MB `/dev/shm`
|
||||
> убили Chrome в crash-loop. Здесь обошлось без swap: RAM 21 GB, доступно 5.6 GB, FS держит
|
||||
> 710 MB, CPU 0.68%. **Swap не трогали** — не нужен при таком объёме памяти.
|
||||
|
||||
## История
|
||||
|
||||
@@ -131,17 +209,18 @@ Kinozal/Kinozal M — упираются в скорость CF-челлендж
|
||||
`vless-proxy` не в `media_net`. Прокси-маршрут для Prowlarr починен в тот же день (3/6 индексеров).
|
||||
Остаток — Cloudflare на RuTracker/Kinozal. [[personal/plans/lidarr-taiga-and-indexer-unblock]]
|
||||
- **2026-09-28** — **FlareSolverr развёрнут** по задаче Alex «ставь как на Кра́кене + прокси-контейнер».
|
||||
Ключевое: FS сам ходит через `vless-proxy` (`PROXY_URL`) — двойной обход DNS+CF.
|
||||
RuTracker впервые стал `valid` за всё время существования стека (с 2026-05-20).
|
||||
Питфоллы: `requestTimeout` 60→120, `?forceSave=true`, гонка параллельного `testall`.
|
||||
Решено последовательно: (1) FS сам ходит через `vless-proxy` (`PROXY_URL`) — двойной обход DNS+CF;
|
||||
(2) `requestTimeout` 60→180; (3) теги `[1,2]` на все CF-индексеры; (4) **`sessions.destroy`
|
||||
сессии `prowlarr`** — последний блокер (сессия была создана до `PROXY_URL`).
|
||||
Итог: **6/6 индексеров, health `[]`, поиск 256 результатов.**
|
||||
RuTracker впервые `valid` за всё время существования стека (с 2026-05-20).
|
||||
|
||||
## Открытые пункты
|
||||
|
||||
- Прогнать финальный **sequential** тест всех 6 → зафиксировать результат.
|
||||
- Kinozal (5): подтвердить `valid` вне гонки (вручную челлендж решается).
|
||||
- **Приёмка Alex в UI:** `https://prowlarr.mallexxx.duckdns.org` → Indexers → 6 зелёных без карантинов.
|
||||
- Проверить, что RuTracker реально **логинится** (не только челлендж на login.php) —
|
||||
тестовый поиск с авторизацией.
|
||||
выдача 50 результатов намекает, что да.
|
||||
- Lidarr: метаданные `api.lidarr.audio` → 403 CF прямым, 200 через `vless-proxy`.
|
||||
Ранее заготовлен `/tmp/add_proxy_env.py` (HTTP_PROXY/HTTPS_PROXY) — **не применён**;
|
||||
теперь у FlareSolverr есть `PROXY_URL`, но Lidarr ходит в SkyHook сам, не через FS.
|
||||
Разбирать отдельно — [[family/plans/lidarr-taiga-deploy]].
|
||||
Заготовка `/tmp/add_proxy_env.py` (HTTP_PROXY/HTTPS_PROXY) — **не применена**;
|
||||
Lidarr ходит в SkyHook сам, НЕ через FS. Разбирать отдельно —
|
||||
[[family/plans/lidarr-taiga-deploy]].
|
||||
Reference in new issue
Block a user