[2026-09-28] eagle: family/index.md family/plans/lidarr-artist-watchlist.md family/plans/lidarr-artist-watchlist.md.bak-sibling-20260928 personal/tech/skill-arr-media-stack-setup-additions.md

2026-09-28 23:41:55 +06:00
1 parent d1107a9de1
commit 0f352f3bca
@@ -129,6 +129,51 @@ docker exec transmission sh -c 'cat /config/settings.json'   # → "download-dir
 Плюс Transmission монтирует `/mnt/storage`, Radarr — `/storage` (один хост-путь под двумя именами).
 **Всегда проверять наличие записей в API** (`GET /api/v3/remotepathmapping`), а не то, что записано в доке.

+## 6. 🔴 Прокси в Lidarr: «записан» ≠ «применяется» (2026-09-28, поздний вечер)
+
+**Конфиг-ридбэк ИДЕАЛЬНЫЙ** — `proxyEnabled:true`, `proxyType:"http"`, `proxyHostname:"vless-proxy"`,
+`proxyPort:1081`, `proxyBypassFilter` расширен на все docker-имена стека — **а Lidarr всё равно
+ходит напрямую**:
+
+```
+docker logs lidarr | grep -i proxy
+  [Error] ProxyCheck: Proxy Health Check failed
+```
+
+`artist/lookup` → **403 Cloudflare**, и сама страница ошибки CF выдаёт egress-IP:
+`Your IP: 90.189.160.148` — **домашний аплинк**, не VPS. `docker restart lidarr` **не помог**.
+
+### Диагностическая триада: «прокси настроен неверно» vs «прокси не применяется»
+
+```bash
+# 1. конфиг верный?            GET /api/v1/config/host  → proxyEnabled / proxyType / proxyPort
+# 2. прокси САМ работает?      (из того же контейнера)
+docker exec lidarr sh -c 'curl -s -m 15 -x http://vless-proxy:1081 https://api.ipify.org'  # VPS IP
+docker exec lidarr sh -c 'curl -s -m 15 https://api.ipify.org'                             # домашний IP
+# 3. Lidarr ЕГО ИСПОЛЬЗУЕТ?    ЛОГ — единственный надёжный сигнал
+docker logs lidarr 2>&1 | grep -i proxy     # ProxyCheck failed ⇒ НЕ использует
+```
+
+Если (1) ✅ и (2) ✅, а (3) даёт `ProxyCheck failed` — **конфиг инертен**.
+
+- **Подозреваемый №1: `proxyBypassLocalAddresses: true`.** `api.lidarr.audio` резолвится в
+  Cloudflare-IP; эвристика «локальный адрес» может его проглотить. Проверить с `false`.
+- **Подозреваемый №2: IPv6-цель против IPv4-only прокси.** В контейнере `api.lidarr.audio` даёт
+  `2606:4700:...` (AAAA), а `vless-proxy:1081` — только IPv4. CONNECT к v6-цели падает, и
+  .NET-клиент **молча откатывается** на прямое соединение.
+  Проверка: `curl -x http://vless-proxy:1081 -6 https://api.lidarr.audio/...`
+- **Подозреваемый №3: `proxyType:"socks5"` + порт `1080`** — обойти специфику HTTP-CONNECT.
+
+> 🔴 **`GET /api/v1/health` → `[]` НЕ значит «сервис здоров».** Lidarr пишет провал `ProxyCheck`
+> **только в лог** — в health-API он не попадает. `health: []` сосуществовал с жёстким `403` на
+> каждом вызове метаданных. **Проверять живым `artist/lookup` + `docker logs | grep`, не `health`.**
+
+> 🔴 **Обобщённое правило для этого хоста:** любой сервис, который ходит в интернет сам
+> (Lidarr → SkyHook, FlareSolverr → Chrome), по умолчанию выходит через **домашний аплинк**
+> (`90.189.160.148`). `curl api.ipify.org` **на хосте Тайги** возвращает домашний IP — VPS-выход
+> существует **только** за `vless-proxy`. ⇒ «прокси настроен» бессмысленно; доказательство одно:
+> **отличается ли egress-IP этого сервиса от `90.189.160.148`**.
+
 ## Связанные заметки

 - [[personal/plans/lidarr-taiga-and-indexer-unblock]] — план, из которого выросли эти находки