---
title: REALITY ML-DSA-65 (PQ) × Akamai-dest несовместимость
type: concept
tags: [reality, xray, vless, post-quantum, mldsa65, x25519mlkem768, troubleshooting, 3x-ui]
sources: []
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.

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

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