curl: как проверить сайт из командной строки — 10 приёмов с примерами

curl — это возможность посмотреть на сайт глазами робота: без кэша браузера, расширений и магии. Именно так его видят поисковики, интеграции и системы мониторинга. Разбираем десять приёмов, которыми curl закрывает 90% диагностики сайта, — от «какой код отвечает» до «сколько миллисекунд съедает каждый этап загрузки».

curl — консольная утилита для выполнения сетевых запросов, в первую очередь HTTP. Она предустановлена в macOS, Linux и Windows 10/11 — скорее всего, у вас она уже есть: откройте терминал и наберите curl --version. Для владельца сайта curl ценен одним свойством: он показывает ровно то, что отдаёт сервер, без слоёв браузера — кэша, куки, расширений, авторедиректов. Когда «у меня открывается, а у клиента нет», curl — первый беспристрастный свидетель.

Базовая диагностика

1. Какой код отвечает страница. Флаг -I запрашивает только заголовки (HEAD-запросом — чем он отличается от GET, мы разбирали в статье о методах HTTP):

$ curl -I https://prufen.ru
HTTP/2 200
content-type: text/html; charset=utf-8
...

2. Пройти по редиректам. По умолчанию curl редиректам не следует — и это полезно: видно каждый шаг. Флаг -L идёт до конца, а связка с -sIL печатает всю цепочку заголовков — мгновенная проверка, что HTTP→HTTPS настроен одним 301-м, а не каскадом из трёх прыжков:

$ curl -sIL http://prufen.ru | grep -E "HTTP|location"
HTTP/1.1 301 Moved Permanently
location: https://prufen.ru/
HTTP/2 200

3. Замерить, где теряется время. Самый недооценённый приём: флаг -w раскладывает запрос на этапы:

$ curl -s -o /dev/null -w "DNS: %{time_namelookup}s
TCP: %{time_connect}s
TLS: %{time_appconnect}s
TTFB: %{time_starttransfer}s
Всего: %{time_total}s
" https://prufen.ru

Одна команда — и видно, кто виноват в медленном ответе: DNS, установка соединения, TLS-рукопожатие или сам сервер, думающий над ответом. Что означает каждая из этих фаз и какие значения считать нормой — в статье про TTFB.

4. Проверить сертификат. Просроченный или кривой сертификат curl не пропустит — и подробно объяснит, что не так:

$ curl -vI https://prufen.ru 2>&1 | grep -E "expire|issuer|subject"
* expire date: ...
* issuer: C=US; O=Let's Encrypt; ...

Приёмы уровня «про»

5. Проверить сайт на новом сервере до переключения DNS. Лучший трюк curl для переездов — флаг --resolve подменяет DNS-ответ локально, не трогая настоящие записи:

# сайт уже развёрнут на новом IP 203.0.113.7, DNS ещё старый:
$ curl -I --resolve prufen.ru:443:203.0.113.7 https://prufen.ru

Вы обращаетесь к новому серверу по настоящему домену — с настоящим сертификатом и виртуальным хостом. Убедились, что всё отвечает — только тогда меняете DNS. Это превращает переезд из прыжка веры в проверяемую операцию.

6. Представиться другим клиентом. Флаг -A меняет User-Agent — так проверяют, не отдаёт ли сайт разным клиентам разное (и не банит ли защита роботов чересчур рьяно — тема нашего разбора про WAF):

$ curl -I -A "Mozilla/5.0 (compatible; YandexBot/3.0)" https://prufen.ru

7. Проверить API. POST-запрос с JSON — три флага: -X POST -H "Content-Type: application/json" -d '{...}'. Для быстрой проверки «жив ли эндпоинт и что отвечает» этого достаточно; систематический контроль API — отдельная дисциплина, разобранная в статье о мониторинге API.

8. Игнорировать битый сертификат осознанно. Флаг -k отключает проверку TLS — полезно ровно в одной ситуации: сертификат сломан, а понять, жив ли сам сайт за ним, нужно сейчас. В скрипты и автоматизацию -k не тащить.

9. Уложить проверку в одну строку для скрипта. Конструкция для cron-скриптов и healthcheck'ов:

$ curl -s -o /dev/null -w "%{http_code}" --max-time 10 https://prufen.ru
200

10. Посмотреть весь диалог. Флаг -v печатает переговоры целиком: резолвинг, соединение, TLS, заголовки в обе стороны. Когда непонятно вообще ничего — начинайте с него.

Почему curl видит не то, что браузер

Регулярная ситуация: в браузере страница открывается, curl получает ошибку — или наоборот. Это не глюк, а список различий, каждое из которых может оказаться решающим. Кэш и куки: браузер может показывать сохранённую копию или страницу для «узнанного» пользователя; curl всегда приходит чистым и анонимным. User-Agent: по умолчанию curl честно представляется curl'ом — а часть защит и CDN отвечает «неизвестным клиентам» отказом или капчей; проверяется подменой через -A (приём №6). JavaScript: curl не исполняет скрипты — если страница строится на клиенте, он увидит пустой каркас; это нормально и даже полезно: ровно так сайт видят простые роботы. Сжатие: добавьте --compressed, чтобы получать ответ как браузер — со сжатием.

Отсюда практический вывод: расхождение curl и браузера — это не помеха, а диагноз. «Браузер открывает, curl банится» — у вас агрессивный анти-бот фильтр, и роботы поисковиков могут страдать так же. «Curl отдаёт 200, браузер показывает старьё» — проблема в кэше. «Curl видит пустую страницу» — контент рендерится JavaScript'ом, и стоит проверить, как сайт индексируется.

curl и мониторинг: одна механика

Приём №9 — это, по сути, самодельная проверка доступности: запросить страницу, сверить код, уложиться в таймаут. Профессиональный мониторинг делает ровно то же самое, только по расписанию, из многих точек сразу и с уведомлениями — GET-проверка доступности в Пруфене устроена именно так, вплоть до контроля ожидаемого кода ответа. А замер фаз из приёма №3 — это ручная версия того, что делает проверка с расписанием: только мониторинг ещё и хранит историю, на которой видно, когда TTFB начал деградировать. Разовая диагностика — curl; дежурство по расписанию — проверки с интервалом.