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

Поддержка – Xray/Конфигурации
1

Продакшн-сервис (панель 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 на www.wikipedia.org — не помогло. Подтверждено через openssl s_client -servername 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) — но подтверждений нет, все стандартные причины перепробованы и исключены.

2

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

3

Конфиг — вот полностью, ничего не срезано (это чистый 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-синтаксисе.

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

4

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