Выбор SNI для VLESS Reality: как проверить домен и не попасть под блок

Что мы настраиваем и зачем

VLESS Reality — транспортная схема в Xray-core для защищённого клиент-серверного соединения. Она использует TLS-рукопожатие, похожее на подключение к обычному HTTPS-сайту, но проверка клиента строится на ключевой паре Reality, short ID и параметрах VLESS. В отличие от обычного TLS-прокси, серверу не нужен публичный домен и собственный сертификат для входящего подключения.

Главный параметр, который обычно вызывает вопросы, — SNI, Server Name Indication. Это имя хоста, передаваемое клиентом в начале TLS-сессии. В конфигурации Reality список разрешённых имён задаётся параметром serverNames, а целевой публичный HTTPS-хост — параметром dest. Обычно один и тот же домен используется и в serverNames, и как hostname в dest.

Цель настройки — получить контролируемый личный сервер для безопасного доступа к собственным ресурсам и защищённого трафика в недоверенных сетях. После выполнения шагов у вас будет:

• VPS с минимально защищённым SSH-доступом и firewall;
• установленный актуальный Xray-core;
• пара ключей X25519 для Reality;
• конфигурация VLESS Reality на TCP-порту 443;
• методика проверки SNI-домена до добавления его в рабочую конфигурацию;
• сценарий резервного копирования конфигов и ключевого материала;
• диагностика типичных ошибок подключения.

Как Reality использует SNI

Клиент подключается к IP-адресу вашего VPS, но в TLS ClientHello указывает выбранное имя, например www.example.net. Сервер Xray принимает соединение только при совпадении SNI с разрешённым списком и при успешной криптографической проверке параметров Reality. Для внешнего наблюдателя соединение выглядит как TLS-сессия с указанным именем, однако сетевой маршрут ведёт на IP вашего сервера.

Параметр dest нужен Reality как целевой TLS-профиль и fallback-направление для невалидных соединений. Важно, чтобы домен действительно обслуживал HTTPS и был технически похож на ожидаемый браузерный трафик. Неподходящий домен может приводить к тайм-аутам, ошибкам рукопожатия или нестабильной работе после изменений на стороне сайта.

Какие домены не стоит выбирать

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

• Не используйте сайты банков, бирж, платёжных систем и государственных порталов.
• Не используйте домены, которые в вашей сети уже недоступны или требуют нестандартного DNS.
• Избегайте сайтов с TLS 1.2-only, самоподписанными сертификатами и ошибочной цепочкой CA.
• Не выбирайте домены, которые отвечают только через IPv6, если у ваших клиентов нестабильный IPv6.
• Не используйте хосты, которые постоянно меняют CDN, сертификаты или требуют JavaScript-проверку уже на уровне соединения.
• Не используйте чужие бренды в названиях профилей, QR-кодов и публичных инструкций для пользователей.

Альтернативы: управляемые сервисы и собственный VPS

Управляемые VPN-сервисы проще запускать: не нужно обновлять систему, настраивать firewall и хранить ключи. Но вы не контролируете серверную конфигурацию, журналирование, маршрутизацию и срок хранения данных. Кроме того, провайдер может менять адреса, правила доступа и доступные протоколы без вашего согласования.

Self-hosted VLESS Reality на VPS требует базового администрирования Linux, но даёт контроль над IP-адресом, портами, доступом пользователей и резервными копиями. Для одного владельца или небольшой команды это обычно оправдано, если вы готовы регулярно устанавливать обновления и проверять журналы.

Какой VPS-конфиг нужен под эту задачу

VLESS Reality сам по себе потребляет немного памяти и процессорного времени. Нагрузка определяется не числом конфигурационных строк, а количеством одновременных TLS-соединений, скоростью шифрования, объёмом передаваемых данных и дополнительными сервисами на сервере.

Практичный стартовый вариант — 2 vCPU, 2 ГБ RAM, 20 ГБ NVMe, IPv4 и канал 1 Гбит/с. Такой запас позволяет разместить Xray-core, fail2ban, систему резервного копирования, мониторинг и несколько пользователей без борьбы за память. При выборе можно взять VPS с указанными характеристиками или аналогичный план у другого провайдера.

На что смотреть кроме CPU и RAM

• Выделенный IPv4. Он упрощает подключение старых сетей и мобильных клиентов.
• IPv6. Полезен как дополнительный путь, но не должен быть единственной точкой доступа.
• Трафик. Оцените месячный лимит. Видеозвонки и обновления ОС расходуют его заметно быстрее обычного веб-сёрфинга.
• Политика допустимого использования. Не нарушайте правила дата-центра и местное законодательство.
• Возможность переустановки ОС и snapshot. Это сокращает время восстановления после ошибки.
• Консоль доступа. VNC, serial console или rescue mode нужны, если вы ошиблись в firewall и закрыли SSH.

Когда нужен dedicated, а не VPS

Выделенный сервер не нужен для одного пользователя и обычно не нужен для маленькой команды. Он становится обоснованным при устойчивой нагрузке в сотни мегабит в секунду, большом количестве одновременных клиентов, необходимости изолировать ресурсы от соседей по виртуализации или при размещении дополнительных тяжёлых сервисов.

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

Как влияет локация VPS

Локация определяет задержку, маршрут до клиентов и доступность выбранного SNI-домена из дата-центра. Для интерактивных задач выбирайте сервер ближе к основной аудитории: задержка до 60–100 мс обычно комфортна для браузинга и звонков. Проверяйте не только ping до VPS, но и реальную скорость TCP-соединений в часы пик.

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

Подготовка сервера

Ниже используется Ubuntu Server 24.04 LTS. На начало 2026 года это стабильная LTS-база с поддержкой безопасности до 2029 года. Команды подходят и для Debian 12/13 с небольшими изменениями названий пакетов.

Подключитесь к серверу под пользователем, выданным провайдером, и сразу обновите систему. Не оставляйте парольный SSH-доступ, если можно использовать ключи.

ssh root@SERVER_IP
apt update && apt full-upgrade -y
reboot

Команды устанавливают обновления безопасности и перезагружают сервер, если обновилось ядро.

ssh root@SERVER_IP
adduser deploy
usermod -aG sudo deploy

Создаётся отдельный пользователь deploy с правом выполнять административные команды через sudo.

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Добавьте в файл публичный SSH-ключ с вашего компьютера. Не закрывайте текущую root-сессию до проверки входа под новым пользователем.

ssh deploy@SERVER_IP
sudo -v
exit

Эта проверка подтверждает, что вход по ключу и sudo работают до отключения root-входа.

sudo apt install -y curl wget jq ca-certificates gnupg lsb-release \
unzip ufw fail2ban openssl dnsutils mtr-tiny cron

Устанавливаются утилиты для загрузки релизов, проверки DNS/TLS, firewall, защиты SSH и планировщика задач.

sudo nano /etc/ssh/sshd_config.d/10-hardening.conf

Создайте отдельный файл с параметрами SSH, чтобы не редактировать основной конфиг дистрибутива.

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3

sudo sshd -t && sudo systemctl restart ssh
sudo systemctl status ssh --no-pager

Сначала проверяется синтаксис SSH-конфига, затем безопасно перезапускается служба.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Firewall запрещает все входящие соединения, кроме SSH и TCP-порта 443 для Xray.

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Fail2ban отслеживает повторяющиеся неудачные попытки SSH-входа и временно блокирует источники перебора.

Важно: если SSH работает на нестандартном порту, откройте его в UFW до команды ufw enable. Проверьте также cloud firewall в панели провайдера: он может существовать отдельно от UFW.

Установка ПО — пошагово

Xray-core активно развивается, поэтому фиксировать номер версии в статье рискованно: к моменту установки он может устареть. Безопаснее получать номер последнего стабильного релиза из официального репозитория проекта и сохранять его в системном файле. Перед обновлением всегда читайте changelog релиза, особенно при изменениях формата конфигурации.

sudo install -d -m 0755 /etc/xray /var/log/xray /usr/local/lib/xray
sudo chown -R nobody:nogroup /var/log/xray

Создаются каталоги для конфигурации, логов и дополнительных файлов Xray.

XRAY_VERSION=$(curl -fsSL https://api.github.com/repos/XTLS/Xray-core/releases/latest | jq -r .tag_name)
echo "$XRAY_VERSION"

Команда получает тег последнего официального стабильного релиза Xray-core через GitHub API.

ARCH=$(dpkg --print-architecture)
case "$ARCH" in
  amd64) XRAY_ARCH="64" ;;
  arm64) XRAY_ARCH="arm64-v8a" ;;
  ) echo "Неподдерживаемая архитектура: $ARCH"; exit 1 ;;
esac
echo "$XRAY_ARCH"

cd /tmp
curl -fL -o xray.zip "https://github.com/XTLS/Xray-core/releases/download/${XRAY_VERSION}/Xray-linux-${XRAY_ARCH}.zip"
unzip -o xray.zip -d xray-release
sudo install -m 0755 xray-release/xray /usr/local/bin/xray
sudo install -m 0644 xray-release/geoip.dat xray-release/geosite.dat /usr/local/share/
xray version

sudo useradd --system --no-create-home --shell /usr/sbin/nologin xray || true
sudo chown -R xray:xray /etc/xray
sudo chmod 750 /etc/xray

sudo /usr/local/bin/xray x25519

openssl rand -hex 8

uuidgen

sudo tee /etc/systemd/system/xray.service > /dev/null <<'EOF'
[Unit]
Description=Xray Service
Documentation=https://github.com/XTLS/Xray-core
After=network-online.target nss-lookup.target
Wants=network-online.target

[Service]
Type=simple
User=xray
Group=xray
EnvironmentFile=/etc/xray/reality.env
ExecStartPre=/usr/bin/envsubst < /etc/xray/config.json.template > /run/xray-config.json
ExecStart=/usr/local/bin/xray run -config /run/xray-config.json
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ReadWritePaths=/run /var/log/xray

[Install]
WantedBy=multi-user.target
EOF

sudo apt install -y gettext-base
sudo systemctl daemon-reload

sudo tee /etc/logrotate.d/xray > /dev/null <<'EOF'
/var/log/xray/.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 0640 xray xray
}
EOF
sudo logrotate -d /etc/logrotate.d/xray

Настраивается ежедневная ротация логов с хранением 14 архивов. Ключ -d выполняет тест без фактического изменения файлов.

Автобэкап через restic

Restic создаёт зашифрованные дедуплицированные резервные копии. Репозиторий можно разместить в S3-совместимом хранилище, на отдельном VPS через SFTP или в другом изолированном хранилище. Ниже пример для S3-совместимого endpoint; реальные секреты храните в root-доступном файле.

sudo apt install -y restic
sudo install -d -m 0700 /root/.config/restic
sudo nano /root/.config/restic/env

Устанавливается restic и создаётся закрытый каталог для параметров резервного хранилища.

export RESTIC_REPOSITORY="s3:https://s3.example-storage.net/xray-backup"
export RESTIC_PASSWORD="REPLACE_WITH_LONG_UNIQUE_PASSWORD"
export AWS_ACCESS_KEY_ID="REPLACE_WITH_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="REPLACE_WITH_SECRET_KEY"

sudo chmod 600 /root/.config/restic/env
sudo bash -c 'source /root/.config/restic/env && restic init'

Устанавливаются строгие права на секреты и инициализируется зашифрованный репозиторий restic.

sudo tee /usr/local/sbin/backup-xray.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
source /root/.config/restic/env

restic backup \
  /etc/xray \
  /etc/systemd/system/xray.service \
  /etc/ufw \
  /etc/fail2ban \
  --tag xray --tag "$(hostname -s)"

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check
EOF
sudo chmod 700 /usr/local/sbin/backup-xray.sh

Скрипт создаёт резервную копию, удаляет старые точки по политике хранения и проверяет целостность репозитория.

sudo /usr/local/sbin/backup-xray.sh
sudo crontab -e

Сначала выполните резервное копирование вручную. После успешного завершения добавьте ежедневный запуск в root-crontab.

20 03   * /usr/local/sbin/backup-xray.sh >> /var/log/backup-xray.log 2>&1

Обновления и окно обслуживания

Обновления Xray-core лучше выполнять в короткое maintenance window. Для одного сервера это означает перерыв в несколько секунд или минут: скачайте релиз, проверьте конфиг, перезапустите сервис и подключитесь тестовым клиентом. Не обновляйте сервер, если у вас нет рабочей копии конфигурации и аварийного доступа через консоль.

sudo systemctl stop xray
sudo cp /usr/local/bin/xray /usr/local/bin/xray.previous
sudo systemctl start xray
sudo systemctl is-active xray
sudo journalctl -u xray -n 30 --no-pager

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

Для двух серверов используйте rolling-подход: обновите первый узел, проверьте подключение, затем обновите второй. Клиенты должны иметь два отдельных профиля или механизм переключения, чтобы обслуживание одного сервера не лишало вас доступа полностью.

Troubleshooting + FAQ

Почему клиент показывает «TLS handshake failed» или «reality verification failed»?

Сначала сравните параметры клиента и сервера: SNI, public key, short ID, UUID, порт и тип транспорта должны совпадать. Частая ошибка — вставить в клиент private key вместо public key или указать SNI с префиксом https://. На сервере проверьте journalctl -u xray -n 100 и убедитесь, что служба использует актуальный файл /etc/xray/reality.env. После изменения переменных всегда выполняйте sudo systemctl restart xray.

Как понять, что выбранный SNI-домен плохой?

Плохой кандидат нестабилен при повторных TLS-проверках, не поддерживает TLS 1.3, периодически выдаёт reset или недоступен из сети клиента. Проверьте его через openssl s_client и curl с VPS, затем повторите тест из мобильной и домашней сети. Не оценивайте домен по одной успешной попытке: сделайте минимум пять-десять запросов в разное время. Если есть регулярные тайм-ауты, выберите другой технически стабильный HTTPS-хост.

Почему порт 443 не слушается после запуска Xray?

Скорее всего, порт уже занят другим процессом: Caddy, nginx, Apache, Docker-контейнером или старой копией Xray. Выполните sudo ss -lntp | grep ':443', чтобы увидеть владельца сокета. Остановите конфликтующую службу либо перенесите её на другой IP-адрес или порт. Затем проверьте JSON командой xray run -test -config и перезапустите Xray. Не пытайтесь одновременно запускать два TLS-сервиса на одном IP:443 без продуманной архитектуры.

Подключение работает по Wi-Fi, но не работает через мобильную сеть. Что делать?

Сравните DNS-разрешение, доступность IP VPS и TLS-проверку из обеих сетей. Проблема может быть в маршруте оператора, IPv6, локальном фильтре сети или в том, что выбранный SNI недоступен именно там. Убедитесь, что клиент подключается к IPv4, если IPv6 нестабилен. Не меняйте сразу все параметры: сначала проверьте доступность TCP 443 до VPS, затем настройки профиля, после этого протестируйте другой заранее проверенный SNI на отдельном серверном профиле.

Какой VPS-конфиг минимально подойдёт?

Для одного владельца и нескольких устройств минимально достаточно 1 vCPU, 1 ГБ RAM, 10 ГБ SSD или NVMe, выделенного IPv4 и канала от 100 Мбит/с. Однако более комфортный старт — 2 vCPU, 2 ГБ RAM и 20 ГБ NVMe: останется запас для обновлений, логов, fail2ban и restic. Важнее характеристик CPU качество сети, доступный месячный трафик, стабильный IPv4 и возможность восстановить сервер через консоль.

Что выбрать — VPS или dedicated для этой задачи?

Для личного VLESS Reality и небольшой команды выбирайте VPS: он дешевле, проще масштабируется и обычно полностью покрывает потребность в CPU и памяти. Dedicated имеет смысл при устойчивом высоком трафике, десятках или сотнях одновременных пользователей, строгой потребности в изоляции ресурсов либо размещении дополнительных тяжёлых сервисов. Не переходите на выделенный сервер для исправления ошибок конфигурации: сначала исключите проблемы SNI, firewall, маршрута и клиентских параметров.

Нужно ли выпускать сертификат Let’s Encrypt или настраивать Caddy?

Нет, для VLESS Reality сертификат Let’s Encrypt не нужен и не участвует в авторизации клиента. Сервер Reality использует private key X25519, а клиент — соответствующий public key, SNI и short ID. Caddy или certbot нужны только если вы отдельно размещаете обычный HTTPS-сайт или защищённую веб-панель. Не ставьте Caddy на тот же TCP-порт 443 того же IP, где уже запущен Xray, иначе получите ошибку занятости порта.

Как безопасно добавить второго пользователя?

Создайте для него отдельный UUID и, желательно, отдельный short ID. Добавьте новую запись в массив clients и при необходимости новый элемент в shortIds, затем проверьте итоговый JSON и перезапустите Xray. Не выдавайте двум людям один общий UUID: при проблеме вы не сможете отозвать доступ только одного пользователя. Ведите зашифрованный список соответствий «пользователь — UUID — дата выдачи» вне VPS.

Как быстро отозвать скомпрометированный профиль?

Удалите соответствующий UUID из массива clients, пересоберите конфигурацию и перезапустите службу. Если есть риск утечки не только UUID, но и полного URI с short ID и public key, смените short ID. При подозрении на утечку private key создайте новую пару X25519, замените private key на сервере и обновите public key у всех доверенных клиентов. После изменений проверьте журналы и резервные копии конфигурации.

Выводы и следующие шаги

Теперь у вас есть базовая схема VLESS Reality на защищённом VPS и понятный процесс выбора SNI: домен проверяется по DNS, TLS 1.3, сертификату, стабильности и доступности из реальных клиентских сетей. Главное правило — не искать «магический» популярный домен, а использовать технически предсказуемый публичный HTTPS-хост и регулярно тестировать его доступность.

1. Добавьте второй независимый сервер в другой локации и подготовьте резервный клиентский профиль.
2. Создавайте отдельные UUID для устройств и пользователей, периодически отзывайте неиспользуемые учётные данные.
3. Раз в месяц проверяйте обновления Xray-core, состояние firewall, успешность restic-бэкапов и журналы ошибок.