Полная конфигурация сервера

На этой странице приведена документация по каждому полю конфигурационного файла сервера.

ПРИМЕЧАНИЕ: Один из распространённых паттернов в конфигурации клиента и сервера — «селектор типа»:

example:
  type: a
  a:
    something: something
  b:
    something: something
  c:
    something: something

type определяет, какой режим использовать и какие подполя парсить. В этом примере поле example может быть a, b или c. Если выбрано a, будет обработано подполе a, а подполя b и c будут проигнорированы.

Listen

Поле listen — это адрес прослушивания сервера. Если опущено, сервер будет слушать на :443, так как это стандартный порт HTTP/3.

listen: :443 # (1)!

1. Если IP-адрес опущен, сервер будет слушать на всех интерфейсах, как IPv4, так и IPv6. Для прослушивания только IPv4 используйте 0.0.0.0:443. Для только IPv6 — [::]:443.

TLS

Можно использовать либо tls, либо acme, но не оба одновременно.

tls: # (1)!
  cert: some.crt
  key: some.key
  sniGuard: strict | disable | dns-san # (2)!
  clientCA: client.crt # (3)!

acme:
  domains:
    - domain1.com
    - domain2.org
  email: [email protected]
  ca: zerossl # (1)!
  listenHost: 0.0.0.0 # (2)!
  dir: my_acme_dir # (3)!
  type: http | tls | dns # (4)!
  http:
    altPort: 8888 # (5)!
  tls:
    altPort: 44333 # (6)!
  dns:
    name: gomommy # (7)!
    config:
      key1: value1
      key2: value2

Обфускация

По умолчанию протокол Hysteria имитирует HTTP/3. Если ваша сеть специально блокирует QUIC или HTTP/3 трафик (но не UDP в целом), для обхода можно использовать обфускацию. В настоящее время у нас есть реализация обфускации под названием «Salamander», которая преобразует пакеты в случайные байты без паттернов. Для этой функции требуется пароль, который должен быть одинаковым на стороне клиента и сервера.

ПРИМЕЧАНИЕ: Включение обфускации сделает ваш сервер несовместимым со стандартными QUIC-соединениями, и он перестанет функционировать как валидный HTTP/3-сервер.

obfs:
  type: salamander # (2)!
  salamander:
    password: cry_me_a_r1ver # (1)!

1. Замените на надёжный пароль по вашему выбору.
2. Пожалуйста, прочитайте инструкции о «селекторе типа» в начале этой страницы.

Параметры QUIC

quic:
  initStreamReceiveWindow: 8388608 # (1)!
  maxStreamReceiveWindow: 8388608 # (2)!
  initConnReceiveWindow: 20971520 # (3)!
  maxConnReceiveWindow: 20971520 # (4)!
  maxIdleTimeout: 30s # (5)!
  maxIncomingStreams: 1024 # (6)!
  disablePathMTUDiscovery: false # (7)!

1. Начальный размер окна приёма потока QUIC.
2. Максимальный размер окна приёма потока QUIC.
3. Начальный размер окна приёма соединения QUIC.
4. Максимальный размер окна приёма соединения QUIC.
5. Максимальный таймаут бездействия. Сколько времени сервер будет считать клиента подключённым при отсутствии активности.
6. Максимальное количество параллельных входящих потоков.
7. Отключить обнаружение MTU пути QUIC.

Размеры окна приёма потока и соединения по умолчанию составляют 8 МБ и 20 МБ соответственно. Мы не рекомендуем изменять эти значения, если вы полностью не понимаете, что делаете. Если вы решите их изменить, рекомендуем сохранять соотношение окна приёма потока к окну приёма соединения как 2:5.

Полоса пропускания

bandwidth:
  up: 1 gbps
  down: 1 gbps

Значения полосы пропускания на стороне сервера действуют как ограничители скорости, ограничивая максимальную скорость отправки и приёма данных сервером (для каждого клиента). Обратите внимание, что скорость загрузки сервера — это скорость скачивания клиента, и наоборот. Вы можете опустить эти значения или установить в ноль с одной или обеих сторон, что будет означать отсутствие ограничения.

Поддерживаемые единицы измерения:

• bps или b (бит в секунду)
• kbps или kb или k (килобит в секунду)
• mbps или mb или m (мегабит в секунду)
• gbps или gb или g (гигабит в секунду)
• tbps или tb или t (терабит в секунду)

Игнорирование полосы пропускания клиента

ignoreClientBandwidth: false

ignoreClientBandwidth — это специальная опция, которая при включении заставляет сервер игнорировать любые подсказки о полосе пропускания от клиентов и использовать более традиционный алгоритм управления перегрузкой (в настоящее время BBR). Это фактически переопределяет любые значения полосы пропускания, установленные клиентами в обоих направлениях.

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

Процесс согласования полосы пропускания

На следующей диаграмме показан процесс согласования алгоритма управления перегрузкой и значения полосы пропускания между клиентом и сервером при различных конфигурациях.

graph TD;
    ICB{{"Настроено ли на сервере ignoreClientBandwidth: true?"}} -- "Да" --> BBR[/"Используется BBR"/];
    ICB -- "Нет" --> C_has_BW;
    C_has_BW{{"Настроена ли на клиенте bandwidth?"}} -- "Нет" --> BBR;
    C_has_BW -- "Да" --> Brutal;
    Brutal["Используется Brutal"] --> S_has_BW;
    S_has_BW{{"Настроена ли на сервере bandwidth?"}} -- "Нет" --> Brutal_C[/"Используется значение клиента"/];
    S_has_BW -- "Да" --> S_C_CMP;
    S_C_CMP{{"Сравнение значений bandwidth сервера и клиента"}} -- "Сервер больше" --> Brutal_C;
    S_C_CMP -- "Клиент больше" --> Brutal_S[/"Используется значение сервера"/];

    style BBR fill:#dc322f;
    style Brutal fill:#268bd2;
    style Brutal_C fill:#2aa198;
    style Brutal_S fill:#2aa198;

Если вы настраиваете сервер Hysteria для личного использования, можно упростить, удалив bandwidth и ignoreClientBandwidth из конфигурации сервера и указав полосу пропускания только в конфигурации клиента:

graph TD;
    S_no_BW["`Убедитесь, что на сервере **НЕ** настроены bandwidth и ignoreClientBandwidth`"] --> C_has_BW;
    C_has_BW{{"Настроена ли на клиенте bandwidth?"}} -- "Нет" --> BBR[/"BBR"/];
    C_has_BW -- "Да" --> Brutal_C[/"Brutal со значением клиента"/];

    style BBR fill:#dc322f;
    style Brutal_C fill:#2aa198;

Детали управления перегрузкой

(Информация в этом разделе считается внутренними деталями реализации Hysteria и может меняться между версиями)

В настоящее время в Hysteria есть 2 алгоритма управления перегрузкой:

BBR: Изначально разработан Google для TCP, мы адаптировали этот алгоритм для QUIC с незначительными модификациями. BBR — это типичный алгоритм управления перегрузкой, включающий фазы медленного старта и оценку полосы пропускания на основе изменений RTT. Он работает самостоятельно и не требует настройки полосы пропускания.

Brutal: Это пользовательский алгоритм управления перегрузкой Hysteria. В отличие от BBR, Brutal работает на модели фиксированной скорости и не снижает скорость в ответ на потерю пакетов или изменения RTT. Если ему не удаётся достичь заданной целевой скорости, алгоритм рассчитывает коэффициент потери пакетов и компенсирует его увеличением скорости. Это работает, только если вы знаете (и точно указываете) теоретическую максимальную скорость вашего текущего соединения. Он особенно эффективен для захвата полосы пропускания в перегруженных сетях с принципом «лучшие усилия», отсюда и его название.

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

Алгоритмы управления перегрузкой контролируют отправку данных. С точки зрения клиента, если пользователь не указал значение полосы пропускания для скачивания (но указал для загрузки), сервер Hysteria будет отправлять данные клиенту с использованием BBR, а клиент будет загружать данные на сервер с использованием Brutal, и наоборот. Клиент может указать оба значения, тогда оба направления будут использовать Brutal, или не указывать ни одного — тогда оба будут использовать BBR.

Особый случай, упомянутый выше, — когда на сервере включено ignoreClientBandwidth, в этом случае обе стороны всегда будут использовать BBR, независимо от значений полосы пропускания клиента.

Ограничение полосы пропускания сервера в настоящее время применяется только к Brutal. Оно не влияет на BBR.

Тест скорости

speedTest: false

speedTest включает встроенный сервер теста скорости. При включении клиенты могут тестировать скорость скачивания и загрузки с сервером. Подробнее см. документацию по тесту скорости.

UDP

disableUDP: false

disableUDP отключает перенаправление UDP, разрешая только TCP-соединения.

udpIdleTimeout: 60s

udpIdleTimeout указывает, сколько времени сервер будет держать открытым локальный UDP-порт для каждой UDP-сессии при отсутствии активности. Это концептуально похоже на таймаут UDP-сессии NAT.

Аутентификация

auth:
  type: password | userpass | http | command # (6)!
  password: your_password # (1)!
  userpass: # (2)!
    user1: pass1
    user2: pass2
    user3: pass3
  http:
    url: http://your.backend.com/auth # (3)!
    insecure: false # (4)!
  command: /etc/some_command # (5)!

1. Замените на надёжный пароль по вашему выбору.
2. Словарь пар имя-пароль.
3. URL бэкенд-сервера для обработки аутентификации.
4. Отключить проверку TLS для бэкенд-сервера (применяется только к HTTPS URL).
5. Путь к команде для обработки аутентификации.
6. Пожалуйста, прочитайте инструкции о «селекторе типа» в начале этой страницы.

HTTP-аутентификация

При использовании HTTP-аутентификации сервер отправляет POST-запрос на бэкенд-сервер со следующим JSON-телом при попытке подключения клиента:

{
  "addr": "123.123.123.123:44556", // (1)!
  "auth": "something_something", // (2)!
  "tx": 123456 // (3)!
}

1. IP-адрес и порт клиента.
2. Данные аутентификации клиента.
3. Скорость передачи (tx) (в байтах в секунду). Tx с точки зрения сервера; соответствует скорости приёма (скачивания) клиента.

Ваш эндпоинт должен ответить JSON-объектом со следующими полями:

{
  "ok": true, // (1)!
  "id": "john_doe" // (2)!
}

1. Разрешить ли данному клиенту подключение.
2. Уникальный идентификатор клиента. Используется в логах и API статистики трафика.

ПРИМЕЧАНИЕ: HTTP-код статуса должен быть 200, чтобы аутентификация считалась успешной.

Аутентификация командой

При использовании аутентификации командой сервер выполняет указанную команду со следующими аргументами при попытке подключения клиента:

/etc/some_command addr auth tx # (1)!

1. Определение каждого аргумента такое же, как в разделе HTTP-аутентификации выше.

Команда должна вывести уникальный идентификатор клиента в stdout и вернуть код завершения 0, если клиенту разрешено подключение, или вернуть ненулевой код завершения, если клиент отклонён.

Если команда не может быть выполнена, клиент будет отклонён.

Резолвер

Вы можете указать, какой резолвер (DNS-сервер) использовать для разрешения доменных имён в запросах клиентов.

resolver:
  type: udp | tcp | tls | https # (8)!
  tcp:
    addr: 8.8.8.8:53 # (1)!
    timeout: 4s # (2)!
  udp:
    addr: 8.8.4.4:53 # (3)!
    timeout: 4s
  tls:
    addr: 1.1.1.1:853 # (4)!
    timeout: 10s
    sni: cloudflare-dns.com # (5)!
    insecure: false # (6)!
  https:
    addr: 1.1.1.1:443 # (7)!
    timeout: 10s
    sni: cloudflare-dns.com
    insecure: false

1. Адрес TCP-резолвера.
2. Таймаут DNS-запросов.
3. Адрес UDP-резолвера.
4. Адрес TLS-резолвера.
5. SNI для TLS-резолвера.
6. Отключить проверку TLS для TLS-резолвера.
7. Адрес HTTPS-резолвера.
8. Пожалуйста, прочитайте инструкции о «селекторе типа» в начале этой страницы.

Если опущено, Hysteria будет использовать системный резолвер по умолчанию.

Анализ протоколов

Из-за таких факторов, как входящий трафик клиента (например, режим TUN) и конфигурация, Hysteria иногда не может получить доменное имя адреса назначения и получает только IP. Но IP, который получают клиент и сервер для одного домена, могут различаться, и доменные правила ACL не могут сопоставить IP-запросы. Включив анализ протоколов, сервер может использовать DPI для извлечения доменного имени из соединения (для поддерживаемых протоколов) и преобразования IP-запроса в доменный.

Поддерживаемые протоколы:

• HTTP — Host в заголовке
• TLS (HTTPS) — SNI
• QUIC (HTTP/3) — SNI

sniff:
  enable: true # (1)!
  timeout: 2s # (2)!
  rewriteDomain: false # (3)!
  tcpPorts: 80,443,8000-9000 # (4)!
  udpPorts: all # (5)!

1. Включить ли анализ протоколов.
2. Таймаут анализа. Если протокол/домен не может быть определён за это время, для установки соединения будет использован исходный адрес.
3. Перезаписывать ли запросы, которые уже содержат доменное имя. Если включено, запросы с целевым адресом в виде доменного имени всё равно будут анализироваться.
4. Список TCP-портов. Только TCP-запросы на эти порты будут анализироваться.
5. Список UDP-портов. Только UDP-запросы на эти порты будут анализироваться.

Примечание: Если список портов не указан, по умолчанию анализируются все порты. Формат списка портов аналогичен формату смены портов — поддерживаются множественные одиночные порты и диапазоны портов (включительно), разделённые запятыми.

ACL

ACL, часто используемый в сочетании с исходящими каналами, — это очень мощная функция сервера Hysteria, позволяющая настраивать обработку запросов клиентов. Например, вы можете использовать ACL для блокировки определённых адресов или для использования разных исходящих каналов для разных сайтов.

Подробности о синтаксисе, использовании и другую информацию см. в документации ACL.

Можно использовать либо file, либо inline, но не оба одновременно.

acl:
  file: some.txt # (1)!
  # geoip: geoip.dat (2)
  # geosite: geosite.dat (3)
  # geoUpdateInterval: 168h (4)

acl:
  inline: # (1)!
    - reject(suffix:v2ex.com)
    - reject(all, udp/443)
    - reject(geoip:cn)
    - reject(geosite:netflix)
  # geoip: geoip.dat (2)
  # geosite: geosite.dat (3)
  # geoUpdateInterval: 168h (4)

ПРИМЕЧАНИЕ: В настоящее время Hysteria использует формат «dat» на основе protobuf для данных geoip/geosite, исходящих из v2ray. Если вам не нужна настройка, можно опустить поля geoip или geosite и позволить Hysteria автоматически скачать последнюю версию (с https://github.com/Loyalsoldier/v2ray-rules-dat) в рабочую директорию. Файлы будут загружены и использованы, только если в вашем ACL есть хотя бы одно правило, использующее эту функцию.

ПРИМЕЧАНИЕ: В настоящее время Hysteria загружает базы данных GeoIP/GeoSite только один раз при запуске. Вам потребуется использовать внешние инструменты для периодического перезапуска сервера Hysteria для регулярного обновления баз данных через geoUpdateInterval. Это может измениться в будущих версиях.

Исходящие каналы

Исходящие каналы используются для определения «выхода», через который должно маршрутизироваться соединение. Например, при использовании с ACL вы можете маршрутизировать весь трафик, кроме Netflix, напрямую через локальный интерфейс, а трафик Netflix — через SOCKS5-прокси.

В настоящее время Hysteria поддерживает следующие типы исходящих каналов:

• direct: Прямое соединение через локальный интерфейс.
• socks5: SOCKS5-прокси.
• http: HTTP/HTTPS-прокси.

ПРИМЕЧАНИЕ: HTTP/HTTPS-прокси не поддерживают UDP на уровне протокола. Отправка UDP-трафика в HTTP-исходящие каналы приведёт к отклонению.

Если вы не используете ACL, все соединения всегда будут маршрутизироваться через первый («по умолчанию») исходящий канал в списке, а все остальные будут проигнорированы.

outbounds:
  - name: my_outbound_1 # (1)!
    type: direct # (7)!
  - name: my_outbound_2
    type: socks5
    socks5:
      addr: shady.proxy.ru:1080 # (2)!
      username: hackerman # (3)!
      password: Elliot Alderson # (4)!
  - name: my_outbound_3
    type: http
    http:
      url: http://username:[email protected]:8081 # (5)!
      insecure: false # (6)!

1. Имя исходящего канала. Используется в правилах ACL.
2. Адрес SOCKS5-прокси.
3. Необязательно. Имя пользователя для SOCKS5-прокси, если требуется аутентификация.
4. Необязательно. Пароль для SOCKS5-прокси, если требуется аутентификация.
5. URL HTTP/HTTPS-прокси. (Может быть http:// или https://)
6. Необязательно. Отключить проверку TLS. Применяется только к HTTPS-прокси.
7. Пожалуйста, прочитайте инструкции о «селекторе типа» в начале этой страницы.

Настройка исходящего канала direct

Исходящий канал direct имеет несколько дополнительных опций для настройки поведения:

ПРИМЕЧАНИЕ: Опции bindIPv4, bindIPv6 и bindDevice взаимоисключающие. Можно указать bindIPv4 и/или bindIPv6 без bindDevice, или использовать bindDevice без bindIPv4 и bindIPv6.

outbounds:
  - name: hoho
    type: direct
    direct:
      mode: auto # (1)!
      bindIPv4: 2.4.6.8 # (2)!
      bindIPv6: 0:0:0:0:0:ffff:0204:0608 # (3)!
      bindDevice: eth233 # (4)!
      fastOpen: false # (5)!

1. См. пояснение ниже.
2. Локальный IPv4-адрес для привязки.
3. Локальный IPv6-адрес для привязки.
4. Локальный сетевой интерфейс для привязки.
5. Включить TCP Fast Open.

Доступные значения mode:

• auto: По умолчанию. Двухстековый режим «happy eyeballs». Клиент попытается подключиться к назначению, используя как IPv4, так и IPv6 адреса (если доступны), и использует первый успешный.
• 64: Всегда использовать IPv6, если доступен, иначе IPv4.
• 46: Всегда использовать IPv4, если доступен, иначе IPv6.
• 6: Всегда использовать IPv6. Ошибка, если IPv6 недоступен.
• 4: Всегда использовать IPv4. Ошибка, если IPv4 недоступен.

API статистики трафика (HTTP)

API статистики трафика позволяет запрашивать статистику трафика сервера и отключать клиентов через HTTP API. Подробнее об эндпоинтах и использовании см. документацию API статистики трафика.

trafficStats:
  listen: :9999 # (1)!
  secret: some_secret # (2)!

1. Адрес прослушивания.
2. Секретный ключ для аутентификации. Прикрепите его к заголовку Authorization в ваших HTTP-запросах.

ПРИМЕЧАНИЕ: Если вы не установите секрет, любой, кто имеет доступ к адресу прослушивания API, сможет видеть статистику трафика и отключать пользователей. Настоятельно рекомендуем установить секрет или хотя бы использовать ACL для блокировки доступа пользователей к API.

Маскировка

Одним из ключевых элементов устойчивости Hysteria к цензуре является возможность маскироваться под стандартный HTTP/3-трафик. Это означает, что пакеты не только выглядят как HTTP/3 для промежуточных устройств, но и сервер отвечает на HTTP-запросы как обычный веб-сервер. Однако это означает, что ваш сервер должен действительно отдавать некоторый контент, чтобы выглядеть правдоподобно для потенциальных цензоров.

Если цензура вас не беспокоит, вы можете полностью опустить секцию masquerade. В этом случае Hysteria будет всегда возвращать «404 Not Found» на все HTTP-запросы.

В настоящее время Hysteria предоставляет следующие режимы маскировки:

• file: Действует как статический файловый сервер, отдавая файлы из директории.
• proxy: Действует как обратный прокси, отдавая контент с другого сайта.
• string: Действует как сервер, который всегда возвращает указанную пользователем строку.

masquerade:
  type: file | proxy | string # (7)!
  file:
    dir: /www/masq # (1)!
  proxy:
    url: https://some.site.net # (2)!
    rewriteHost: true # (3)!
    insecure: false # (4)!
  string:
    content: hello stupid world # (5)!
    headers: # (6)!
      content-type: text/plain
      custom-stuff: ice cream so good
    statusCode: 200 # (7)!

1. Директория для отдачи файлов.
2. URL проксируемого сайта.
3. Перезаписывать ли заголовок Host для соответствия проксируемому сайту. Это необходимо, если целевой веб-сервер использует Host для определения обслуживаемого сайта.
4. Отключить проверку TLS для проксируемого сайта.
5. Возвращаемая строка.
6. Необязательно. Возвращаемые заголовки.
7. Необязательно. Возвращаемый код статуса. По умолчанию 200.
8. Пожалуйста, прочитайте инструкции о «селекторе типа» в начале этой страницы.

Вы можете протестировать конфигурацию маскировки, запустив Chrome со специальным флагом (для принудительного использования QUIC):

chrome --origin-to-force-quic-on=your.site.com:443 # (1)!

1. Замените на доменное имя вашего сервера.

ПРИМЕЧАНИЕ: Перед запуском Chrome с флагом убедитесь, что вы полностью закрыли его, чтобы ни один процесс Chrome не работал в фоне. Иначе флаг не вступит в силу.

Затем перейдите на https://your.site.com, чтобы убедиться, что всё работает как ожидается.

Маскировка HTTP/HTTPS

Сайты, поддерживающие HTTP/3, обычно предлагают его как опцию обновления, также предоставляя HTTP/HTTPS на основе TCP на портах 80/443. Если вы хотите имитировать это поведение, можете использовать опции listenHTTP и listenHTTPS для включения маскировки HTTP/HTTPS. В этом случае не нужно запускать Chrome со специальным флагом, упомянутым выше; вы можете протестировать, просто зайдя на сайт как обычно.

masquerade:
  # ... (другие ваши опции)
  listenHTTP: :80 # (1)!
  listenHTTPS: :443 # (2)!
  forceHTTPS: true # (3)!

1. Адрес прослушивания HTTP (TCP).
2. Адрес прослушивания HTTPS (TCP).
3. Принудительно использовать HTTPS. Если включено, все HTTP-запросы будут перенаправлены на HTTPS.

Примечание: Нет доказательств того, что какие-либо государственные или коммерческие фаерволы используют «отсутствие TCP HTTP/HTTPS» как средство обнаружения серверов Hysteria. Эта функция предоставляется только для пользователей, которые хотят «подстраховаться». И если так, нет причин слушать на портах, отличных от стандартных 80/443 (хотя Hysteria это позволяет).