Настройка сервера Hysteria2 требует доступного пути UDP, действительного сертификата TLS и отдельного секрета аутентификации. Здесь используется фиксированная версия нативного бинарного файла, независимый административный доступ и раздельная проверка прикладного трафика TCP и UDP до принятия сервиса в эксплуатацию.

Ключевые выводы

Прикладной TCP тоже передаётся через транспорт Hysteria на основе UDP.

Сертификат подтверждает сервер, но не разрешает подключение клиента.

Ответ веб-сервера не доказывает успешную аутентификацию прокси.

Неверный секрет должен отклоняться также после перезапуска и восстановления.

Когда нужна настройка сервера Hysteria2?

Начните с плана ответственности и восстановления своего узла. Для изучения развёртывания на базе QUIC эта процедура задаёт ограниченный сценарий приёмки. Для обычного интернет-выхода сначала сравните обслуживание VPS и готовый сервис: сертификаты и обновления хоста останутся вашей обязанностью.

Обзор Hysteria2 объясняет модель транспорта. Если клиентская сеть не пропускает нужный UDP, изучите последствия блокировки UDP, а не пытайтесь исправить её открытием TCP. Развёртывание Shadowsocks Rust представляет другой вариант реализации с иной моделью ключей.

Применимость и доказательства: выделенный сервер Ubuntu 24.04 LTS x86-64, отдельный Linux-клиент, Hysteria v2.13.0, публичный адрес IPv4 и заранее выданный действительный сертификат вашего домена. Автор не проводил сквозное развёртывание. Команды и ожидаемые условия ниже предназначены для проверки читателем и основаны на официальной документации, а не на измерениях. Для другой архитектуры требуется соответствующий файл выпуска, а не бинарный файл ниже.［1］［2］

Шаг 1: Сохраните управление и установите доверенный бинарный файл

Проверьте новое SSH-подключение и консоль провайдера, независимые от будущего прокси. Приватно запишите порты, маршруты, DNS, владельцев правил межсетевого экрана, службы, пути сертификатов и задания продления. Зарезервируйте UDP 8443, а на клиенте — TCP 1080 и UDP 19001. При конфликте или наличии пользователя, каталога либо unit-файла hysteria-ops остановитесь: чужую установку заменять нельзя.

Высокий порт 8443 позволяет отдельной служебной учётной записи работать без root и разрешения на низкие порты. При необходимости установите curl, ca-certificates и Python 3 из доверенных пакетов Ubuntu. Загружайте файл выбранного официального выпуска; до запуска проверьте доступные сведения о целостности и принадлежность проекта. При сомнениях прекратите установку. Строка версии сама по себе не подтверждает происхождение.

umask 077
curl --fail --show-error --location \
  https://github.com/HyNetworks/hysteria/releases/download/app%2Fv2.13.0/hysteria-linux-amd64 \
  -o hysteria-v2.13.0
chmod 700 hysteria-v2.13.0
./hysteria-v2.13.0 version
sudo install -m 755 hysteria-v2.13.0 /usr/local/bin/hysteria-ops
sudo useradd --system --home /nonexistent --shell /usr/sbin/nologin hysteria-ops
sudo install -d -o root -g hysteria-ops -m 750 /etc/hysteria-ops

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

Шаг 2: Подготовьте сертификат Hysteria2 и аутентификацию

До продолжения получите действительный сертификат реального домена утверждённым способом. Проверьте SAN, срок действия, цепочку и соответствие закрытого ключа. Записи A/AAAA, которые может выбрать клиент, должны указывать на предусмотренные доступные пути. Здесь сервер слушает IPv4; ошибочная AAAA-запись может создать проблему маршрута, а не пароля.

Для этой схемы используйте серверный сертификат ECDSA или RSA. Клиент v2.13.0 по умолчанию имитирует рукопожатие Chrome, не объявляя поддержку подписей Ed25519. Поэтому даже действительный сертификат Ed25519 может привести к отказу рукопожатия; получите совместимый сертификат, не отключая его проверку.［6］

Разместите полную цепочку и закрытый ключ по указанным путям. Создайте /etc/hysteria-ops/config.yaml редактором с правами root, замените секрет отдельным случайным значением из менеджера паролей. Не помещайте его в аргументы оболочки, публичные URI или журналы. Используются вручную управляемые файлы TLS и пароль; одновременно настраивать ACME и статические файлы не нужно.［3］［4］

listen: 0.0.0.0:8443
tls:
  cert: /etc/hysteria-ops/fullchain.pem
  key: /etc/hysteria-ops/privkey.pem
auth:
  type: password
  password: "REPLACE_WITH_DISTINCT_RANDOM_SECRET"
disableUDP: false

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

Сохраните следующий unit как /etc/systemd/system/hysteria-ops.service. Это отдельная служба данного примера, а не название службы официального установщика.

[Unit]
Description=Dedicated Hysteria2 reader deployment
After=network-online.target
Wants=network-online.target

[Service]
User=hysteria-ops
Group=hysteria-ops
ExecStart=/usr/local/bin/hysteria-ops server -c /etc/hysteria-ops/config.yaml
Restart=no
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=strict

[Install]
WantedBy=multi-user.target

Шаг 3: Настройте UDP Hysteria2 в межсетевом экране

Сохраните независимые правила SSH. У фактических владельцев облачного и хостового межсетевых экранов сначала разрешите UDP 8443 только от авторизованного тестового клиента. Не очищайте таблицы и не отключайте межсетевой экран. При наличии NAT разрешённое перенаправление должно передавать UDP на этот хост; TCP 8443 данный слушатель не заменяет.［3］

sudo chmod 640 /etc/hysteria-ops/config.yaml /etc/hysteria-ops/privkey.pem /etc/hysteria-ops/fullchain.pem
sudo chown root:hysteria-ops /etc/hysteria-ops/config.yaml /etc/hysteria-ops/privkey.pem /etc/hysteria-ops/fullchain.pem
sudo systemctl daemon-reload
sudo systemctl start hysteria-ops
sudo systemctl status hysteria-ops --no-pager
sudo ss -lunp

Ожидаются работающая выбранная служба и слушатель IPv4 UDP на 8443. Это подтверждает лишь запуск и привязку. Если служба завершается, изучите journalctl -u hysteria-ops: отдельно проверьте YAML, права на файлы, сертификат и конфликты адресов. Исправляйте при закрытом входящем доступе. Игнорирование сертификата на клиенте не является исправлением TLS.

Шаг 4: Подключите правильный клиент и отклоните неверный секрет

На отдельном разрешённом Linux-клиенте получите подходящий бинарный файл той же версии описанным доверенным способом. В приватном каталоге создайте client.yaml, замените оба примера доменов и секрет. Для UDP нужен разрешённый эхо-ответчик под вашим управлением на udp-check.example.net:9001, доступный с сервера. Имя в примере не обозначает публичный тестовый сервис. Без ответчика приёмка UDP остаётся неподтверждённой.［5］［6］

server: hy.example.com:8443
auth: "REPLACE_WITH_DISTINCT_RANDOM_SECRET"
tls:
  sni: hy.example.com
  insecure: false
socks5:
  listen: 127.0.0.1:1080
udpForwarding:
  - listen: 127.0.0.1:19001
    remote: udp-check.example.net:9001

Оба локальных слушателя должны оставаться на loopback. Запись UDP forwarding передаёт пакеты управляемому ответчику через Hysteria; она не меняет маршруты всей системы и не открывает общий прокси в LAN. Запустите клиент в отдельном терминале и не публикуйте вывод.

chmod 600 client.yaml
./hysteria-v2.13.0 client -c client.yaml

Явно выберите SOCKS5 127.0.0.1:1080 в тестовом браузере и, если поддерживается, разрешайте домены через прокси. Затем проверьте видимый IP выхода и сравните его с известным выходным адресом сервера. Нужен фактический запрос браузера, а не только сообщение «подключено».

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

Шаг 5: Раздельно проверьте TCP, UDP, DNS и отключение

Вернитесь к профилю с правильным секретом. HTTPS-запрос браузера проверяет прикладной TCP, хотя транспорт Hysteria использует UDP. Следующая команда читателя отдельно отправляет один UDP-пакет через локальное перенаправление. Ожидается идентичная полезная нагрузка от вашего ответчика; фактический вывод здесь не приводится.

python3 - <<'CHECK'
import socket
with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock:
    sock.settimeout(3)
    sock.sendto(b"reader-check", ("127.0.0.1", 19001))
    data, _ = sock.recvfrom(1024)
    assert data == b"reader-check", "Unexpected UDP reply"
CHECK

Уровень	Доказательство читателя	При неудаче
Прикладной TCP	Новый HTTPS-запрос через прокси и нужный выход	Раздельно проверьте браузер, auth, выход сервера и назначение
Прикладной UDP	Эхо-ответ совпадает с пакетом	Проверьте forwarding, `disableUDP`, ответчик и обратный путь
DNS	Разрешение соответствует политике приложения	Разграничьте локальный и удалённый DNS, не делайте вывод по IP
IPv6	Каждый применимый путь намеренно направлен или исключён	IPv4 не доказывает охват всего устройства
Отключение	Прокси отказывает или переключается на резервный путь строго по настройке	Прекратите чувствительные действия до проверки нужной политики

Обычная проверка TCP-порта и ответ HTTP3 не доказывают аутентификацию клиента Hysteria. Веб-страница с ошибкой может отвечать при отклонённом прокси-доступе. Не смешивайте проверку неверного секрета с доступностью и прикладными TCP/UDP. Локальный SOCKS не предоставляет туннель всего устройства или kill switch.［3］［5］

Шаг 6: Продлевайте, отзывайте, восстанавливайте и останавливайте осознанно

В согласованное окно перезапустите отдельную службу, повторите проверки правильного и неверного секрета, TCP и UDP. Только после приёмки выполняйте systemctl enable hysteria-ops, если нужен автозапуск. Сначала убедитесь, что после перезагрузки хоста сертификаты и конфигурация останутся доступны службе.

При продлении существующий ответственный за сертификат должен атомарно установить согласованную новую цепочку и ключ по заданным путям, восстановить root:hysteria-ops и режимы 640, затем перезапустить службу в согласованное окно. Проверьте новую идентичность обычным клиентом с проверкой TLS. Истёкший сертификат требует исправления, а не insecure: true; неполное обновление требует возврата действительной пары либо закрытия сервиса.

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

С остановленной службы сохраните каталог конфигурации и TLS, выбранный бинарный файл, unit, записи о продлении и правилах межсетевого экрана в зашифрованное ограниченное хранилище вне хоста. Более поздний журнал смены и отзыва секретов храните отдельно. Восстанавливайте на изолированной замене той же версии при закрытом входе: верните владельцев, права и действительную пару сертификатов, затем примените текущие секреты из журнала до запуска. Повторите положительные, отрицательные и перезапусковые проверки до открытия. Старый пароль в архиве не становится разрешённым автоматически.

Команды жизненного цикла ниже выполняются отдельно: перезапуск для приёмки, просмотр журнала, затем остановка и отключение при выводе из эксплуатации. Не вставляйте блок как непрерывный тест доступности.

sudo systemctl restart hysteria-ops
sudo journalctl -u hysteria-ops --since "10 minutes ago" --no-pager
sudo systemctl stop hysteria-ops
sudo systemctl disable hysteria-ops

При выводе закройте только UDP-правило этого развёртывания, остановите клиент, удалите его настройку прокси в браузере и локальный UDP-слушатель, отзовите секреты. После решения о хранении удалите только созданные здесь unit, бинарный файл, каталог и пользователя; перечитайте systemd. Отдельно рассмотрите задания продления, DNS и облачные ресурсы. Проверьте новое SSH-подключение и исходные службы. Удаление программы не прекращает оплату облака. Если восстановление не подтверждено, оставьте вход закрытым и остановите изменения.

Итоги

Проверяйте серверную идентичность, клиентскую аутентификацию и прикладной транспорт отдельно.
Разделяйте продление сертификата и смену пароля, повторяя проверки после перезапуска.
Восстановление завершено только после отказа старым секретам и успеха разрешённых клиентов.

Часто задаваемые вопросы (FAQ)

Поможет ли открытие TCP 8443 при блокировке UDP?

Нет. Сервер слушает UDP даже для прикладного TCP. Исследуйте разрешённый путь UDP, не заменяя его несвязанным правилом TCP.

Разрешает ли действительный сертификат доступ клиента?

Сертификат подтверждает сервер клиенту, а отдельный пароль разрешает клиентский доступ. Обе проверки обязательны; их секреты должны различаться.

Стоит ли копировать большое значение bandwidth?

Не копируйте неизмеренную скорость. Здесь настройка полосы опущена; документированные параметры добавляйте только после получения данных своей разрешённой сети.

Достаточно ли браузера для проверки прикладного UDP?

Успешный HTTPS-запрос проверяет другой прикладной путь. Используйте поддерживаемый UDP-режим клиента и управляемый ответчик, записывая результат отдельно.

Можно ли отозвать только одного клиента с этим паролем?

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

Почему веб-страница отвечает при неработающем прокси?

HTTP-ответ и аутентифицированный запрос прокси являются разными действиями. Требуйте реальный запрос с правильными данными и отказ с неверными.

Выполнил ли автор эти проверки?

Сквозное авторское тестирование не заявлено. Таблица задаёт ожидаемые доказательства; сервер, клиент, сеть, дату и результаты запишите в своей разрешённой среде.

Источники:

Hysteria v2.13.0 — https://github.com/HyNetworks/hysteria/releases/tag/app/v2.13.0
Hysteria 2 — Installation — https://v2.hysteria.network/docs/getting-started/Installation/
Hysteria 2 — Server — https://v2.hysteria.network/docs/getting-started/Server/
Hysteria 2 — Full Server Config — https://v2.hysteria.network/docs/advanced/Full-Server-Config/
Hysteria 2 — Client — https://v2.hysteria.network/docs/getting-started/Client/
Hysteria 2 — Full Client Config — https://v2.hysteria.network/docs/advanced/Full-Client-Config/

Sources checked 11 октября 2026 г.

Рекомендуемые статьи:

Настройка сервера Hysteria2: UDP, TLS и проверка доступа