REALITY timeout: как отличить сеть, порт и неверный профиль

REALITY — это технология, которая маскирует прокси-трафик под обычное HTTPS-соединение с реальным сайтом. Однако даже с идеальной настройкой пользователи иногда сталкиваются с ошибкой timeout, когда попытка подключения зависает и завершается по таймауту. В этой статье мы разберём, как отделить проблемы сети, порта и неверного профиля, чтобы быстро найти причину и восстановить работу.

Что такое REALITY и почему возникает timeout?

REALITY — это транспортный протокол, основанный на TLS. Клиент подключается к серверу, который отдаёт ему поддельные сертификаты реальных сайтов, например www.microsoft.com. Сервер проверяет, что клиент знает секретный ключ, и только после этого пропускает трафик. Если какой-то из этапов не проходит, соединение обрывается или истекает по таймауту.

Таймаут — это время, в течение которого клиент ожидает ответа от сервера. Если сервер не отвечает, клиент прекращает попытку. Причин может быть три группы:

• сетевые проблемы — сервер недоступен по IP, блокируется провайдером или находится слишком далеко;
• проблемы с портом — порт закрыт, неправильно указан в конфигурации или заблокирован фаерволом;
• неверный профиль — параметры REALITY не совпадают между клиентом и сервером.

Классификация симптомов: что именно происходит?

Прежде чем перебирать настройки, посмотрите на ошибку. Она может быть разной:

• Немедленный отказ в соединении — клиент сразу получает отказ (connection refused). Обычно это значит, что порт закрыт, или серверное приложение не слушает этот порт.
• Долгая пауза и таймаут — клиент отправляет пакеты, но ответа нет. Это чаще всего говорит о блокировке на уровне сети (фаервол, DPI) или о том, что сервер обрабатывает запрос, но клиент не может завершить рукопожатие.
• Таймаут после успешного TCP-подключения — если TCP-порт открыт, но TLS-рукопожатие не проходит, значит проблема в профиле REALITY или в том, что сервер не распознаёт клиента.

Обратите внимание на время ожидания. Если ошибка появляется мгновенно, это почти наверняка не сеть, а порт или профиль.

Проверка сети: диагностика TCP/IP и DNS

Начните с проверки доступности сервера. Откройте терминал (командную строку) и выполните:

ping -c 4 <IP-сервера>

Если пинг не проходит (потеря пакетов), значит проблема на уровне сети. Возможно, сервер выключен или IP заблокирован. Проверьте также DNS:

nslookup <ваш-домен>

Если домен не резолвится, значит проблема с DNS. Для REALITY обычно используется IP-адрес напрямую, но в некоторых конфигурациях применяется домен. Если вы используете домен, убедитесь, что он указывает на правильный IP сервера.

Для более точной диагностики используйте traceroute (Linux) или tracert (Windows). Это покажет, на каком участке маршрута теряются пакеты. Если пакеты доходят до сервера, но далеко от него, возможно, дело в фаерволе или прокси-сервере.

Порт: как исключить ошибки настройки и блокировки

Если сеть работает, проверьте порт. Убедитесь, что порт, указанный в конфигурации клиента, совпадает с портом, который слушает сервер. Проверить это можно следующими способами:

• На сервере выполните ss -tlnp | grep <порт>, чтобы увидеть, слушает ли Xray этот порт.
• С локальной машины проверьте доступность порта через nc -zv <IP> <порт> (Linux) или telnet <IP> <порт> (Windows).

Если порт не отвечает, проверьте правила фаервола: iptables, firewalld или панель управления хостинг-провайдера (например, security groups в AWS). Откройте нужный порт для TCP. Также убедитесь, что Xray запущен и не упал после недавнего изменения конфигурации.

Ещё одна частая ошибка — использование порта, который уже перехвачен другим приложением. Например, если на сервере уже работает Nginx на 443, Xray не сможет занять тот же порт. В этом случае измените порт в конфигурации или отключите конфликтующее приложение.

Неверный профиль: ключи REALITY и их взаимная проверка

Если порт открыт и TCP-соединение устанавливается, но таймаут возникает позже, проблема почти наверняка в параметрах REALITY. Основные поля, которые должны точно совпадать:

• serverNames — список доменов, которые клиент отправляет в SNI. На сервере они должны совпадать с списком разрешённых.
• privateKey (на сервере) и proxyPublicKey (на клиенте) — это ключи REALITY. Они образуют пару. Если ключи не совпадают, сервер не сможет расшифровать запрос клиента, и соединение зависнет.
• shortId — короткий идентификатор, который тоже должен совпадать. Если он пустой или отличается, подключение не пройдёт.
• fingerprint — отпечаток TLS-клиента. Он также должен быть одинаковым (например, chrome).

Проверьте, что все эти поля в конфигурации клиента взяты именно с сервера. Скопируйте их без лишних пробелов и проверьте каждую букву. Особенно важно правильно передать длинные ключи — они должны быть одинаковыми в обеих частях.

Также обратите внимание на формат профиля. В некоторых клиентах (например, в v2rayN) есть отдельное поле для прокси-ключей. Если вы открываете конфигурацию вручную, легко перепутать publicKey и privateKey. Помните: privateKey — на сервере, publicKey — у клиента.

Пошаговая диагностика на клиенте

Когда вы исключили сеть и порт, включите подробные логи в клиенте. В Xray для этого в конфигурации нужно указать уровень сложности debug:

"log": { "loglevel": "debug" }

Затем перезапустите клиент и посмотрите вывод. Если появляются сообщения типа connection refused — проблема с портом. Если timeout while waiting for TLS handshake — значит TCP-подключение прошло, но TLS-рукопожатие зависло. Это уже указывает на профиль или на то, что сервер не видит подходящего клиента.

Также проверьте, не блокируется ли ваше соединение другими инструментами. Например, если у вас уже запущен VPN или прокси, они могут перехватывать трафик и создавать конфликт. Попробуйте отключить всё остальное и оставить только Xray.

Анализ логов на сервере

Логи на сервере дают самую точную информацию. Если у вас настроен systemd, выполните:

journalctl -u xray -f

При попытке подключения вы увидите записи. Если появляется предупреждение о неверном shortId или SNI, значит проблема в профиле. Если ничего нет — запрос не доходит до сервера, ищите проблему в сети или порту.

Обратите внимание на уровень логирования. По умолчанию Xray пишет только ошибки, поэтому лучше установить loglevel в debug и на сервере. Тогда вы увидите детали TLS-рукопожатия.

Сводный алгоритм и частая ошибка

Чтобы систематизировать действия, используйте такой порядок:

1. Проверьте, отвечает ли сервер по IP (ping).
2. Проверьте DNS (nslookup).
3. Проверьте доступность порта (netcat/telnet).
4. Сравните конфигурации клиента и сервера (поля serverNames, shortId, ключи).
5. Включите логи на клиенте и сервере.

Частая ошибка — использование устаревших конфигураций. Если вы обновили сервер или клиент, параметры могли измениться. Например, в новых версиях Xray появились дополнительные требования к длине ключей. Всегда сверяйтесь с актуальной документацией.

Если вы всё проверили, но проблема осталась, попробуйте временно отключить на сервере другие службы, которые могут мешать, или перезапустите Xray.