[2026-09-15] eagle: family/how-to/truenas-infrastructure.md family/plans/reverse-xray-3xui-kraken.md personal/tech/xray-outbound-subscription-3xui.md

family/how-to/truenas-infrastructure.md

@@ -141,6 +141,8 @@ TrueNAS использует **NFSv4 ACL**, а не стандартный POSIX
 | ser2net ⛔ | ghcr.io/jippi/docker-ser2net | 502 | **ПОГАШЕН 2026-09-14** — spare-master, конфликт порта с mbusd |
 | cups-splix | cups-splix | 631 | принтер |
 | xray-admin | ghcr.io/mhsanaei/3x-ui:latest | 2053 (панель), 10095 (vless-ws), 443 (sub) | vpn-panel.mallexxx.duckdns.org, vpn.mallexxx.duckdns.org |
+
+> 🔴 **`xray-admin`: compose-файл УТРАЧЕН (обнаружено 2026-09-15).** В `/mnt/RED_2TB/docker/xray-admin/` лежат только `x-ui.db`, `-shm`, `-wal`, `system_metrics.gob`. Docker label указывает на `docker-compose.yml`, но файла нет. **Причина (найдено через Zulip DB, `personal/zulip router issues`, id=86681):** 2026-09-01 05:40:08 UTC агент выполнил `docker exec xray-admin rm -f /etc/x-ui/docker-compose.yml` — volume смонтирован как `/etc/x-ui` (bind-mount), поэтому `rm` внутри контейнера снёс файл на хосте, через 1,5 минуты после создания. **Пересоздать контейнер из папки сейчас НЕЛЬЗЯ** — только из `docker inspect`. Подробно и параметры для восстановления: [[family/plans/reverse-xray-3xui-kraken]]. Проверить перед любым `docker compose` по этому сервису.
 | xray-reverse-portal | teddysun/xray:latest | 12345 (SOCKS), 12346 (VLESS-TCP REALITY interconn) | — (см. `personal/tech/xray-reverse-tunnel-kraken-truenas.md`) |
 
 ### cups-splix — принтер Samsung CLX-216x (✅ поднят 2026-08-26; ✅ mDNS-фикс 2026-08-31 завершён)
@@ -463,6 +465,19 @@ arr, caddy, cups, filebrowser, gitea, hermes, immich, inpx-web, inpxer, library,
 - Verified with the local `xray-test-client`: unchanged `user1` returned TrueNAS IP; changing only the client UUID to `kraken-user` returned Kraken IP over both HTTP and HTTPS.
 - Pre/post backups: `/mnt/RED_2TB/docker/backups/xray-per-user-20260902-1200/`.
 
+**Sub-канал (проверено 2026-09-15):**
+
+| Клиент | `subId` | sub-ссылка | Egress |
+|---|---|---|---|
+| `user1` | `68c5cy5n5ui138yh` | `https://vpn-panel.mallexxx.duckdns.org/sub/68c5cy5n5ui138yh` | TrueNAS `90.189.160.148` |
+| `kraken-user` | `f43074a029dc656e` | `https://vpn-panel.mallexxx.duckdns.org/sub/f43074a029dc656e` | Kraken `92.62.70.41` |
+
+- Sub-сервер отдаёт **base64-список** `vless://…` (проверено: HTTP 200, `text/plain`). Пример тела: `vless://ce320965-…@vpn.mallexxx.duckdns.org:443?encryption=none&host=vpn.mallexxx.duckdns.org&path=%2Fvless&security=tls&type=ws#vless-ws-user1`.
+- **`/sub/<subId>` отдаётся БЕЗ авторизации** — любой, кто знает `subId`, получает рабочий ключ. Открытый вопрос безопасности.
+- Панель: `/login` с `admin/admin` → **403** (не подбирать; креды не записаны).
+
+**`vless-space` — подготовлен, НЕ применён (2026-09-15):** третий клиент, чей egress идёт через внешнюю Xray-подписку `profilegrid.net` (10 серверов, `leastPing`). `user1` и `kraken-user` не трогаются. Артефакты собраны и проверены в песочнице, применение в живую БД не выполнено. Полный разбор — [[personal/tech/xray-outbound-subscription-3xui]].
+
 > ⚠️ База `x-ui.db` была **уже настроена** под эту Caddy-интеграцию (inbound vless-ws:10095, subDomain vpn-panel), поэтому панель заработала «из коробки». Бэкап базы/Caddyfile до изменений: `/mnt/RED_2TB/docker/backups/reverse-xray-3xui-20260901-113625/`.
 
 ### `xray-reverse-portal` — Xray reverse portal (TrueNAS, добавлен 2026-09-01)

family/plans/reverse-xray-3xui-kraken.md

@@ -2,6 +2,45 @@
 
 > Создано: 2026-09-01. Цель: проксировать трафик локальных клиентов (сеть TrueNAS 192.168.2.x) через TrueNAS → Kraken → интернет. **Kraken = точка выхода (exit node).** TrueNAS = bridge/контроллер.
 
+## 🔴 2026-09-15: COMPOSE-ФАЙЛ `xray-admin` УТРАЧЕН — восстановлен из `docker inspect`
+
+**Факт (проверено по Zulip DB, `personal/zulip router issues`, сообщение `id=86681`, 2026-09-01 05:40:08 UTC):**
+
+Compose-файл был создан 1 сентября и **уничтожен через 1,5 минуты после создания** — самим агентом:
+
+```bash
+# сообщение 86681, 2026-09-01 05:40:08 UTC
+docker exec xray-admin rm -f /etc/x-ui/docker-compose.yml
+```
+
+**Обоснование агента (сообщение 86678, дословно):**
+> «Обратил внимание: в `/etc/x-ui/` появился `docker-compose.yml` — это мой загруженный файл попал в volume (он смонтирован в `/etc/x-ui`). Не страшно, но лучше убрать его из `/etc/x-ui` (не должен лежать в контейнере).»
+
+**Почему это снесло файл на хосте:** volume `/mnt/RED_2TB/docker/xray-admin` смонтирован в контейнер как `/etc/x-ui` — это **bind-mount**, не копия. `rm` внутри контейнера удалил реальный файл на TrueNAS.
+
+**Хронология (из Zulip):**
+
+| Время (UTC) | Событие |
+|---|---|
+| 05:38:31 | Compose собран в `/tmp/xray-admin-compose.yml`, залит `scp` → `/mnt/RED_2TB/docker/xray-admin/docker-compose.yml` |
+| 05:38:58 | `docker compose up -d` — контейнер поднялся, панель HTTP 200 |
+| 05:39:56 | Агент заметил compose «внутри» контейнера (это тот же файл через bind-mount) |
+| **05:40:08** | **`rm -f /etc/x-ui/docker-compose.yml` — файл уничтожен на хосте** |
+| 05:40:45 | В доке зафиксировано «всё чисто», потеря не замечена |
+
+**Диагностика 2026-09-15 (три пустых проверки):**
+1. `ls /mnt/RED_2TB/docker/xray-admin/` → только `system_metrics.gob`, `x-ui.db`, `x-ui.db-shm`, `x-ui.db-wal`
+2. `docker exec xray-admin sh -c "ls /etc/x-ui/ | grep -i compose"` → пусто
+3. `find /mnt/RED_2TB/docker -maxdepth 2 -name "*compose*" | grep -i xray` → пусто
+4. В бэкапах тоже нет: `backups/reverse-xray-3xui-20260901-113625/` содержит только `xray-admin/x-ui.db`, `caddy/Caddyfile`, `docker-inventory.txt`
+
+> ⚠️ **Docker label врёт о наличии файла.** `docker inspect xray-admin --format '{{index .Config.Labels "com.docker.compose.project.config_files"}}'` → `/mnt/RED_2TB/docker/xray-admin/docker-compose.yml`. Label пишется при создании контейнера и **не обновляется** при удалении файла. Наличие в label ≠ наличие на диске.
+
+> 🔴 **ГЛАВНЫЙ ПИТФОЛЛ (повторяемый):** никогда не выполнять `rm`/`mv`/правку файлов внутри контейнера, чей volume — bind-mount на хостовую папку с compose-файлом. Volume `xray-admin` = `/etc/x-ui`, и там же лежит `docker-compose.yml`. Команда «почистить контейнер» уничтожает конфиг деплоя.
+> **Правильно:** если хочется убрать compose из контейнерного view — это невозможно без удаления с хоста, т.к. это один и тот же файл. Ничего не делать. Либо держать compose **вне** смонтированной папки.
+
+**Восстановление:** только из `docker inspect` (см. ниже). Параметры: образ `ghcr.io/mhsanaei/3x-ui:latest`, `container_name: xray-admin`, `hostname: xray-admin`, `restart: unless-stopped`, `TZ=Asia/Novosibirsk`, `PUID=950`, `PGID=950`, volume `/mnt/RED_2TB/docker/xray-admin:/etc/x-ui`, `ports: 54321:54321`, сеть `caddy_default` (external). Эквивалент: `docker run` с теми же флагами.
+
 ## Архитектура
 
 ```text

personal/tech/xray-outbound-subscription-3xui.md

@@ -162,3 +162,41 @@ curl подписки → base64 -d → build_template.py → пересобра
 - [[family/how-to/truenas-infrastructure]] — контейнер `xray-admin`, клиенты, sub-канал
 - [[personal/tech/xray-reverse-tunnel-kraken-truenas]] — reverse-туннель (отдельный механизм)
 - [[family/how-to/vps-qentra]] — удалённый VPS (источник мёртвого `v.qentra.top`)
+
+## 🔴 2026-09-15: попутные находки этой сессии
+
+### 1. `hermes-taiga` ходит НЕ через `xray-admin`, а через `vless-proxy` (мёртвый)
+
+Разбор путаницы «таига настроена через user1?» — **нет**:
+
+| | |
+|---|---|
+| Env `hermes-taiga` | `TELEGRAM_PROXY=socks5://vless-proxy:1080`, `DISCORD_PROXY=socks5://vless-proxy:1080` |
+| Сети `hermes-taiga` | `hermes_taiga_net`, `ha_default` |
+| `vless-proxy` | образ `teddysun/xray:latest`, SOCKS `:1080` + HTTP `:1081`, outbound → **`v.qentra.top:443` (мёртв, VPS удалён)** |
+| Сеть `xray-admin` | `caddy_default` — с `hermes-taiga` **не пересекается** |
+| `user1` | id `ce320965-…` — клиент inbound `in-10095-tcp`, `hermes-taiga` к нему **не обращается** |
+
+**Следствие:** Telegram/Discord у `hermes-taiga` сейчас без сети (цепочка `hermes-taiga → vless-proxy:1080 → v.qentra.top → timeout`).
+
+**Как чинить (обсуждалось, НЕ выполнено):** переписать outbound `/mnt/RED_2TB/docker/vless-proxy/config.json` с мёртвого `v.qentra.top` на живой сервер. 4 поля:
+
+| Поле | Сейчас | Станет |
+|---|---|---|
+| `address` | `v.qentra.top` | `vpn.mallexxx.duckdns.org` |
+| `users[0].id` | `2D9F24C4-21FE-4784-9843-F11C384DA67A` | `ce320965-6956-4759-84bb-7cb71cfc6252` (`user1`) |
+| `tlsSettings.serverName` | `v.qentra.top` | `vpn.mallexxx.duckdns.org` |
+| `wsSettings.headers.Host` | `v.qentra.top` | `vpn.mallexxx.duckdns.org` |
+| `wsSettings.path` | `/qentra` | `/vless` |
+
+Порт `443`, `security: tls`, `network: ws` — без изменений. `xray-admin` **не имеет SOCKS-входа** (он сервер) — поэтому `vless-proxy` нужен как локальный клиент-мостик, его нельзя просто «выкинуть».
+
+> ⚠️ Побочный эффект: трафик пойдёт `vless-proxy → vpn.mallexxx.duckdns.org:443 → Caddy → xray-admin` на том же хосте → egress = IP TrueNAS `90.189.160.148`. Петля внутри TrueNAS.
+
+### 2. Compose-файл `xray-admin` утрачен — подробный разбор
+
+См. [[family/plans/reverse-xray-3xui-kraken]] (шапка). Кратко: `rm -f /etc/x-ui/docker-compose.yml` внутри контейнера 2026-09-01 05:40:08 UTC снёс файл на хосте через bind-mount. Восстанавливать из `docker inspect`.
+
+### 3. «Auto» в Xray-контейнере = только скрипт
+
+Ещё раз зафиксировано: **Xray-бинарник подписки не умеет.** Умеет один/несколько статических outbound'ов + `routing.balancers`. Авто-подписка (`update_interval`) — только GUI-клиенты (Happ/v2rayN/NekoBox) **или** штатная таблица `outbound_subscriptions` 3x-ui через панель. Для docker-контейнера (`hermes-taiga`, `vless-proxy`) «auto» = cron-скрипт.