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

personal/tech/flaresolverr-taiga.md

@@ -1,11 +1,12 @@
 # FlareSolverr на Тайге + обход блокировок индексеров
 
-> 🔴🔴 **ОБНОВЛЕНИЕ 2026-09-29 (поздняя сессия): КОРЕНЬ НАЙДЕН.**
+> 🔴🔴 **ОБНОВЛЕНИЕ 2026-09-29 (поздняя сессия): ДЕФЕКТ ЛОКАЛИЗОВАН — Chrome FS стартует БЕЗ `--proxy-server=`.**
-> Причина падения RuTracker — **НЕ сессия FS и НЕ карантин**, а **DNS-запись `vpn.mallexxx.duckdns.org`
+> Прокси-контейнер `vless-proxy` **жив и работает** (логи: `tunneling request ... via vpn.mallexxx.duckdns.org:443`).
-> указывает на домашний IP `90.189.160.148`** (Ростелеком, Новосибирск) вместо VPS ⇒ VLESS-туннель
+> `PROXY_URL=socks5://vless-proxy:1080` в env FS есть, но **к Chrome не применяется** — в командной строке
-> фактически не работает, трафик выходит через дом. Подробности — раздел «КОРЕНЬ НАЙДЕН» в конце.
+> Chrome флага `--proxy-server` нет вообще, и контрольный Chrome-запрос **не оставил следа в логе `vless-proxy`**.
-> Карантин снят (`IndexerStatus` = 0), FS чист, бэкап БД сделан — но **RuTracker не заработает,
+> ⇒ Chrome ходит напрямую, выходит с домашнего `90.189.160.148`. Следствие: RuTracker `ERR_TIMED_OUT` → карантин.
-> пока не починен DNS/UPS VLESS**. Диагностику начинать с `getent hosts vpn.mallexxx.duckdns.org`.
+> Диагностику начинать НЕ с карантина и НЕ с сессий, а с: `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`
+⚠️ **Ошибочная версия (VPS + DuckDNS) отвергнута Alex.** Никакого VPS нет — есть контейнер
-указывает на дом, RuTracker не заработает.
+`vless-proxy` на самой Тайге. Логи это подтверждают: контейнер **жив** (`Up 2 days`), туннель
+устанавливается (`tunneling request ... via vpn.mallexxx.duckdns.org:443`), SOCKS5-порты принимаются.
 
-1. **Проверить, жив ли VPS** — нужен его реальный IP. Запись DuckDNS перезаписать на IP VPS.
+🔴 **НАСТОЯЩИЙ ДЕФЕКТ: Chrome FlareSolverr стартует БЕЗ `--proxy-server=` — `PROXY_URL` к Chrome НЕ применяется.**
-2. Проверить, не умер ли DuckDNS-апдейтер **на VPS** (тогда запись «утекла» на домашний апдейтер).
+
-3. После правки DNS — **проверить, что `api.ipify.org` через Chrome FS отдаёт IP VPS**, и только потом
+Доказательство — командная строка живого процесса Chrome в контейнере FS:
-   принимать RuTracker.
+```
+/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 |
+| 2 | след Chrome-запроса в `docker logs vless-proxy` | пусто → Chrome к прокси не обращался |
-| 3 | `sessions.list` + `bb_session` в cookies | только после 0–2 |
+| 3 | `ERR_[A-Z_]+` в Chrome-странице ошибки | `ERR_TIMED_OUT` ≠ капча ≠ CF |
-| 4 | `IndexerStatus` в БД | снимать SQL, тест ПРОДЛЕВАЕТ |
+| 4 | `sessions.list` + `bb_session` в cookies | только после 0–3 |
+| 5 | `IndexerStatus` в БД | снимать SQL, тест ПРОДЛЕВАЕТ |
 
 > 🔴 **Урок:** «прокси настроен (`PROXY_URL` в env)» ≠ «прокси работает». Конфиг верный,
 > сеть `media_net` верная, FS живой — а трафика через туннель нет. Единственное доказательство