[2026-09-28] eagle: personal/tech/flaresolverr-taiga.md

2026-09-28 22:10:40 +06:00
1 parent 58d2ae71f8
commit 0225381a5f
@@ -1,12 +1,20 @@
 # FlareSolverr на Тайге + обход блокировок индексеров

-> 🟡 **СОСТОЯНИЕ 2026-09-29 (конец сессии): FS настроен верно, НО RuTracker снова упал в 0.**
+> 🔴🔴 **ОБНОВЛЕНИЕ 2026-09-29 (поздняя сессия): КОРЕНЬ НАЙДЕН.**
+> Причина падения RuTracker — **НЕ сессия FS и НЕ карантин**, а **DNS-запись `vpn.mallexxx.duckdns.org`
+> указывает на домашний IP `90.189.160.148`** (Ростелеком, Новосибирск) вместо VPS ⇒ VLESS-туннель
+> фактически не работает, трафик выходит через дом. Подробности — раздел «КОРЕНЬ НАЙДЕН» в конце.
+> Карантин снят (`IndexerStatus` = 0), FS чист, бэкап БД сделан — но **RuTracker не заработает,
+> пока не починен DNS/UPS VLESS**. Диагностику начинать с `getent hosts vpn.mallexxx.duckdns.org`.
+>
+> 🟡 **СОСТОЯНИЕ 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]].

@@ -372,3 +380,87 @@ search:  idx1=50  idx2=33  idx4=47  idx5=EMPTY  idx6=0     ← НА МОМЕНТ
 снесены как ненужные). Но **логин RuTracker нестабилен**: сессия FS `prowlarr` периодически
 «отравляется» и переживает рестарт FS — лечится `sessions.destroy` + снятие карантина SQL.
 **Причина отравления не установлена** — открытый вопрос для следующей сессии.
+
+---
+
+# 🔴🔴 КОРЕНЬ НАЙДЕН (2026-09-29, поздняя сессия): DNS-запись `vpn.mallexxx.duckdns.org` указывает НА ДОМ
+
+**Гипотеза «отравленная сессия FS» — СЛЕДСТВИЕ, а не причина.** Настоящая причина в том,
+что **VLESS-туннель не работает вообще**, потому что VPN-хост резолвится в домашний IP.
+
+## Доказательства (факты, не догадки)
+
+```
+vpn.mallexxx.duckdns.org @8.8.8.8   → 90.189.160.148   ❌ (домашний Ростелеком, Новосибирск)
+vpn.mallexxx.duckdns.org @1.1.1.1   → 90.189.160.148   ❌
+vpn.mallexxx.duckdns.org @локальный → 192.168.0.10     ❌ (роутер дома, DNS 192.168.2.2)
+```
+
+`90.189.160.148` = **внешний IP домашней сети Тайги** (Тайга сама `192.168.2.197`), Rostelecom
+AS12389. Проверка: `ip-api.com/line/90.189.160.148` → Russia / Novosibirsk / Rostelecom.
+
+**Куда уходит трафик при «рабочем» прокси:**
+```
+Chrome FS (PROXY_URL) → vless-proxy → dial vpn.mallexxx.duckdns.org:443 → 90.189.160.148 (ДОМ!)
+   → выход через тот же Ростелеком → api.ipify.org отдаёт 90.189.160.148
+```
+То есть прокси-цепочка формально проходит, но **выходной узел = домашний IP** ⇒ обхода
+блокировки НЕТ. Прокси не падает с ошибкой — он **молча не проксирует**.
+
+```
+docker logs vless-proxy:
+  accepted tcp:rutracker.org:443
+  tunneling request to tcp:rutracker.org:443 via vpn.mallexxx.duckdns.org:443
+  ... failed to transfer response payload > websocket: close 1000 (normal)   ← рвётся
+```
+
+## Как это выглядело в FS (ложный след)
+
+| Тест | Результат | Правда |
+|---|---|---|
+| `curl --socks5-hostname vless-proxy:1080 rutracker` из FS | `http=200, 1.16s` | шёл **напрямую**, DNS на хосте, не через туннель |
+| `curl --socks5-hostname ... api.ipify.org` из FS | **пусто** | VLESS-цепочка умирает на удалённом конце |
+| Chrome FS `api.ipify.org` | `90.189.160.148` | **домашний IP** → туннеля нет |
+| POST login RuTracker через FS | `len=254410, cookies=[]` | `ERR_TIMED_OUT` (не капча, не CF!) |
+
+🔴 **`ERR_TIMED_OUT` в Chrome-странице ошибки = «сайт не ответил», а НЕ «блок Cloudflare» и НЕ «капча»:**
+```bash
+curl -s ... -d @/tmp/login.json | jq -r ".solution.response" \
+  | grep -oE "ERR_[A-Z_]+" | sort -u       # → ERR_TIMED_OUT
+```
+🔴 **Признак «прокси реально работает» = внешний IP ОТЛИЧАЕТСЯ от домашнего.** Проверять
+`api.ipify.org` через Chrome FS и сравнивать с `curl api.ipify.org` напрямую с хоста.
+Домашний IP, вернувшийся через «прокси», ДОКАЗЫВАЕТ, что прокси не проксирует.
+
+## ✅ Что сделано в этой сессии (факты)
+
+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 и снова уйдёт в карантин.
+
+## 🔴 ЧТО ЧИНИТЬ (открыто, следующий шаг)
+
+**Чинить не FS и не Prowlarr — чинить DNS/узел VLESS.** Пока `vpn.mallexxx.duckdns.org`
+указывает на дом, RuTracker не заработает.
+
+1. **Проверить, жив ли VPS** — нужен его реальный IP. Запись DuckDNS перезаписать на IP VPS.
+2. Проверить, не умер ли DuckDNS-апдейтер **на VPS** (тогда запись «утекла» на домашний апдейтер).
+3. После правки DNS — **проверить, что `api.ipify.org` через Chrome FS отдаёт IP VPS**, и только потом
+   принимать RuTracker.
+
+⚠️ **Порядок диагностики «RuTracker = 0» ОБНОВЛЁН** (старый порядок из раздела выше —
+`sessions.list` первый — ведёт по ложному следу):
+
+| # | Проверка | Признак |
+|---|---|---|
+| **0** | `getent hosts vpn.mallexxx.duckdns.org` | резолвится в дом → **туннель мёртв, дальше смотреть нечего** |
+| 1 | IP через Chrome FS vs IP хоста напрямую | совпадают → прокси не проксирует |
+| 2 | `ERR_[A-Z_]+` в Chrome-странице ошибки | `ERR_TIMED_OUT` ≠ капча ≠ CF |
+| 3 | `sessions.list` + `bb_session` в cookies | только после 0–2 |
+| 4 | `IndexerStatus` в БД | снимать SQL, тест ПРОДЛЕВАЕТ |
+
+> 🔴 **Урок:** «прокси настроен (`PROXY_URL` в env)» ≠ «прокси работает». Конфиг верный,
+> сеть `media_net` верная, FS живой — а трафика через туннель нет. Единственное доказательство
+> работы прокси — **внешний IP на выходе**.