Недавно я переносил часть своего сайта на отдельный поддомен. После того как новый поддомен был настроен, я всё проверил — казалось, что всё работает. Однако спустя некоторое время я столкнулся со странным поведением на своём компьютере. При переходе на новый поддомен браузер сразу перенаправлял меня на основной сайт. На соседнем компьютере такой проблемы не было.
Сначала я решил, что успел закэшировать постоянный редирект во время настройки. Но оказалось, что причина совсем в другом. Я заметил, что первый запрос выполняется по HTTP/3, и именно он возвращает редирект. Выяснилось, что я настроил сайт, но забыл включить его обслуживание по HTTP/3. В результате пользователи, подключавшиеся по этому протоколу, попадали на виртуальный хост по умолчанию, где уже было настроено перенаправление на основной сайт.
Я поискал инструменты, которые могли бы быстро проверить подобную ситуацию, но ничего подходящего не нашёл. Поэтому решил написать собственную утилиту.
Начнём с постановки задачи. У нас есть веб-сервер, который должен быть доступен в интернете по нескольким протоколам разного уровня.
Первая проблема — два протокола IP: IPv4 и IPv6
Меня очень расстраивает, насколько медленно интернет переходит на IPv6. Этот протокол решает множество проблем и позволяет сделать сеть проще, быстрее и дешевле в эксплуатации. Однако многие провайдеры продолжают всеми силами продлевать жизнь IPv4. Я ещё понимаю, почему IPv4-адреса стоят дорого — это ограниченный ресурс. Но не понимаю, зачем продолжать вкладываться в инфраструктуру, которая существует лишь для поддержки устаревшего протокола. Вместо этого можно постепенно развивать оборудование, рассчитанное на IPv6, и со временем полностью отказаться от IPv4.
Так или иначе, мой сайт должен быть доступен как пользователям IPv6, так и тем, кто всё ещё работает через IPv4. Поэтому утилита должна уметь проверять оба варианта подключения.
Вторая проблема — HTTP часто перенаправляет на HTTPS
Пользователь вводит в адресной строке браузера адрес сайта — например, tavda.org. Некоторые браузеры до сих пор сначала пытаются установить соединение по HTTP. Это не запрещено, особенно для сайтов, где не требуется авторизация. Однако незашифрованное соединение позволяет тем, кто может перехватывать трафик, видеть содержимое страниц и даже подменять его, например вставляя собственную рекламу. Поэтому лучшей практикой является перенаправление пользователей на HTTPS, где весь обмен данными защищён TLS. Кроме того, HTTPS позволяет убедиться, что пользователь действительно подключился к нужному сайту.
Третья проблема — производительность
Долгое время основным протоколом в интернете был HTTP/1.1. При загрузке большого количества файлов браузеру приходилось открывать множество соединений, а при использовании HTTPS для каждого из них требовалось выполнять TLS-рукопожатие. Всё это увеличивало задержки и объём служебного трафика.
HTTP/2 решил эту проблему, позволив передавать несколько запросов одновременно по одному соединению. Благодаря этому уменьшается количество соединений и снижаются накладные расходы.
Но и это ещё не всё. HTTP и HTTPS традиционно работают поверх TCP. В стабильных сетях это практически не создаёт проблем. Однако в мобильных сетях потеря пакетов происходит значительно чаще. TCP самостоятельно восстанавливает потерянные данные, но браузер практически не может влиять на этот процесс.
Именно поэтому появился протокол QUIC, который работает поверх UDP. Он реализует собственный механизм доставки данных и позволяет независимо передавать несколько потоков. Потеря пакетов в одном потоке больше не блокирует передачу данных в остальных. HTTP/3 — это HTTP, работающий поверх QUIC.
Четвёртая проблема — а куда мне, собственно, подключаться?
Теперь перед браузером возникает вопрос: к какому серверу нужно подключаться? В упрощённом виде алгоритм выглядит так:
спроси DNS куда тебе;
IP адрес знаешь, теперь попробуем подключиться по HTTP, раз пользователь не указал протокол;
по HTTP сказали, что нужно перейти на HTTPS версию сайта;
HTTPS версия сайта сказала, что есть возможность использовать QUIC;
круто, теперь все запросы делаем через QUIC.
Вам не кажется, что схема слишком сложная? На каждый этап уходит довольно много времени, особенно если у вас не очень быстрое соединение.
Как будем решать наш ворох проблем?
Да, этот процесс можно немного сократить, например сразу подключаясь по HTTPS. Но современный DNS позволяет пойти ещё дальше. Для этого существует запись типа HTTPS. Она сообщает браузеру, что сайт поддерживает HTTPS, какие версии протокола доступны (например HTTP/2 или HTTP/3) и к каким адресам лучше подключаться.
Если такой информации недостаточно, браузер всё равно дополнительно запросит записи A и AAAA. Главное преимущество в том, что все эти DNS-запросы могут выполняться параллельно, после чего браузер сразу выбирает наиболее подходящий способ подключения.
Для чего моя утилита
Как вы понимаете, существует несколько способов подключения к одному и тому же сайту. Какой именно выберет конкретный браузер, заранее неизвестно, поэтому мне хотелось проверить все возможные варианты.
Если упростить, получается шесть основных сценариев: IPv4 и IPv6, каждый из которых может использовать HTTP, HTTPS или HTTP/3. Я попробовал несколько онлайн-сервисов, но у всех оказался один общий недостаток — они практически не учитывают различия между IPv4 и IPv6. Поэтому я решил написать собственную утилиту, которая проверяет именно те сценарии, которые важны для меня.
Возможно, кто-то скажет, что зачем тебе маяться, просто используй только IPv4 и максимум только HTTP/2. Да, вариант, конечно, рабочий. Но я хочу, чтобы мой сайт использовал все возможные современные технологии. Эта утилита позволяет быстро оценить на сколько всё правильно настроено и на что нужно обратить внимание.
Возможности:
🌐 DNS HTTPS RR (RFC 9460)
Валидация HTTPS-записей DNS (ServiceMode / AliasMode)
Проверка параметров alpn (h2, h3)
Кросс-проверка ipv4hint/ipv6hint с A/AAAA записями
🚀 HTTP/2 и HTTP/3
Фактические сетевые запросы по TCP (HTTP/2) и UDP/QUIC (HTTP/3)
Проверка реальной поддержки протоколов, а не только декларации
Тестирование доступности по IPv4 и IPv6 при их поддержке сайтом
🔄 Согласованность DNS и сервера
Проверка Alt-Svc заголовков vs HTTPS DNS записи
Выявление рассинхронизации между конфигурациями
📊 Согласованность ответов
Содержимое: сравнение контента страниц по разным протоколам (IPv4/IPv6, HTTP/HTTPS, HTTP/2/HTTP/3)
Статусы: проверка что все HTTP-ответы возвращают одинаковый статус, и все HTTPS-ответы возвращают одинаковый статус
Ложечка дёгтя
Я не настолько хорошо знаю Go, чтобы написать такую программу самостоятельно. В основном я программирую на PHP и TypeScript. Поэтому мне стало интересно попробовать реализовать эту идею с помощью ИИ. Несколько часов ушло только на то, чтобы правильно сформулировать задачу, но в итоге получилось собрать утилиту, которая вполне успешно решает мои задачи.
А зачем всё это?
Эта заметка появилась потому, что я так и не нашёл простой утилиты, которая могла бы быстро проверить всё, о чём рассказал выше. Даже ИИ поначалу не смог предложить готовое решение. В итоге я просто использовал его как помощника и реализовал инструмент, который был нужен именно мне.
Надеюсь, эта утилита окажется полезной и кому-то ещё. Возможно, кто-то предложит улучшения, оптимизирует код или даже полностью перепишет его. Я не считаю себя специалистом по Go, но беглый осмотр кода показался мне понятным.
Если вам интересно, исходный код проекта доступен на GitHub. Там же вы можете скачать уже собранную утилиту из раздела релизов под свою платформу.
Update 10.07.2026 статья немного переработана, учтены замечания читателей, исправлены некоторые ошибки и немного переработан текст.
Update 10.07.2026 для удобства, теперь на Github формируются релизы и можно просто скачать исполняемый файл под вашу операционную систему.
