Если Xray REALITY не проходит handshake, туннель не успевает перейти к передаче пользовательского трафика. Частые причины — несовпадение ключей, shortId, serverName, flow, времени или транспортных параметров между клиентом и сервером.
Сравните одну клиентскую запись с активным inbound на сервере и включите диагностические логи на короткое время. Проверяйте параметры попарно, не генерируя новые ключи после каждого неудачного подключения.
Коротко: что сделать
- Синхронизировать время клиента и сервера
- Сверить public key и private key
- Сверить shortId, serverName и flow
- Проверить порт и доступ firewall
- Проверить совместимость версий Xray
Почему возникает проблема
REALITY чувствителен к точному совпадению криптографических и транспортных параметров. Обычная доступность TCP-порта еще не означает успешный handshake.
- Клиент использует public key от старой конфигурации
- shortId записан с ошибкой или не разрешен на сервере
- serverName отсутствует в допустимом списке
- flow отличается между inbound и клиентом
- Системное время сильно расходится
- Порт перенаправляется не на тот Xray inbound
Пошаговая диагностика
Проверку лучше проводить на одном воспроизводимом примере и фиксировать результат каждого шага. Так можно быстро отделить первопричину от побочных ошибок и не менять несколько компонентов одновременно.
- Проверить systemctl status и журнал Xray
- Убедиться, что процесс слушает нужный IP и порт
- Проверить TCP-доступность извне
- Сравнить экспорт клиента с серверным inbound
- Временно проверить один transport без дополнительных прокси
- Сверить версию ядра на обеих сторонах
Как исправить
Нужно привести клиент и сервер к одной проверенной конфигурации и только затем возвращать балансировщики, CDN или сложную маршрутизацию.
- Обновить public key на клиенте без публикации private key
- Исправить shortId и serverNames
- Установить одинаковый flow там, где он требуется
- Открыть порт только для нужного сервиса
- Исправить NAT или reverse proxy, направляющий трафик не туда
- Обновить Xray совместимо на клиенте и сервере
Как проверить результат
- Проверить handshake из другой сети
- Убедиться, что в журнале появляется успешная сессия
- Открыть несколько HTTPS-ресурсов через туннель
- Проверить DNS и IPv4/IPv6 отдельно
- Вернуть обычный уровень логирования после теста
Как не допустить повторения
Рабочую конфигурацию стоит хранить с версиями и понятной привязкой ключей к узлам.
- Не смешивать ключи разных серверов
- Синхронизировать время через NTP
- Делать резервную копию конфигурации перед обновлением
- Мониторить порт и состояние процесса
Чего не стоит делать
- Не публиковать private key и UUID
- Не отключать firewall полностью
- Не менять одновременно ключи, transport и маршрутизацию
- Не маскировать сетевую ошибку бесконечными переподключениями
Что подготовить для диагностики
- Версии клиента и сервера
- Обезличенные параметры inbound и клиента
- Точное время ошибки
- Фрагменты журналов без секретов
- Схема порта, NAT и прокси
Частые вопросы
Почему порт открыт, но handshake не проходит?
TCP-соединение проверяет только доступность порта. REALITY затем сверяет ключи и параметры протокола.
Нужно ли менять ключи?
Только если они скомпрометированы или точно перепутаны. Для обычной диагностики достаточно корректно сопоставить существующую пару.
Может ли мешать время?
Да. Значительное расхождение времени способно нарушить проверку и должно быть устранено до дальнейшей диагностики.
Когда стоит обратиться за помощью
Стоит обратиться за помощью, если прямой inbound работает, а за NAT или прокси — нет, либо конфигурация управляет несколькими пользователями и нельзя рисковать действующими подключениями.
Итог
Handshake REALITY восстанавливается последовательной сверкой времени, ключей, shortId, serverName, flow и сетевого пути. Настроить Xray без раскрытия секретов можно через @rabotator_support.