Files
HY2XS_flamy/docs/testing
founder b9d3c03f8d fix(admin): считать достижимым только тот адрес Traffic Stats API, который админка действительно опрашивает
Проверка принимала любой ip.IsLoopback(), то есть считала рабочим и 127.0.0.5.
Это неверно: слушатель на конкретном адресе принимает соединения только на него,
а слой proxy обращается строго к http://127.0.0.1:<port>.

  bind 127.0.0.5:38712  ->  dial 127.0.0.1:38712  ->  connection refused
  bind 0.0.0.0:38713    ->  dial 127.0.0.1:38713  ->  connected

Такой адрес выглядел локальным, ломал контур доступа целиком (лимит устройств
fail-closed => не подключается никто) и не вызывал у админки ни одного
возражения. Принимаются ровно 127.0.0.1, 0.0.0.0 и пустой хост.

IPv6-wildcard не принимается сознательно: соединение он принял бы, но HY2XS
объявлен IPv4-only, а зависеть в ответе «достучусь» от net.ipv6.bindv6only
нельзя.

На странице конфигурации мягкое состояние nonCanonicalLoopback убрано: прочий
loopback — это ошибка, а не предупреждение. Осталось три состояния: канон
профиля, wildcard, недостижим.

Свойство закреплено тестом с настоящими сокетами, а гейт приёмки запрещает
возврат IsLoopback() и требует негативного случая 127.0.0.5 в тестах.
2026-09-03 03:53:46 +05:00
..

Проверки и приёмка HY2XS

Набор проверок разложен по слоям, на которых они выполняются. Раньше он был одним файлом на 117 КБ и 57 разделов; ориентироваться в нём приходилось поиском по строке.

Нумерация 11-* сохранена: это стабильный идентификатор документа, под которым на него ссылаются CHANGELOG и релизные гейты.

Документ Слой Что закрывает
11-1-how-to-run.md команды запуска всех наборов
11-2-builder-layer.md builder резолвер Hysteria, контракт версий, юнит-тесты оркестратора и админки, гейты сборки
11-3-target-and-runtime.md target установка на чистый хост, состояние сервисов, конфиг, share URI
11-4-fault-injection.md target D0 на живом сервере, D1a-D1h — отказы и откат, D2 — устаревший DNS
11-5-negative-and-matrix.md target негативные сценарии, production-матрица, критерии приёмки

Отчёты о фактических прогонах

Проверки описывают, ЧТО должно выполняться. Результаты конкретных прогонов на конкретных сборках лежат отдельно — см. docs/acceptance/.

Разделение намеренное: документ проверок переживает релизы, а отчёт о прогоне относится к одному артефакту и одному хосту и после релиза не редактируется.