[2026-09-28] eagle: personal/tech/flaresolverr-taiga.md
This commit is contained in:
Alexey Martemyanov committed
1 parent
0225381a5f
commit
cca59799dd
1 file changed
+58
-17
@@ -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 живой — а трафика через туннель нет. Единственное доказательство
|
||||
|
||||
Reference in new issue
Block a user