Files

vitya 5cdedb376a wiki(nl-vds-3xui): ingest session 2026-06-05 — honest final state + lessons

- new sources/nl-vds-3xui-setup-2026-06-05.md (full chronicle; HONEST outcome:
  у реальных клиентов из РФ работает только plain VLESS 32030; Reality/MTProto/
  SOCKS не поднялись)
- new concepts/proxy-debugging-test-the-real-client.md (anti-pattern: own curl/
  standalone tests passed while user's real clients failed; overclaim + bad
  MSS-clamp fix that broke things)
- rewrote entities/nl-vds-3xui.md — removed false "Reality verified/fixed" &
  "mtg works" claims; honest status table; MSS-clamp removed
- caveat added to reality-pq concept (disabling PQ != working Reality for GUI
  clients); index.md + log.md updated

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-05 14:36:36 +03:00

7.5 KiB

Raw Permalink Blame History

title, type, tags, sources, updated

title

type

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

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

Сменить 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-фронт обычно нет).
Выключить ML-DSA-65 на инбаунде (убрать mldsa65Seed / пересоздать инбаунд без PQ) — тогда intel работает. Проще, но теряется пост-квантовая стойкость. Брать только если PQ не нужен.

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

Поднять временную replica-пару xray run -c на localhost-портах с loglevel:debug и curl -x socks5h://… через тоннель — НЕ трогая боевой инбаунд (см. методику в nl-vds-3xui). Признак 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 «проходил» — но это нерепрезентативно. Причина отказа Reality у боевых клиентов в той сети не установлена (перенос порта 443→2053 тоже не помог). Не читать этот concept как «снял PQ → Reality работает»: PQ — лишь одна из преград.

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

nl-vds-3xui / session 2026-06-05 — инбаунд 443→2053, обнаружено 2026-06-05.

7.5 KiB Raw Permalink Blame History Unescape Escape