Если HEAD и GET возвращают разные коды, для проверки открытия обычной страницы ориентируйтесь на GET и содержимое ответа. Успешный HEAD не доказывает, что HTML сформирован и передан, а ошибка HEAD сама по себе не означает, что посетители не могут открыть сайт.
Сначала сравните оба метода для одного URL в одинаковых условиях, затем найдите слой, который меняет результат. Не добавляйте ошибочный код в список допустимых только ради исчезновения тревоги.
Что проверяет HEAD, а что — GET
GET получает представление ресурса, например HTML страницы. HEAD запрашивает ответ без тела: по RFC 9110 его семантика соответствует GET, но сервер не должен отправлять содержимое. Некоторые заголовки, вычисляемые при генерации тела, могут отсутствовать; отсутствие Content-Length у HEAD само по себе не доказывает неисправность.
На практике приложение, прокси, CDN или защитный фильтр могут обрабатывать методы по-разному. Поэтому HEAD полезен для контроля ответа без передачи тела, но не заменяет проверку текста, размера или полной загрузки ресурса. И GET через curl не выполняет JavaScript, вход в кабинет или оплату.
1. Сравните один адрес без редиректов
Выберите небольшой публичный URL своего сайта, который безопасно читать. Зафиксируйте время и часовой пояс, точный путь и ожидаемый результат; не используйте ссылку с токеном или операцией изменения данных.
В терминале выполните пару запросов, заменив example.com своим адресом:
curl -sS --max-time 20 -I 'https://example.com/page/'
curl -sS --max-time 20 -D - -o /dev/null 'https://example.com/page/'Первый запрос — HEAD, второй — обычный GET, тело которого скачивается и отбрасывается. Предел 20 секунд выбран только для примера; выход curl по тайм-ауту нельзя записывать как полученный HTTP-код.
В документации curl параметр -I предназначен для HEAD. Не заменяйте его на -X HEAD: эта опция меняет слово метода, но не переводит клиент в правильный режим обработки ответа без тела.
Оба запроса идут без авторизации, из одной сети, с одинаковым клиентом и без автоматического перехода. Сравните:
- код ответа и Location;
- Content-Type, Cache-Control, Age и доступные признаки CDN-кэша;
- Allow при ответе 405;
- завершился ли GET без ошибки передачи.
Значения Set-Cookie и других чувствительных заголовков не копируйте в общий отчёт. Если ошибка зависит от входа в кабинет, отдельно сравните гостевой и авторизованный режимы в браузере, не передавая cookie в переписке.
2. Проверьте переходы и реальное тело
Если получен редирект, повторите пару с параметром -L. Так будут видны заголовки переходов; сверяйте не только последний код, но и каждый Location. Успешная страница входа после редиректа не подтверждает доступность исходного ресурса.
Для небольшого публичного HTML можно временно убрать -o /dev/null из GET и посмотреть содержимое локально. Ответ 200 с заглушкой, страницей проверки браузера или сообщением об ошибке приложения — иной результат, чем ожидаемая страница.
Если без авторизации оба метода успешны, а браузер показывает сбой, переходите к Network и Console: причина может быть в ресурсах страницы, сессии или клиентском коде. Повторение HEAD здесь не проверит сломанный сценарий.
3. Разберите сочетание результатов
HEAD возвращает 405, GET — ожидаемую страницу
Проверьте Allow и регистрацию HEAD для конкретного маршрута. Отказ метода отличается от общей недоступности: порядок поиска в приложении и серверных правилах описан в руководстве по 405 Method Not Allowed.
Если цель — открытие страницы посетителем, используйте подтверждённую GET-проверку. Если HEAD нужен балансировщику или другому клиенту, исправляйте поддержку метода отдельно; не разрешайте все методы на всём сайте.
HEAD возвращает 200, GET — 500 или ошибку загрузки
HEAD мог не пройти путь генерации и передачи тела. Сопоставьте запросы с журналами приложения, прокси и CDN: обработчик мог завершить HEAD раньше, чем GET обращается к данным или формирует HTML.
Такой HEAD нельзя считать доказательством исправности страницы. Проверяйте GET и ожидаемое содержимое; при обрыве передачи важен также результат завершения запроса, а не только уже полученный статус 200.
Один метод получает 403, 429 или другой редирект
Проверьте события WAF, ограничения частоты и правила по методу. Заголовки и оформление ответа дают подсказку, но источник отказа подтверждают журналы: прокси может заменить их.
Повторите пару после разумной паузы, затем из другой доступной сети. Если результат меняется между запросами одного метода, сначала исследуйте нестабильность узлов или кэша — отличия нельзя автоматически приписывать HEAD/GET.
4. Найдите слой и подтвердите исправление
Идите от внешнего ответа к CDN/WAF, reverse proxy и приложению, сопоставляя время, URL и метод. Отсутствие запроса в одном журнале не доказывает отказ до сервера: проверьте полноту логирования и другие узлы.
Для кэша сравните Age и признаки попадания в кэш, затем согласуйте точечную проверку с администратором. Не очищайте весь CDN ради эксперимента: это изменит нагрузку и затруднит сравнение.
После исправления повторите исходную пару и проверку тела GET на всех доступных администратору узлах.
Как выбрать правило мониторинга
Для публичной страницы разумная основа — безопасный GET, ожидаемый конечный адрес, код и устойчивый признак содержимого. Для специально выделенного endpoint критерии определяет его назначение; HEAD подходит, когда достаточно ответа без тела и поддержка метода проверена.
Не переносите успех с одного метода на другой и не расширяйте допустимые коды без объяснения. Одиночное измерение не подтверждает стабильность, а обычный HTTP-контроль не проверяет доставку формы или работу браузерного приложения.
Web-Puls можно использовать для регулярного контроля доступности выбранного публичного URL. Перед подключением уточните фактический метод и правила проверки; эта статья не предполагает, что сервис позволяет произвольно менять метод.
Если причина различий остаётся между приложением, прокси и защитой, отправьте заявку на диагностику. Укажите публичный URL, время, результаты HEAD/GET и недавние изменения без секретов: специалист оценит задачу и предложит формат работ.