---
title: REALITY ML-DSA-65 (PQ) × Akamai-dest несовместимость
type: concept
tags: [reality, xray, vless, post-quantum, mldsa65, x25519mlkem768, troubleshooting, 3x-ui]
sources: [../sources/nl-vds-3xui-setup-2026-06-05.md]
updated: 2026-06-05
---

# REALITY + ML-DSA-65 (post-quantum) ломается с не-PQ dest (напр. www.intel.com)

## Симптом

Свежий 3x-UI / Xray-инбаунд VLESS+Reality **не коннектится** (клиент молча висит до таймаута, никакой
ошибки в GUI), при этом **обычный VLESS на другом порту работает**. На сервере (при debug-логе):

```
transport/internet/tcp: REALITY: processed invalid connection from <ip>: handshake did not complete successfully
```

Клиент крутит ретраи и сдаётся: `proxy/vless/outbound: failed to find an available destination > [EOF]`.

## Root cause

Современный 3x-UI (Xray ≥ 25.x, здесь 26.6.1) для нового Reality-инбаунда **по умолчанию включает
пост-квантовый режим ML-DSA-65** (`realitySettings.mldsa65Seed` на сервере + `mldsa65Verify` у клиента).
В этом режиме ClientHello несёт пост-квантовый key-share **`X25519MLKEM768`** (~1.2 КБ).

REALITY-сервер релеит ClientHello на `dest`/`target`, чтобы «позаимствовать» его TLS-рукопожатие. Если dest
**не поддерживает PQ-группу обмена ключами**, он отвечает **HelloRetryRequest** (просит другую группу) —
а borrowed-TLS поток REALITY этого не переживает → хендшейк не достраивается. `www.intel.com` за **Akamai**
именно такой: PQ-обмен не поддерживает.

Ключевой нюанс диагностики: **неаутентифицированный** гость (обычный `openssl s_client`) идёт по
fallback-пути REALITY (прозрачный релей на dest) и получает настоящий сертификат intel — поэтому сервер
кажется «живым». Ломается только **аутентифицированный** путь, и только в связке с PQ.

## Изоляционная матрица (replica-пара, Xray 26.6.1 ↔ 26.6.1, debug)

Полностью подконтрольная пара (свой сервер-инбаунд на 8443 + клиент на socks 10888, ключи выведены из seed):

| dest/SNI | ML-DSA-65 | Результат |
|---|---|---|
| `www.intel.com` | **вкл** | ❌ `handshake did not complete` |
| `www.intel.com` | выкл | ✅ HTTP 204 |
| `www.microsoft.com` | выкл | ✅ 204 |
| `www.microsoft.com` | **вкл** | ✅ 204 |
| `www.yahoo.com` | выкл | ✅ 204 |

→ Падает **только** `intel + PQ`. Порознь оба компонента исправны. Версии ядер, X25519-ключи, shortId, flow,
UUID, seed↔verify, часы — всё проверено и совпадает; ни один из них не виноват.

## Fix

Два варианта (рекомендация — первый):

1. **Сменить dest на PQ-совместимый** (сохраняет пост-квантовую защиту). На сервере в инбаунде:
   `realitySettings.target` → `www.microsoft.com:443`, `serverNames` → `["www.microsoft.com"]`; в клиенте —
   SNI → `www.microsoft.com`. Менять **симметрично** обе стороны. PQ-совместимость dest проверяется
   тестом из матрицы выше (или: dest должен уметь TLS1.3 hybrid PQ key-exchange `X25519MLKEM768` —
   Cloudflare/Google/Microsoft умеют, Akamai-фронт обычно нет).
2. **Выключить ML-DSA-65** на инбаунде (убрать `mldsa65Seed` / пересоздать инбаунд без PQ) — тогда `intel`
   работает. Проще, но теряется пост-квантовая стойкость. Брать только если PQ не нужен.

## Как воспроизвести/проверить dest на PQ (read-only)

Поднять временную replica-пару `xray run -c` на localhost-портах с `loglevel:debug` и `curl -x socks5h://…`
через тоннель — НЕ трогая боевой инбаунд (см. методику в [`nl-vds-3xui`](../entities/nl-vds-3xui.md)).
Признак PQ-несовместимого dest: сервер логирует `REALITY: ... handshake did not complete` **только** при
включённом seed.

## Update 2026-06-05: GUI-клиенты вообще не умеют PQ — отключать ML-DSA-65

Даже после fix dest (intel→microsoft) **реальные клиенты не коннектились** через Reality (v2rayN 7.19.5,
телефонные приложения), хотя ручной xray-конфиг с вписанным `mldsa65Verify` работал. Причина: **GUI-клиенты
не передают `mldsa65Verify` в конфиг ядра** (v2rayN пишет его пустым — видно в `binConfigs/configTest*.json`).
Replica-матрица на noPQ-сервере:

| Сервер | Клиент | Результат |
|---|---|---|
| PQ (mldsa65Seed) | без verify (как v2rayN) | ❌ 000 |
| noPQ | без verify | ✅ 204 |
| noPQ | с verify | ❌ 000 |

**Вывод:** ML-DSA-65 (post-quantum REALITY) на середину 2026 поддерживается только ручным xray-конфигом; ни
v2rayN, ни мобильные клиенты его не отдают. Для рабочего Reality с GUI-клиентами **PQ надо выключать**
(убрать `mldsa65Seed` из инбаунда) → обычный Reality X25519, который умеют все. 3x-UI включает PQ по
умолчанию на новых инбаундах — это и ломает «из коробки».

## ⚠️ Caveat: отключение PQ ≠ рабочий Reality (случай nl-vds 2026-06-05)

Этот разбор корректно объясняет, почему PQ-Reality ломается и почему PQ надо отключать для GUI-клиентов.
**Но отключение PQ + dest microsoft НЕ сделало Reality рабочим у реальных клиентов пользователя** (v2rayN
на ПК, телефон) — он всё равно не поднимался, при том что plain VLESS на другом порту работал. В
изолированных curl/standalone-xray тестах с того же ПК Reality «проходил» — но это [нерепрезентативно](proxy-debugging-test-the-real-client.md).
Причина отказа Reality у боевых клиентов в той сети **не установлена** (перенос порта 443→2053 тоже не
помог). Не читать этот concept как «снял PQ → Reality работает»: PQ — лишь одна из преград.

## Где встречалось

- [`nl-vds-3xui`](../entities/nl-vds-3xui.md) / [session 2026-06-05](../sources/nl-vds-3xui-setup-2026-06-05.md) — инбаунд 443→2053, обнаружено 2026-06-05.