---
title: NL VDS 3x-UI — setup & troubleshooting session 2026-06-05
type: source
tags: [vless, reality, mtproto, hiddify, v2rayn, rkn, troubleshooting, session]
ingested: 2026-06-05
raw_path: (live session, no raw file)
sources: []
updated: 2026-06-05
---

# NL VDS 3x-UI — сессия настройки/диагностики 2026-06-05

Хроника заведения и отладки прокси-VDS [`nl-vds-3xui`](../entities/nl-vds-3xui.md).

## Что сделано

1. **Заведение в вики + ротация кредов.** Узел задокументирован, креды (SSH root, panel, JWT secret) ротированы и положены в `pass nl-vds-3xui/full-env` (оригиналы светились в плейнтексте).
2. **Reality 443 диагностика.** Не коннектился. Root cause: 3x-UI включил ML-DSA-65 (PQ) + dest `www.intel.com` (Akamai, не умеет PQ key-exchange) → handshake не достраивался. Изоляционная матрица на replica-парах. Разбор: [`reality-pq-mldsa65-dest-incompatibility`](../concepts/reality-pq-mldsa65-dest-incompatibility.md).
3. **Fix Reality (server-side):** dest→`www.microsoft.com`, затем снят `mldsa65Seed` (GUI-клиенты не шлют `mldsa65Verify`), затем порт 443→2053.
4. **MTProto:** поднят mtg 2.2.8 (FakeTLS cloudflare) на 8443.
5. **SOCKS5:** инбаунд на 47020 (auth).
6. **Инструкции для друзей** (Hiddify, Win/Mac/Android).

## Чем закончилось (честный итог)

**У реальных клиентов из РФ работает ТОЛЬКО plain VLESS 32030.** Reality (2053), MTProto (8443), SOCKS5 (47020) — **не поднялись** на боевых клиентах:

- **Reality 2053:** в изолированных тестах (отдельный `xray.exe` + `curl -x socks5h` с того же ПК) — проходил, exit NL, 5 МБ/с. Боевой v2rayN на том же ПК и телефон — **нет**. Причина не установлена. Версионная/PQ-несовместимость исключена (PQ снят, flow на месте, конфиг сверен — идентичен рабочему тесту). Вероятная гипотеза (НЕ доказана) — обработка TLS-хендшейка к этому IP в сети пользователя.
- **MTProto 8443:** Telegram (Desktop и телефон) висит «соединение…». tcpdump (телефон изолирован, Desktop закрыт): телефон шлёт 1288-б ClientHello → mtg отвечает 0 байт, телефон долбится десятками повторов. Локальный FakeTLS (`openssl` на сервере) проходит — но это лишь камуфляж-путь, реальную MTProto-сессию mtg здесь не держит. «Доступен (пинг N мс)» в Telegram — пассивная проверка, не равна рабочей сессии.
- **SOCKS5 47020:** на сервере исправен (внешний curl с auth проходил), но у пользователя режется DPI.

**Грубые ошибки в процессе (см. урок ниже):**
- Несколько раз заявлял «работает» по своим коротким curl/standalone-тестам, тогда как боевые клиенты не работали. Тесты были нерепрезентативны (часто шли не через тот путь, что у пользователя; либо через системный прокси v2rayN; либо это был мой отдельный процесс, не v2rayN).
- Влепил **MSS-clamp 1360** на сервер по неверной MTU-гипотезе (пользователь сразу сказал, что дело не в MTU) — clamp **ломал** соединения; после снятия комп-телега через системный прокси заработала.

## Рабочее решение для друзей (раздаётся)

Клиент **Hiddify** (Win/Mac/Android, один на все платформы) либо v2rayN/v2rayNG. Импорт по `vless://`-ссылке или QR, профиль 32030. При включённом VPN — в Telegram прокси не настраивать (моб. «отключить прокси», desktop «системный прокси», кастомные удалить).

Каждому другу — **свой** клиентский UUID (на момент сессии на 32030 один общий `a6fa7965-…`; рекомендовано завести отдельных клиентов под каждого для возможности отзыва — не сделано, ждёт решения user).

## Открытые хвосты

- **Reality/MTProto у реальных клиентов из РФ не работают** — причина не доведена до конца. Если нужен DPI-стойкий канал (не plain VLESS) — отдельная задача (возможно: другой IP/провайдер, CDN-fronting, или клиент с TUN вместо встроенного Telegram-прокси).
- Per-friend UUID на 32030 — завести отдельных клиентов.
- Опционально: убрать неработающие инбаунды (2053 Reality / 47020 SOCKS / 8443 mtg), чтобы не торчали лишние порты.