]*>.*?`** (заголовки разделов). Это критично: без этого блоки с ``-заголовком (раздел «Правовая подготовка» и «Огневая подготовка») давали 0 карточек, вопросы терялись целиком. Убирание заголовков заставляет обрабатывать каждый `` единообразно (как в блоках без заголовка).
+- `_scan(inner)` — токенизация текста/тегов; каждый `N. `-ответ → `cur["a"]`; ``-цифра → `cur["c"]` (правильный); strong без номера при пустых ответах → мержится в текущий вопрос.
+- `_btn(num, text, correct)` — инлайн `onclick`, красящий красный/зелёный.
+
+## Pitfalls
+
+1. **Блоки с ``-заголовком**: если не вырезать `
.../p>` первым шагом, такие блоки дают 0 карточек (вопросы теряются). Симптом: в собранном файле `cards` вдвое меньше (~86 вместо ~180).
+2. **Скрытие номера**: не выводить `` в разметку — только `data-correct` на кнопке.
+3. **`grep -c` по однострочному HTML** вернёт 1 (файл — одна гигантская строка), даже если совпадений сотни. Считать через `python` (`s.count(...)`), не через grep.
+4. **Файл после генерации большой** (~894 КБ): на каждую кнопку инлайн-`onclick` — приемлемо для статики.
+5. Node парсеры/`node --max-old-space-size` тут НЕ нужны — на больших минифицированных Tilda-файлах node легко падает в OOM (heap limit) при самопальных токенизаторах. Python + `str.find`/`regex` надёжнее и не жрёт память.
+
+## Деплой в Eagle Dashboard Pages
+
+- Механика + права — в `personal/projects/personal-os/eagle-dashboard.md` (секция «Как добавить страницу в Pages»).
+- Скопировать `bilety.html` в `/Library/WebServer/Documents/` (root-owned, нужен sudo) → страница подхватывается живьём, рестарт дашборда не нужен.
diff --git a/personal/tech/inter-site-throughput-taiga-to-mac.md b/personal/tech/inter-site-throughput-taiga-to-mac.md
new file mode 100644
index 00000000..76251527
--- /dev/null
+++ b/personal/tech/inter-site-throughput-taiga-to-mac.md
@@ -0,0 +1,59 @@
+---
+title: Межсайтовая пропускная способность — TrueNAS (Taiga) ↔ Mac/TV
+created: '2026-09-02'
+updated: '2026-09-02'
+type: tech
+namespace: personal
+tags: [network, truenas, throughput, rtt, tcp, jellyfin, xray, bottleneck]
+related:
+ - "[[xray-reverse-tunnel-kraken-truenas]]"
+ - "[[../how-to/truenas-infrastructure]]"
+---
+
+# Межсайтовая пропускная способность — TrueNAS ↔ Mac/TV
+
+> Контекст: после восстановления стека медиа/права на Taiga (см. `family/documents/vault-sync/2026-09-02-restore-privilege-scope.md`) Jellyfin запустился и файлы читаются, но **прямое воспроизведение с ТВ «грузится кусками»**. Диагностика 2026-09-02 установила: это **НЕ транскодинг и НЕ тариф**, а ограничение сети между двумя физически разнесёнными локальными сетями.
+
+## Cетевой layout (фактический)
+
+| Узел | LAN | Шлюз | Egress IP | Провайдер |
+|---|---|---|---|---|
+| Mac / TV (дом) | `192.168.1.57` | `192.168.1.1` | динамический | ТТК (92.62.x / 185.20.x) |
+| **TrueNAS (Taiga)** | `192.168.2.197` | `192.168.2.2` | `90.189.160.148` (`mallexxx.duckdns.org`) | Ростелеком (194.186.x → 217.107.x) |
+
+**Ключевое:** TrueNAS НЕ в локальной сети Мака/ТВ. Трафик ТВ→Jellyfin идёт целиком по интернету между двумя разными операторами/домохозяйствами.
+
+## Замеры (2026-09-02)
+
+### Задержка / маршрут
+- RTT Mac → TrueNAS: **~104 мс**.
+- Traceroute: хопы 1–7 моего ISP (ТТК) — **3–6 мс** ✅ чисто. **На хопе 8 (`194.186.168.65`) прыжок до ~54 мс** — межоператорская передача в сеть Ростелекома, где живёт TrueNAS. Хоп 10 (`217.107.108.41`) ~60 мс.
+- Этот +50 мс — физическое/пиринговое расстояние между региональными операторами, НЕ петля. Перенастройка маршрута полностью RTT не уберёт.
+- Примечание: **дальние сети в целом** (8.8.8.8 ~100 мс) у ТТК тоже идут через ~50 мс переход — деградация на стороне выхода, а не только до TrueNAS.
+
+### Пропускная способность (распутали про «тариф»)
+- Mac download с CDN: **~78 Мбит/с** (линия Мака в порядке).
+- **TrueNAS сторона**: NIC `enp3s0` 1 Gb/s, до шлюза 0.2–0.8 мс 0% loss. NAS→Cloudflare: **download ~184 Мбит/с, upload ~117 Мбит/с**. → **Лимита тарифа на TrueNAS НЕТ.**
+- Mac → TrueNAS (SCP 200MB): **~28 Мбит/с** одним потоком.
+- Mac → TrueNAS, **4 параллельных SCP потока: ~28 → ~51 Мбит/с** (агрегат растёт с параллельностью).
+
+## Вывод (важно)
+
+Ограничение — **НЕ по суммарной полосе транзита, а по одному TCP-потоку из-за высокого RTT (~104 мс) + BDP / congestion-window**. Доказательство: 4 потока дали рост ×1.8 (28→51) — при жёстком лимите линии рост не произошёл бы.
+
+**Почему Jellyfin дёргается прямо:** Jellyfin отдаёт видео одним последовательным HLS-потоком (один TCP). Один поток душится RTT-штрафом до ~28–50 Мбит, а BluRay-файл в пиках идёт к 20+ Мбит → с 104 мс RTT сегменты не успевают → стоп-кары. Файл The.Jungle.Book.1967.720p.BluRay ≈ 7.1GB/~78мин → средний ~12 Мбит/с, пики выше.
+
+## Факты ИЗ ЛОГОВ Jellyfin (подтверждают: транскодинг не причина в этих тестах)
+- Реальный транскод с `libx264` + reduce был только на "Snatch" (тестовые короткие старты каждые ~5 с — клиент переподключался).
+- "Один день в Стамбуле"/"Рождественские хроники" — ремукс `-codec:v:0 copy` в HLS (не перекодирование), стоп на ~2-3 сек.
+- В моменте (пока ТВ крутит 720p) — ffmpeg-дочерних процессов нет, папка transcodes пуста → **прямой stream/direct, транскодинг не идёт**.
+
+## Решение / направление
+1. **Правильное лекарство** (не мультипоток ради мультипотока, а либо снижение латентности, либо запас по битрейту под single-flow): лимит транскода ~12–18 Мбит, ЛИБО гнать трафик ТВ→TrueNAS через **xray tunnel** (`vpn.mallexxx.duckdns.org`, смотри `[[xray-reverse-tunnel-kraken-truenas]]`) вместо прямого межоператорского пути.
+2. Jellyfin **не умеет** штатно разбивать один плейбек на параллельные TCP. Параллельность (28→51 Мбит) достижима только поднятием файла способом «качалка в N коннектов» + прокси, либо через туннель.
+3. Задача замера скорости через **`xray-test-client`** контейнер (teddysun/xray, SOCKS `127.0.0.1:1080`) — НЕ завершена: команда замера была заблокирована юзером; способ/endpoint (стучались на внутренний `192.168.2.197:8096`) предложен неверно.
+
+### Endpoint-факты для замера туннеля
+- Локальный тестовый xray-клиент на Mac: контейнер **`xray-test-client`** (`127.0.0.1:1080->1080/tcp`), конфиг `/Users/admin/xray-test/config.json`, оставлен на `kraken-user`.
+- Per-user egress на `vpn.mallexxx.duckdns.org`: `user1` → direct TrueNAS `90.189.160.148`; `kraken-user` → reverse через Kraken `92.62.70.41`.
+- Конфиг клиента лежит на Mac отдельно (не в vault); бэкап direct-клиента: `/Users/admin/xray-test/config.json.bak-user1-direct-20260902-1227`.
diff --git a/personal/tech/mac-print-shared-services.md b/personal/tech/mac-print-shared-services.md
new file mode 100644
index 00000000..bab8cc72
--- /dev/null
+++ b/personal/tech/mac-print-shared-services.md
@@ -0,0 +1,174 @@
+---
+type: tech
+topic: print
+tags:
+ - print
+ - printer
+ - samsung
+ - cups
+ - macos
+created: 2026-08-26T00:00:00.000Z
+updated: '2026-09-02T00:00:00.000Z'
+---
+
+# Печать и общие сервисы (Mac + сеть)
+
+Проверка службы печати 2026-08-26: «не видит принтер с телефона».
+
+## Состояние на момент проверки
+
+На Mac (admin, macOS 26.6.1, arm64) в системе зарегистрированы два принтера:
+
+| Принтер | Способ подключения | Статус |
+|---|---|---|
+| **Samsung CLX-216x** | Сетевой `ipp://192.168.2.197/printers/Samsung_CLX-216x_Series`, драйвер Generic PostScript | не pингуется в текущей сети |
+| **Samsung M2020 Series** (SEC84251974A6B3) | AirPrint `dnssd://…_ipp._tcp.local.`, дефолтный, PPD Samsung M2020 Series-AirPrint | не отвечает по сети |
+
+Системный дефолт: `Samsung_M2020_Series__SEC84251974A6B3_` (idle, enabled 2026-07-29).
+
+## Ключевые находки
+
+- **CUPS слушает только локально**: в `/etc/cups/cupsd.conf` → `Listen localhost:631` + `Listen /private/var/run/cupsd`. Наружу (по сети, для AirPrint) служба печати НЕ отдаётся.
+- **Шеринг печати выключен** (`SharePrinters` в cupsd.conf закомментирован/неактивен; в `system_profiler` оба принтера `Shared: No`, `System Printer Sharing: No`).
+- **Порт 631 наружу закрыт**: `nc -z 192.168.2.197 631` → closed.
+- Сеть Мака — `192.168.6.x` (адрес `192.168.6.173`, шлюз `192.168.6.1`). Принтер прописан в подсети `192.168.2.x`.
+
+## ⚠️ Важное наблюдение (пересечение с TrueNAS)
+
+Адрес **`192.168.2.197` — это TrueNAS** (truenas_admin, SSH через `mallexxx.duckdns.org`), НЕ сам принтер. Samsung CLX-216x физически подключён к TrueNAS (USB) и печатается через docker-контейнер **cups-splix** (драйвер splix). Запись `ipp://192.168.2.197/printers/Samsung_CLX-216x_Series` в системе Мака — результат обнаружения расшаренной печати TrueNAS на этом адресе.
+
+## ✅ НаСТОЯЩИЙ ДИАГНОЗ (2026-08-26, подтверждено SSH на TrueNAS)
+
+**Корень проблемы: cups-splix контейнер НЕ запущен на TrueNAS.**
+- На TrueNAS **нет ни одной работающей службы печати**: `lpstat`/`cupsd` в системе не установлены, порт 631 закрыт (и локально, и снаружи).
+- Ни одного docker-контейнера по печати в `docker ps` нет (cup/sprint/ipp — пусто). **Официальный список контейнеров** (docker ps -a): immich(redis/server/postgres), modbus-bridge, mbusd, zigbee2mqtt, webdav, vless-proxy, hermes-taiga, portainer(-mcp), homeassistant, caddy, watchtower, transmission, syncthing, ser2net, rclone, nodered, mosquitto, library, inpxer, inpx-web, gitea, filebrowser. **`cups-splix` отсутствует.**
+- Образ `cups-splix` не собран (`docker images | grep cups|splix` → пусто).
+
+### Конфиг cups-splix (цел, на месте)
+
+Папка `/mnt/RED_2TB/docker/cups/`: `Dockerfile`, `docker-compose.yml`, `docker build.txt`, `data/`, `cache/`, `spool/`, `uld/`.
+
+**docker-compose.yml:**
+```yaml
+services:
+ cups-splix:
+ image: cups-splix
+ container_name: cups-splix
+ command: ["/usr/sbin/cupsd", "-f"]
+ network_mode: host
+ privileged: true
+ volumes:
+ - /dev/bus/usb:/dev/bus/usb
+ - /mnt/RED_2TB/docker/cups/data:/etc/cups
+ - /mnt/RED_2TB/docker/cups/cache:/var/cache/cups
+ - /mnt/RED_2TB/docker/cups/spool:/var/spool/cups
+ restart: unless-stopped
+```
+
+**Dockerfile** (debian:12-slim): ставит `cups-daemon cups-client cups-common printer-driver-splix avahi-utils dbus usbutils nano`, пользователь `cupsadmin:admin` (в группе lpadmin), `EXPOSE 631`, CMD `cupsd -f`.
+
+**Как поднять** (из доки, раздел «Сборка»):
+```
+cd /mnt/RED_2TB/docker/cups/
+docker build -t cups-splix .
+docker compose up -d # или docker run из build.txt
+# проверить: порт 631 открылся, принтер подцепился
+```
+
+### Почему выпал
+`.ix-apps` вызов docker data-root при пересоздании пула НЕ переносился → образы (=кеш) потеряны, перекачиваются заново. `cups-splix` — локальная сборка, она не «перекачается», нужно пересобрать. Конфиги целы.
+
+## ✅ РЕЗОЛЮЦИЯ (2026-08-26, выполнено)
+
+**cups-splix поднят, печать восстановлена.** Шаги, фактически выполненные на TrueNAS:
+
+```bash
+cd /mnt/RED_2TB/docker/cups
+docker build -t cups-splix . # образ собран успешно (~225s), splix установлен
+docker compose up -d # контейнер запущен
+docker exec cups-splix lpstat -p -d # printer Samsung_CLX-216x_Series ... idle, enabled
+docker exec cups-splix lpstat -a # ... accepting requests
+nc -z 192.168.2.197 631 # 631 OPEN снаружи
+```
+
+- **Принтер подключён по USB к TrueNAS**: `usb://Samsung/CLX-216x%20Series?serial=9566BAGQ213134Z.&interface=1` (Bus 002 Device 008, `04e8:3425` Samsung CLX-216x).
+- CUPS-конфиг сохранился в `/mnt/RED_2TB/docker/cups/data` (это `/etc/cups`) → принтер прописан и подцепился после рестарта сам.
+- Образ собрался без ошибок → **раньше его просто не запускали собирать** (не поломка Dockerfile), а потеряли при восстановлении стека вместе с `.ix-apps`.
+- Порт 631 открыт наружу → печать доступна по сети на `192.168.2.197:631`.
+
+**Условие для телефона:** телефон должен быть в сети `192.168.2.x` (той же, что и TrueNAS), чтобы увидеть принтер. Если телефон в другой подсети (напр. `192.168.6.x`) — это сетевой вопрос, не печатный.
+
+Полный рецепт на будущее продублирован в `truenas-infrastructure.md` → раздел «Печать / cups-splix».
+
+## ✅ Печать PDF извне сети TrueNAS (когда клиент НЕ в подсети, `mallexxx.duckdns.org:631` закрыт)
+
+Когда принтер физически в TrueNAS, а клиент НЕ в подсети `192.168.2.x` → прямой IPP до `:631` закрыт. Печатать через SSH `mallexxx.duckdns.org` в контейнер `cups-splix` (проверено 2026-09-02):
+
+```bash
+# 1. Залить PDF на TrueNAS
+scp -i ~/.ssh/id_rsa file.pdf truenas_admin@mallexxx.duckdns.org:/tmp/evrika_print.pdf
+# 2. Скопировать внутрь контейнера
+ssh -i ~/.ssh/id_rsa truenas_admin@mallexxx.duckdns.org \
+ 'docker cp /tmp/evrika_print.pdf cups-splix:/tmp/evrika_print.pdf'
+# 3. Отправить в очередь (CUPS сам конвертит PDF→vnd.cups-postscript→pstoqpdl; gs+pdftops в контейнере есть)
+ssh -i ~/.ssh/id_rsa truenas_admin@mallexxx.duckdns.org \
+ 'docker exec cups-splix lp -d Samsung_CLX-216x_Series -o media=A4 /tmp/evrika_print.pdf'
+```
+
+**Проверка успеха:** `lpstat -W completed | grep ""` (искомый job появляется строкой `Samsung_CLX-216x_Series- ... <дата>`), очередь пуста (`lpstat -o`), принтер `idle … Rendering completed`. access_log контейнера: `Create-Job successful-ok` + `Send-Document successful-ok`.
+
+**Важно:** `lp -d file.pdf` сам создаёт job (`Create-Job`) — НЕ комбинировать с отдельным print-job-id, иначе `client-error-not-found`. PPD CLX-216x принимает `application/vnd.cups-postscript` (`*cupsFilter: 0 pstoqpdl`), поэтому чистый PDF конвертится автоматически. Job в `lpstat -W completed` показывает владельцем `root` (выполняется через docker по SSH) — это нормально.
+
+Полный шаги: залить → `docker cp` → `docker exec cups-splix lp` → проверить `completed` → убрать временные файлы (`/tmp/...` на хосте и внутри контейнера).
+
+## ⚠️ ТОПОЛОГИЯ ИЗМЕНЕНА (2026-08-31) — TrueNAS больше НЕ в локальной сети
+
+TrueNAS ушла из локальной сети и доступна **только** через публичный DNS `mallexxx.duckdns.org` (внешка `90.189.160.148`). Локальный `192.168.2.197` физически **недостижим** (пинг 100% потеря) — TrueNAS не в `192.168.2.x` и не в сети телефона.
+
+**Подтверждено SSH на TrueNAS (2026-08-31):**
+- `cups-splix` **Up** (4 days), принтер `Samsung_CLX-216x_Series` **idle / enabled / accepting requests**.
+- Принтер подключён по USB: `usb://Samsung/CLX-216x%20Series?serial=9566BAGQ213134Z.&interface=1`.
+- CUPS слушает **`0.0.0.0:631`** (все интерфейсы, `network_mode: host`).
+- CUPS config: `Port 631`, `WebInterface Yes`, `ServerAlias *` (раздел `cupsd.conf`).
+- **Снаружи `mallexxx.duckdns.org:631` — CLOSED** (наружу не проброшен).
+
+**Реальная картина печати:**
+- **Samsung Mobile Print (app)** — печатает. У приложения адрес вписан вручную/закэширован (не обязательно `192.168.2.197`).
+- **Штатная Android print service** — добавлял вручную `ipp://192.168.2.197:631/printers/Samsung_CLX-216x_Series` → **«недоступен»**. Ожидаемо: TrueNAS ушла из локальной сети, а адрес `192.168.2.197` из телефона недостижим.
+
+**Вывод:** «недоступен» в штатной службе — НЕ баг настройки и НЕ проблема порта. Это прямое следствие того, что CUPS-хост (TrueNAS) физически вне сети телефона: локального пути нет, а публичный `mallexxx.duckdns.org:631` закрыт. Android-штатная служба не умеет удалённый IPP через интернет без открытого наружу порта.
+
+**ОТКРЫТЫЙ ВОПРОС** (не разобран, нет доступа к настройкам приложения): по какому именно адресу Samsung Mobile Print реально шлёт печать, раз 631 снаружи закрыт. Гипотезы: (1) приложение кэширует соединение с времён, когда TrueNAS была локально; (2) используется другой публичный путь (реверс-прокси Caddy на ином порту/HTTPS), не записанный в доках. Для полного разбора нужен адрес/хост из настроек принтера внутри Samsung Mobile Print. Отмечено: **лог CUPS access_log показывает, что практически вся печать шла с IP `192.168.2.141`** (26-30 авг, POST /printers/... Print-Job → 200 successful-ok) — т.е. Samsung Mobile Print ходил по локальному IP, когда TrueNAS ещё была в сети. Похоже, приложение реально кэшировало локальное соединение.
+
+## ✅ НАСТОЯЩИЙ МЕХАНИЗМ «недоступен» в Android print service (2026-08-31, подтверждено ipptool)
+
+Дополнительная проверка **внутри контейнера** (`ipptool -tv` → CUPS) дала ключевой факт:
+
+- **`printer-dns-sd-name = no-value`**
+- В контейнере cups-splix **НЕ запущен `avahi-daemon`** (процессы: только `cupsd`; `ps aux | grep avahi` — пусто). Пакеты `dbus` + `avahi-utils` в образе есть, но **`avahi-daemon` не установлен и не стартует**, а CMD — только `cupsd -f`.
+
+**Механика:** Samsung Mobile Print — вендорское приложение, ходит на CUPS **напрямую по IPP** (POST Print-Job по IP) → работает даже без mDNS. **Android штатная служба печати** (Mopria/Default) даже при ручном добавлении по IP затем делает **mDNS/AirPrint-проверку** принтера (`_ipp._tcp` / `_ipps._tcp.local`), чтобы получить `printer-uuid` и capabilities. Если mDNS-анонса нет (`printer-dns-sd-name = no-value`, avahi не запущен) — Android помечает принтер **«недоступен»**, даже если IPP по-IP физически отвечает. Полный ответ CUPS на Get-Printer-Attributes — `successful-ok [PASS]`, принтер idle/accepting/shared — подтверждает: CUPS здоров, всё дело в отсутствии mDNS-анонса.
+
+## ✅ РЕЗУЛЬТАТ (2026-08-31, выполнен полностью): mDNS поднят через avahi-daemon
+
+**Место:** папка `/mnt/RED_2TB/docker/cups/`.
+
+**Выполнено и проверено (все шаги):**
+- ✅ **Бэкап** конфига: `/mnt/RED_2TB/docker/cups/backup_20260831-003619.tar.gz` (создан внутри контейнера `tar` → `docker cp`; md5 `0e303a6a57ae767d1e14cd72c8039fe4`). Внутри: `/etc/cups`, `/var/spool/cups`, `/var/cache/cups`. Дубль в `/tmp/cups_backup_.tar.gz` на хосте.
+- ✅ **Новый `Dockerfile`** (в cups/, заменил старый): в apt добавлен **`avahi-daemon`** + `procps`; добавлен `COPY entrypoint.sh /entrypoint.sh`; `ENTRYPOINT ["/entrypoint.sh"]` вместо `CMD ["cupsd","-f"]`.
+- ✅ **`entrypoint.sh`** (в cups/): стартует `dbus-daemon --system --fork`, затем `avahi-daemon --no-drop-root --syslog` в фоне, затем `exec cupsd -f`.
+- ✅ **`cupsd.conf`**: `Browsing Off` → `Browsing On` + `BrowseLocalProtocols dnssd` (бэкап `cupsd.conf.pre-avahi`). Валидность: `/usr/sbin/cupsd -t` → OK.
+- ✅ **Образ**: собрал `cups-splix-new`, затем пометил **старый образ как `cups-splix-old`** (откат), а новый — как `cups-splix`.
+- ✅ **Контейнер пересоздан**: `docker stop cups-splix && docker rm cups-splix && docker compose up -d`.
+
+**Проверка mDNS (всё сошлось):**
+- `ps aux`: запущены `cupsd` (PID1), `dbus-daemon --system`, `avahi-daemon: running [truenas.local]`.
+- `ipptool` Get-Printer-Attributes: `printer-dns-sd-name` больше не `no-value` → теперь анонс зарегистрирован.
+- `avahi-browse -rt -p _ipp._tcp`: на физическом интерфейсе **`;enp3s0;IPv4;`** по адресу **`192.168.2.197;631`** с TXT **`mopria-certified=1.3`**, `pdl=application/pdf,...`, `rp=printers/Samsung_CLX-216x_Series`, `UUID=68e3b8c6-...`.
+- CUPS по-прежнему слушает `0.0.0.0:631`, принтер `idle/enabled/accepting`.
+
+**Pitfall (важно):** НЕ использовать **`docker restart cups-splix`** после правки конфига — он убивает avahi-daemon (становится ``), dbus тоже пропадает. Подъём ТОЛЬКО полным пересозданием: **`docker stop cups-splix && docker rm cups-splix && docker compose up -d`**, чтобы `entrypoint.sh` выполнился с нуля.
+
+**Pitfall (compose):** `docker-compose.yml` в cups/ — `-rw------- root:root` (600), **truenas_admin перезаписать не может** (Permission denied) → compose НЕ менял. Это ок: ENTRYPOINT переопределяет `command`, лишний cupsd не стартует (скрипт сам делает `exec cupsd -f`, аргументы `$@` игнорирует). Если потребуется убрать `command` из compose — править через root/UI.
+
+**Pitfall (бэкап):** `data/ cache/ spool/` под TrueNAS — `drwx------ root:lp` (0700), truenas_admin их напрямую не читает → **бэкап делать ТОЛЬКО через контейнер** (`docker exec ... tar` → `docker cp`), либо через /admin (root).
diff --git a/personal/tech/truenas-nfs4-acl-and-arrmultiuser.md b/personal/tech/truenas-nfs4-acl-and-arrmultiuser.md
new file mode 100644
index 00000000..abba86b1
--- /dev/null
+++ b/personal/tech/truenas-nfs4-acl-and-arrmultiuser.md
@@ -0,0 +1,78 @@
+---
+title: TrueNAS NFS4 ACL repair + cross-container media PUID
+created: 2026-09-02
+updated: 2026-09-02
+type: tech
+namespace: personal
+tags: [truenas, nfs4, acl, midclt, arr, radarr, sonarr, jellyfin, transmission, docker]
+related:
+ - "[[truenas-zfs-panic-recovery]]"
+ - "[[arr-stack-taiga]]"
+---
+
+# TrueNAS NFS4 ACL repair + cross-container media PUID
+
+> Hard-won lessons from the 2026-08-31/09-01/09-02 TrueNAS restore-incident remediation. Mirror of skill `truenas-nfs4-acl-and-arrmultiuser`. Detailed incident log: `family/documents/vault-sync/2026-09-02-restore-privilege-scope.md`.
+
+## Trigger
+Any "permission denied" / file not readable / git `loose object ... corrupt` / empty Jellyfin library on **TrueNAS SCALE** (acltype=nfsv4) after a zfs restore, OR wiring Prowlarr/Radarr/Sonarr/Jellyfin/Transmission so container-written files are readable by other containers.
+
+## Core facts
+- TrueNAS SCALE uses **NFSv4 ACL**, not plain POSIX. `ls -la` shows a POSIX mask that can mislead.
+- Read real ACL: `midclt call filesystem.getacl `; write: `midclt call filesystem.setacl`.
+- **`truenas_admin` is FULL_ADMIN in midclt** → can chown/setacl without passwordless root.
+- Web UI ACL editing only works on zfs **datasets**, not arbitrary subdirs under one dataset → use midclt/CLI.
+- Post-restore a tree may be owned by wrong uid (e.g. 921 `transmission`) with files `mode 0000`.
+
+## The two big gotchas
+### 1. setacl takes ONE JSON with `path` INSIDE it
+`midclt call filesystem.setacl /path {…}` → `[EFAULT] Too many arguments (expected 1, found 2)`.
+Correct form:
+```
+midclt call filesystem.setacl '{"path":"/x","uid":950,"gid":950,"acltype":"NFS4","dacl":[...],"options":{...}}'
+```
+Jobs run async → returns a job id; verify `midclt call core.get_jobs` (state `SUCCESS`).
+
+### 2. stripacl does NOT remove DENY; full dacl replacement does
+`options.stripacl:true` reported `SUCCESS` but left the `owner@ DENY` ACE intact. Only passing a **complete dacl array** works — setacl treats it as a full REPLACE of the ACL.
+
+## NFSv4 DENY overrides ALLOW (the corrupt-object trap)
+A file owned by uid 950 carrying `owner@ DENY READ_DATA=True` cannot be read by uid 950 itself. Git then reports `loose object ... corrupt` — this is **ACL, not data damage** (data intact; root reads fine).
+Diagnostic trap: `git fsck` under **root** is clean, but fetch/push under the owning uid fails → ACL, not corruption.
+Broken files often show POSIX `mode 40` (`r--------`); healthy objects `750`.
+
+## Repair / cross-container recipe (linuxserver media stack)
+Goal: all containers run under ONE uid (950) so transmission→radarr/sonarr→jellyfin all read each other's files.
+- transmission: add `PUID=950 PGID=950` to env in `docker-compose.yml`. It mounts `storage`→`/mnt/storage`, download-dir `/mnt/storage/Downloads`.
+- radarr/sonarr/prowlarr/jellyfin compose: add `PUID=950 PGID=950` to each (retain `TZ`).
+- linuxserver s6 images (Entrypoint `/init`, `/etc/s6-overlay`) honor PUID/PGID natively. Default (unset) = runs **root** → creates root-owned files that 950-services can't read → always set PUID/PGID.
+- Recreate from proper folder: `cd /mnt/RED_2TB/docker/ && docker compose up -d` (+`--force-recreate` if env changed). Verify daemon uid via `ps aux` inside container (process as `abc`/950 = applied). NOTE `docker exec id` ≠ daemon uid.
+- Simple datasets: recursive POSIX `chown -R 950:950` + `chmod` under root SUFFICE (ACLs were trivial). Use midclt/ACL only when non-trivial ACEs present (check `filesystem.getacl` → `trivial:true`).
+- Bare git repo with `owner@ DENY` on objects → full dacl replacement recursively (perms JSON like above).
+
+### GOTCHA 3 — root dataset traverse (Permission denied despite clean file ACL)
+After chown-ing all leaf dirs/files to 950, if a service still gets `Permission denied` reading `/storage/Movies/...` (or jellyfin FFmpeg exit 243), check the **root of the dataset** `/mnt/RED_2TB/storage` itself. In the restore it stayed `921:921` with `owner@/group@ ALLOW` but `everyone@ EXECUTE=False`. uid 950 (not owner, not in gid-921-group) falls under `everyone@` → **cannot traverse past the root** into the tree, even though every nested ACL is clean. Fix (root):
+```bash
+chown 950:950 /mnt/RED_2TB/storage
+chmod 750 /mnt/RED_2TB/storage # rwxr-x---: gid 950 = truenas_admin (containers' group) gets r-x traverse
+```
+Kernel needs EXEC (traverse) on EVERY path component. Diagnostic via `setpriv --reuid=950 ... ls` shows `Permission denied` on a dir whose `getacl` looks clean → suspect root/parent traverse. `stat` via root shows clean 770 but uid 950 can't ls.
+
+### GOTCHA 4 — transmission "all torrents No Data Found" after data migration
+If every transmission torrent shows `error 3: No Data Found` right after a container recreate/pool migration:
+- Check: `docker exec -u` fine to read? downloadDir & files present? If files ARE there and readable as uid 950, the error is likely **stale from daemon startup while traverse was blocked** (see GOTCHA 3).
+- `torrent-verify` on a single torrent does NOT clear it. Fix is trivial & non-destructive:
+```bash
+docker restart transmission
+```
+On restart the daemon re-validates → torrents clear (e.g. **254/255 instantly**). Leftover #1 → Verify Local Data in Web UI.
+
+## Docker network persistency (per-service compose)
+- `docker network connect ` is LOST on recreate → declare `` in the service's compose `networks:`.
+- Caddy must co-own a network with its reverse-proxy target. transmission Web UI works because caddy is ALSO in `transmission_default`; radarr↔transmission works because both in `media_net`.
+- `external: true` networks (media_net/caddy_default) aren't created by compose — if they vanish (pool rebuild), `docker network create media_net`.
+
+## Containers / uid summary (as of 2026-09-02, TrueNAS "Taiga")
+- prowlarr/radarr/sonarr/jellyfin: all running, all daemons under **uid 950**, project `arr`.
+- transmission: PUID/PGID=950, in networks `media_net` + `transmission_default` (both external).
+- Radarr/sonarr/jellyfin mount `/mnt/RED_2TB/storage` as `/storage` (NOT `/media` as on Kraken) → set radarr root-folder accordingly.
diff --git a/personal/tech/truenas-zfs-panic-recovery.md b/personal/tech/truenas-zfs-panic-recovery.md
new file mode 100644
index 00000000..9ec6f3c5
--- /dev/null
+++ b/personal/tech/truenas-zfs-panic-recovery.md
@@ -0,0 +1,86 @@
+# TrueNAS — Восстановление ZFS пула при kernel panic (space map corruption)
+
+> Создано 2026-08-17. Зеркало скила `truenas-zfs-panic-recovery`.
+
+## Когда это нужно
+
+Пул TrueNAS не импортируется и вызывает **kernel panic / boot loop**:
+```
+panic - not syncing: zfs: adding existent segment to range tree
+ ZFS: space_map_load / metaslab_activate / zio_dva_allocate → zfs_panic_recover
+```
+Это **повреждение space map (метаданных ZFS)**. НЕ обязательно потеря данных, но структура пула повреждена. Read-write импорт паникует, т.к. читает битые space maps.
+
+## Ключевая идея
+
+**Read-only import НЕ читает space maps и НЕ паникует** (mav/iXsystems: "read-only imports don't even read space maps"). Стратегия: обойти панику → readonly-импорт → выгрузить данные → пересоздать пул.
+
+**Пул НЕ «чинится»** — только выгрузка данных и пересоздание.
+
+## Проверенные шаги (2026-08-17, TrueNAS SCALE 24.10)
+
+### 1. Загрузка без паники — единственный рабочий способ:
+
+**Физически отключить все диски проблемного пула** → boot-pool поднимается, паники нет → дошли до shell/WebUI → **воткнуть диски обратно (горячо)** в те же порты.
+
+**Что НЕ работает (проверено):**
+- Тюнабели в GRUB `zfs.zfs_recover=1 zfs.zil_replay_disable=1` — не помогли
+- `rd.break=pre-mount` и `rd.break` — не помогли
+- `zfsforce=1` — не помогает
+
+### 2. Readonly-импорт (под root):
+
+```bash
+/usr/sbin/zpool import -o readonly=on RED_2TB
+```
+→ `Import was successful, but unable to mount some datasets` — это нормально/ожидаемо.
+
+### 3. Монтирование datasets (2026-08-18: подтверждено под root)
+
+Если корневая ФС readonly мешает создавать mountpoint-ы (`cannot mount '/RED_2TB': failed to create mountpoint: Read-only file system`) — сначала сделать root ФС rw, затем смонтировать всё:
+```bash
+mount -o remount,rw /
+zfs mount -a
+```
+После этого дочерние datasets (`storage`, `backup`, `Photos`, `Edu`, `docker`, `old-bu`, `TimeMachine/guest`, `iocage/*`) видны на `/RED_2TB/*` (все `ro` — readonly; для чтения rsync это ок). Проверка: `df -h /RED_2TB` покажет ~4.6T (НЕ 1.1T родительского), `ls /RED_2TB/storage` не пуст.
+> ⚠️ Монтирование — **только под root**. Под `truenas_admin` `zfs mount -a` даёт `Insufficient privileges`.
+
+### 4. Выгрузка:
+
+```bash
+rsync -aHAX --info=progress2 /RED_2TB/ /mnt/IRONWOLF/ > /tmp/rsync2.log 2>&1 &
+```
+Лучше в tmux. Затем `zpool destroy` + пересоздать пул.
+
+**⚠️ ВАЖНО (2026-08-18): использовать именно `rsync`, НЕ `zfs send | zfs recv`.** `zfs send` на пуле с повреждённой space map падает (`signal received` / `Bad file descriptor` / `IOT (core dumped)`, exit 1) — ZFS не может прочитать данные на лету при stream-чтении. rsync переживает ошибки чтения отдельных файлов (exit 23) и копирует остальное.
+
+**⚠️ Почему первая попытка rsync дала только 355G (разгадано 2026-08-18):** дочерние datasets НЕ были смонтированы, поэтому `/RED_2TB/storage` и др. были пустыми mountpoint-дирами; rsync скопировал только ~355G из родительского dataset. **Сначала смонтировать datasets (`zfs mount -a`), потом rsync** — иначе скопируется лишь несколько сотен ГБ.
+
+**Целевой диск для выгрузки (2026-08-17):** **IronWolf 12TB** подключён к материнке (`sdc`, by-id `WV700FQ5`, 10.9T, свободен/не в пуле) — создай на нём пул-приёмник и копируй туда. Места достаточно (10.9T > 4.6T данных).
+
+**Что на RED_2TB спасать (структура datasets от 2026-08-17):**
+- Критично (пользовательские данные): `storage` (3.24T), `backup` (287G), `Photos` (146G), `Edu` (214G), `TimeMachine` (+`guest`, 277G), `old-bu` (65.5G), `openbsd` (10.2G).
+- Конфиги (если нужно): `docker` (2.98G), `iocage/*` jails (plex, emby, homeassistant, transmission, worker), `ix-apps` (24G).
+- Служебное не критично: `RED_2TB/.system/*`.
+- Итого ~4.6T. Для «100% восстановления с правами»: `rsync -aHAX` или `zfs send | zfs recv`.
+
+### 5. Пул НЕ чинится in-place — только пересоздание
+
+`zpool attach` (идея зеркала на 2 WD2TB) НЕ выполним в текущем состоянии — attach это write → паника. Всегда: спасти → destroy → recreate.
+
+## Подводные камни
+
+- `zpool` не в PATH для zsh-юзеров (`command not found`) — использовать `/sbin/zpool` или `/usr/sbin/zpool`.
+- `zpool import` требует **root** (`some devices require root privileges`). `truenas_admin` НЕ root, sudo просит пароль. **На конец 2026-08-17 это главный блокер** — для импорта/монтирования/выгрузки нужен root (через WebUI-админ, консоль, или включив `PermitRootLogin` в SSH).
+- **WD 2TB#1 (`sdd2` simplex-член RED_2TB) сейчас отключён** — чтобы загрузиться без паники его отсоединяли. RED_2TB импортируется без него (mirror-1 жив), но его данные частично недоступны. Учесть при восстановлении.
+- `zpool import -n RED_2TB` — нелегальный синтаксис без `-F` (`-n` только с `-F`).
+- **НЕ повторять `import -F` настойчиво** — углубляет риск. Сначала readonly.
+- `zpool import -f -F -X` НЕ работает для этой паники (TrueNAS forum).
+- **⚠️ ЛОВУШКА «zfs send -n» (dry-run) НЕ подтверждает права send:** под `truenas_admin` `zfs send -n` возвращал exit 0 без ошибок — обманчиво. Реальный `zfs send` даёт `permission denied`. Дочерние datasets доступны только root (ACL root-only). Не доверять dry-run для проверки прав send.
+- Данные могут показать `Permission denied` если сами данные повреждены (в тяжёлых случаях — частичное восстановление).
+- **Проверить RAM** — на non-ECC (P8H77-V) повреждение space map часто от плохой памяти. memtest.
+- Буквы дисков shift-аются — сверять по by-id/модели, не по буквам.
+
+## Root cause
+
+`adding existent segment to range tree` = openzfs #15030 / #13483. Триггер: члены пула отвалились при перетыкании/перезагрузке, либо RAM corruption (non-ECC).
diff --git a/personal/tech/xray-reverse-tunnel-kraken-truenas.md b/personal/tech/xray-reverse-tunnel-kraken-truenas.md
new file mode 100644
index 00000000..b1cc9b5c
--- /dev/null
+++ b/personal/tech/xray-reverse-tunnel-kraken-truenas.md
@@ -0,0 +1,454 @@
+---
+title: Xray Reverse Tunnel — Kraken ↔ TrueNAS
+created: '2026-09-01'
+updated: '2026-09-02'
+type: tech
+namespace: personal
+tags:
+ - xray
+ - reverse
+ - kraken
+ - truenas
+ - tunnel
+ - networking
+confidence: high
+related:
+ - '[[family/how-to/vps-qentra]]'
+ - '[[family/how-to/truenas-infrastructure]]'
+ - '[[family/how-to/kraken-access]]'
+ - '[[family/how-to/rasputin-router]]'
+downgrade_to_26.4.25: >-
+ portal+bridge BOTH pinned to 26.4.25; required but insufficient by itself.
+verified_fix_2026_09_02: >-
+ Kraken bridge must use Docker network_mode: host; Docker bridge/NAT reset the
+ VLESS reverse mux. REALITY+Vision verified end-to-end with Kraken egress.
+---
+
+# Xray Reverse Tunnel — Kraken ↔ TrueNAS
+
+> **Статус: ✅ ВНЕДРЕНО И ПРОВЕРЕНО END-TO-END (2026-09-02).** TrueNAS SOCKS `:12345` → VLESS Reverse TCP+REALITY+Vision → Kraken → internet работает. HTTP и HTTPS тесты оба вернули выходной IP Kraken `92.62.70.41`. **Истинная причина:** Docker bridge/NAT на Kraken сбрасывал reverse mux; bridge должен работать с `network_mode: host`. Более ранние секции со статусом «не работает» и гипотезами #6612/#6242 сохранены ниже как история диагностики и суперсидированы секцией «Верифицированный фикс».
+> Архитектурное решение: проксировать исходящий трафик локальных клиентов сети TrueNAS через **TrueNAS → Kraken → интернет**.
+
+> ## ✅ ВАЖНО (2026-09-02): `xray-admin` (3x-ui) на TrueNAS — это ОДНОВРЕМЕННО РАБОЧИЙ САМОСТОЯТЕЛЬНЫЙ Xray-VPN-сервер
+> Путаница в вопросе юзера выявила: `vpn.mallexxx.duckdns.org:443` — это **не только reverse-frontend**, а полноценный Xray-сервер со **своим собственным выходом в интернет** (outbound `freedom`/`direct` → сразу через TrueNAS), НЕ зависящий от reverse-канала к Kraken. Это **отдельная фича**, параллельная reverse-туннелю.
+> - **Проверено end-to-end 2026-09-02** (временный xray-клиент с Mac): VLESS+WS через `vpn.mallexxx.duckdns.org:443` → HTTP 200, выход IP `90.189.160.148` = TrueNAS. Контейнеры `xray-admin` (Up 21h) + `caddy` (Up 20h) живы.
+> - Inbound `in-10095-tcp` (VLESS-WS): client id `ce320965-6956-4759-84bb-7cb71cfc6252` (user1), `security: none`, path `/vless`, host `vpn.mallexxx.duckdns.org`. TLS терминирует Caddy → в клиенте `network: ws` + TLS на домен, **без** двойного TLS внутрь.
+> - Полные параметры и pitfalls (вкл. удаление `allowInsecure` в Xray 26.7.28) — в `family/how-to/truenas-infrastructure.md`, раздел `xray-admin`.
+> - Reverse к Kraken — это ОТДЕЛЬНЫЙ механизм (для проксирования локальных клиентов сети TrueNAS через Kraken-egress). Он теперь также внедрён и проверен; см. «Верифицированный фикс». 3x-ui-сервер остаётся независимым рабочим VPN-выходом через TrueNAS.
+
+## Контекст / Почему
+
+- **VPS qentra.top (91.207.28.205) УДАЛЁН** — вся прежняя Xray-инфраструктура на нём (VLESS+REALITY, OpenVPN, WebSocket v.qentra.top) больше не существует.
+- Нужен новый путь для выхода локальных клиентов сети TrueNAS в интернет через другую точку выхода (Kraken).
+- Белый IP есть только у **TrueNAS** (`mallexxx.duckdns.org` = `90.189.160.148`).
+- **Kraken за NAT**, входящие не принимает — только исходящие соединения.
+
+## Принятая схема
+
+```
+Локальные клиенты (сеть TrueNAS, 192.168.2.x)
+ │ шлют трафик на локальный прокси TrueNAS (SOCKS 1080 / HTTP 1081)
+ ▼
+TrueNAS ←── контроллер / bridge (белый IP, mallexxx.duckdns.org), принимает
+ │ TrueNAS заворачивает трафик в reverse-канал
+ ▼ ▲
+Kraken ──┘ держит ИСХОДЯЩИЙ reverse-канал к TrueNAS, отпускает трафик → интернет
+ ▼
+интернет
+```
+
+**Тип решения: Xray `reverse`.** Роли по Xray:
+
+| Узел | Роль | Держит канал? | Выход в интернет? |
+|------|------|---------------|-------------------|
+| **TrueNAS** | bridge/контроллер (inbound `reverse`) | ❌ слушает | ❌ |
+| **Kraken** | outbound reverse-нода + exit | ✅ **исходящий** к TrueNAS | ✅ **да** |
+| **Локальные клиенты** | используют TrueNAS как локальный прокси-шлюз | — | через Kraken |
+
+**Ключевое физическое ограничение:** Kraken за NAT не может принимать входящих. Поэтому канал держит **Kraken исходящим** к TrueNAS. Для передачи клиентского трафика TrueNAS → Kraken используются конструкции `dokodemo-door` + `reverse` + policy-маршрутизация (routing rules). Это чуть сложнее "поставить reverse и всё", конфиг нужен аккуратный.
+
+## ⚠️ Факты, проверенные 2026-09-01 (важно, ломают прежние допущения)
+
+1. **На 443 у TrueNAS НЕ Xray.** Проверено `openssl s_client`: на `mallexxx.duckdns.org:443` отвечает **обычный TLS 1.3 с валидным Let's Encrypt сертификатом для `mallexxx.duckdns.org`** (`issuer=Let's Encrypt/CN=YE2`). Это **Caddy/nginx reverse-proxy**, НЕ Xray REALITY (у REALITY сертификат был бы чужой/поддельный). → Твоя память «на 443 висел xray server» не подтверждается.
+2. **`vless-proxy` на TrueNAS** (контейнер `teddysun/xray:latest`, Up 7 дней):
+ - inbound: SOCKS `0.0.0.0:1080`, HTTP `0.0.0.0:1081` (локально в LAN TrueNAS)
+ - outbound: VLESS+WS+TLS на `v.qentra.top:443`, path `/qentra`, id `2D9F24C4-21FE-4784-9843-F11C384DA67A` — **указывает на УДАЛЁННЫЙ VPS → сейчас мёртвый**.
+ - ⚠️ Используется Hermes-Taiga как SOCKS5-прокси (`vless-proxy:1080`) → **Hermes-Taiga сейчас без рабочего прокси**.
+3. **Kraken→TrueNAS по `mallexxx.duckdns.org`:** открыты **только 22 (SSH) и 443 (HTTPS/TLS)**. `8443/8964/8080/9000` — closed. Порт 443 — TLS (Caddy), не сырой.
+4. **Kraken:** Docker установлен (`/usr/bin/docker`), но демон отвечает медленно/рвёт SSH (проверка `docker ps` не завершилась за 40s). Xray на Kraken **отсутствует** (`which xray` пусто) — нужен Docker-контейнер.
+5. **Связанность Kraken↔TrueNAS по 22/443 — подтверждена** (оба OPEN с Kraken).
+
+## ✅ ВНЕДРЕНО 2026-09-01: 3x-ui на TrueNAS (фронтенд + Docker Compose)
+
+**Решение Alex:** использовать **3x-ui frontend** + **Docker Compose** (управление клиентами через панель), а не ручной Caddy-pass-through с сырым Xray. Это изменило исходный план реализации (Шаг 1 ниже устарел по способу).
+
+### Развёрнут контейнер `xray-admin` (TrueNAS)
+- **Имя контейнера:** `xray-admin` (строго, т.к. Caddyfile резолвит `xray-admin` по имени в docker-сети).
+- **Образ:** `ghcr.io/mhsanaei/3x-ui:latest` (**3.7.0**, Xray **26.7.28**).
+- **Сеть:** `caddy_default` (external) — там же Caddy, чтобы резолвить имя.
+- **Volume:** `/mnt/RED_2TB/docker/xray-admin:/etc/x-ui` (туда лёг существующий `x-ui.db`).
+- **Порт панели:** хостовый `54321 → 54321` (внутри панель реально слушает **2053** — Caddy проксирует `vpn-panel.mallexxx.duckdns.org` → `xray-admin:2053`).
+- **Compose-файл:** `/mnt/RED_2TB/docker/xray-admin/docker-compose.yml` (deployed версия с `TZ=Asia/Novosibirsk`, `PUID/PGID=950`; см. актуальный файл на TrueNAS — отличается от черновика в плане).
+- **Панель доступна:** `https://vpn-panel.mallexxx.duckdns.org/` → **HTTP 200**.
+- **Sub-сервер:** `[::]:443` (path `/sub`), панель `[::]:2053`, inbound `vless-ws:10095` (path `/vless`, host `vpn.mallexxx.duckdns.org`).
+
+### Почему это заработало «из коробки» (важно)
+База `/mnt/RED_2TB/docker/xray-admin/x-ui.db` **уже была настроена под эту Caddy-интеграцию** (раньше 3x-ui уже задумывался на TrueNAS): inbound `vless-ws` port 10095 tag `in-10095-tcp`, subDomain `vpn-panel.mallexxx.duckdns.org`, subPort 443, subScheme https. Caddyfile уже содержал (мёртвые до подъёма) блоки:
+- `vpn.mallexxx.duckdns.org` → `@ws path /vless` → `xray-admin:10095` (WS)
+- `vpn-panel.mallexxx.duckdns.org` → `@sub path /sub/*` → `xray-admin:443` + fallback `xray-admin:2053`
+- LE-сертификаты для этих поддоменов уже выданы.
+
+### 3x-ui поддерживает reverse
+В бинарнике `/app/x-ui` присутствует **`clientReverseTags`** → reverse-настройка реализуема через панель 3x-ui (3.7.0).
+
+### Бэкап (сделан до изменений)
+`/mnt/RED_2TB/docker/backups/reverse-xray-3xui-20260901-113625/` — содержит: `caddy/Caddyfile` (копия из контейнера, 90 строк), `xray-admin/x-ui.db`, `docker-inventory.txt`.
+
+### Мелочь/питфолл
+Скопированный в volume `docker-compose.yml` оказался внутри контейнера `/etc/x-ui/` (т.к. volume смонтирован туда) — удалить лишний файл из контейнера: `docker exec xray-admin rm -f /etc/x-ui/docker-compose.yml`.
+
+## ✅ ВНЕДРЕНО 2026-09-01: Reverse portal (TrueNAS) + bridge (Kraken) — VLESS-WS
+
+После 3x-ui развёрнут полноценный reverse. **Ключевое открытие:** Xray **26.x заменил legacy reverse на "VLESS Reverse Proxy"** — старая схема `reverse.bridges/portals` (Xray-examples/ReverseProxy) **не работает** в этой версии (ошибка `The feature "legacy reverse" has been removed and migrated to "VLESS Reverse Proxy"`). Новая схема: `reverse.tag` в VLESS-клиентах/аутбаундах (примеры — `xtls.github.io/en/document/level-2/vless_reverse.html`, use case "Home Broadband Egress").
+
+### Роли (новая терминология VLESS Reverse)
+- **Internal device (Kraken) = BRIDGE**: VLESS-**outbound** с `"reverse":{"tag":"reverse-in"}` → активно устанавливает канал к TrueNAS; на своей стороне создаётся виртуальный **inbound** `reverse-in`, чей трафик направляется в freedom (интернет).
+- **Public server (TrueNAS) = PORTAL**: VLESS-**inbound** с `"reverse":{"tag":"reverse-out"}` у клиента → создаёт **routable-маутбаунд** `reverse-out`; локальные клиенты (SOCKS) маршрутизируются в `reverse-out`.
+- `reverse.tag` на двух сторонах **не обязаны совпадать** — соответствие через общий UUID соединения.
+
+### TrueNAS — `xray-reverse-portal` (папка `/mnt/RED_2TB/docker/reverse-portal/`)
+compose: image `teddysun/xray:latest` (26.7.28), сеть `caddy_default`, volume `config.json:/etc/xray/config.json:ro`, проброс host **`12345:12345`**.
+`config.json`:
+- inbound `interconn` (:12346, VLESS, ws path `/rvs`, host `vpn.mallexxx.duckdns.org`, client id `a81c3179-312b-4c5e-8a46-6bf3c30c2941`, `"reverse":{"tag":"reverse-out"}`)
+- inbound `local` (:12345, SOCKS `noauth udp:true`) — точка входа для клиентов сети TrueNAS
+- routing: `inboundTag:["local"] → outboundTag:"reverse-out"`
+- outbounds: `freedom` (placeholder — обязателен, иначе `reverse-out` станет default и весь трафик уйдёт в reverse)
+- Порт 12346 НЕ проброшен наружу — к нему обращается Caddy по имени `xray-reverse-portal:12346` в docker-сети.
+
+### TrueNAS — Caddyfile (bind mount `/mnt/RED_2TB/docker/caddy/Caddyfile`)
+Добавлен маршрут в блок `vpn.mallexxx.duckdns.org`:
+```caddy
+@rvs path /rvs
+reverse_proxy @rvs xray-reverse-portal:12346
+```
+Питфоллы: **Caddyfile нельзя править `docker cp`** в контейнер (volume → `device or resource busy`) — править на хосте через `docker run --rm -v /:/host alpine cp /host/tmp/...`. Валидация `docker exec caddy caddy validate --config /tmp/Caddyfile.new` → "Valid configuration". Перезапуск `docker restart caddy` безопасен. Бэкап: `Caddyfile.pre-reverse`.
+
+### Kraken — `xray-reverse-bridge` (папка `/home/kraken/xray-reverse/`)
+compose: image `teddysun/xray:latest`, volume `config.json:/etc/xray/config.json:ro`.
+`config.json`:
+- outbound `direct` = `freedom` + `"finalRules":[{"action":"allow","network":"tcp,udp","ip":["0.0.0.0/0"]}]` (интернет-egress Kraken)
+- outbound `conn` = **VLESS упрощённого стиля** (`settings.address/port/id/encryption/reverse` — НЕ `vnext[]`!) → `vpn.mallexxx.duckdns.org:443` ws `/rvs` `"reverse":{"tag":"reverse-in"}`, security tls, tlsSettings.serverName `vpn.mallexxx.duckdns.org`
+- routing: `inboundTag:["reverse-in"] → outboundTag:"direct"`
+- **Питфолл:** VLESS-outbound с `reverse` должен быть упрощённого стиля. Если через `vnext[]/users[]` → Xray 26.x: `VLESS users: please use simplified outbound's config style to use "reverse"`.
+- `loglevel debug` (для диагностики).
+
+### Reverse-канал: ✅ установлен
+- Kraken `netstat`: `172.24.0.2:... → 90.189.160.148:443 ESTABLISHED`
+- Portal: `::ffff:172.16.1.7:12346 ::ffff:172.16.1.3:52616 ESTABLISHED` (172.16.1.3 = Caddy)
+- Bridge logs: `common/mux: received request for udp:reverse:0`
+
+### ❌ End-to-end payload НЕ работает
+- `curl --socks5 127.0.0.1:12345 http://api.ipify.org` на TrueNAS → `code=000` (прямой curl → 200).
+- Portal логи: `accepted tcp:8.47.69.0:80 [local -> reverse-out]` — запрос ушёл в reverse-out.
+- **Bridge НЕ логирует received для этого TCP-payload** — данные теряются между reverse-out (portal) и reverse-in (bridge).
+- Kraken имеет прямой интернет (`api.ipify` → `92.62.70.41`), проблема не в egress.
+
+### ✅ ВНЕДРЕНО (2026-09-01) — TCP+REALITY переход, все шаги выполнены
+WS-транспорт не пропускал reverse-payload; переведён на **прямой TCP + REALITY** (Alex согласовал проброс). Все 4 шага ВЫПОЛНЕНЫ:
+1. ✅ Пересоздан `xray-reverse-portal` на TrueNAS (compose `12345:12345` + `12346:12346`, config REALITY TCP). Проверено `ss -tlnp` → `0.0.0.0:12346 LISTEN`.
+2. ✅ OpenWrt DNAT добавлен: redirect `xray-reverse-12346`, `src_dport=12346` → `dest_ip=192.168.2.197:12346`, `target=DNAT`, `/etc/init.d/firewall reload` → `DNAT_ADDED`. Проверено: `mallexxx.duckdns.org:12346` → **OPEN** извне.
+3. ✅ Пересоздан `xray-reverse-bridge` на Kraken (config REALITY TCP). Reverse-канал ESTABLISHED: Kraken `172.24.0.2 → 90.189.160.148:12346` + `common/mux: received request for udp:reverse:0`.
+4. ❌ **Тест payload НЕ прошёл даже на TCP+REALITY**: `curl --socks5 127.0.0.1:12345 http://api.ipify.org` → **`code=000`**. Portal: `accepted tcp:8.6.112.0:80 [local -> reverse-out]`, но bridge НЕ логирует приход TCP-payload.
+
+### ❌ Дополнительно пробовано: снятие `flow: xtls-rprx-vision`
+Убрал `flow: xtls-rprx-vision` с обеих сторон (portal interconn client + bridge conn outbound), пересоздал контейнеры (оба `Configuration OK`). Результат: **по-прежнему `code=000`**. Reverse-канал устанавливается, TCP-payload до bridge не доходит.
+
+**Вывод:** проблема НЕ в `flow` и НЕ в WS. **Даже на «каноничном» TCP+REALITY payload от portal-reverse-out до bridge-reverse-in не передаётся** (bridge не получает inbound-TCP). Гипотеза про WS **опровергнута**.
+
+### 🔑 КОРЕНЬ ПРОБЛЕМЫ НАЙДЕН (2026-09-01, интернет-поиск) — issue XTLS/Xray-core #6612
+
+**Симптомы точно совпадают с #6612:** reverse-канал устанавливается (`udp:reverse:0` на месте), но TCP-payload не проходит; portal логирует `accepted tcp:... -> reverse-out`, а bridge НЕ получает входящих reverse-in-соединений; curl → 000.
+
+**Причина:** начиная с **Xray v26.5+** (PR #6027) у outbound `freedom`/`direct` появилась **дефолтная политика безопасности**, которая **блокирует ВСЕ цели для трафика VLESS Reverse**, если не задан явный `finalRules`. Контрольный reverse-канал при этом продолжает устанавливаться — поэтому «всё выглядит подключённым», но реальный payload молча отбрасывается. Это ровно наш случай на версии **26.7.28**.
+
+**Точный фикс** — добавить в freedom `direct` на **BRIDGE** (место реального egress из reverse-in в интернет):
+```json
+{
+ "protocol": "freedom",
+ "tag": "direct",
+ "settings": {
+ "domainStrategy": "AsIs",
+ "finalRules": [ { "action": "allow" } ]
+ }
+}
+```
+Issue говорит прямо: проблема воспроизводится с обычным Freedom без finalRules вообще, и добавление безусловного `allow` чинит на 26.7.28.
+
+**Релевантные ссылки:**
+- **#6612** — главный фикс: `https://github.com/XTLS/Xray-core/issues/6612`
+- **#6027** — корень (finalRules у Direct/Freedom): `https://github.com/XTLS/Xray-core/pull/6027`
+- Документация freedom: `https://xtls.github.io/en/config/outbounds/freedom.html`
+- 3x-ui разбор под reverse: `https://github.com/MHSanaei/3x-ui/issues/4782`
+- **#2664** — если finalRules не поможет: `flow: xtls-rprx-vision` на BRIDGE-outbound + REALITY может ломать доставку (держите `flow:""` на reverse-клиенте): `https://github.com/XTLS/Xray-core/issues/2664`
+- **Регрессия роутинга reverse v26.5+** (если фикс не поможет): #6242, #6195, #6248 — временный кварк: пинить **v26.4.25**.
+
+**Важные детали из поиска (проверить при продолжении):**
+- Портал ДОЛЖЕН иметь placeholder-freedom (у нас есть) — иначе reverse-out станет default. Плейсхолдеру не нужен `finalRules:allow` (он обслуживает только несопоставленный трафик).
+- Роутинг `inboundTag:["reverse-in"] -> direct` на bridge — нужен (у нас есть).
+- У VLESS outbound поле `encryption` обязательно (`"none"` или парный PQ-ключ к серверному `decryption`) — у нас `"none"`, ок.
+
+### ✅ ФИКС ПРИМЕНЁН, но заблокирован (2026-09-01)
+
+Новый bridge-конфиг с `finalRules:[{action:"allow"}]` в `direct` **залит** на Kraken (`/home/kraken/xray-reverse/config.json`, 1098 байт, проверено `cat | head -5`). НО:
+- ⛔ **Kraken по docker НЕДОСТУПЕН**: `systemctl is-active docker` → **`activating`** (не `active`), демон застрял, накоплено множество зависших docker-процессов (ps/run/compose).
+- **Причина: USB-HDD снова не поднялся** — `lsblk /dev/sda` → **`0B`** (без раздела). Docker data-root = `/srv/dev-disk-by-uuid-49e8f586-3839-4c5d-a1e1-58bfc3579ade/docker-data` (на этом HDD) → daemon ждёт диск и застревает.
+- ⚠️ **Замечено расхождение UUID**: сейчас data-root указывает на `/srv/dev-disk-by-uuid-49e8f586-...`, а в контексте ранее фигурировал смонтированный HDD `/srv/dev-disk-by-uuid-6194539b-...` (sda1 1.8T). Текущий `sda` = 0B без раздела.
+- **`docker compose down/up` для bridge не выполнен** — контейнер всё ещё со старым конфигом (больше не деплоится, daemon не отвечает).
+
+**Шаг для продолжения (требует подтверждения Alex):** починить HDD/docker на Kraken (повторить утренний сценарий: `sudo reboot` или физическое переподключение USB-диска), затем пересоздать bridge-контейнер (`cd /home/kraken/xray-reverse && docker compose down && docker compose up -d`), затем тест `curl --socks5 127.0.0.1:12345 http://api.ipify.org` на TrueNAS → ожидаем выход с IP Kraken.
+
+**Статус: задание НЕ завершено — остаётся применить bridge-фикс после восстановления docker на Kraken.**
+
+## ✅ 2026-09-02: Kraken восстановлен (диск/docker) + фикс #6612 применён — НО payload всё равно мёртв → ИСТИННЫЙ КОРЕНЬ #6242 (bridge-side v26.5+)
+
+### Kraken полностью поднялся (проверено живьём по SSH)
+- Uptime 2 мин — Kraken перезагрузился (USB-HDD-сценарий). `systemctl is-active docker` был `activating` первые минуты (ждал поднятия диска), затем стал **`active`**.
+- **Диск `/dev/sda1` поднялся**: 1.8T, смонтирован к `/srv/dev-disk-by-uuid-6194539b-03e0-4f33-986b-4da09834e82f`, 235G свободно (87% занято). (В отличие от 2026-09-01, когда `sda` был `0B`.)
+- **Все контейнеры восстановились** (в прошлый раз — 0): transmission, sonarr, prowlarr, homeassistant, jellyfin, radarr, hermes-kraken, portainer, rclone, cloudflared, flaresolverr, watchtower, **xray-reverse-bridge**. Docker Root Dir `/srv/dev-disk-by-uuid-6194539b-.../docker-data`.
+- **Bridge-конфиг содержит фикс #6612**: `/home/kraken/xray-reverse/config.json` → `freedom/direct` с `"finalRules":[{"action":"allow"}]`.
+- **Reverse-канал к TrueNAS жив**: bridge лог 2026-09-02 13:12: `dialing TCP to mallexxx.duckdns.org:12346` → `tunneling request` → `received request for udp:reverse:0`. Bridge = Xray **26.7.28** (`teddysun/xray:latest`).
+
+### Portal (TrueNAS) — состояние
+`xray-reverse-portal` Up 22h, reverse-канал от Kraken держится. Лог portal: `accepted tcp:8.6.112.0:80 [local -> reverse-out]` — запрос с локального SOCKS-входа уходит в reverse-out (в сторону Kraken). Конфиг portal без изменений (interconn :12346 REALITY client `a81c3179...` reverse-out; local :12345 SOCKS; routing `local→reverse-out`; placeholder-freedom). Сеть `caddy_default`, curl-контейнер в ней резолвит `xray-reverse-portal:12345` = `172.16.1.7`.
+
+### ❌ End-to-end payload по-прежнему НЕ проходит (даже с фиксом #6612)
+Тест временным контейнером `curlimages/curl` в сети `caddy_default` на TrueNAS:
+```
+docker run --rm --network caddy_default curlimages/curl:latest curl -sv --socks5-hostname xray-reverse-portal:12345 -m 20 http://api.ipify.org
+```
+→ verbos: `Opened SOCKS connection from 172.16.1.8 port ... to api.ipify.org port 80 (via 172.16.1.7 port 12345)` → `Request completely sent off` → **`Empty reply from server`** (соединение закрыто без ответа). Трафик доходит до portal, уходит в reverse-out, НО не возвращается от bridge → ответ теряется.
+
+### 🔑 ИСТИННЫЙ КОРЕНЬ (2026-09-02, интернет-поиск): issue XTLS/Xray-core #6242 — регрессия bridge в v26.5+
+Симптомы точно совпадают с [issue #6242](https://github.com/XTLS/Xray-core/issues/6242) (закрыта "not planned"):
+- Регрессия **только на стороне BRIDGE** (outbound-initiating), версия portal не важна.
+- С **v26.5+** (и 26.6.x) bridge стартует без ошибок, reverse-канал вроде устанавливается (`udp:reverse:0`), но **трафик не маршрутизируется через reverse tunnel**. Ровно наш случай на 26.7.28.
+- **Понижение ТОЛЬКО bridge до v26.4.25 мгновенно возвращает полную работу** без изменений конфига.
+- Связано с #5750 (BurstObservatory не успевает health-check динамически регистрируемых `rproxy-*` outbound'ов — до 10 мин) и обсуждением #5962 (stale-tunnel mappings после рестартов). PR #5101 прямо предупреждал: "reverse sub-protocol unstable, will break, кросс-версий совместимости НЕ гарантировано".
+- **Почему фикс #6612 не помог:** #6612 (`finalRules:allow`) лечит ДРУГУЮ проблему (Freedom блокирует payload) — мы её уже устранили. Но осталась регрессия маршрутизации #6242, которую `finalRules` не обходит.
+
+**Решение/кварк:** сдаунгрейд **bridge** до Xray **26.4.25** (образ `teddysun/xray:26.4.25`, существует на Docker Hub / GitHub Container Registry `ghcr.io/xtls/xray-core:26.4.25`). Portal-сторона (26.7.28) остаётся.
+
+### План внедрения (согласован с Alex — что НЕ трогать `vpn.mallexxx` и `xray-admin`)
+1. На Kraken: остановить `xray-reverse-bridge` контейнер.
+2. В `/home/kraken/xray-reverse/docker-compose.yml` сменить образ `teddysun/xray:latest` → `teddysun/xray:26.4.25`.
+3. `cd /home/kraken/xray-reverse && docker compose up -d` (пересоздаст bridge на 26.4.25).
+4. Проверить reverse-канал: bridge лог `udp:reverse:0`.
+5. Контрольный end-to-end: временный curl-контейнер в сети `caddy_default` на TrueNAS через `xray-reverse-portal:12345` → ожидаем выход с **IP Kraken** (`92.62.70.41`), НЕ IP TrueNAS.
+⛔ НЕ трогать: `xray-admin` / `vpn.mallexxx` / Caddy / portal.
+
+### ⚠️ Важное прояснение для будущих сессий (из этого диалога)
+Запрос юзера "не могу подключиться к xray на truenas до наших измерений" — это была путаница между **тремя** разными сущностями:
+1. `vless-proxy` (teddysun/xray, SOCKS :1080/:1081, outbound на удалённый VPS qentra.top) — **мёртв из-за удаления VPS** 2026-09-01.
+2. `xray-admin` (3x-ui) = **самостоятельный рабочий Xray-VPN из интернета** через `vpn.mallexxx.duckdns.org:443` (см. секцию «ВАЖНО 2026-09-02» выше). Жив, end-to-end проверен.
+3. reverse-туннель TrueNAS↔Kraken (portal `xray-reverse-portal` + bridge на Kraken) — это про проксирование egress ЛОКАЛЬНЫХ клиентов сети TrueNAS через Kraken. НЕ связан с vpn.mallexxx.
+
+
+## ❌ ИСТОРИЯ ДИАГНОСТИКИ 2026-09-02: downgrade сам по себе не помог
+
+> ⚠️ ВАЖНО: вопреки секции «ИСТИННЫЙ КОРЕНЬ #6242» выше (которая была гипотезой, ещё не проверенной полностью), **полный downgrade обеих сторон до Xray 26.4.25 payload НЕ починил**. Это зафиксировано здесь как фактический итог.
+
+### Что было сделано (выполнено по факту, alive-диагностика)
+По согласованию с Alex (не трогая `vpn.mallexxx` / `xray-admin`) выполнено:
+1. Bridge (Kraken): `/home/kraken/xray-reverse/docker-compose.yml` → образ **`teddysun/xray:26.4.25`**. Docker Pull прошёл, контейнер на 26.4.25 (`Xray 26.4.25 ... go1.26.2 linux/arm64`). Бэкап: `docker-compose.yml.bak-26.7.28`.
+2. Portal (TrueNAS): `/mnt/RED_2TB/docker/reverse-portal/docker-compose.yml` → тоже **`teddysun/xray:26.4.25`** (Linux amd64, образ 21.59MB Pull). Бэкап: `docker-compose.yml.bak-26.7.28`. Контейнер `xray-reverse-portal` пересоздан.
+3. Portal `config.json` `loglevel` поднят на `debug` (для диагностики), залит в `/mnt/RED_2TB/docker/reverse-portal/config.json`.
+4. Локальные копии файлов на Mac (для правки): `~/xray-test/` → `docker-compose.bridge.yml`, `docker-compose.portal.yml`, `portal.config.json`, `config.json` (тестовый клиент vpn.mallexxx, удалить не нужно).
+5. После смены версии bridge перезапущен (для переустановки reverse-канала к новому portal).
+
+### Результат end-to-end теста (обе стороны 26.4.25)
+- Reverse-канал у bridge **устанавливается**: лог `dialing TCP to mallexxx.duckdns.org:12346` → `tunneling request to unknown` → `received request for udp:reverse:0`. Portal принимает (лог: `proxy/vless/inbound: received request for tcp:v1.rvs.cool:0` → `dispatching request to udp:reverse:0`).
+- **НО payload по-прежнему НЕ проходит**: тест curl через `xray-reverse-portal:12345` → `Empty reply from server` / `exit=52`.
+- **Portal (TrueNAS) debug-лог полностью проясняет картину:**
+ - При запросе: `[118463829] proxy/socks: TCP Connect request to tcp:api.ipify.org:80` → `[118463829] app/dispatcher: taking detour [reverse-out] for [tcp:api.ipify.org:80]` — **и НИЧЕГО дальше** (ни ошибки, ни dial к bridge). Dispatch в `reverse-out` молча глотается.
+ - Фоновые разрывы: `common/mux: failed to read metadata > read tcp 172.16.1.7:12346->92.62.70.41:3266: connection reset by peer` — portal пытается что-то слать к bridge, но канал рвётся.
+- **Критично:** на TrueNAS **НЕТ постоянного ESTABLISHED TCP-соединения от bridge на :12346** (`ss -tn sport=:12346` пусто). Reverse-канал НЕ держится постоянным — устанавливается эфемерно (per контрольный UDP прочёт), и data-stream по нему не доходит до bridge.
+- Bridge (Kraken) никогда не логирует приём `reverse-in` TCP-payload (только контрольный `udp:reverse:0`).
+
+### Вывод
+Проблема **НЕ** регрессия #6242 фиксируемая версией bridge — иначе downgrade до рабочей по issue пары 26.4.25↔26.4.25 решил бы. После полного downgrade payload по-прежнему мёртв. **Настоящая причина: reverse-канал portal↔bridge не удерживается постоянным на TCP-уровне** (нет стабильного ESTABLISHED :12346), поэтому dispatch портала в `reverse-out` не находит живой транспорт до bridge и молча теряет данные.
+
+Это согласуется с предупреждением PR #5101: **новый VLESS Reverse sub-protocol itself нестабилен** («will break, кросс-версий совместимость не гарантирована») — по-видимому канал между двумя разнесёнными docker-реализациями (Kraken arm64 ↔ TrueNAS amd64, обе 26.4.25) не держится стабильно.
+
+### Дальнейшие гипотезы (НЕ проверены, треб.WB)
+1. Транспортный REALITY mismatch arm64(26.4.25 bridge) ↔ amd64(26.4.25 portal) даёт нестабильный mux → попробовать не-REALITY (простой TCP, т.к. канал только между сервисами TrueNAS↔Kraken, не извне) — убрать REALITY, оставить VLESS-TCP без camouflage.
+2. Перепроверить, что bridge реально удерживает единственное mux-соединение (в xray reverse bridge обычно держит persistent канал, у нас его нет → пере-аудит конфиг bridge: возможно не хватает чего-то, заставляющего держать канал постоянно).
+3. Запросить консультацию/повторно изучить рабочую конфигурацию сбора из живого разбора темы (потому что каноничные примеры из доки и issues не дали полного рабочего egress-конфига).
+
+### ⚠️ ТЕКУЩЕЕ СОСТОЯНИЕ СИСТЕМ (на момент записи, 2026-09-02)
+- **Версии:** BOTH portal и bridge сейчас на **`teddysun/xray:26.4.25`** (исходно были на `:latest` = 26.7.28). Откат при необходимости: поменять образ в compose обратно на `teddysun/xray:latest` и `docker compose up -d`.
+- Конфиг portal имеет `loglevel: debug` (пока). Bridge `config.json` содержит фикс #6612 `finalRules:allow`.
+- `vpn.mallexxx.duckdns.org` / `xray-admin` / Caddy — **НЕ тронуты**, работают (см. секцию «ВАЖНО 2026-09-02»).
+- Reverse к Kraken **НЕ внедрён/не работает end-to-end** — это остаётся открытой задачей.
+
+## ⏳ Открытые вопросы по reverse (требуют ответа/действия Alex)
+
+## План реализации (история; Шаг 1 устарел — см. «ВНЕДРЕНО» выше)
+
+### Шаг 1 — TrueNAS: Xray reverse-server поверх Caddy
+- **Способ (рекомендован): Caddy TLS-pass-through.** Добавить в Caddy TCP-правило: поддомен `xray.mallexxx.duckdns.org:443` → внутренний порт Xray-контейнера (напр. `localhost:8443`). Caddy передаёт сырой TLS-стрим дальше. Xray на TrueNAS принимает VLESS+Reality/TLS. Kraken ходит на `xray.mallexxx.duckdns.org:443`.
+ - Плюс: переиспользуем уже открытый/проброшенный 443 на роутере, не трогаем роутер, туннель маскируется под HTTPS.
+ - Альтернатива: пробросить отдельный порт на роутере (напр. 8443) → требует доступа к роутеру. Менее предпочтительно.
+- Новый/доразвернутый Xray-контейнер:
+ - inbound `reverse`/`dokodemo-door` на 8443 (извне по pass-through)
+ - local inbound SOCKS/HTTP (уже есть 1080/1081)
+ - routing: трафик клиентов → в reverse-канал к Kraken
+
+### Шаг 2 — TrueNAS: бэкап перед изменением
+- Снять копию текущего конфига `vless-proxy` (config.json), в `/mnt/RED_2TB/docker//backup/` (паттерн как с cups-splix).
+
+### Шаг 3 — Kraken: Xray outbound reverse в Docker
+- Контейнер Xray на Kraken (`docker run --restart unless-stopped`, как остальные).
+- outbound vless → `xray.mallexxx.duckdns.org:443` (через Caddy pass-through).
+- inbound SOCKS/HTTP на Kraken — точка выхода.
+- reverse-конфиг: Kraken регистрирует «сервис» (весь трафик через dokodemo-door) наружу через канал к TrueNAS.
+
+### Шаг 4 — Проверка связности
+- Kraken → `xray.mallexxx.duckdns.org:443` (TCP).
+- Локальный клиент → TrueNAS:1080 → curl через прокси → должен выйти с IP Kraken.
+
+### Шаг 5 — Обновить Obsidian после внедрения
+- Дополнить `family/how-to/truenas-infrastructure.md` (Xray reverse-настройка), `family/how-to/kraken-access.md`; обновить `personal/tech/vps-qentra.md` (VPS удалён, ссылки на него).
+
+## Открытые вопросы (требуют ответа Alex)
+
+1. ✅ (решено) **Проброс порта для reverse** — переведён на TCP+REALITY, ВСЁ ВЫПОЛНЕНО (portal пересоздан с REALITY, OpenWrt DNAT `внешний:12346 → 192.168.2.197:12346` добавлен, bridge на Kraken пересоздан). См. секции «ВНЕДРЕНО — TCP+REALITY» выше. **Компанент работает, но payload НЕ проходит (см. пункт 4).**
+2. **Какой трафик TrueNAS пустить через Kraken** — весь исходящий интернет, или конкретные сервисы/подсети? (Влияет на маршрутизацию на Kraken.) — всё ещё открыто.
+3. ✅ **Kraken docker** — РАБОТАЕТ, ВОССТАНОВИЛСЯ 2026-09-02: `systemctl is-active docker` → `active`, диск `/dev/sda1 1.8T` смонтирован к `/srv/dev-disk-by-uuid-6194539b-...`, 235G свободно (87% занято). **Все контейнеры восстановились** (в отличие от 2026-09-01, когда было 0): transmission, sonarr, prowlarr, homeassistant, jellyfin, radarr, hermes-kraken, portainer, rclone, cloudflared, flaresolverr, watchtower, **xray-reverse-bridge** (Up).
+4. ✅ **End-to-end payload проходит.** #6612/#6242 оказались неполными гипотезами. Верифицированный корень — Docker bridge/NAT на Kraken; решение — Xray 26.4.25 + `network_mode: host` на bridge. См. authoritative-секцию ниже.
+
+## ✅ Верифицированный фикс 2026-09-02 (authoritative)
+
+> Эта секция суперсидирует все более ранние выводы «payload мёртв», «нет persistent ESTABLISHED» и предполагаемые корни #6612/#6242. Фикс найден и проверен живыми A/B-тестами.
+
+### Истинная причина
+
+`xray-reverse-bridge` на Kraken работал в обычной Docker bridge-сети. Docker bridge/NAT на этом узле сбрасывал long-lived VLESS reverse mux после успешной регистрации `udp:reverse:0`. Поэтому portal создавал `reverse-out`, но payload не доходил до `reverse-in`.
+
+Ключевой A/B-тест:
+
+1. Тот же JSON на temporary bridge amd64 внутри TrueNAS заработал сразу → portal/config/routing исправны.
+2. Тот же Xray 26.4.25 arm64 + тот же JSON на Kraken в `--network host` заработал сразу → CPU architecture и WAN исправны, отличие только в Docker network mode.
+3. После возврата REALITY+Vision туннель остался рабочим → проблема не в REALITY, Vision или TCP transport.
+
+### Постоянная конфигурация
+
+Kraken: `/home/kraken/xray-reverse/docker-compose.yml`
+
+```yaml
+services:
+ xray-reverse-bridge:
+ image: teddysun/xray:26.4.25
+ network_mode: host
+```
+
+Bridge config возвращён к защищённому VLESS TCP + REALITY + `flow: xtls-rprx-vision`. `direct` сохраняет `finalRules: [{"action":"allow"}]`. Portal на TrueNAS также на `teddysun/xray:26.4.25`, REALITY+Vision. `xray-admin`, Caddy и `vpn.mallexxx.duckdns.org` не менялись.
+
+`network_mode: host` расширяет сетевые права bridge-контейнера. В этом конфиге у него нет физических listening inbounds; `reverse-in` — виртуальный inbound Xray. Не добавлять в этот контейнер обычные inbounds без аудита bind address/firewall.
+
+### Финальная проверка
+
+2026-09-02 после permanent Compose deploy:
+
+- `docker inspect xray-reverse-bridge` → image `teddysun/xray:26.4.25`, network `host`, status `running`, restart count `0`.
+- Bridge лог: `received request for udp:reverse:0`, затем TCP payload принят в `reverse-in -> direct`.
+- HTTPS через SOCKS `xray-reverse-portal:12345` → `92.62.70.41`.
+- HTTP через тот же SOCKS → `92.62.70.41`.
+- `92.62.70.41` — публичный egress Kraken; TrueNAS egress `90.189.160.148` не использовался.
+
+### Бэкапы и rollback
+
+Kraken:
+
+- `/home/kraken/xray-reverse/docker-compose.yml.bak-bridge-network-20260902-1147`
+- `/home/kraken/xray-reverse/config.json.bak-plain-host-working-20260902-1146`
+- `/home/kraken/xray-reverse/config.json.bak-reality-vision-20260902-1142`
+
+TrueNAS:
+
+- `/mnt/RED_2TB/docker/reverse-portal/config.json.bak-plain-host-working-20260902-1146`
+- `/mnt/RED_2TB/docker/reverse-portal/config.json.bak-reality-vision-20260902-1142`
+
+Rollback network fix: вернуть compose-бэкап на Kraken и выполнить `docker compose up -d`. Это вернёт нерабочий Docker bridge mode, поэтому делать только для диагностики/отката.
+
+## ✅ Per-user egress на `vpn.mallexxx.duckdns.org` (2026-09-02)
+
+В существующий VLESS-WS inbound `in-10095-tcp` добавлен второй клиент. Маршрутизация теперь различает клиентов по `email`:
+
+| Client email | Client ID | Egress |
+|---|---|---|
+| `user1` | `ce320965-6956-4759-84bb-7cb71cfc6252` | `direct` → TrueNAS `90.189.160.148` |
+| `kraken-user` | `93a5dc4b-1b8d-4af5-9363-eb0091734293` | `via-kraken` → portal SOCKS `xray-reverse-portal:12345` → Kraken `92.62.70.41` |
+
+В persistent 3x-ui Xray template (`settings.key = xrayTemplateConfig`) добавлен SOCKS outbound:
+
+```json
+{
+ "protocol": "socks",
+ "tag": "via-kraken",
+ "settings": {
+ "address": "xray-reverse-portal",
+ "port": 12345
+ }
+}
+```
+
+После глобальных `geoip:private -> blocked` и `bittorrent -> blocked` добавлено правило:
+
+```json
+{
+ "type": "field",
+ "user": ["kraken-user"],
+ "outboundTag": "via-kraken",
+ "ruleTag": "kraken-user-via-reverse"
+}
+```
+
+Проверка одним и тем же локальным Docker-клиентом `xray-test-client`, менялся только client ID:
+
+- `user1` → HTTPS `api.ipify.org` → `90.189.160.148` (TrueNAS direct).
+- `kraken-user` → HTTP и HTTPS `api.ipify.org` → `92.62.70.41` (Kraken reverse).
+
+Локальный `/Users/admin/xray-test/config.json` оставлен на `kraken-user`. Бэкап direct-клиента: `/Users/admin/xray-test/config.json.bak-user1-direct-20260902-1227`.
+
+### ⚠️ СОСТОЯНИЕ КЛИЕНТА 2026-09-02 (после замеров скорости туннеля)
+
+Контейнер `xray-test-client` **переключён с `kraken-user` на `user1-direct`** для замеров скорости direct-пути, и НЕ возвращён обратно. Активная конфигурация = **`user1` (direct, REALITY)**.
+
+- Контейнер: `xray-test-client` (image `teddysun/xray:latest`; лог старта показал «Xray 26.7.28 started»), bind-mount `/Users/admin/xray-test/config.json:/etc/xray/config.json:ro`, SOCKS `127.0.0.1:1080→1080`.
+- **Как переключать:** в `/Users/admin/xray-test/`:
+ - `user1-direct` = `config.json.bak-user1-direct-20260902-1227` (id `ce320965-6956-4759-84bb-7cb71cfc6252`) — выход TrueNAS `90.189.160.148`.
+ - kraken-user = прежний активный, сохранён в `config.json.current-kraken-user` (id `93a5dc4b-1b8d-4af5-9363-eb0091734293`) — выход Kraken `92.62.70.41`.
+ - Смена: `cp <файл> /Users/admin/xray-test/config.json && docker restart xray-test-client`.
+- Размер обоих конфигов одинаковый (831 байт), inbound общий (SOCKS :1080 noauth), различие только в VLESS-outbound (client id / egress).
+
+### 📊 Замеры скорости туннелей (2026-09-02, с Mac через `xray-test-client` :1080)
+
+Замер пропускной способности каждого egress-режима (скачивание файлов по SOCKS-прокси контейнера; источник http cachefly + ovh; Cloudflare с этого egress режется = 0 B/s → не показатель):
+
+| Режим | egress IP | Средний down | Разброс | Комментарий |
+|---|---|---|---|---|
+| `kraken-user` (reverse) | `92.62.70.41` (Kraken) | ~5.7 МБ/с (~45 Мбит) | 2.0–6.98 МБ/с | нестабилен, убывающий по ходу |
+| `user1` (direct/REALITY) | `90.189.160.148` (TrueNAS) | ~4.6 МБ/с (~37 Мбит) | 3.67–5.63 МБ/с | cachefly 4×10MB |
+
+Вывод: оба egress-режима туннеля дают ~35–45 Мбит/с с нестабильностью — **не кратно быстрее** прямого межоператорского пути (~28 Мбит single-flow), туннель не даёт надёжного запаса под stрим пиковых битрейтов BluRay (~20+ Мбит). Для jellyfin-стрима на ТВ туннель не решает проблему дёрганья.
+
+Контроль (не туннель, Mac напрямую до Cloudflare): ~55 МБ/с. Туннель ~в 10× медленнее прямого локального интернета.
+
+Бэкапы TrueNAS до и после изменения: `/mnt/RED_2TB/docker/backups/xray-per-user-20260902-1200/` (`x-ui.db`, `x-ui.post-change.db`, runtime configs, reverse portal config/compose). Temporary full-admin API token **не создавался**; `api_tokens` осталась пустой.
+
+## Связанные заметки
+- [[family/how-to/vps-qentra]] — VPS на 2026-09-01 УДАЛЁН
+- [[family/how-to/truenas-infrastructure]] — TrueNAS Caddy/контейнеры
+- [[family/how-to/kraken-access]] — Docker Kraken
+- [[family/how-to/rasputin-router]] — прежний VLESS-туннель на VPS (тоже требует пересмотра, VPS нет)
+- [[family/how-to/wireguard-vpn]] — WG Eagle↔VPS↔Kraken (VPS-звено теперь мёртво)
diff --git a/personal/tech/xray-reverse-tunnel-kraken-truenas.md.bak-20260902-1154 b/personal/tech/xray-reverse-tunnel-kraken-truenas.md.bak-20260902-1154
new file mode 100644
index 00000000..8270195d
--- /dev/null
+++ b/personal/tech/xray-reverse-tunnel-kraken-truenas.md.bak-20260902-1154
@@ -0,0 +1,332 @@
+---
+title: Xray Reverse Tunnel — Kraken ↔ TrueNAS
+created: '2026-09-01'
+updated: '2026-09-02'
+type: tech
+namespace: personal
+tags:
+ - xray
+ - reverse
+ - kraken
+ - truenas
+ - tunnel
+ - networking
+confidence: medium
+related:
+ - '[[family/how-to/vps-qentra]]'
+ - '[[family/how-to/truenas-infrastructure]]'
+ - '[[family/how-to/kraken-access]]'
+ - '[[family/how-to/rasputin-router]]'
+downgrade_to_26.4.25: >-
+ portal+bridge BOTH downgraded 2026-09-02 — payload still dead (корень глубже
+ #6242)
+---
+
+# Xray Reverse Tunnel — Kraken ↔ TrueNAS
+
+> **Статус: НЕ ВНЕДРЕНО (2026-09-02, финал сессии аудита).** Reverse TrueNAS↔Kraken по-прежнему НЕ работает end-to-end. **Выполнен полный downgrade обеих сторон (portal+bridge) до Xray 26.4.25 — это НЕ помогло**: payload по-прежнему мёртв (`Empty reply`/exit 52). ✅ 3x-ui (`vpn.mallexxx`) жив и работает (рабочий Xray-VPN через TrueNAS). ✅ Kraken восстановлен (диск/docker/контейнеры). ⛔ **Остаётся открытым**: reverse-канал portal↔bridge не удерживается постоянным (нет ESTABLISHED :12346), dispatch портала в reverse-out теряется. Подробности+гипотезы: см. секцию «❌ ФАКТИЧЕСКИЙ РЕЗУЛЬТАТ 2026-09-02» ниже. Не трогать `vpn.mallexxx`.
+> Архитектурное решение: проксировать исходящий трафик локальных клиентов сети TrueNAS через **TrueNAS → Kraken → интернет**.
+
+> ## ✅ ВАЖНО (2026-09-02): `xray-admin` (3x-ui) на TrueNAS — это ОДНОВРЕМЕННО РАБОЧИЙ САМОСТОЯТЕЛЬНЫЙ Xray-VPN-сервер
+> Путаница в вопросе юзера выявила: `vpn.mallexxx.duckdns.org:443` — это **не только reverse-frontend**, а полноценный Xray-сервер со **своим собственным выходом в интернет** (outbound `freedom`/`direct` → сразу через TrueNAS), НЕ зависящий от reverse-канала к Kraken. Это **отдельная фича**, параллельная reverse-туннелю.
+> - **Проверено end-to-end 2026-09-02** (временный xray-клиент с Mac): VLESS+WS через `vpn.mallexxx.duckdns.org:443` → HTTP 200, выход IP `90.189.160.148` = TrueNAS. Контейнеры `xray-admin` (Up 21h) + `caddy` (Up 20h) живы.
+> - Inbound `in-10095-tcp` (VLESS-WS): client id `ce320965-6956-4759-84bb-7cb71cfc6252` (user1), `security: none`, path `/vless`, host `vpn.mallexxx.duckdns.org`. TLS терминирует Caddy → в клиенте `network: ws` + TLS на домен, **без** двойного TLS внутрь.
+> - Полные параметры и pitfalls (вкл. удаление `allowInsecure` в Xray 26.7.28) — в `family/how-to/truenas-infrastructure.md`, раздел `xray-admin`.
+> - То есть reverse к Kraken — это ОТДЕЛЬНЫЙ механизм (для проксирования локальных клиентов сети TrueNAS через Kraken-egress); он по-прежнему НЕ внедрён. Сам по себе 3x-ui-сервер уже даёт рабочий VPN-выход через TrueNAS.
+
+## Контекст / Почему
+
+- **VPS qentra.top (91.207.28.205) УДАЛЁН** — вся прежняя Xray-инфраструктура на нём (VLESS+REALITY, OpenVPN, WebSocket v.qentra.top) больше не существует.
+- Нужен новый путь для выхода локальных клиентов сети TrueNAS в интернет через другую точку выхода (Kraken).
+- Белый IP есть только у **TrueNAS** (`mallexxx.duckdns.org` = `90.189.160.148`).
+- **Kraken за NAT**, входящие не принимает — только исходящие соединения.
+
+## Принятая схема
+
+```
+Локальные клиенты (сеть TrueNAS, 192.168.2.x)
+ │ шлют трафик на локальный прокси TrueNAS (SOCKS 1080 / HTTP 1081)
+ ▼
+TrueNAS ←── контроллер / bridge (белый IP, mallexxx.duckdns.org), принимает
+ │ TrueNAS заворачивает трафик в reverse-канал
+ ▼ ▲
+Kraken ──┘ держит ИСХОДЯЩИЙ reverse-канал к TrueNAS, отпускает трафик → интернет
+ ▼
+интернет
+```
+
+**Тип решения: Xray `reverse`.** Роли по Xray:
+
+| Узел | Роль | Держит канал? | Выход в интернет? |
+|------|------|---------------|-------------------|
+| **TrueNAS** | bridge/контроллер (inbound `reverse`) | ❌ слушает | ❌ |
+| **Kraken** | outbound reverse-нода + exit | ✅ **исходящий** к TrueNAS | ✅ **да** |
+| **Локальные клиенты** | используют TrueNAS как локальный прокси-шлюз | — | через Kraken |
+
+**Ключевое физическое ограничение:** Kraken за NAT не может принимать входящих. Поэтому канал держит **Kraken исходящим** к TrueNAS. Для передачи клиентского трафика TrueNAS → Kraken используются конструкции `dokodemo-door` + `reverse` + policy-маршрутизация (routing rules). Это чуть сложнее "поставить reverse и всё", конфиг нужен аккуратный.
+
+## ⚠️ Факты, проверенные 2026-09-01 (важно, ломают прежние допущения)
+
+1. **На 443 у TrueNAS НЕ Xray.** Проверено `openssl s_client`: на `mallexxx.duckdns.org:443` отвечает **обычный TLS 1.3 с валидным Let's Encrypt сертификатом для `mallexxx.duckdns.org`** (`issuer=Let's Encrypt/CN=YE2`). Это **Caddy/nginx reverse-proxy**, НЕ Xray REALITY (у REALITY сертификат был бы чужой/поддельный). → Твоя память «на 443 висел xray server» не подтверждается.
+2. **`vless-proxy` на TrueNAS** (контейнер `teddysun/xray:latest`, Up 7 дней):
+ - inbound: SOCKS `0.0.0.0:1080`, HTTP `0.0.0.0:1081` (локально в LAN TrueNAS)
+ - outbound: VLESS+WS+TLS на `v.qentra.top:443`, path `/qentra`, id `2D9F24C4-21FE-4784-9843-F11C384DA67A` — **указывает на УДАЛЁННЫЙ VPS → сейчас мёртвый**.
+ - ⚠️ Используется Hermes-Taiga как SOCKS5-прокси (`vless-proxy:1080`) → **Hermes-Taiga сейчас без рабочего прокси**.
+3. **Kraken→TrueNAS по `mallexxx.duckdns.org`:** открыты **только 22 (SSH) и 443 (HTTPS/TLS)**. `8443/8964/8080/9000` — closed. Порт 443 — TLS (Caddy), не сырой.
+4. **Kraken:** Docker установлен (`/usr/bin/docker`), но демон отвечает медленно/рвёт SSH (проверка `docker ps` не завершилась за 40s). Xray на Kraken **отсутствует** (`which xray` пусто) — нужен Docker-контейнер.
+5. **Связанность Kraken↔TrueNAS по 22/443 — подтверждена** (оба OPEN с Kraken).
+
+## ✅ ВНЕДРЕНО 2026-09-01: 3x-ui на TrueNAS (фронтенд + Docker Compose)
+
+**Решение Alex:** использовать **3x-ui frontend** + **Docker Compose** (управление клиентами через панель), а не ручной Caddy-pass-through с сырым Xray. Это изменило исходный план реализации (Шаг 1 ниже устарел по способу).
+
+### Развёрнут контейнер `xray-admin` (TrueNAS)
+- **Имя контейнера:** `xray-admin` (строго, т.к. Caddyfile резолвит `xray-admin` по имени в docker-сети).
+- **Образ:** `ghcr.io/mhsanaei/3x-ui:latest` (**3.7.0**, Xray **26.7.28**).
+- **Сеть:** `caddy_default` (external) — там же Caddy, чтобы резолвить имя.
+- **Volume:** `/mnt/RED_2TB/docker/xray-admin:/etc/x-ui` (туда лёг существующий `x-ui.db`).
+- **Порт панели:** хостовый `54321 → 54321` (внутри панель реально слушает **2053** — Caddy проксирует `vpn-panel.mallexxx.duckdns.org` → `xray-admin:2053`).
+- **Compose-файл:** `/mnt/RED_2TB/docker/xray-admin/docker-compose.yml` (deployed версия с `TZ=Asia/Novosibirsk`, `PUID/PGID=950`; см. актуальный файл на TrueNAS — отличается от черновика в плане).
+- **Панель доступна:** `https://vpn-panel.mallexxx.duckdns.org/` → **HTTP 200**.
+- **Sub-сервер:** `[::]:443` (path `/sub`), панель `[::]:2053`, inbound `vless-ws:10095` (path `/vless`, host `vpn.mallexxx.duckdns.org`).
+
+### Почему это заработало «из коробки» (важно)
+База `/mnt/RED_2TB/docker/xray-admin/x-ui.db` **уже была настроена под эту Caddy-интеграцию** (раньше 3x-ui уже задумывался на TrueNAS): inbound `vless-ws` port 10095 tag `in-10095-tcp`, subDomain `vpn-panel.mallexxx.duckdns.org`, subPort 443, subScheme https. Caddyfile уже содержал (мёртвые до подъёма) блоки:
+- `vpn.mallexxx.duckdns.org` → `@ws path /vless` → `xray-admin:10095` (WS)
+- `vpn-panel.mallexxx.duckdns.org` → `@sub path /sub/*` → `xray-admin:443` + fallback `xray-admin:2053`
+- LE-сертификаты для этих поддоменов уже выданы.
+
+### 3x-ui поддерживает reverse
+В бинарнике `/app/x-ui` присутствует **`clientReverseTags`** → reverse-настройка реализуема через панель 3x-ui (3.7.0).
+
+### Бэкап (сделан до изменений)
+`/mnt/RED_2TB/docker/backups/reverse-xray-3xui-20260901-113625/` — содержит: `caddy/Caddyfile` (копия из контейнера, 90 строк), `xray-admin/x-ui.db`, `docker-inventory.txt`.
+
+### Мелочь/питфолл
+Скопированный в volume `docker-compose.yml` оказался внутри контейнера `/etc/x-ui/` (т.к. volume смонтирован туда) — удалить лишний файл из контейнера: `docker exec xray-admin rm -f /etc/x-ui/docker-compose.yml`.
+
+## ✅ ВНЕДРЕНО 2026-09-01: Reverse portal (TrueNAS) + bridge (Kraken) — VLESS-WS
+
+После 3x-ui развёрнут полноценный reverse. **Ключевое открытие:** Xray **26.x заменил legacy reverse на "VLESS Reverse Proxy"** — старая схема `reverse.bridges/portals` (Xray-examples/ReverseProxy) **не работает** в этой версии (ошибка `The feature "legacy reverse" has been removed and migrated to "VLESS Reverse Proxy"`). Новая схема: `reverse.tag` в VLESS-клиентах/аутбаундах (примеры — `xtls.github.io/en/document/level-2/vless_reverse.html`, use case "Home Broadband Egress").
+
+### Роли (новая терминология VLESS Reverse)
+- **Internal device (Kraken) = BRIDGE**: VLESS-**outbound** с `"reverse":{"tag":"reverse-in"}` → активно устанавливает канал к TrueNAS; на своей стороне создаётся виртуальный **inbound** `reverse-in`, чей трафик направляется в freedom (интернет).
+- **Public server (TrueNAS) = PORTAL**: VLESS-**inbound** с `"reverse":{"tag":"reverse-out"}` у клиента → создаёт **routable-маутбаунд** `reverse-out`; локальные клиенты (SOCKS) маршрутизируются в `reverse-out`.
+- `reverse.tag` на двух сторонах **не обязаны совпадать** — соответствие через общий UUID соединения.
+
+### TrueNAS — `xray-reverse-portal` (папка `/mnt/RED_2TB/docker/reverse-portal/`)
+compose: image `teddysun/xray:latest` (26.7.28), сеть `caddy_default`, volume `config.json:/etc/xray/config.json:ro`, проброс host **`12345:12345`**.
+`config.json`:
+- inbound `interconn` (:12346, VLESS, ws path `/rvs`, host `vpn.mallexxx.duckdns.org`, client id `a81c3179-312b-4c5e-8a46-6bf3c30c2941`, `"reverse":{"tag":"reverse-out"}`)
+- inbound `local` (:12345, SOCKS `noauth udp:true`) — точка входа для клиентов сети TrueNAS
+- routing: `inboundTag:["local"] → outboundTag:"reverse-out"`
+- outbounds: `freedom` (placeholder — обязателен, иначе `reverse-out` станет default и весь трафик уйдёт в reverse)
+- Порт 12346 НЕ проброшен наружу — к нему обращается Caddy по имени `xray-reverse-portal:12346` в docker-сети.
+
+### TrueNAS — Caddyfile (bind mount `/mnt/RED_2TB/docker/caddy/Caddyfile`)
+Добавлен маршрут в блок `vpn.mallexxx.duckdns.org`:
+```caddy
+@rvs path /rvs
+reverse_proxy @rvs xray-reverse-portal:12346
+```
+Питфоллы: **Caddyfile нельзя править `docker cp`** в контейнер (volume → `device or resource busy`) — править на хосте через `docker run --rm -v /:/host alpine cp /host/tmp/...`. Валидация `docker exec caddy caddy validate --config /tmp/Caddyfile.new` → "Valid configuration". Перезапуск `docker restart caddy` безопасен. Бэкап: `Caddyfile.pre-reverse`.
+
+### Kraken — `xray-reverse-bridge` (папка `/home/kraken/xray-reverse/`)
+compose: image `teddysun/xray:latest`, volume `config.json:/etc/xray/config.json:ro`.
+`config.json`:
+- outbound `direct` = `freedom` + `"finalRules":[{"action":"allow","network":"tcp,udp","ip":["0.0.0.0/0"]}]` (интернет-egress Kraken)
+- outbound `conn` = **VLESS упрощённого стиля** (`settings.address/port/id/encryption/reverse` — НЕ `vnext[]`!) → `vpn.mallexxx.duckdns.org:443` ws `/rvs` `"reverse":{"tag":"reverse-in"}`, security tls, tlsSettings.serverName `vpn.mallexxx.duckdns.org`
+- routing: `inboundTag:["reverse-in"] → outboundTag:"direct"`
+- **Питфолл:** VLESS-outbound с `reverse` должен быть упрощённого стиля. Если через `vnext[]/users[]` → Xray 26.x: `VLESS users: please use simplified outbound's config style to use "reverse"`.
+- `loglevel debug` (для диагностики).
+
+### Reverse-канал: ✅ установлен
+- Kraken `netstat`: `172.24.0.2:... → 90.189.160.148:443 ESTABLISHED`
+- Portal: `::ffff:172.16.1.7:12346 ::ffff:172.16.1.3:52616 ESTABLISHED` (172.16.1.3 = Caddy)
+- Bridge logs: `common/mux: received request for udp:reverse:0`
+
+### ❌ End-to-end payload НЕ работает
+- `curl --socks5 127.0.0.1:12345 http://api.ipify.org` на TrueNAS → `code=000` (прямой curl → 200).
+- Portal логи: `accepted tcp:8.47.69.0:80 [local -> reverse-out]` — запрос ушёл в reverse-out.
+- **Bridge НЕ логирует received для этого TCP-payload** — данные теряются между reverse-out (portal) и reverse-in (bridge).
+- Kraken имеет прямой интернет (`api.ipify` → `92.62.70.41`), проблема не в egress.
+
+### ✅ ВНЕДРЕНО (2026-09-01) — TCP+REALITY переход, все шаги выполнены
+WS-транспорт не пропускал reverse-payload; переведён на **прямой TCP + REALITY** (Alex согласовал проброс). Все 4 шага ВЫПОЛНЕНЫ:
+1. ✅ Пересоздан `xray-reverse-portal` на TrueNAS (compose `12345:12345` + `12346:12346`, config REALITY TCP). Проверено `ss -tlnp` → `0.0.0.0:12346 LISTEN`.
+2. ✅ OpenWrt DNAT добавлен: redirect `xray-reverse-12346`, `src_dport=12346` → `dest_ip=192.168.2.197:12346`, `target=DNAT`, `/etc/init.d/firewall reload` → `DNAT_ADDED`. Проверено: `mallexxx.duckdns.org:12346` → **OPEN** извне.
+3. ✅ Пересоздан `xray-reverse-bridge` на Kraken (config REALITY TCP). Reverse-канал ESTABLISHED: Kraken `172.24.0.2 → 90.189.160.148:12346` + `common/mux: received request for udp:reverse:0`.
+4. ❌ **Тест payload НЕ прошёл даже на TCP+REALITY**: `curl --socks5 127.0.0.1:12345 http://api.ipify.org` → **`code=000`**. Portal: `accepted tcp:8.6.112.0:80 [local -> reverse-out]`, но bridge НЕ логирует приход TCP-payload.
+
+### ❌ Дополнительно пробовано: снятие `flow: xtls-rprx-vision`
+Убрал `flow: xtls-rprx-vision` с обеих сторон (portal interconn client + bridge conn outbound), пересоздал контейнеры (оба `Configuration OK`). Результат: **по-прежнему `code=000`**. Reverse-канал устанавливается, TCP-payload до bridge не доходит.
+
+**Вывод:** проблема НЕ в `flow` и НЕ в WS. **Даже на «каноничном» TCP+REALITY payload от portal-reverse-out до bridge-reverse-in не передаётся** (bridge не получает inbound-TCP). Гипотеза про WS **опровергнута**.
+
+### 🔑 КОРЕНЬ ПРОБЛЕМЫ НАЙДЕН (2026-09-01, интернет-поиск) — issue XTLS/Xray-core #6612
+
+**Симптомы точно совпадают с #6612:** reverse-канал устанавливается (`udp:reverse:0` на месте), но TCP-payload не проходит; portal логирует `accepted tcp:... -> reverse-out`, а bridge НЕ получает входящих reverse-in-соединений; curl → 000.
+
+**Причина:** начиная с **Xray v26.5+** (PR #6027) у outbound `freedom`/`direct` появилась **дефолтная политика безопасности**, которая **блокирует ВСЕ цели для трафика VLESS Reverse**, если не задан явный `finalRules`. Контрольный reverse-канал при этом продолжает устанавливаться — поэтому «всё выглядит подключённым», но реальный payload молча отбрасывается. Это ровно наш случай на версии **26.7.28**.
+
+**Точный фикс** — добавить в freedom `direct` на **BRIDGE** (место реального egress из reverse-in в интернет):
+```json
+{
+ "protocol": "freedom",
+ "tag": "direct",
+ "settings": {
+ "domainStrategy": "AsIs",
+ "finalRules": [ { "action": "allow" } ]
+ }
+}
+```
+Issue говорит прямо: проблема воспроизводится с обычным Freedom без finalRules вообще, и добавление безусловного `allow` чинит на 26.7.28.
+
+**Релевантные ссылки:**
+- **#6612** — главный фикс: `https://github.com/XTLS/Xray-core/issues/6612`
+- **#6027** — корень (finalRules у Direct/Freedom): `https://github.com/XTLS/Xray-core/pull/6027`
+- Документация freedom: `https://xtls.github.io/en/config/outbounds/freedom.html`
+- 3x-ui разбор под reverse: `https://github.com/MHSanaei/3x-ui/issues/4782`
+- **#2664** — если finalRules не поможет: `flow: xtls-rprx-vision` на BRIDGE-outbound + REALITY может ломать доставку (держите `flow:""` на reverse-клиенте): `https://github.com/XTLS/Xray-core/issues/2664`
+- **Регрессия роутинга reverse v26.5+** (если фикс не поможет): #6242, #6195, #6248 — временный кварк: пинить **v26.4.25**.
+
+**Важные детали из поиска (проверить при продолжении):**
+- Портал ДОЛЖЕН иметь placeholder-freedom (у нас есть) — иначе reverse-out станет default. Плейсхолдеру не нужен `finalRules:allow` (он обслуживает только несопоставленный трафик).
+- Роутинг `inboundTag:["reverse-in"] -> direct` на bridge — нужен (у нас есть).
+- У VLESS outbound поле `encryption` обязательно (`"none"` или парный PQ-ключ к серверному `decryption`) — у нас `"none"`, ок.
+
+### ✅ ФИКС ПРИМЕНЁН, но заблокирован (2026-09-01)
+
+Новый bridge-конфиг с `finalRules:[{action:"allow"}]` в `direct` **залит** на Kraken (`/home/kraken/xray-reverse/config.json`, 1098 байт, проверено `cat | head -5`). НО:
+- ⛔ **Kraken по docker НЕДОСТУПЕН**: `systemctl is-active docker` → **`activating`** (не `active`), демон застрял, накоплено множество зависших docker-процессов (ps/run/compose).
+- **Причина: USB-HDD снова не поднялся** — `lsblk /dev/sda` → **`0B`** (без раздела). Docker data-root = `/srv/dev-disk-by-uuid-49e8f586-3839-4c5d-a1e1-58bfc3579ade/docker-data` (на этом HDD) → daemon ждёт диск и застревает.
+- ⚠️ **Замечено расхождение UUID**: сейчас data-root указывает на `/srv/dev-disk-by-uuid-49e8f586-...`, а в контексте ранее фигурировал смонтированный HDD `/srv/dev-disk-by-uuid-6194539b-...` (sda1 1.8T). Текущий `sda` = 0B без раздела.
+- **`docker compose down/up` для bridge не выполнен** — контейнер всё ещё со старым конфигом (больше не деплоится, daemon не отвечает).
+
+**Шаг для продолжения (требует подтверждения Alex):** починить HDD/docker на Kraken (повторить утренний сценарий: `sudo reboot` или физическое переподключение USB-диска), затем пересоздать bridge-контейнер (`cd /home/kraken/xray-reverse && docker compose down && docker compose up -d`), затем тест `curl --socks5 127.0.0.1:12345 http://api.ipify.org` на TrueNAS → ожидаем выход с IP Kraken.
+
+**Статус: задание НЕ завершено — остаётся применить bridge-фикс после восстановления docker на Kraken.**
+
+## ✅ 2026-09-02: Kraken восстановлен (диск/docker) + фикс #6612 применён — НО payload всё равно мёртв → ИСТИННЫЙ КОРЕНЬ #6242 (bridge-side v26.5+)
+
+### Kraken полностью поднялся (проверено живьём по SSH)
+- Uptime 2 мин — Kraken перезагрузился (USB-HDD-сценарий). `systemctl is-active docker` был `activating` первые минуты (ждал поднятия диска), затем стал **`active`**.
+- **Диск `/dev/sda1` поднялся**: 1.8T, смонтирован к `/srv/dev-disk-by-uuid-6194539b-03e0-4f33-986b-4da09834e82f`, 235G свободно (87% занято). (В отличие от 2026-09-01, когда `sda` был `0B`.)
+- **Все контейнеры восстановились** (в прошлый раз — 0): transmission, sonarr, prowlarr, homeassistant, jellyfin, radarr, hermes-kraken, portainer, rclone, cloudflared, flaresolverr, watchtower, **xray-reverse-bridge**. Docker Root Dir `/srv/dev-disk-by-uuid-6194539b-.../docker-data`.
+- **Bridge-конфиг содержит фикс #6612**: `/home/kraken/xray-reverse/config.json` → `freedom/direct` с `"finalRules":[{"action":"allow"}]`.
+- **Reverse-канал к TrueNAS жив**: bridge лог 2026-09-02 13:12: `dialing TCP to mallexxx.duckdns.org:12346` → `tunneling request` → `received request for udp:reverse:0`. Bridge = Xray **26.7.28** (`teddysun/xray:latest`).
+
+### Portal (TrueNAS) — состояние
+`xray-reverse-portal` Up 22h, reverse-канал от Kraken держится. Лог portal: `accepted tcp:8.6.112.0:80 [local -> reverse-out]` — запрос с локального SOCKS-входа уходит в reverse-out (в сторону Kraken). Конфиг portal без изменений (interconn :12346 REALITY client `a81c3179...` reverse-out; local :12345 SOCKS; routing `local→reverse-out`; placeholder-freedom). Сеть `caddy_default`, curl-контейнер в ней резолвит `xray-reverse-portal:12345` = `172.16.1.7`.
+
+### ❌ End-to-end payload по-прежнему НЕ проходит (даже с фиксом #6612)
+Тест временным контейнером `curlimages/curl` в сети `caddy_default` на TrueNAS:
+```
+docker run --rm --network caddy_default curlimages/curl:latest curl -sv --socks5-hostname xray-reverse-portal:12345 -m 20 http://api.ipify.org
+```
+→ verbos: `Opened SOCKS connection from 172.16.1.8 port ... to api.ipify.org port 80 (via 172.16.1.7 port 12345)` → `Request completely sent off` → **`Empty reply from server`** (соединение закрыто без ответа). Трафик доходит до portal, уходит в reverse-out, НО не возвращается от bridge → ответ теряется.
+
+### 🔑 ИСТИННЫЙ КОРЕНЬ (2026-09-02, интернет-поиск): issue XTLS/Xray-core #6242 — регрессия bridge в v26.5+
+Симптомы точно совпадают с [issue #6242](https://github.com/XTLS/Xray-core/issues/6242) (закрыта "not planned"):
+- Регрессия **только на стороне BRIDGE** (outbound-initiating), версия portal не важна.
+- С **v26.5+** (и 26.6.x) bridge стартует без ошибок, reverse-канал вроде устанавливается (`udp:reverse:0`), но **трафик не маршрутизируется через reverse tunnel**. Ровно наш случай на 26.7.28.
+- **Понижение ТОЛЬКО bridge до v26.4.25 мгновенно возвращает полную работу** без изменений конфига.
+- Связано с #5750 (BurstObservatory не успевает health-check динамически регистрируемых `rproxy-*` outbound'ов — до 10 мин) и обсуждением #5962 (stale-tunnel mappings после рестартов). PR #5101 прямо предупреждал: "reverse sub-protocol unstable, will break, кросс-версий совместимости НЕ гарантировано".
+- **Почему фикс #6612 не помог:** #6612 (`finalRules:allow`) лечит ДРУГУЮ проблему (Freedom блокирует payload) — мы её уже устранили. Но осталась регрессия маршрутизации #6242, которую `finalRules` не обходит.
+
+**Решение/кварк:** сдаунгрейд **bridge** до Xray **26.4.25** (образ `teddysun/xray:26.4.25`, существует на Docker Hub / GitHub Container Registry `ghcr.io/xtls/xray-core:26.4.25`). Portal-сторона (26.7.28) остаётся.
+
+### План внедрения (согласован с Alex — что НЕ трогать `vpn.mallexxx` и `xray-admin`)
+1. На Kraken: остановить `xray-reverse-bridge` контейнер.
+2. В `/home/kraken/xray-reverse/docker-compose.yml` сменить образ `teddysun/xray:latest` → `teddysun/xray:26.4.25`.
+3. `cd /home/kraken/xray-reverse && docker compose up -d` (пересоздаст bridge на 26.4.25).
+4. Проверить reverse-канал: bridge лог `udp:reverse:0`.
+5. Контрольный end-to-end: временный curl-контейнер в сети `caddy_default` на TrueNAS через `xray-reverse-portal:12345` → ожидаем выход с **IP Kraken** (`92.62.70.41`), НЕ IP TrueNAS.
+⛔ НЕ трогать: `xray-admin` / `vpn.mallexxx` / Caddy / portal.
+
+### ⚠️ Важное прояснение для будущих сессий (из этого диалога)
+Запрос юзера "не могу подключиться к xray на truenas до наших измерений" — это была путаница между **тремя** разными сущностями:
+1. `vless-proxy` (teddysun/xray, SOCKS :1080/:1081, outbound на удалённый VPS qentra.top) — **мёртв из-за удаления VPS** 2026-09-01.
+2. `xray-admin` (3x-ui) = **самостоятельный рабочий Xray-VPN из интернета** через `vpn.mallexxx.duckdns.org:443` (см. секцию «ВАЖНО 2026-09-02» выше). Жив, end-to-end проверен.
+3. reverse-туннель TrueNAS↔Kraken (portal `xray-reverse-portal` + bridge на Kraken) — это про проксирование egress ЛОКАЛЬНЫХ клиентов сети TrueNAS через Kraken. НЕ связан с vpn.mallexxx.
+
+
+## ❌ ФАКТИЧЕСКИЙ РЕЗУЛЬТАТ 2026-09-02: downgrade НЕ помог
+
+> ⚠️ ВАЖНО: вопреки секции «ИСТИННЫЙ КОРЕНЬ #6242» выше (которая была гипотезой, ещё не проверенной полностью), **полный downgrade обеих сторон до Xray 26.4.25 payload НЕ починил**. Это зафиксировано здесь как фактический итог.
+
+### Что было сделано (выполнено по факту, alive-диагностика)
+По согласованию с Alex (не трогая `vpn.mallexxx` / `xray-admin`) выполнено:
+1. Bridge (Kraken): `/home/kraken/xray-reverse/docker-compose.yml` → образ **`teddysun/xray:26.4.25`**. Docker Pull прошёл, контейнер на 26.4.25 (`Xray 26.4.25 ... go1.26.2 linux/arm64`). Бэкап: `docker-compose.yml.bak-26.7.28`.
+2. Portal (TrueNAS): `/mnt/RED_2TB/docker/reverse-portal/docker-compose.yml` → тоже **`teddysun/xray:26.4.25`** (Linux amd64, образ 21.59MB Pull). Бэкап: `docker-compose.yml.bak-26.7.28`. Контейнер `xray-reverse-portal` пересоздан.
+3. Portal `config.json` `loglevel` поднят на `debug` (для диагностики), залит в `/mnt/RED_2TB/docker/reverse-portal/config.json`.
+4. Локальные копии файлов на Mac (для правки): `~/xray-test/` → `docker-compose.bridge.yml`, `docker-compose.portal.yml`, `portal.config.json`, `config.json` (тестовый клиент vpn.mallexxx, удалить не нужно).
+5. После смены версии bridge перезапущен (для переустановки reverse-канала к новому portal).
+
+### Результат end-to-end теста (обе стороны 26.4.25)
+- Reverse-канал у bridge **устанавливается**: лог `dialing TCP to mallexxx.duckdns.org:12346` → `tunneling request to unknown` → `received request for udp:reverse:0`. Portal принимает (лог: `proxy/vless/inbound: received request for tcp:v1.rvs.cool:0` → `dispatching request to udp:reverse:0`).
+- **НО payload по-прежнему НЕ проходит**: тест curl через `xray-reverse-portal:12345` → `Empty reply from server` / `exit=52`.
+- **Portal (TrueNAS) debug-лог полностью проясняет картину:**
+ - При запросе: `[118463829] proxy/socks: TCP Connect request to tcp:api.ipify.org:80` → `[118463829] app/dispatcher: taking detour [reverse-out] for [tcp:api.ipify.org:80]` — **и НИЧЕГО дальше** (ни ошибки, ни dial к bridge). Dispatch в `reverse-out` молча глотается.
+ - Фоновые разрывы: `common/mux: failed to read metadata > read tcp 172.16.1.7:12346->92.62.70.41:3266: connection reset by peer` — portal пытается что-то слать к bridge, но канал рвётся.
+- **Критично:** на TrueNAS **НЕТ постоянного ESTABLISHED TCP-соединения от bridge на :12346** (`ss -tn sport=:12346` пусто). Reverse-канал НЕ держится постоянным — устанавливается эфемерно (per контрольный UDP прочёт), и data-stream по нему не доходит до bridge.
+- Bridge (Kraken) никогда не логирует приём `reverse-in` TCP-payload (только контрольный `udp:reverse:0`).
+
+### Вывод
+Проблема **НЕ** регрессия #6242 фиксируемая версией bridge — иначе downgrade до рабочей по issue пары 26.4.25↔26.4.25 решил бы. После полного downgrade payload по-прежнему мёртв. **Настоящая причина: reverse-канал portal↔bridge не удерживается постоянным на TCP-уровне** (нет стабильного ESTABLISHED :12346), поэтому dispatch портала в `reverse-out` не находит живой транспорт до bridge и молча теряет данные.
+
+Это согласуется с предупреждением PR #5101: **новый VLESS Reverse sub-protocol itself нестабилен** («will break, кросс-версий совместимость не гарантирована») — по-видимому канал между двумя разнесёнными docker-реализациями (Kraken arm64 ↔ TrueNAS amd64, обе 26.4.25) не держится стабильно.
+
+### Дальнейшие гипотезы (НЕ проверены, треб.WB)
+1. Транспортный REALITY mismatch arm64(26.4.25 bridge) ↔ amd64(26.4.25 portal) даёт нестабильный mux → попробовать не-REALITY (простой TCP, т.к. канал только между сервисами TrueNAS↔Kraken, не извне) — убрать REALITY, оставить VLESS-TCP без camouflage.
+2. Перепроверить, что bridge реально удерживает единственное mux-соединение (в xray reverse bridge обычно держит persistent канал, у нас его нет → пере-аудит конфиг bridge: возможно не хватает чего-то, заставляющего держать канал постоянно).
+3. Запросить консультацию/повторно изучить рабочую конфигурацию сбора из живого разбора темы (потому что каноничные примеры из доки и issues не дали полного рабочего egress-конфига).
+
+### ⚠️ ТЕКУЩЕЕ СОСТОЯНИЕ СИСТЕМ (на момент записи, 2026-09-02)
+- **Версии:** BOTH portal и bridge сейчас на **`teddysun/xray:26.4.25`** (исходно были на `:latest` = 26.7.28). Откат при необходимости: поменять образ в compose обратно на `teddysun/xray:latest` и `docker compose up -d`.
+- Конфиг portal имеет `loglevel: debug` (пока). Bridge `config.json` содержит фикс #6612 `finalRules:allow`.
+- `vpn.mallexxx.duckdns.org` / `xray-admin` / Caddy — **НЕ тронуты**, работают (см. секцию «ВАЖНО 2026-09-02»).
+- Reverse к Kraken **НЕ внедрён/не работает end-to-end** — это остаётся открытой задачей.
+
+## ⏳ Открытые вопросы по reverse (требуют ответа/действия Alex)
+
+## План реализации (история; Шаг 1 устарел — см. «ВНЕДРЕНО» выше)
+
+### Шаг 1 — TrueNAS: Xray reverse-server поверх Caddy
+- **Способ (рекомендован): Caddy TLS-pass-through.** Добавить в Caddy TCP-правило: поддомен `xray.mallexxx.duckdns.org:443` → внутренний порт Xray-контейнера (напр. `localhost:8443`). Caddy передаёт сырой TLS-стрим дальше. Xray на TrueNAS принимает VLESS+Reality/TLS. Kraken ходит на `xray.mallexxx.duckdns.org:443`.
+ - Плюс: переиспользуем уже открытый/проброшенный 443 на роутере, не трогаем роутер, туннель маскируется под HTTPS.
+ - Альтернатива: пробросить отдельный порт на роутере (напр. 8443) → требует доступа к роутеру. Менее предпочтительно.
+- Новый/доразвернутый Xray-контейнер:
+ - inbound `reverse`/`dokodemo-door` на 8443 (извне по pass-through)
+ - local inbound SOCKS/HTTP (уже есть 1080/1081)
+ - routing: трафик клиентов → в reverse-канал к Kraken
+
+### Шаг 2 — TrueNAS: бэкап перед изменением
+- Снять копию текущего конфига `vless-proxy` (config.json), в `/mnt/RED_2TB/docker//backup/` (паттерн как с cups-splix).
+
+### Шаг 3 — Kraken: Xray outbound reverse в Docker
+- Контейнер Xray на Kraken (`docker run --restart unless-stopped`, как остальные).
+- outbound vless → `xray.mallexxx.duckdns.org:443` (через Caddy pass-through).
+- inbound SOCKS/HTTP на Kraken — точка выхода.
+- reverse-конфиг: Kraken регистрирует «сервис» (весь трафик через dokodemo-door) наружу через канал к TrueNAS.
+
+### Шаг 4 — Проверка связности
+- Kraken → `xray.mallexxx.duckdns.org:443` (TCP).
+- Локальный клиент → TrueNAS:1080 → curl через прокси → должен выйти с IP Kraken.
+
+### Шаг 5 — Обновить Obsidian после внедрения
+- Дополнить `family/how-to/truenas-infrastructure.md` (Xray reverse-настройка), `family/how-to/kraken-access.md`; обновить `personal/tech/vps-qentra.md` (VPS удалён, ссылки на него).
+
+## Открытые вопросы (требуют ответа Alex)
+
+1. ✅ (решено) **Проброс порта для reverse** — переведён на TCP+REALITY, ВСЁ ВЫПОЛНЕНО (portal пересоздан с REALITY, OpenWrt DNAT `внешний:12346 → 192.168.2.197:12346` добавлен, bridge на Kraken пересоздан). См. секции «ВНЕДРЕНО — TCP+REALITY» выше. **Компанент работает, но payload НЕ проходит (см. пункт 4).**
+2. **Какой трафик TrueNAS пустить через Kraken** — весь исходящий интернет, или конкретные сервисы/подсети? (Влияет на маршрутизацию на Kraken.) — всё ещё открыто.
+3. ✅ **Kraken docker** — РАБОТАЕТ, ВОССТАНОВИЛСЯ 2026-09-02: `systemctl is-active docker` → `active`, диск `/dev/sda1 1.8T` смонтирован к `/srv/dev-disk-by-uuid-6194539b-...`, 235G свободно (87% занято). **Все контейнеры восстановились** (в отличие от 2026-09-01, когда было 0): transmission, sonarr, prowlarr, homeassistant, jellyfin, radarr, hermes-kraken, portainer, rclone, cloudflared, flaresolverr, watchtower, **xray-reverse-bridge** (Up).
+4. 🔑 **End-to-end payload НЕ проходит даже после фикса #6612** — **ИСТИННЫЙ КОРЕНЬ НАЙДЕН (2026-09-02, issue #6242)**. Несмотря на то что фикс `finalRules:[{action:"allow"}]` применён на bridge и Kraken полностью восстановлен (docker active, bridge перезапущен с фиксом, reverse-канал `udp:reverse:0` жив), payload всё равно не проходит: тест временным curl-контейнером в сети `caddy_default` через `xray-reverse-portal:12345` → verbos `Opened SOCKS connection... Empty reply from server`. **Причина: регрессия роутинга VLESS Reverse на BRIDGE-стороне в Xray v26.5+** (bridge на `teddysun/xray:latest` = 26.7.28). Issue #6242 закрыта "not planned" — фикса нет. **Решение/кварк: сдаунгрейд bridge до `teddysun/xray:26.4.25`** (образ существует на Docker Hub), portal-сторона (26.7.28) остаётся. План согласован с Alex, выполнение ждёт команды. См. секцию «✅ 2026-09-02: Kraken восстановлен + ИСТИННЫЙ КОРЕНЬ #6242» ниже.
+
+## Связанные заметки
+- [[family/how-to/vps-qentra]] — VPS на 2026-09-01 УДАЛЁН
+- [[family/how-to/truenas-infrastructure]] — TrueNAS Caddy/контейнеры
+- [[family/how-to/kraken-access]] — Docker Kraken
+- [[family/how-to/rasputin-router]] — прежний VLESS-туннель на VPS (тоже требует пересмотра, VPS нет)
+- [[family/how-to/wireguard-vpn]] — WG Eagle↔VPS↔Kraken (VPS-звено теперь мёртво)
diff --git a/personal/tech/xray-reverse-tunnel-kraken-truenas.md.bak-per-user-20260902-1229 b/personal/tech/xray-reverse-tunnel-kraken-truenas.md.bak-per-user-20260902-1229
new file mode 100644
index 00000000..53cbd362
--- /dev/null
+++ b/personal/tech/xray-reverse-tunnel-kraken-truenas.md.bak-per-user-20260902-1229
@@ -0,0 +1,388 @@
+---
+title: Xray Reverse Tunnel — Kraken ↔ TrueNAS
+created: '2026-09-01'
+updated: '2026-09-02'
+type: tech
+namespace: personal
+tags:
+ - xray
+ - reverse
+ - kraken
+ - truenas
+ - tunnel
+ - networking
+confidence: high
+related:
+ - '[[family/how-to/vps-qentra]]'
+ - '[[family/how-to/truenas-infrastructure]]'
+ - '[[family/how-to/kraken-access]]'
+ - '[[family/how-to/rasputin-router]]'
+downgrade_to_26.4.25: >-
+ portal+bridge BOTH pinned to 26.4.25; required but insufficient by itself.
+verified_fix_2026_09_02: >-
+ Kraken bridge must use Docker network_mode: host; Docker bridge/NAT reset the
+ VLESS reverse mux. REALITY+Vision verified end-to-end with Kraken egress.
+---
+
+# Xray Reverse Tunnel — Kraken ↔ TrueNAS
+
+> **Статус: ✅ ВНЕДРЕНО И ПРОВЕРЕНО END-TO-END (2026-09-02).** TrueNAS SOCKS `:12345` → VLESS Reverse TCP+REALITY+Vision → Kraken → internet работает. HTTP и HTTPS тесты оба вернули выходной IP Kraken `92.62.70.41`. **Истинная причина:** Docker bridge/NAT на Kraken сбрасывал reverse mux; bridge должен работать с `network_mode: host`. Более ранние секции со статусом «не работает» и гипотезами #6612/#6242 сохранены ниже как история диагностики и суперсидированы секцией «Верифицированный фикс».
+> Архитектурное решение: проксировать исходящий трафик локальных клиентов сети TrueNAS через **TrueNAS → Kraken → интернет**.
+
+> ## ✅ ВАЖНО (2026-09-02): `xray-admin` (3x-ui) на TrueNAS — это ОДНОВРЕМЕННО РАБОЧИЙ САМОСТОЯТЕЛЬНЫЙ Xray-VPN-сервер
+> Путаница в вопросе юзера выявила: `vpn.mallexxx.duckdns.org:443` — это **не только reverse-frontend**, а полноценный Xray-сервер со **своим собственным выходом в интернет** (outbound `freedom`/`direct` → сразу через TrueNAS), НЕ зависящий от reverse-канала к Kraken. Это **отдельная фича**, параллельная reverse-туннелю.
+> - **Проверено end-to-end 2026-09-02** (временный xray-клиент с Mac): VLESS+WS через `vpn.mallexxx.duckdns.org:443` → HTTP 200, выход IP `90.189.160.148` = TrueNAS. Контейнеры `xray-admin` (Up 21h) + `caddy` (Up 20h) живы.
+> - Inbound `in-10095-tcp` (VLESS-WS): client id `ce320965-6956-4759-84bb-7cb71cfc6252` (user1), `security: none`, path `/vless`, host `vpn.mallexxx.duckdns.org`. TLS терминирует Caddy → в клиенте `network: ws` + TLS на домен, **без** двойного TLS внутрь.
+> - Полные параметры и pitfalls (вкл. удаление `allowInsecure` в Xray 26.7.28) — в `family/how-to/truenas-infrastructure.md`, раздел `xray-admin`.
+> - Reverse к Kraken — это ОТДЕЛЬНЫЙ механизм (для проксирования локальных клиентов сети TrueNAS через Kraken-egress). Он теперь также внедрён и проверен; см. «Верифицированный фикс». 3x-ui-сервер остаётся независимым рабочим VPN-выходом через TrueNAS.
+
+## Контекст / Почему
+
+- **VPS qentra.top (91.207.28.205) УДАЛЁН** — вся прежняя Xray-инфраструктура на нём (VLESS+REALITY, OpenVPN, WebSocket v.qentra.top) больше не существует.
+- Нужен новый путь для выхода локальных клиентов сети TrueNAS в интернет через другую точку выхода (Kraken).
+- Белый IP есть только у **TrueNAS** (`mallexxx.duckdns.org` = `90.189.160.148`).
+- **Kraken за NAT**, входящие не принимает — только исходящие соединения.
+
+## Принятая схема
+
+```
+Локальные клиенты (сеть TrueNAS, 192.168.2.x)
+ │ шлют трафик на локальный прокси TrueNAS (SOCKS 1080 / HTTP 1081)
+ ▼
+TrueNAS ←── контроллер / bridge (белый IP, mallexxx.duckdns.org), принимает
+ │ TrueNAS заворачивает трафик в reverse-канал
+ ▼ ▲
+Kraken ──┘ держит ИСХОДЯЩИЙ reverse-канал к TrueNAS, отпускает трафик → интернет
+ ▼
+интернет
+```
+
+**Тип решения: Xray `reverse`.** Роли по Xray:
+
+| Узел | Роль | Держит канал? | Выход в интернет? |
+|------|------|---------------|-------------------|
+| **TrueNAS** | bridge/контроллер (inbound `reverse`) | ❌ слушает | ❌ |
+| **Kraken** | outbound reverse-нода + exit | ✅ **исходящий** к TrueNAS | ✅ **да** |
+| **Локальные клиенты** | используют TrueNAS как локальный прокси-шлюз | — | через Kraken |
+
+**Ключевое физическое ограничение:** Kraken за NAT не может принимать входящих. Поэтому канал держит **Kraken исходящим** к TrueNAS. Для передачи клиентского трафика TrueNAS → Kraken используются конструкции `dokodemo-door` + `reverse` + policy-маршрутизация (routing rules). Это чуть сложнее "поставить reverse и всё", конфиг нужен аккуратный.
+
+## ⚠️ Факты, проверенные 2026-09-01 (важно, ломают прежние допущения)
+
+1. **На 443 у TrueNAS НЕ Xray.** Проверено `openssl s_client`: на `mallexxx.duckdns.org:443` отвечает **обычный TLS 1.3 с валидным Let's Encrypt сертификатом для `mallexxx.duckdns.org`** (`issuer=Let's Encrypt/CN=YE2`). Это **Caddy/nginx reverse-proxy**, НЕ Xray REALITY (у REALITY сертификат был бы чужой/поддельный). → Твоя память «на 443 висел xray server» не подтверждается.
+2. **`vless-proxy` на TrueNAS** (контейнер `teddysun/xray:latest`, Up 7 дней):
+ - inbound: SOCKS `0.0.0.0:1080`, HTTP `0.0.0.0:1081` (локально в LAN TrueNAS)
+ - outbound: VLESS+WS+TLS на `v.qentra.top:443`, path `/qentra`, id `2D9F24C4-21FE-4784-9843-F11C384DA67A` — **указывает на УДАЛЁННЫЙ VPS → сейчас мёртвый**.
+ - ⚠️ Используется Hermes-Taiga как SOCKS5-прокси (`vless-proxy:1080`) → **Hermes-Taiga сейчас без рабочего прокси**.
+3. **Kraken→TrueNAS по `mallexxx.duckdns.org`:** открыты **только 22 (SSH) и 443 (HTTPS/TLS)**. `8443/8964/8080/9000` — closed. Порт 443 — TLS (Caddy), не сырой.
+4. **Kraken:** Docker установлен (`/usr/bin/docker`), но демон отвечает медленно/рвёт SSH (проверка `docker ps` не завершилась за 40s). Xray на Kraken **отсутствует** (`which xray` пусто) — нужен Docker-контейнер.
+5. **Связанность Kraken↔TrueNAS по 22/443 — подтверждена** (оба OPEN с Kraken).
+
+## ✅ ВНЕДРЕНО 2026-09-01: 3x-ui на TrueNAS (фронтенд + Docker Compose)
+
+**Решение Alex:** использовать **3x-ui frontend** + **Docker Compose** (управление клиентами через панель), а не ручной Caddy-pass-through с сырым Xray. Это изменило исходный план реализации (Шаг 1 ниже устарел по способу).
+
+### Развёрнут контейнер `xray-admin` (TrueNAS)
+- **Имя контейнера:** `xray-admin` (строго, т.к. Caddyfile резолвит `xray-admin` по имени в docker-сети).
+- **Образ:** `ghcr.io/mhsanaei/3x-ui:latest` (**3.7.0**, Xray **26.7.28**).
+- **Сеть:** `caddy_default` (external) — там же Caddy, чтобы резолвить имя.
+- **Volume:** `/mnt/RED_2TB/docker/xray-admin:/etc/x-ui` (туда лёг существующий `x-ui.db`).
+- **Порт панели:** хостовый `54321 → 54321` (внутри панель реально слушает **2053** — Caddy проксирует `vpn-panel.mallexxx.duckdns.org` → `xray-admin:2053`).
+- **Compose-файл:** `/mnt/RED_2TB/docker/xray-admin/docker-compose.yml` (deployed версия с `TZ=Asia/Novosibirsk`, `PUID/PGID=950`; см. актуальный файл на TrueNAS — отличается от черновика в плане).
+- **Панель доступна:** `https://vpn-panel.mallexxx.duckdns.org/` → **HTTP 200**.
+- **Sub-сервер:** `[::]:443` (path `/sub`), панель `[::]:2053`, inbound `vless-ws:10095` (path `/vless`, host `vpn.mallexxx.duckdns.org`).
+
+### Почему это заработало «из коробки» (важно)
+База `/mnt/RED_2TB/docker/xray-admin/x-ui.db` **уже была настроена под эту Caddy-интеграцию** (раньше 3x-ui уже задумывался на TrueNAS): inbound `vless-ws` port 10095 tag `in-10095-tcp`, subDomain `vpn-panel.mallexxx.duckdns.org`, subPort 443, subScheme https. Caddyfile уже содержал (мёртвые до подъёма) блоки:
+- `vpn.mallexxx.duckdns.org` → `@ws path /vless` → `xray-admin:10095` (WS)
+- `vpn-panel.mallexxx.duckdns.org` → `@sub path /sub/*` → `xray-admin:443` + fallback `xray-admin:2053`
+- LE-сертификаты для этих поддоменов уже выданы.
+
+### 3x-ui поддерживает reverse
+В бинарнике `/app/x-ui` присутствует **`clientReverseTags`** → reverse-настройка реализуема через панель 3x-ui (3.7.0).
+
+### Бэкап (сделан до изменений)
+`/mnt/RED_2TB/docker/backups/reverse-xray-3xui-20260901-113625/` — содержит: `caddy/Caddyfile` (копия из контейнера, 90 строк), `xray-admin/x-ui.db`, `docker-inventory.txt`.
+
+### Мелочь/питфолл
+Скопированный в volume `docker-compose.yml` оказался внутри контейнера `/etc/x-ui/` (т.к. volume смонтирован туда) — удалить лишний файл из контейнера: `docker exec xray-admin rm -f /etc/x-ui/docker-compose.yml`.
+
+## ✅ ВНЕДРЕНО 2026-09-01: Reverse portal (TrueNAS) + bridge (Kraken) — VLESS-WS
+
+После 3x-ui развёрнут полноценный reverse. **Ключевое открытие:** Xray **26.x заменил legacy reverse на "VLESS Reverse Proxy"** — старая схема `reverse.bridges/portals` (Xray-examples/ReverseProxy) **не работает** в этой версии (ошибка `The feature "legacy reverse" has been removed and migrated to "VLESS Reverse Proxy"`). Новая схема: `reverse.tag` в VLESS-клиентах/аутбаундах (примеры — `xtls.github.io/en/document/level-2/vless_reverse.html`, use case "Home Broadband Egress").
+
+### Роли (новая терминология VLESS Reverse)
+- **Internal device (Kraken) = BRIDGE**: VLESS-**outbound** с `"reverse":{"tag":"reverse-in"}` → активно устанавливает канал к TrueNAS; на своей стороне создаётся виртуальный **inbound** `reverse-in`, чей трафик направляется в freedom (интернет).
+- **Public server (TrueNAS) = PORTAL**: VLESS-**inbound** с `"reverse":{"tag":"reverse-out"}` у клиента → создаёт **routable-маутбаунд** `reverse-out`; локальные клиенты (SOCKS) маршрутизируются в `reverse-out`.
+- `reverse.tag` на двух сторонах **не обязаны совпадать** — соответствие через общий UUID соединения.
+
+### TrueNAS — `xray-reverse-portal` (папка `/mnt/RED_2TB/docker/reverse-portal/`)
+compose: image `teddysun/xray:latest` (26.7.28), сеть `caddy_default`, volume `config.json:/etc/xray/config.json:ro`, проброс host **`12345:12345`**.
+`config.json`:
+- inbound `interconn` (:12346, VLESS, ws path `/rvs`, host `vpn.mallexxx.duckdns.org`, client id `a81c3179-312b-4c5e-8a46-6bf3c30c2941`, `"reverse":{"tag":"reverse-out"}`)
+- inbound `local` (:12345, SOCKS `noauth udp:true`) — точка входа для клиентов сети TrueNAS
+- routing: `inboundTag:["local"] → outboundTag:"reverse-out"`
+- outbounds: `freedom` (placeholder — обязателен, иначе `reverse-out` станет default и весь трафик уйдёт в reverse)
+- Порт 12346 НЕ проброшен наружу — к нему обращается Caddy по имени `xray-reverse-portal:12346` в docker-сети.
+
+### TrueNAS — Caddyfile (bind mount `/mnt/RED_2TB/docker/caddy/Caddyfile`)
+Добавлен маршрут в блок `vpn.mallexxx.duckdns.org`:
+```caddy
+@rvs path /rvs
+reverse_proxy @rvs xray-reverse-portal:12346
+```
+Питфоллы: **Caddyfile нельзя править `docker cp`** в контейнер (volume → `device or resource busy`) — править на хосте через `docker run --rm -v /:/host alpine cp /host/tmp/...`. Валидация `docker exec caddy caddy validate --config /tmp/Caddyfile.new` → "Valid configuration". Перезапуск `docker restart caddy` безопасен. Бэкап: `Caddyfile.pre-reverse`.
+
+### Kraken — `xray-reverse-bridge` (папка `/home/kraken/xray-reverse/`)
+compose: image `teddysun/xray:latest`, volume `config.json:/etc/xray/config.json:ro`.
+`config.json`:
+- outbound `direct` = `freedom` + `"finalRules":[{"action":"allow","network":"tcp,udp","ip":["0.0.0.0/0"]}]` (интернет-egress Kraken)
+- outbound `conn` = **VLESS упрощённого стиля** (`settings.address/port/id/encryption/reverse` — НЕ `vnext[]`!) → `vpn.mallexxx.duckdns.org:443` ws `/rvs` `"reverse":{"tag":"reverse-in"}`, security tls, tlsSettings.serverName `vpn.mallexxx.duckdns.org`
+- routing: `inboundTag:["reverse-in"] → outboundTag:"direct"`
+- **Питфолл:** VLESS-outbound с `reverse` должен быть упрощённого стиля. Если через `vnext[]/users[]` → Xray 26.x: `VLESS users: please use simplified outbound's config style to use "reverse"`.
+- `loglevel debug` (для диагностики).
+
+### Reverse-канал: ✅ установлен
+- Kraken `netstat`: `172.24.0.2:... → 90.189.160.148:443 ESTABLISHED`
+- Portal: `::ffff:172.16.1.7:12346 ::ffff:172.16.1.3:52616 ESTABLISHED` (172.16.1.3 = Caddy)
+- Bridge logs: `common/mux: received request for udp:reverse:0`
+
+### ❌ End-to-end payload НЕ работает
+- `curl --socks5 127.0.0.1:12345 http://api.ipify.org` на TrueNAS → `code=000` (прямой curl → 200).
+- Portal логи: `accepted tcp:8.47.69.0:80 [local -> reverse-out]` — запрос ушёл в reverse-out.
+- **Bridge НЕ логирует received для этого TCP-payload** — данные теряются между reverse-out (portal) и reverse-in (bridge).
+- Kraken имеет прямой интернет (`api.ipify` → `92.62.70.41`), проблема не в egress.
+
+### ✅ ВНЕДРЕНО (2026-09-01) — TCP+REALITY переход, все шаги выполнены
+WS-транспорт не пропускал reverse-payload; переведён на **прямой TCP + REALITY** (Alex согласовал проброс). Все 4 шага ВЫПОЛНЕНЫ:
+1. ✅ Пересоздан `xray-reverse-portal` на TrueNAS (compose `12345:12345` + `12346:12346`, config REALITY TCP). Проверено `ss -tlnp` → `0.0.0.0:12346 LISTEN`.
+2. ✅ OpenWrt DNAT добавлен: redirect `xray-reverse-12346`, `src_dport=12346` → `dest_ip=192.168.2.197:12346`, `target=DNAT`, `/etc/init.d/firewall reload` → `DNAT_ADDED`. Проверено: `mallexxx.duckdns.org:12346` → **OPEN** извне.
+3. ✅ Пересоздан `xray-reverse-bridge` на Kraken (config REALITY TCP). Reverse-канал ESTABLISHED: Kraken `172.24.0.2 → 90.189.160.148:12346` + `common/mux: received request for udp:reverse:0`.
+4. ❌ **Тест payload НЕ прошёл даже на TCP+REALITY**: `curl --socks5 127.0.0.1:12345 http://api.ipify.org` → **`code=000`**. Portal: `accepted tcp:8.6.112.0:80 [local -> reverse-out]`, но bridge НЕ логирует приход TCP-payload.
+
+### ❌ Дополнительно пробовано: снятие `flow: xtls-rprx-vision`
+Убрал `flow: xtls-rprx-vision` с обеих сторон (portal interconn client + bridge conn outbound), пересоздал контейнеры (оба `Configuration OK`). Результат: **по-прежнему `code=000`**. Reverse-канал устанавливается, TCP-payload до bridge не доходит.
+
+**Вывод:** проблема НЕ в `flow` и НЕ в WS. **Даже на «каноничном» TCP+REALITY payload от portal-reverse-out до bridge-reverse-in не передаётся** (bridge не получает inbound-TCP). Гипотеза про WS **опровергнута**.
+
+### 🔑 КОРЕНЬ ПРОБЛЕМЫ НАЙДЕН (2026-09-01, интернет-поиск) — issue XTLS/Xray-core #6612
+
+**Симптомы точно совпадают с #6612:** reverse-канал устанавливается (`udp:reverse:0` на месте), но TCP-payload не проходит; portal логирует `accepted tcp:... -> reverse-out`, а bridge НЕ получает входящих reverse-in-соединений; curl → 000.
+
+**Причина:** начиная с **Xray v26.5+** (PR #6027) у outbound `freedom`/`direct` появилась **дефолтная политика безопасности**, которая **блокирует ВСЕ цели для трафика VLESS Reverse**, если не задан явный `finalRules`. Контрольный reverse-канал при этом продолжает устанавливаться — поэтому «всё выглядит подключённым», но реальный payload молча отбрасывается. Это ровно наш случай на версии **26.7.28**.
+
+**Точный фикс** — добавить в freedom `direct` на **BRIDGE** (место реального egress из reverse-in в интернет):
+```json
+{
+ "protocol": "freedom",
+ "tag": "direct",
+ "settings": {
+ "domainStrategy": "AsIs",
+ "finalRules": [ { "action": "allow" } ]
+ }
+}
+```
+Issue говорит прямо: проблема воспроизводится с обычным Freedom без finalRules вообще, и добавление безусловного `allow` чинит на 26.7.28.
+
+**Релевантные ссылки:**
+- **#6612** — главный фикс: `https://github.com/XTLS/Xray-core/issues/6612`
+- **#6027** — корень (finalRules у Direct/Freedom): `https://github.com/XTLS/Xray-core/pull/6027`
+- Документация freedom: `https://xtls.github.io/en/config/outbounds/freedom.html`
+- 3x-ui разбор под reverse: `https://github.com/MHSanaei/3x-ui/issues/4782`
+- **#2664** — если finalRules не поможет: `flow: xtls-rprx-vision` на BRIDGE-outbound + REALITY может ломать доставку (держите `flow:""` на reverse-клиенте): `https://github.com/XTLS/Xray-core/issues/2664`
+- **Регрессия роутинга reverse v26.5+** (если фикс не поможет): #6242, #6195, #6248 — временный кварк: пинить **v26.4.25**.
+
+**Важные детали из поиска (проверить при продолжении):**
+- Портал ДОЛЖЕН иметь placeholder-freedom (у нас есть) — иначе reverse-out станет default. Плейсхолдеру не нужен `finalRules:allow` (он обслуживает только несопоставленный трафик).
+- Роутинг `inboundTag:["reverse-in"] -> direct` на bridge — нужен (у нас есть).
+- У VLESS outbound поле `encryption` обязательно (`"none"` или парный PQ-ключ к серверному `decryption`) — у нас `"none"`, ок.
+
+### ✅ ФИКС ПРИМЕНЁН, но заблокирован (2026-09-01)
+
+Новый bridge-конфиг с `finalRules:[{action:"allow"}]` в `direct` **залит** на Kraken (`/home/kraken/xray-reverse/config.json`, 1098 байт, проверено `cat | head -5`). НО:
+- ⛔ **Kraken по docker НЕДОСТУПЕН**: `systemctl is-active docker` → **`activating`** (не `active`), демон застрял, накоплено множество зависших docker-процессов (ps/run/compose).
+- **Причина: USB-HDD снова не поднялся** — `lsblk /dev/sda` → **`0B`** (без раздела). Docker data-root = `/srv/dev-disk-by-uuid-49e8f586-3839-4c5d-a1e1-58bfc3579ade/docker-data` (на этом HDD) → daemon ждёт диск и застревает.
+- ⚠️ **Замечено расхождение UUID**: сейчас data-root указывает на `/srv/dev-disk-by-uuid-49e8f586-...`, а в контексте ранее фигурировал смонтированный HDD `/srv/dev-disk-by-uuid-6194539b-...` (sda1 1.8T). Текущий `sda` = 0B без раздела.
+- **`docker compose down/up` для bridge не выполнен** — контейнер всё ещё со старым конфигом (больше не деплоится, daemon не отвечает).
+
+**Шаг для продолжения (требует подтверждения Alex):** починить HDD/docker на Kraken (повторить утренний сценарий: `sudo reboot` или физическое переподключение USB-диска), затем пересоздать bridge-контейнер (`cd /home/kraken/xray-reverse && docker compose down && docker compose up -d`), затем тест `curl --socks5 127.0.0.1:12345 http://api.ipify.org` на TrueNAS → ожидаем выход с IP Kraken.
+
+**Статус: задание НЕ завершено — остаётся применить bridge-фикс после восстановления docker на Kraken.**
+
+## ✅ 2026-09-02: Kraken восстановлен (диск/docker) + фикс #6612 применён — НО payload всё равно мёртв → ИСТИННЫЙ КОРЕНЬ #6242 (bridge-side v26.5+)
+
+### Kraken полностью поднялся (проверено живьём по SSH)
+- Uptime 2 мин — Kraken перезагрузился (USB-HDD-сценарий). `systemctl is-active docker` был `activating` первые минуты (ждал поднятия диска), затем стал **`active`**.
+- **Диск `/dev/sda1` поднялся**: 1.8T, смонтирован к `/srv/dev-disk-by-uuid-6194539b-03e0-4f33-986b-4da09834e82f`, 235G свободно (87% занято). (В отличие от 2026-09-01, когда `sda` был `0B`.)
+- **Все контейнеры восстановились** (в прошлый раз — 0): transmission, sonarr, prowlarr, homeassistant, jellyfin, radarr, hermes-kraken, portainer, rclone, cloudflared, flaresolverr, watchtower, **xray-reverse-bridge**. Docker Root Dir `/srv/dev-disk-by-uuid-6194539b-.../docker-data`.
+- **Bridge-конфиг содержит фикс #6612**: `/home/kraken/xray-reverse/config.json` → `freedom/direct` с `"finalRules":[{"action":"allow"}]`.
+- **Reverse-канал к TrueNAS жив**: bridge лог 2026-09-02 13:12: `dialing TCP to mallexxx.duckdns.org:12346` → `tunneling request` → `received request for udp:reverse:0`. Bridge = Xray **26.7.28** (`teddysun/xray:latest`).
+
+### Portal (TrueNAS) — состояние
+`xray-reverse-portal` Up 22h, reverse-канал от Kraken держится. Лог portal: `accepted tcp:8.6.112.0:80 [local -> reverse-out]` — запрос с локального SOCKS-входа уходит в reverse-out (в сторону Kraken). Конфиг portal без изменений (interconn :12346 REALITY client `a81c3179...` reverse-out; local :12345 SOCKS; routing `local→reverse-out`; placeholder-freedom). Сеть `caddy_default`, curl-контейнер в ней резолвит `xray-reverse-portal:12345` = `172.16.1.7`.
+
+### ❌ End-to-end payload по-прежнему НЕ проходит (даже с фиксом #6612)
+Тест временным контейнером `curlimages/curl` в сети `caddy_default` на TrueNAS:
+```
+docker run --rm --network caddy_default curlimages/curl:latest curl -sv --socks5-hostname xray-reverse-portal:12345 -m 20 http://api.ipify.org
+```
+→ verbos: `Opened SOCKS connection from 172.16.1.8 port ... to api.ipify.org port 80 (via 172.16.1.7 port 12345)` → `Request completely sent off` → **`Empty reply from server`** (соединение закрыто без ответа). Трафик доходит до portal, уходит в reverse-out, НО не возвращается от bridge → ответ теряется.
+
+### 🔑 ИСТИННЫЙ КОРЕНЬ (2026-09-02, интернет-поиск): issue XTLS/Xray-core #6242 — регрессия bridge в v26.5+
+Симптомы точно совпадают с [issue #6242](https://github.com/XTLS/Xray-core/issues/6242) (закрыта "not planned"):
+- Регрессия **только на стороне BRIDGE** (outbound-initiating), версия portal не важна.
+- С **v26.5+** (и 26.6.x) bridge стартует без ошибок, reverse-канал вроде устанавливается (`udp:reverse:0`), но **трафик не маршрутизируется через reverse tunnel**. Ровно наш случай на 26.7.28.
+- **Понижение ТОЛЬКО bridge до v26.4.25 мгновенно возвращает полную работу** без изменений конфига.
+- Связано с #5750 (BurstObservatory не успевает health-check динамически регистрируемых `rproxy-*` outbound'ов — до 10 мин) и обсуждением #5962 (stale-tunnel mappings после рестартов). PR #5101 прямо предупреждал: "reverse sub-protocol unstable, will break, кросс-версий совместимости НЕ гарантировано".
+- **Почему фикс #6612 не помог:** #6612 (`finalRules:allow`) лечит ДРУГУЮ проблему (Freedom блокирует payload) — мы её уже устранили. Но осталась регрессия маршрутизации #6242, которую `finalRules` не обходит.
+
+**Решение/кварк:** сдаунгрейд **bridge** до Xray **26.4.25** (образ `teddysun/xray:26.4.25`, существует на Docker Hub / GitHub Container Registry `ghcr.io/xtls/xray-core:26.4.25`). Portal-сторона (26.7.28) остаётся.
+
+### План внедрения (согласован с Alex — что НЕ трогать `vpn.mallexxx` и `xray-admin`)
+1. На Kraken: остановить `xray-reverse-bridge` контейнер.
+2. В `/home/kraken/xray-reverse/docker-compose.yml` сменить образ `teddysun/xray:latest` → `teddysun/xray:26.4.25`.
+3. `cd /home/kraken/xray-reverse && docker compose up -d` (пересоздаст bridge на 26.4.25).
+4. Проверить reverse-канал: bridge лог `udp:reverse:0`.
+5. Контрольный end-to-end: временный curl-контейнер в сети `caddy_default` на TrueNAS через `xray-reverse-portal:12345` → ожидаем выход с **IP Kraken** (`92.62.70.41`), НЕ IP TrueNAS.
+⛔ НЕ трогать: `xray-admin` / `vpn.mallexxx` / Caddy / portal.
+
+### ⚠️ Важное прояснение для будущих сессий (из этого диалога)
+Запрос юзера "не могу подключиться к xray на truenas до наших измерений" — это была путаница между **тремя** разными сущностями:
+1. `vless-proxy` (teddysun/xray, SOCKS :1080/:1081, outbound на удалённый VPS qentra.top) — **мёртв из-за удаления VPS** 2026-09-01.
+2. `xray-admin` (3x-ui) = **самостоятельный рабочий Xray-VPN из интернета** через `vpn.mallexxx.duckdns.org:443` (см. секцию «ВАЖНО 2026-09-02» выше). Жив, end-to-end проверен.
+3. reverse-туннель TrueNAS↔Kraken (portal `xray-reverse-portal` + bridge на Kraken) — это про проксирование egress ЛОКАЛЬНЫХ клиентов сети TrueNAS через Kraken. НЕ связан с vpn.mallexxx.
+
+
+## ❌ ИСТОРИЯ ДИАГНОСТИКИ 2026-09-02: downgrade сам по себе не помог
+
+> ⚠️ ВАЖНО: вопреки секции «ИСТИННЫЙ КОРЕНЬ #6242» выше (которая была гипотезой, ещё не проверенной полностью), **полный downgrade обеих сторон до Xray 26.4.25 payload НЕ починил**. Это зафиксировано здесь как фактический итог.
+
+### Что было сделано (выполнено по факту, alive-диагностика)
+По согласованию с Alex (не трогая `vpn.mallexxx` / `xray-admin`) выполнено:
+1. Bridge (Kraken): `/home/kraken/xray-reverse/docker-compose.yml` → образ **`teddysun/xray:26.4.25`**. Docker Pull прошёл, контейнер на 26.4.25 (`Xray 26.4.25 ... go1.26.2 linux/arm64`). Бэкап: `docker-compose.yml.bak-26.7.28`.
+2. Portal (TrueNAS): `/mnt/RED_2TB/docker/reverse-portal/docker-compose.yml` → тоже **`teddysun/xray:26.4.25`** (Linux amd64, образ 21.59MB Pull). Бэкап: `docker-compose.yml.bak-26.7.28`. Контейнер `xray-reverse-portal` пересоздан.
+3. Portal `config.json` `loglevel` поднят на `debug` (для диагностики), залит в `/mnt/RED_2TB/docker/reverse-portal/config.json`.
+4. Локальные копии файлов на Mac (для правки): `~/xray-test/` → `docker-compose.bridge.yml`, `docker-compose.portal.yml`, `portal.config.json`, `config.json` (тестовый клиент vpn.mallexxx, удалить не нужно).
+5. После смены версии bridge перезапущен (для переустановки reverse-канала к новому portal).
+
+### Результат end-to-end теста (обе стороны 26.4.25)
+- Reverse-канал у bridge **устанавливается**: лог `dialing TCP to mallexxx.duckdns.org:12346` → `tunneling request to unknown` → `received request for udp:reverse:0`. Portal принимает (лог: `proxy/vless/inbound: received request for tcp:v1.rvs.cool:0` → `dispatching request to udp:reverse:0`).
+- **НО payload по-прежнему НЕ проходит**: тест curl через `xray-reverse-portal:12345` → `Empty reply from server` / `exit=52`.
+- **Portal (TrueNAS) debug-лог полностью проясняет картину:**
+ - При запросе: `[118463829] proxy/socks: TCP Connect request to tcp:api.ipify.org:80` → `[118463829] app/dispatcher: taking detour [reverse-out] for [tcp:api.ipify.org:80]` — **и НИЧЕГО дальше** (ни ошибки, ни dial к bridge). Dispatch в `reverse-out` молча глотается.
+ - Фоновые разрывы: `common/mux: failed to read metadata > read tcp 172.16.1.7:12346->92.62.70.41:3266: connection reset by peer` — portal пытается что-то слать к bridge, но канал рвётся.
+- **Критично:** на TrueNAS **НЕТ постоянного ESTABLISHED TCP-соединения от bridge на :12346** (`ss -tn sport=:12346` пусто). Reverse-канал НЕ держится постоянным — устанавливается эфемерно (per контрольный UDP прочёт), и data-stream по нему не доходит до bridge.
+- Bridge (Kraken) никогда не логирует приём `reverse-in` TCP-payload (только контрольный `udp:reverse:0`).
+
+### Вывод
+Проблема **НЕ** регрессия #6242 фиксируемая версией bridge — иначе downgrade до рабочей по issue пары 26.4.25↔26.4.25 решил бы. После полного downgrade payload по-прежнему мёртв. **Настоящая причина: reverse-канал portal↔bridge не удерживается постоянным на TCP-уровне** (нет стабильного ESTABLISHED :12346), поэтому dispatch портала в `reverse-out` не находит живой транспорт до bridge и молча теряет данные.
+
+Это согласуется с предупреждением PR #5101: **новый VLESS Reverse sub-protocol itself нестабилен** («will break, кросс-версий совместимость не гарантирована») — по-видимому канал между двумя разнесёнными docker-реализациями (Kraken arm64 ↔ TrueNAS amd64, обе 26.4.25) не держится стабильно.
+
+### Дальнейшие гипотезы (НЕ проверены, треб.WB)
+1. Транспортный REALITY mismatch arm64(26.4.25 bridge) ↔ amd64(26.4.25 portal) даёт нестабильный mux → попробовать не-REALITY (простой TCP, т.к. канал только между сервисами TrueNAS↔Kraken, не извне) — убрать REALITY, оставить VLESS-TCP без camouflage.
+2. Перепроверить, что bridge реально удерживает единственное mux-соединение (в xray reverse bridge обычно держит persistent канал, у нас его нет → пере-аудит конфиг bridge: возможно не хватает чего-то, заставляющего держать канал постоянно).
+3. Запросить консультацию/повторно изучить рабочую конфигурацию сбора из живого разбора темы (потому что каноничные примеры из доки и issues не дали полного рабочего egress-конфига).
+
+### ⚠️ ТЕКУЩЕЕ СОСТОЯНИЕ СИСТЕМ (на момент записи, 2026-09-02)
+- **Версии:** BOTH portal и bridge сейчас на **`teddysun/xray:26.4.25`** (исходно были на `:latest` = 26.7.28). Откат при необходимости: поменять образ в compose обратно на `teddysun/xray:latest` и `docker compose up -d`.
+- Конфиг portal имеет `loglevel: debug` (пока). Bridge `config.json` содержит фикс #6612 `finalRules:allow`.
+- `vpn.mallexxx.duckdns.org` / `xray-admin` / Caddy — **НЕ тронуты**, работают (см. секцию «ВАЖНО 2026-09-02»).
+- Reverse к Kraken **НЕ внедрён/не работает end-to-end** — это остаётся открытой задачей.
+
+## ⏳ Открытые вопросы по reverse (требуют ответа/действия Alex)
+
+## План реализации (история; Шаг 1 устарел — см. «ВНЕДРЕНО» выше)
+
+### Шаг 1 — TrueNAS: Xray reverse-server поверх Caddy
+- **Способ (рекомендован): Caddy TLS-pass-through.** Добавить в Caddy TCP-правило: поддомен `xray.mallexxx.duckdns.org:443` → внутренний порт Xray-контейнера (напр. `localhost:8443`). Caddy передаёт сырой TLS-стрим дальше. Xray на TrueNAS принимает VLESS+Reality/TLS. Kraken ходит на `xray.mallexxx.duckdns.org:443`.
+ - Плюс: переиспользуем уже открытый/проброшенный 443 на роутере, не трогаем роутер, туннель маскируется под HTTPS.
+ - Альтернатива: пробросить отдельный порт на роутере (напр. 8443) → требует доступа к роутеру. Менее предпочтительно.
+- Новый/доразвернутый Xray-контейнер:
+ - inbound `reverse`/`dokodemo-door` на 8443 (извне по pass-through)
+ - local inbound SOCKS/HTTP (уже есть 1080/1081)
+ - routing: трафик клиентов → в reverse-канал к Kraken
+
+### Шаг 2 — TrueNAS: бэкап перед изменением
+- Снять копию текущего конфига `vless-proxy` (config.json), в `/mnt/RED_2TB/docker//backup/` (паттерн как с cups-splix).
+
+### Шаг 3 — Kraken: Xray outbound reverse в Docker
+- Контейнер Xray на Kraken (`docker run --restart unless-stopped`, как остальные).
+- outbound vless → `xray.mallexxx.duckdns.org:443` (через Caddy pass-through).
+- inbound SOCKS/HTTP на Kraken — точка выхода.
+- reverse-конфиг: Kraken регистрирует «сервис» (весь трафик через dokodemo-door) наружу через канал к TrueNAS.
+
+### Шаг 4 — Проверка связности
+- Kraken → `xray.mallexxx.duckdns.org:443` (TCP).
+- Локальный клиент → TrueNAS:1080 → curl через прокси → должен выйти с IP Kraken.
+
+### Шаг 5 — Обновить Obsidian после внедрения
+- Дополнить `family/how-to/truenas-infrastructure.md` (Xray reverse-настройка), `family/how-to/kraken-access.md`; обновить `personal/tech/vps-qentra.md` (VPS удалён, ссылки на него).
+
+## Открытые вопросы (требуют ответа Alex)
+
+1. ✅ (решено) **Проброс порта для reverse** — переведён на TCP+REALITY, ВСЁ ВЫПОЛНЕНО (portal пересоздан с REALITY, OpenWrt DNAT `внешний:12346 → 192.168.2.197:12346` добавлен, bridge на Kraken пересоздан). См. секции «ВНЕДРЕНО — TCP+REALITY» выше. **Компанент работает, но payload НЕ проходит (см. пункт 4).**
+2. **Какой трафик TrueNAS пустить через Kraken** — весь исходящий интернет, или конкретные сервисы/подсети? (Влияет на маршрутизацию на Kraken.) — всё ещё открыто.
+3. ✅ **Kraken docker** — РАБОТАЕТ, ВОССТАНОВИЛСЯ 2026-09-02: `systemctl is-active docker` → `active`, диск `/dev/sda1 1.8T` смонтирован к `/srv/dev-disk-by-uuid-6194539b-...`, 235G свободно (87% занято). **Все контейнеры восстановились** (в отличие от 2026-09-01, когда было 0): transmission, sonarr, prowlarr, homeassistant, jellyfin, radarr, hermes-kraken, portainer, rclone, cloudflared, flaresolverr, watchtower, **xray-reverse-bridge** (Up).
+4. ✅ **End-to-end payload проходит.** #6612/#6242 оказались неполными гипотезами. Верифицированный корень — Docker bridge/NAT на Kraken; решение — Xray 26.4.25 + `network_mode: host` на bridge. См. authoritative-секцию ниже.
+
+## ✅ Верифицированный фикс 2026-09-02 (authoritative)
+
+> Эта секция суперсидирует все более ранние выводы «payload мёртв», «нет persistent ESTABLISHED» и предполагаемые корни #6612/#6242. Фикс найден и проверен живыми A/B-тестами.
+
+### Истинная причина
+
+`xray-reverse-bridge` на Kraken работал в обычной Docker bridge-сети. Docker bridge/NAT на этом узле сбрасывал long-lived VLESS reverse mux после успешной регистрации `udp:reverse:0`. Поэтому portal создавал `reverse-out`, но payload не доходил до `reverse-in`.
+
+Ключевой A/B-тест:
+
+1. Тот же JSON на temporary bridge amd64 внутри TrueNAS заработал сразу → portal/config/routing исправны.
+2. Тот же Xray 26.4.25 arm64 + тот же JSON на Kraken в `--network host` заработал сразу → CPU architecture и WAN исправны, отличие только в Docker network mode.
+3. После возврата REALITY+Vision туннель остался рабочим → проблема не в REALITY, Vision или TCP transport.
+
+### Постоянная конфигурация
+
+Kraken: `/home/kraken/xray-reverse/docker-compose.yml`
+
+```yaml
+services:
+ xray-reverse-bridge:
+ image: teddysun/xray:26.4.25
+ network_mode: host
+```
+
+Bridge config возвращён к защищённому VLESS TCP + REALITY + `flow: xtls-rprx-vision`. `direct` сохраняет `finalRules: [{"action":"allow"}]`. Portal на TrueNAS также на `teddysun/xray:26.4.25`, REALITY+Vision. `xray-admin`, Caddy и `vpn.mallexxx.duckdns.org` не менялись.
+
+`network_mode: host` расширяет сетевые права bridge-контейнера. В этом конфиге у него нет физических listening inbounds; `reverse-in` — виртуальный inbound Xray. Не добавлять в этот контейнер обычные inbounds без аудита bind address/firewall.
+
+### Финальная проверка
+
+2026-09-02 после permanent Compose deploy:
+
+- `docker inspect xray-reverse-bridge` → image `teddysun/xray:26.4.25`, network `host`, status `running`, restart count `0`.
+- Bridge лог: `received request for udp:reverse:0`, затем TCP payload принят в `reverse-in -> direct`.
+- HTTPS через SOCKS `xray-reverse-portal:12345` → `92.62.70.41`.
+- HTTP через тот же SOCKS → `92.62.70.41`.
+- `92.62.70.41` — публичный egress Kraken; TrueNAS egress `90.189.160.148` не использовался.
+
+### Бэкапы и rollback
+
+Kraken:
+
+- `/home/kraken/xray-reverse/docker-compose.yml.bak-bridge-network-20260902-1147`
+- `/home/kraken/xray-reverse/config.json.bak-plain-host-working-20260902-1146`
+- `/home/kraken/xray-reverse/config.json.bak-reality-vision-20260902-1142`
+
+TrueNAS:
+
+- `/mnt/RED_2TB/docker/reverse-portal/config.json.bak-plain-host-working-20260902-1146`
+- `/mnt/RED_2TB/docker/reverse-portal/config.json.bak-reality-vision-20260902-1142`
+
+Rollback network fix: вернуть compose-бэкап на Kraken и выполнить `docker compose up -d`. Это вернёт нерабочий Docker bridge mode, поэтому делать только для диагностики/отката.
+
+## Связанные заметки
+- [[family/how-to/vps-qentra]] — VPS на 2026-09-01 УДАЛЁН
+- [[family/how-to/truenas-infrastructure]] — TrueNAS Caddy/контейнеры
+- [[family/how-to/kraken-access]] — Docker Kraken
+- [[family/how-to/rasputin-router]] — прежний VLESS-туннель на VPS (тоже требует пересмотра, VPS нет)
+- [[family/how-to/wireguard-vpn]] — WG Eagle↔VPS↔Kraken (VPS-звено теперь мёртво)
diff --git a/personal/user-profile.md b/personal/user-profile.md
index e8af1e55..0d161a59 100755
--- a/personal/user-profile.md
+++ b/personal/user-profile.md
@@ -86,6 +86,7 @@ confidence: 0.9
- Home automation (Home Assistant, Zigbee, RPi)
- 3D-печать — [[3d-print-wishlist]]
+- **Сетевые принтеры (домашние):** Samsung CLX-216x (шарится через TrueNAS, адрес `192.168.2.197`) + Samsung M2020 (по AirPrint, дефолт на Mac). Диагностика печати: см. [[personal/tech/mac-print-shared-services]]
- **Видеоигры:** игровой ПК собран как TV-приставка (лончер, джойстики, эмуляторы настроены). Играет редко — паттерн накопления без использования. Прогресс: прошёл с Лизой уровень Shovel Knight, запустил Witcher 3 (вводная сцена).
- Настолки: Руммикуб, Шакал, Ticket to Ride, Hive, Rush Hour, Диксит
- Совместные игры с Лизой — [[games-wishlist]]
diff --git a/work/projects/cpm-extension-health-pixels-privacy-triage.md b/work/projects/cpm-extension-health-pixels-privacy-triage.md
new file mode 100644
index 00000000..92c53663
--- /dev/null
+++ b/work/projects/cpm-extension-health-pixels-privacy-triage.md
@@ -0,0 +1,70 @@
+# Privacy Triage: Apple - CPM Extension Health Pixels
+
+Status: **DRAFT**
+
+**Name:** Alex M
+**Email:** amartemyanov@duckduckgo.com
+**Objective:** O-E
+**PR:** [Add PR link]
+**Project:** https://app.asana.com/1/137249556945/project/1163321984198618/task/1216761517055116?focus=true
+
+## Pixels
+
+| Pixel | Trigger | Frequency |
+| -------------------------------------------------------------------------- | --------------------------------------------------------------------- | --------------- |
+| `debug_web_extension_cpm_initialization_failed_after_session_restoration` | CPM fails after a restored-page navigation. | Daily |
+| `debug_web_extension_cpm_initialization_failed_after_tab_crash` | CPM fails on the first eligible navigation after a tab crash. | Daily |
+| `debug_web_extension_cpm_initialization_failed_after_extension_reload` | CPM fails on the first eligible navigation after an extension reload. | Daily |
+| `debug_web_extension_cpm_initialization_failed_after_other` | CPM fails after another eligible navigation. | Daily |
+| `debug_web_extension_cpm_messaging_stuck_session_restoration` | Messaging remains stuck after a restoration-originated failure. | Daily + count, once/episode |
+| `debug_web_extension_cpm_messaging_stuck_tab_crash` | Messaging remains stuck across attempts associated with a tab crash. | Daily + count, once/episode |
+| `debug_web_extension_cpm_messaging_stuck_other` | Messaging remains stuck across other independent navigations. | Daily + count, once/episode |
+| `debug_web_extension_cpm_messaging_recovered_without_extension_reload` | A failed tab or stuck episode recovers without an extension reload. | Daily + count, once/episode |
+| `debug_web_extension_cpm_messaging_recovered_after_extension_reload` | A failed tab or stuck episode recovers after an extension reload. | Daily + count, once/episode |
+| `debug_web_extension_cpm_messaging_extension_reload_failed` | CPM still fails after a successful extension reload. | Daily + count, once/episode |
+
+iOS and macOS send the exact same pixel names. Parameters distinguish `platform=ios|macos` and `form_factor=phone|tablet|desktop`.
+`appVersion` is included; macOS also includes `pixelSource` and `channel`.
+
+## Detection Rules
+
+- Check only finished, current, main-frame HTTP(S) document navigations after a grace period. A failure means the extension is loaded and the dashboard remains `.waiting`; `cpmStage` is diagnostic data, not part of detection.
+- A redirected restored-page navigation remains classified as session restoration.
+- After restoration, any independent eligible document navigation can be the next attempt: reload, typed URL, link, new-tab navigation, or a real back/forward load.
+- Redirects do not count separately. Same-document, failed, non-HTTP(S), and BFCache navigations do not count when CPM is not expected to initialize again.
+- A tab crash marks only the next eligible navigation in that tab.
+- A successful extension reload marks only the next eligible CPM attempt.
+- `stuck` keeps the reason of the first initialization failure; a later failure does not replace it.
+- Any successful CPM initialization breaks the failure sequence. Recovery is reported when that success belongs to a previously failed tab or follows a stuck state.
+
+## Privacy Questions
+
+**Do the pixels use transparent names?**
+Yes.
+
+**Do they share parameters with other pixels?**
+Yes. They use `platform` and `form_factor` to combine both apps under the same pixel names.
+
+**Could the parameters link pixels to the same user?**
+No. Both parameters are coarse enums and contain no identifier.
+
+**Do the pixels include a URL or search query?**
+No. They also exclude hostnames, page titles, tab IDs, document IDs, navigation types, errors, and CPM rules.
+
+**Are the pixels temporary?**
+The session-restoration and post-crash/reload pixels are diagnostics. The stuck-state and recovery pixels are permanent health monitoring.
+
+**Why are the permanent pixels needed?**
+To measure how often CPM messaging becomes stuck and whether extension reload recovers it.
+
+**Do any parameters or suffixes fall outside the standard criteria?**
+`platform` and `form_factor` are explicit enum parameters used instead of platform-specific pixel names.
+
+**Do the pixels fire on sensitive user events?**
+No. They report only CPM extension health states.
+
+**Can occurrences be tied to the same user or a small group?**
+No. There is no correlation identifier or browsing data.
+
+**Does this meet the self-service criteria?**
+Yes.