# [BUG] RemnaNode 3.0.0 / Xray 26.7.28: VLESS TCP REALITY перестаёт передавать трафик, TCP Recv-Q растёт, health-check остаётся успешным
## Описание
После обновления Remnawave Node с `2.8.0` до `3.0.0` (`remnawave/node:latest`) VLESS TCP REALITY через некоторое время перестаёт передавать пользовательский трафик.
Контейнер и процесс Xray продолжают работать, API RemnaNode на порту 2222 отвечает, панель считает ноду доступной. При этом клиенты устанавливают TCP-соединения с портом 443, но интернета через прокси нет. Перезапуск ноды временно восстанавливает работу. Откат образа до `remnawave/node:2.8.0` восстанавливает стабильную работу.
Проблема была воспроизведена на нескольких нодах после обновления. Ноды на `2.8.0` работали нормально до обновления. Одна малонагруженная нода на 3.0.0 могла продолжать работать, поэтому проблема, вероятно, зависит от нагрузки или количества одновременных соединений.
## Окружение
- Remnawave Panel: `3.0.0`, Docker image `remnawave/backend:3`
- Проблемная Remnawave Node: `3.0.0`, Docker image `remnawave/node:latest`
- Xray в Node 3.0.0: `26.7.28`, commit `5ca6f4b`, Go `1.26.5`
- Рабочая версия после отката: Remnawave Node `2.8.0`
- Xray в Node 2.8.0: `26.6.27`, commit `45cf289`, Go `1.26.4`
- Протокол: VLESS TCP REALITY, flow `xtls-rprx-vision`
- `network_mode: host`
- `cap_add: NET_ADMIN`
- ОС проверенной ноды: Ubuntu 22.04, kernel `5.15.0-186-generic`
- Ресурсы: 1 CPU, около 2 GB RAM
- Клиент/шлюз: sing-box через NetShift/OpenWrt, несколько VLESS outbounds и URLTest
## Шаги воспроизведения
1. Запустить панель Remnawave 3.0.0.
2. Запустить ноду на `remnawave/node:2.8.0` с VLESS TCP REALITY.
3. Убедиться, что прокси передаёт трафик.
4. Изменить образ на `remnawave/node:latest` (на момент теста это Node 3.0.0 с Xray 26.7.28).
5. Пересоздать контейнер.
6. Создать постоянную нагрузку и множество соединений через VLESS. В тесте за маршрутизацию отвечал sing-box/NetShift с URLTest.
7. Через некоторое время прокси перестаёт передавать трафик, но контейнер, Xray и API ноды остаются запущенными.
## Фактическое поведение
- VPN-клиент подключается к VLESS, но интернет отсутствует.
- Latency test возвращает `Timeout`/`N/A`.
- `docker inspect` показывает:
```text
status=running restart=0 oom=false
```
- Remnawave Node продолжает слушать порт 2222.
- Xray продолжает слушать порт 443.
- Панель не всегда регистрирует `Lost connection`, потому что health/stats API ноды остаётся доступным.
- В логах RemnaNode/Xray после успешного запуска может не быть ошибки в момент зависания.
## Диагностика сокетов во время сбоя
Во время воспроизведённого сбоя:
```text
ESTABLISHED_443=1423
NONZERO_RECVQ=1024
NONZERO_SENDQ=3
XRAY_FDS=5579
```
Позднее количество соединений с непрочитанной входящей очередью продолжило расти:
```text
INBOUND_EST=1246
INBOUND_RECVQ=1221
XRAY_ALL_EST=1251
```
У процесса Xray почти отсутствовали исходящие TCP-соединения. Большинство клиентских сокетов имели ненулевой `Recv-Q`: данные поступали в kernel receive queue, но Xray их не считывал или не обрабатывал.
Пример команды проверки:
```bash
ss -Hnt state established ‘( sport = :443 )’ | wc -l
ss -Hnt state established ‘( sport = :443 )’ | awk ‘$1>0{n++} END{print n+0}’
ss -Hntp state established | grep -c rw-core
```
## Что было исключено
### Нехватка ресурсов
Во время сбоя:
```text
load average: 0.20, 0.07, 0.03
CPU RemnaNode: около 2.3%
Memory RemnaNode: около 214 MiB
Available RAM: около 1.4 GiB
OOMKilled: false
```
### Лимит файловых дескрипторов
```text
Max open files: 1048576
Xray FDs: 5579
```
Лимит не был исчерпан.
### Conntrack
```text
nf_conntrack_count=7506
nf_conntrack_max=65536
```
### Сеть сервера
Прямой запрос с ноды работал:
```text
direct_http=200
connect=0.024s
total=0.096s
```
DNS и маршрут по умолчанию были исправны.
### nftables / плагины Remnawave
Счётчики блокировок были нулевыми:
```text
ingress-filter-ip: 0 packets
torrent-blocker: 0 packets
egress-filter-ip: 0 packets
egress-filter-port: 0 packets
```
## Ожидаемое поведение
Xray должен продолжать принимать и обрабатывать VLESS TCP REALITY-соединения. Если Xray перестал обслуживать listener, health-check ноды должен обнаружить функциональный отказ и вернуть ошибку, а не показывать ноду как исправную.
## Обходное решение
Зафиксировать образ:
```yaml
image: remnawave/node:2.8.0
```
После пересоздания контейнера на Node 2.8.0 / Xray 26.6.27 проверки через sing-box снова стали успешными:
```text
NL node latency: 102-116 ms
FR node latency: 175-185 ms
```
## Предположение
Похоже на регрессию в обработке TCP/REALITY listener в Xray 26.7.28 либо на взаимодействие RemnaNode 3.0.0 с этой версией Xray. Процесс и управляющий API остаются живыми, но Xray перестаёт читать данные из клиентских TCP-сокетов. Xray 26.7.28 опубликован upstream как pre-release.