git_admin/obsidian-vault
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[2026-09-28] eagle: family/projects/media-toolbox-taiga.md personal/plans/flaresolverr-taiga-deploy.md personal/tech/flaresolverr-taiga.md

Browse Source
This commit is contained in:
Alexey Martemyanov committed 2026-09-28 13:26:36 +06:00
1 parent 6dfedbc142
commit 0ac3efb2f5
3 files changed
+254 -260
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

personal/plans/flaresolverr-taiga-deploy.md
+97 -187
View File
@@ -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 (не нужен).