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. Для нескольких серверов сначала обновляйте один узел, проверяйте его, затем переключайте клиентов или балансировщик на него и обновляйте остальные.

Troubleshooting и 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 или более мощный сервер.