diff --git a/personal/tech/flaresolverr-taiga.md b/personal/tech/flaresolverr-taiga.md index 08916404..564e617f 100755 --- a/personal/tech/flaresolverr-taiga.md +++ b/personal/tech/flaresolverr-taiga.md @@ -1,11 +1,12 @@ # FlareSolverr на Тайге + обход блокировок индексеров -> 🔴🔴 **ОБНОВЛЕНИЕ 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 (поздняя сессия): ДЕФЕКТ ЛОКАЛИЗОВАН — 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** ✅. @@ -440,26 +441,66 @@ curl -s ... -d @/tmp/login.json | jq -r ".solution.response" \ 4. Таблица `IndexerStatus` — колонка **`ProviderId`**, НЕ `IndexerId`. Записи были: id1 RuTracker Esc=1, id2 RuTor Esc=0, id4 NoNaMe Esc=1, id5/id6. 5. Очистка карантина **не лечит**: без рабочего туннеля RuTracker снова даст 0 и снова уйдёт в карантин. -## 🔴 ЧТО ЧИНИТЬ (открыто, следующий шаг) +## 🔴 ЧТО ЧИНИТЬ (уточнено Alex 2026-09-29: VPS НЕТ, есть прокси-КОНТЕЙНЕР) -**Чинить не FS и не Prowlarr — чинить DNS/узел VLESS.** Пока `vpn.mallexxx.duckdns.org` -указывает на дом, RuTracker не заработает. +⚠️ **Ошибочная версия (VPS + DuckDNS) отвергнута Alex.** Никакого VPS нет — есть контейнер +`vless-proxy` на самой Тайге. Логи это подтверждают: контейнер **жив** (`Up 2 days`), туннель +устанавливается (`tunneling request ... via vpn.mallexxx.duckdns.org:443`), SOCKS5-порты принимаются. -1. **Проверить, жив ли VPS** — нужен его реальный IP. Запись DuckDNS перезаписать на IP VPS. -2. Проверить, не умер ли DuckDNS-апдейтер **на VPS** (тогда запись «утекла» на домашний апдейтер). -3. После правки DNS — **проверить, что `api.ipify.org` через Chrome FS отдаёт IP VPS**, и только потом - принимать RuTracker. +🔴 **НАСТОЯЩИЙ ДЕФЕКТ: Chrome FlareSolverr стартует БЕЗ `--proxy-server=` — `PROXY_URL` к Chrome НЕ применяется.** + +Доказательство — командная строка живого процесса 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** | `getent hosts vpn.mallexxx.duckdns.org` | резолвится в дом → **туннель мёртв, дальше смотреть нечего** | +| **0** | `docker exec flaresolverr ps aux \| grep chromium` → есть ли `--proxy-server=` | **НЕТ флага → Chrome идёт мимо прокси, это и есть причина** | | 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, тест ПРОДЛЕВАЕТ | +| 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 живой — а трафика через туннель нет. Единственное доказательство