Вибір 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-підхід: оновіть перший вузол, перевірте підключення, потім оновіть другий. Клієнти повинні мати два окремі профілі або механізм перемикання, щоб обслуговування одного сервера не позбавило вас доступу повністю.

Усунення несправностей + 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 і журнали помилок.