Hysteria 2 на VPS: встановлення та налаштування за 10 хвилин

Що ми налаштовуємо і навіщо

У цьому посібнику налаштовується власний сервер Hysteria 2 на Ubuntu Server 24.04 LTS. Hysteria 2 використовує QUIC, що працює поверх UDP, і TLS 1.3 для шифрування трафіку. Клієнт підключається до вашого доменного імені, проходить автентифікацію та надсилає інтернет-трафік через VPS.

Такий сервер корисний, коли потрібен особистий проксі для ноутбука, телефона, домашнього комп'ютера або невеликої команди. На відміну від публічних VPN, ви контролюєте IP-адресу, конфігурацію, логи, пароль доступу та оновлення. Водночас VPS не робить трафік «анонімним»: кінцеві сайти все одно бачать IP сервера, а провайдер VPS може бачити метадані інфраструктури.

Після налаштування у вас буде:

• доменне ім'я, що вказує на VPS;
• дійсний TLS-сертифікат Let's Encrypt;
• служба hysteria-server.service, що запускається після перезавантаження;
• закритий UDP-порт 443, доступний лише через автентифікацію Hysteria 2;
• клієнтський YAML-конфіг для Windows, Linux, macOS, Android або iOS-клієнта з підтримкою Hysteria 2;
• резервна копія конфігурації та сертифікатів.

Чому саме Hysteria 2

Основна відмінність Hysteria 2 від класичного VPN — транспорт. WireGuard використовує власний UDP-протокол, OpenVPN часто використовують поверх UDP або TCP, а Hysteria 2 передає дані через QUIC із TLS. QUIC краще працює з втратою пакетів і зміною мережевого маршруту, що може бути корисним у мобільних мережах і на нестабільних каналах.

Self-hosted або готовий VPN-сервіс

Готовий VPN-сервіс зручний: не потрібно адмініструвати сервер, продовжувати сертифікат і відстежувати оновлення. Але ви ділите інфраструктуру з іншими користувачами, не керуєте серверною конфігурацією та довіряєте оператору сервісу.

Self-hosted Hysteria 2 потребує базового адміністрування Linux, зате дає незалежний сервер, контроль ключів і можливість змінити провайдера, просто розгорнувши конфігурацію на іншому VPS. Для одного-двох користувачів це зазвичай найпростіший сценарій особистої інфраструктури.

Використовуйте сервер у межах законів своєї країни, правил дата-центру та умов сервісів, до яких підключаєтеся. Hysteria 2 — мережевий інструмент, а не засіб обходу юридичних зобов'язань.

Яка VPS-конфігурація потрібна для цього завдання

Hysteria 2 сама по собі споживає мало пам'яті та CPU. Навантаження залежить не від кількості конфігів, а від кількості одночасних клієнтів, швидкості каналу, шифрування та обсягу трафіку, що проходить. Для особистого використання зазвичай важливіші якість мережі та відсутність жорстких обмежень UDP, ніж великий обсяг диска.

Практичний стартовий варіант: 1 vCPU, 1 ГБ RAM, 20 ГБ NVMe/SSD, публічний IPv4, канал 100 Мбіт/с і ввімкнений UDP. Для такого сценарію можна взяти VPS із зазначеними характеристиками або аналогічний віртуальний сервер в іншого провайдера.

Коли VPS достатньо

VPS підходить майже завжди: особистий проксі, кілька пристроїв, невелика сім'я, віддалена робота та тестові середовища. Hysteria 2 не зберігає великі бази даних і не потребує виділеного диска. Навіть за швидкості в сотні мегабіт вузьким місцем зазвичай стає ліміт каналу або місячна квота трафіку, а не обчислювальні ресурси.

Коли потрібен dedicated

Виділений сервер має сенс, якщо десятки користувачів стабільно споживають сотні мегабіт або гігабіт, якщо потрібен гарантований CPU без ефекту noisy neighbor, кілька мережевих IP, нестандартні правила маршрутизації або дуже великий місячний обсяг трафіку. Для одного користувача dedicated майже завжди надмірний.

Як вибрати локацію

Локація впливає на затримку, маршрут і швидкість. Вибирайте регіон, близький до основних користувачів: що менше RTT, то швидше відгукуються вебсайти, дзвінки й інтерактивні застосунки. Перед замовленням перевірте, чи дозволяє провайдер UDP/443 і чи немає фільтрації QUIC. Також враховуйте, що IP-адреса сервера визначатиме доступні регіональні версії сайтів і сервісів.

Для домену знадобиться A-запис, наприклад hy.example.com, що вказує на IPv4 VPS. Якщо вмикаєте IPv6, додайте AAAA-запис лише тоді, коли сервер справді має робочий публічний IPv6 і у firewall відкрито потрібний UDP-порт.

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

Нижче передбачається чистий сервер Ubuntu 24.04 LTS із доступом через SSH під користувачем root. Виконуйте початкове підключення з локального термінала. Перед забороною входу root переконайтеся, що вхід під новим користувачем за SSH-ключем працює в окремому вікні термінала.

Оновіть систему та встановіть базові утиліти

Ця команда оновлює індекс пакетів, встановлює всі доступні оновлення та додає інструменти для firewall, сертифікатів і діагностики.

apt update && apt upgrade -y
apt install -y curl wget ca-certificates gnupg ufw fail2ban certbot qrencode

Перезавантажте сервер, якщо оновлювалося ядро. Після перезавантаження знову підключіться через SSH.

reboot

Створіть окремого адміністратора

Замініть admin на своє ім'я користувача. Команда створює обліковий запис, домашній каталог і додає користувача до групи sudo.

adduser admin
usermod -aG sudo admin

На локальному комп'ютері створіть ключ, якщо його ще немає. Не передавайте приватний ключ на сервер і не надсилайте його в месенджери.

ssh-keygen -t ed25519 -a 100 -C "admin@local"

Скопіюйте публічний ключ на сервер. Вкажіть IP-адресу вашого VPS.

ssh-copy-id admin@SERVER_IP

Перевірте новий вхід в окремому терміналі до зміни параметрів SSH.

ssh admin@SERVER_IP

Вимкніть вхід root і парольну автентифікацію

Відкрийте конфігурацію SSH через редактор nano.

sudo nano /etc/ssh/sshd_config

Додайте або змініть наступні параметри. Якщо рядок уже існує у файлі, відредагуйте його, а не створюйте дублікат.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no

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

sudo sshd -t && sudo systemctl restart ssh

Налаштуйте firewall

Для випуску сертифіката через HTTP-01 знадобиться TCP/80. Hysteria 2 приймає трафік на UDP/443. SSH залишаємо відкритим лише тому, що сервером потрібно керувати. Якщо у вас статичний домашній IP, пізніше можна обмежити SSH лише цією адресою.

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

Не відкривайте TCP/443 без потреби. Hysteria 2 із цієї статті використовує UDP/443. TCP/443 знадобиться, якщо пізніше ви розгорнете Caddy, Nginx або інший вебсервер для сайту чи reverse proxy.

Увімкніть Fail2ban

Fail2ban захищає насамперед SSH від перебору паролів і ключів. За вимкненої парольної автентифікації ризик уже нижчий, але сервіс усе одно корисний як додатковий рівень захисту.

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

Перевірте DNS перед випуском сертифіката

У панелі DNS створіть A-запис. У прикладі використовується домен hy.example.com. Підставте власне доменне ім'я та реальний IP сервера.

dig +short A hy.example.com
curl -4 ifconfig.me

Перша команда має вивести IP VPS, друга — публічний IPv4 сервера. Якщо адреси відрізняються, не продовжуйте: Let's Encrypt не зможе підтвердити володіння доменом.

Встановлення Hysteria 2 — покроково

На початок 2026 року рекомендується використовувати актуальну стабільну гілку Hysteria 2, а не стару Hysteria 1. Перед встановленням звіряйте номер останнього релізу в офіційному репозиторії проєкту. У прикладі використовується офіційний інсталятор: він завантажує відповідний бінарний файл, створює systemd-службу та каталог /etc/hysteria.

Випустіть TLS-сертифікат Let's Encrypt

Certbot у режимі standalone тимчасово запускає невеликий HTTP-сервер на TCP/80. Переконайтеся, що порт відкритий в UFW і панелі провайдера. Замініть адресу пошти та домен на свої.

sudo certbot certonly --standalone \
  --agree-tos \
  --no-eff-email \
  --email [email protected] \
  -d hy.example.com

Після успіху сертифікат буде розміщений у каталозі:

sudo ls -la /etc/letsencrypt/live/hy.example.com/

Нас цікавлять файли fullchain.pem і privkey.pem. Не публікуйте вміст privkey.pem: це приватний TLS-ключ.

Завантажте та встановіть Hysteria 2

Команда нижче запускає офіційний інсталятор. Перед запуском корисно переглянути скрипт у браузері або завантажити його окремо для аудиту, особливо якщо сервер використовується в робочій інфраструктурі.

bash <(curl -fsSL https://get.hy2.sh/)

Інсталятор зазвичай пропонує вибрати встановлення серверного компонента. Після завершення перевірте версію бінарного файлу. Очікується версія виду v2.x.x.

hysteria version

Перевірте, які unit-файли створено. У більшості встановлень сервер називається hysteria-server.service.

sudo systemctl list-unit-files | grep hysteria

Створіть безпечний пароль доступу

Пароль Hysteria 2 не є паролем користувача Linux. Це окремий секрет, який повинні знати сервер і кожен дозволений клієнт. Згенеруйте щонайменше 32 випадкові символи.

openssl rand -base64 36

Збережіть значення в менеджері паролів. Для автоматичної підстановки в конфігурацію можна тимчасово записати його у змінну поточної shell-сесії. Після перезавантаження термінала змінна зникне.

export HY2_PASSWORD='ВСТАВЬТЕ_СЮДА_СГЕНЕРИРОВАННЫЙ_ПАРОЛЬ'

Підготуйте каталог конфігурації

Інсталятор найчастіше вже створює каталог. Команда нижче гарантує його існування та обмежує читання конфігурації root-користувачем.

sudo install -d -m 700 /etc/hysteria
sudo touch /etc/hysteria/config.yaml
sudo chmod 600 /etc/hysteria/config.yaml

На цьому етапі бінарний файл встановлено, сертифікат отримано, а сервер готовий до конфігурації.

Конфігурація сервера та клієнта

Hysteria 2 використовує YAML. У мінімальній серверній конфігурації задаються адреса прослуховування, TLS-сертифікат і пароль автентифікації. Для особистого сервера краще не вмикати обфускацію без потреби: вона ускладнює діагностику та не замінює TLS.

Серверний конфіг

Відкрийте файл:

sudo nano /etc/hysteria/config.yaml

Вставте конфігурацію. Замініть домен і пароль. Порт :443 означає прослуховування UDP/443 на всіх мережевих інтерфейсах.

listen: :443

tls:
  cert: /etc/letsencrypt/live/hy.example.com/fullchain.pem
  key: /etc/letsencrypt/live/hy.example.com/privkey.pem

auth:
  type: password
  password: "ВСТАВЬТЕ_ДЛИННЫЙ_СЛУЧАЙНЫЙ_ПАРОЛЬ"

masquerade:
  type: proxy
  proxy:
    url: https://www.cloudflare.com/
    rewriteHost: true

Блок masquerade визначає відповідь на звичайні HTTP-запити, якщо вони потрапляють на сервер не як валідний трафік Hysteria 2. Він не впливає на парольну автентифікацію клієнтів. Як URL вкажіть доступний HTTPS-сайт; не використовуйте власний домен, якщо на ньому немає окремого вебсервера.

Секрет краще не зберігати в репозиторії Git, скриншотах або публічних нотатках. Для однієї особистої машини допустимо зберігати пароль безпосередньо у файлі з правами 600. У командах автоматизації можна використовувати змінну середовища, але не передавайте її через історію shell або список процесів.

Права на сертифікати

Hysteria запускається з правами root у типовій конфігурації systemd і може читати ключ Let's Encrypt. Перевірте шляхи, щоб виключити помилки.

sudo test -r /etc/letsencrypt/live/hy.example.com/fullchain.pem && echo "cert OK"
sudo test -r /etc/letsencrypt/live/hy.example.com/privkey.pem && echo "key OK"

Запустіть службу

Команда вмикає автозапуск після перезавантаження та негайно запускає сервер.

sudo systemctl enable --now hysteria-server.service
sudo systemctl status hysteria-server.service --no-pager

Якщо unit має іншу назву, використовуйте результат команди systemctl list-unit-files | grep hysteria з попереднього розділу. За успішного запуску статус має бути active (running).

Перевірте UDP-порт

Команда показує процес, що слухає UDP/443. У виводі має бути Hysteria.

sudo ss -lunp | grep ':443'

Клієнтський конфіг Hysteria 2

Створіть на клієнтському комп'ютері файл client.yaml. Він підходить для CLI-клієнта Hysteria 2 і містить лише необхідні параметри. Значення домену та пароля мають повністю збігатися із серверними.

server: hy.example.com:443

auth: "ВСТАВЬТЕ_ДЛИННЫЙ_СЛУЧАЙНЫЙ_ПАРОЛЬ"

tls:
  sni: hy.example.com
  insecure: false

socks5:
  listen: 127.0.0.1:1080

http:
  listen: 127.0.0.1:8080

Параметр insecure: false принципово важливий: клієнт перевіряє сертифікат та ім'я в сертифікаті. Не встановлюйте true для «швидкого виправлення» помилки TLS. Якщо перевірка не проходить, виправляйте DNS, дату пристрою, SNI або сертифікат.

Після запуску клієнта локальний SOCKS5-проксі буде доступний на 127.0.0.1:1080, а HTTP-проксі — на 127.0.0.1:8080. У браузері або застосунку вкажіть SOCKS5 127.0.0.1, порт 1080. Не слухайте SOCKS5 на 0.0.0.0, інакше локальний проксі можуть використовувати інші пристрої мережі.

Запуск клієнта через CLI

Якщо на клієнті встановлено бінарний файл Hysteria 2, запустіть його цією командою:

hysteria -c client.yaml client

Для графічних клієнтів імпортуйте значення вручну: тип протоколу Hysteria 2, адресу hy.example.com, порт 443, пароль, SNI hy.example.com та увімкнену перевірку сертифіката. Назви полів залежать від застосунку, але зміст параметрів однаковий.

Автоматичне продовження сертифіката

Certbot в Ubuntu встановлює systemd timer. Але Hysteria потрібно перезапускати після оновлення файлів сертифіката, інакше процес продовжить використовувати старий сертифікат у пам'яті. Створіть deploy hook.

sudo install -d -m 755 /etc/letsencrypt/renewal-hooks/deploy
sudo nano /etc/letsencrypt/renewal-hooks/deploy/restart-hysteria.sh

Додайте наступний скрипт:

#!/bin/sh
systemctl restart hysteria-server.service

Зробіть файл виконуваним і протестуйте безпечний режим оновлення.

sudo chmod 755 /etc/letsencrypt/renewal-hooks/deploy/restart-hysteria.sh
sudo certbot renew --dry-run

Перевірка працездатності

Перевірка має відбуватися у три етапи: серверна служба, доступність порту та реальне проходження трафіку через клієнт. Не обмежуйтеся статусом systemd: служба може працювати, але UDP може блокуватися firewall провайдера або домен може вести на інший IP.

Перевірте логи сервера

Виведіть останні 100 рядків журналу та залиште потік логів відкритим під час першого підключення клієнта.

sudo journalctl -u hysteria-server.service -n 100 --no-pager
sudo journalctl -u hysteria-server.service -f

За нормального запуску не має бути помилок читання сертифіката, синтаксису YAML або прив'язки порту. Помилка address already in use означає, що UDP/443 уже зайнятий іншим процесом.

Перевірте DNS і сертифікат

З клієнтської машини перевірте, що домен резолвиться у правильний IPv4. Звичайний curl не тестує Hysteria 2, оскільки це не HTTP-сервер, але DNS-перевірка все одно необхідна.

dig +short hy.example.com
ping -c 3 hy.example.com

Ping може бути заблокований правилами мережі та не є остаточною діагностикою. Важливіше збіг IP-адреси з dig з IP VPS та успішне підключення Hysteria-клієнта.

Перевірте трафік через SOCKS5

Після запуску клієнтського процесу виконайте запит через локальний SOCKS5. Команда має показати публічний IP вашого VPS, а не IP домашнього провайдера.

curl --proxy socks5h://127.0.0.1:1080 https://ifconfig.me/ip
echo

Ключ socks5h змушує curl резолвити доменне ім'я через проксі, а не локально. Це корисно для перевірки того, що DNS-запити для цього запиту також проходять через віддалений сервер.

Перевірте швидкість і втрати

Спочатку виміряйте звичайну швидкість VPS, потім тестуйте через проксі. Для швидкої перевірки завантаження великого файлу використовуйте будь-який дозволений публічний ресурс. Якщо швидкість помітно нижча за очікувану, перевірте ліміт тарифу, завантаження CPU, маршрут і наявність UDP-фільтрації.

top
sudo ss -s
sudo journalctl -u hysteria-server.service --since "10 minutes ago"

Не оцінюйте якість за одним тестом швидкості: результат залежить від маршруту до тестового сервера, часу доби та мережі клієнта. Для реальної оцінки перевірте вебсайти, відеодзвінки, завантаження файлів і мобільну мережу.

Бекапи та обслуговування

Hysteria 2 не зберігає базу даних користувачів у базовому сценарії, тому резервне копіювання простіше, ніж для GitLab або Mattermost. Але втрата конфігурації, TLS-ключа та відомостей про домен однаково ускладнить відновлення. Бекап не повинен залишатися лише на тому самому VPS: у разі видалення сервера він буде втрачений разом із даними.

Що бекапити

• /etc/hysteria/config.yaml — конфігурація сервера та пароль доступу;
• /etc/letsencrypt/ — сертифікати, приватні ключі та налаштування продовження;
• /etc/ufw/ — правила UFW, якщо ви змінювали їх вручну;
• /etc/ssh/sshd_config і додаткові файли з /etc/ssh/sshd_config.d/;
• список встановленого ПЗ та systemd-налаштувань;
• окремо збережений клієнтський конфіг або параметри підключення.

Не обов'язково бекапити сам бінарний файл Hysteria: його можна знову завантажити з офіційного релізу. Важливіше зберегти перевірену конфігурацію та секрети.

Простий архівний бекап через rsync

Нижче приклад копіює критичні каталоги на окремий backup VPS через SSH. На резервному сервері заздалегідь створіть користувача backup, каталог /srv/backups/hysteria та окремий SSH-ключ з обмеженими правами.

sudo nano /usr/local/sbin/backup-hysteria.sh

Вміст скрипта:

#!/bin/bash
set -euo pipefail

DATE=$(date +%F)
BACKUP_DIR="/tmp/hysteria-backup-${DATE}"
REMOTE="backup@BACKUP_SERVER_IP:/srv/backups/hysteria/"

mkdir -p "${BACKUP_DIR}"

tar -czf "${BACKUP_DIR}/hysteria-config.tar.gz" \
  /etc/hysteria \
  /etc/letsencrypt \
  /etc/ufw \
  /etc/ssh/sshd_config \
  /etc/ssh/sshd_config.d 2>/dev/null

rsync -a --delete "${BACKUP_DIR}/" "${REMOTE}"
rm -rf "${BACKUP_DIR}"

Зробіть скрипт виконуваним і запустіть вручну. Перший запуск завжди перевіряйте перед додаванням у cron.

sudo chmod 700 /usr/local/sbin/backup-hysteria.sh
sudo /usr/local/sbin/backup-hysteria.sh

Для production-сценарію краще використовувати restic або borg: вони шифрують вміст, підтримують дедуплікацію, історію знімків і зберігання в S3-сумісних бакетах. Якщо використовуєте rsync, шифрування забезпечується SSH під час передавання, але самі файли на резервному сервері будуть доступні його адміністратору.

Додайте cron-завдання

Відкрийте crontab root і запускайте бекап щодня вночі. Лог знадобиться для діагностики невдалих копіювань.

sudo crontab -e

30 3   * /usr/local/sbin/backup-hysteria.sh >> /var/log/hysteria-backup.log 2>&1

Оновлення Hysteria 2

Для особистого сервера оновлюйте Hysteria 2 у коротке вікно обслуговування раз на місяць або після важливих security-релізів. Перед оновленням створіть бекап, прочитайте changelog і збережіть поточну версію. Оновлення зазвичай перериває активні підключення на кілька секунд.

hysteria version
sudo /usr/local/bin/hysteria version
sudo systemctl stop hysteria-server.service
sudo cp /usr/local/bin/hysteria /root/hysteria.backup
sudo systemctl start hysteria-server.service

Конкретна команда оновлення залежить від способу встановлення та може бути доступна в офіційному інсталяторі. Після оновлення завжди виконайте hysteria version, перевірте статус systemd і підключення клієнта. Якщо нова версія не запускається, відновіть бінарний файл і конфігурацію з бекапу.

Для одного сервера «rolling update» не потрібен: використовуйте коротке maintenance window. Для кількох серверів спочатку оновлюйте один вузол, перевіряйте його, потім перемикайте на нього клієнтів або балансувальник і оновлюйте решту.

Усунення несправностей і FAQ

Служба Hysteria 2 не запускається: що перевірити?

Спочатку виконайте sudo systemctl status hysteria-server.service --no-pager і sudo journalctl -u hysteria-server.service -n 100 --no-pager. Найчастіші причини — помилка YAML-відступів, неправильний шлях до fullchain.pem або privkey.pem, порт UDP/443 уже зайнятий або в паролі є неекрановані символи. Використовуйте пробіли, а не табуляцію, і беріть пароль у подвійні лапки. Після виправлення запустіть sudo systemctl restart hysteria-server.service.

Certbot повідомляє, що не зміг пройти HTTP-01 challenge. Як виправити?

Перевірте A-запис командою dig +short hy.example.com: він має вказувати на IP VPS. Переконайтеся, що TCP/80 відкритий і в UFW, і в зовнішньому firewall панелі провайдера. Команда sudo ss -ltnp | grep ':80' покаже, чи не зайнятий порт вебсервером. Якщо Nginx або Caddy вже слухає TCP/80, використовуйте certbot з методом webroot або тимчасово зупиніть вебсервер на час випуску сертифіката.

Клієнт показує помилку TLS certificate verification failed. Що робити?

Не вмикайте insecure: true як постійне рішення. Перевірте, що в клієнті задано sni: hy.example.com, а не IP-адресу VPS, і що саме цей домен вказаний у сертифікаті. Звірте дату й час на клієнтському пристрої. Також переконайтеся, що DNS домену веде на потрібний сервер. Якщо сертифікат нещодавно випускався, перевірте шлях до файлів і перезапустіть Hysteria після продовження.

Сервер запущений, але клієнт не підключається і в логах немає подій. Чому?

Найімовірніше, UDP/443 блокується до сервера. Перевірте sudo ufw status, наявність правила 443/udp ALLOW і мережевий firewall у панелі VPS. Деякі мережі, особливо корпоративні або гостьові Wi-Fi, обмежують UDP або QUIC. Перевірте підключення з мобільної мережі. Також переконайтеся, що сервер справді слухає UDP/443: sudo ss -lunp | grep ':443'.

Чому через Hysteria 2 низька швидкість?

Порівняйте швидкість без проксі та через проксі, потім перевірте CPU командою top під час тесту. Причина може бути в ліміті каналу VPS, місячній квоті трафіку, перевантаженому маршруті, обмеженні на боці мережі клієнта або втратах UDP-пакетів. Виберіть локацію ближче до користувача та протестуйте кілька цілей. Не збільшуйте параметри швидкості в конфігу навмання: спочатку переконайтеся, що проблема не в каналі провайдера.

Яка VPS-конфігурація мінімально підійде?

Для одного користувача або кількох особистих пристроїв мінімально достатньо 1 vCPU, 1 ГБ RAM, 10 ГБ SSD і публічного IPv4. Потрібен доступний UDP-трафік і відкритий UDP/443. Краще одразу вибрати 20 ГБ диска: це дасть запас для оновлень, логів і сертифікатів. Для мережі розумний мінімум — 100 Мбіт/с і від 1 ТБ трафіку на місяць, але для активного відео або завантажень важливіша збільшена квота.

Що вибрати — VPS чи dedicated для цього завдання?

Для Hysteria 2 майже завжди починайте з VPS. Він дешевший, швидко розгортається та забезпечує достатньо ресурсів для особистого проксі або невеликої команди. Dedicated потрібен за постійного високого навантаження, десятків активних користувачів, вимоги гарантованого CPU, 1 Гбіт/с без сильної віртуалізації або дуже великого трафіку. Перехід на dedicated не змінює саму конфігурацію Hysteria: достатньо перенести домен, сертифікат і YAML-файл.

Чи можна підключити кілька пристроїв з одним паролем?

Технічно можна, і для одного власника це зручний варіант. Недолік у тому, що в разі витоку пароля доведеться замінити його на сервері й на всіх пристроях. Для сім'ї або команди використовуйте окремі облікові дані, якщо ваша схема керування Hysteria 2 та використовуваний клієнт це підтримують, або створюйте окремі сервери чи конфігурації. Ніколи не публікуйте клієнтський конфіг із реальним паролем у відкритому доступі.

Чи потрібно відкривати TCP/443?

Для мінімальної конфігурації Hysteria 2 на QUIC потрібен UDP/443, а не TCP/443. TCP/80 потрібен лише на етапі випуску та продовження сертифіката методом HTTP-01. TCP/443 можна залишити закритим, якщо на сервері немає сайту або reverse proxy. Відкривайте додаткові порти лише для конкретного завдання: це зменшує поверхню атаки та спрощує діагностику правил firewall.

Безпека та практичні обмеження

Робочий проксі-сервер — це не лише YAML-файл. Мінімальна безпека включає SSH-ключі, вимкнений root-вхід, firewall, регулярні оновлення та резервні копії. Найчастіша причина компрометації невеликих VPS — не вразливість Hysteria, а слабкий пароль SSH, відкрита панель адміністрування або забутий сервіс, який не оновлюється.

Чекліст після налаштування

• Вхід через SSH дозволений лише за ключами.
• Для користувача root вимкнений віддалений вхід.
• Відкриті лише SSH, TCP/80 і UDP/443.
• Встановлені оновлення безпеки Ubuntu.
• Пароль Hysteria містить щонайменше 32 випадкові символи.
• Перевірка TLS на клієнтах увімкнена.
• Certbot успішно проходить renew --dry-run.
• Конфігурація та сертифікати копіюються за межі VPS.
• Перевірено відновлення хоча б одного бекапу.

Не публікуйте секрети

Файл клієнта містить адресу сервера та пароль. Його не можна надсилати в публічні чати, додавати в GitHub, вставляти в скріншоти або зберігати в незахищеному хмарному документі. Якщо конфіг було надіслано не тій людині, вважайте пароль скомпрометованим: згенеруйте новий, змініть серверний YAML, перезапустіть службу та оновіть усі клієнти.

Стежте за трафіком

Перевіряйте споживання трафіку в панелі VPS і системні логи. Незвичне зростання вихідного трафіку може означати витік пароля або використання сервера сторонньою особою. У разі підозри на компрометацію негайно замініть пароль Hysteria, SSH-ключі за потреби, оновіть систему та вивчіть журнали входів.

sudo journalctl -u hysteria-server.service --since "24 hours ago"
sudo last -a | head -20
sudo apt update && sudo apt upgrade -y

Обмеження Hysteria 2

Hysteria 2 залежить від доступності UDP. У деяких корпоративних мережах, готелях, навчальних закладах і публічних Wi-Fi UDP може бути обмежений або працювати нестабільно. У такому разі корисно мати резервний спосіб віддаленого доступу, наприклад WireGuard або звичайний HTTPS-сервіс для адміністрування. Не видаляйте доступ SSH, доки не протестували підключення Hysteria з реальних мереж, якими плануєте користуватися.

Висновки та наступні кроки

Тепер на VPS працює Hysteria 2 з TLS-сертифікатом, парольною автентифікацією, firewall і автоматичним продовженням сертифіката. Клієнт підключається до вашого домену через UDP/443 і створює локальний SOCKS5 або HTTP-проксі.

1. Перевірте з'єднання з домашньої мережі, мобільного інтернету та робочого Wi-Fi.
2. Налаштуйте зашифрований бекап на окремий VPS або S3-сховище та протестуйте відновлення.
3. Раз на місяць оновлюйте Ubuntu і Hysteria 2, а зі зростанням навантаження контролюйте трафік, CPU та якість маршруту.

Якщо сервером користуватимуться кілька людей, розділіть доступи, документуйте зміну паролів і заздалегідь підготуйте процедуру перенесення на новий IP або потужніший сервер.