diff --git a/personal/tech/flaresolverr-taiga.md b/personal/tech/flaresolverr-taiga.md index 64db6575..08916404 100755 --- a/personal/tech/flaresolverr-taiga.md +++ b/personal/tech/flaresolverr-taiga.md @@ -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 на выходе**.