# VLESS+Reality: handshake проваливается АБСОЛЮТНО для всех клиентов на всех нодах (received real certificate / processed invalid connection)

**URL:** https://f.docs.rw/t/topic/559
**Category:** Поддержка – Xray/Конфигурации
**Created:** 2026-08-18T12:09:57Z
**Posts:** 4

## Post 1 by @satarel12 — 2026-08-18T12:09:57Z

Продакшн-сервис (панель Remnawave + 4 ноды remnanode: NL/FI/US/FR), VLESS+Reality. REALITY-хендшейк не проходит НИ РАЗУ ни для одного клиента, ни на одной ноде, с момента деплоя — сервер безусловно фолбэчит любое соединение на decoy-таргет, включая клиентов с математически верными ключами.

Точная ошибка (получена с внешней машины, официальный Xray 26.3.27 с GitHub-релиза, полностью вне нашей инфраструктуры):  
transport/internet/reality: REALITY: received real certificate (potential MITM or redirection)  
transport/internet/reality: REALITY: processed invalid connection

В панели: usersOnline: 0 постоянно на всех нодах, у тестового аккаунта usedTrafficBytes: 0, onlineAt: null, firstConnectedAt: null несмотря на активные попытки подключения в реальном времени.

Воспроизведено 3 независимыми методами:

1. С самого сервера NL на себя (localhost и публичный IP) — родным xray-бинарником из контейнера remnanode, с точными параметрами из экспортированной подписки → common/retry: [EOF] \> all retry attempts failed.
2. NL → FI (реальный кросс-нода трафик через интернет) → та же EOF-ошибка.
3. С внешней машины, официальный Xray 26.3.27 — самая информативная ошибка, см. выше.

Проверено и исключено как причина (каждый пункт — отдельный тест с рестартом ноды):

- Ключи x25519 — сверены вручную (xray x25519 -i даёт ровно тот pbk, что в подписке), сгенерирована полностью новая пара — не помогло.
- shortId, flow (с xtls-rprx-vision и без), fingerprint (chrome и без) — не помогло.
- minClientVer — знаем про баг с дефолтной версией клиента (issue XTLS/Xray-core #6482/#6477), добавили explicit minClientVer: “1.8.2” — не помогло, это другая проблема.
- Откат remnawave/node:latest (Xray 26.7.28) → remnawave/node:2.8.0 (Xray 26.6.27, до регрессии minClientVer) — не помогло, идентичная ошибка на обеих версиях.
- Свежий docker compose pull + --force-recreate — не помогло.
- Смена REALITY target с [www.microsoft.com](http://www.microsoft.com) на [www.wikipedia.org](http://www.wikipedia.org) — не помогло. Подтверждено через openssl s\_client -servername [www.wikipedia.org](http://www.wikipedia.org), что конфиг реально применился (сервер отдаёт настоящий сертификат wikipedia) — то есть decoy-фолбэк технически работает, просто срабатывает ВСЕГДА вместо валидного REALITY-пути.
- Членство пользователя в squad — подтверждено корректным через /api/internal-squads и /api/users/by-username.

Инфраструктура: HostKey vm.mini VM, network\_mode: host, ядро 6.8.0-137-generic. Контейнер remnanode без volumes, полностью stateless.

Вопрос: сталкивался ли кто-то с точно таким же симптомом — REALITY безусловно фолбэчит на decoy для абсолютно всех клиентов, независимо от ключей/версии/таргета? Есть подозрение на что-то структурное в связке network\_mode: host + Docker + конкретное ядро на виртуалке, либо специфику сборки rw-core (форк Xray-core от Remnawave) — но подтверждений нет, все стандартные причины перепробованы и исключены.

---

## Post 2 by @Klukva38 — 2026-08-18T13:39:56Z

Скорее всего что то не так в твоем конфиге. Не видя конфиг, не понятно, что ты там мог сделать

---

## Post 3 by @satarel12 — 2026-08-18T14:53:34Z

Конфиг — вот полностью, ничего не срезано (это чистый vanilla xray v26.3.27 с официального релиза XTLS, отдельный от Remnawave, специально поднят для диагностики без влияния rw-core):

```
{
  "log": {
    "loglevel": "debug"
  },
  "inbounds": [
    {
      "tag": "VLESS_REALITY_TEST",
      "port": 443,
      "listen": "0.0.0.0",
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "",
            "flow": "xtls-rprx-vision",
            "email": "test"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "dest": "kernel.org:443",
          "xver": 0,
          "serverNames": [
            "kernel.org"
          ],
          "privateKey": "",
          "shortIds": [
            "e1368c0a66d564b0"
          ]
        }
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}
```

Ключи сгенерированы с нуля (xray x25519), проверены на совпадение через xray x25519 -i — всё сходится с pbk в подписке.

Важный факт, из-за которого сомневаюсь, что дело в конфиге: единичные подключения проходят нормально (в логе реальный accepted tcp:… трафик), а вот пачка параллельных TLS-хендшейков к одному и тому же хосту стабильно рвётся с failed to read client hello / handshake did not complete successfully — воспроизведено одинаково на двух разных серверах, у разных провайдеров, в разных странах, с разными ключами и decoy. Похоже на паттерн вроде DPI/фильтрации по числу параллельных соединений, а не на баг в JSON-синтаксисе.

Если у вас есть идеи, что именно в структуре конфига может провоцировать обрыв именно при параллельных соединениях (а не при одиночных) — было бы полезно.

---

## Post 4 by @OnlyGuns — 2026-08-19T07:37:55Z

С наибольшей вероятностью проблема связана с DPI.  
SNI на [kernel.org](http://kernel.org) в РФ работает редко или не работает вовсе, попробуйте другой ресурс: [github.com](http://github.com), [reddit.com](http://reddit.com) и др.