Когда вы разворачиваете веб-ресурс, настраиваете реверс-прокси, вам постоянно нужно проверять, как сервер отдает контент во внешний мир. Открывать для каждой микро-проверки тяжелый браузер, чистить кэш вручную или ковыряться в панели разработчика (F12) — неэффективно.
В консольной среде главным инструментом для тестирования сетевых запросов является утилита curl (Client URL). Она позволяет имитировать поведение любого клиента, проверять SSL-сертификаты, прокидывать кастомные заголовки и детально препарировать ответы сервера. Сегодня разберем базовые приемы работы с curl, которые пригодятся в повседневной практике для быстрой диагностики сайтов напрямую из терминала.
Инспекция заголовков: Флаг -I
Если запустить команду просто так, она вывалит в терминал весь сырой HTML-код целевой страницы. Но при диагностике инфраструктуры сам контент нас интересует меньше всего. Нам нужны метаданные — HTTP-заголовки ответа. Чтобы забрать только их, используется заглавный флаг -I (выполняется облегченный запрос HEAD вместо GET):
curl -I https://phoenix901.ru
В ответ сервер выплеснет структурированный текст. Смотрим на контрольные точки:
- HTTP Status Code: Первая строка должна отдавать
HTTP/2 200илиHTTP/1.1 200 OK. Если там висит 403, 404 или 502 Bad Gateway — прокси-сервер не может достучаться до бэкенда. - Server: Показывает, какое именно ПО встретило запрос (например, Caddy, Apache или nginx).
- Content-Type: Для обычных страниц тут должно быть
text/html; charset=UTF-8. - Заголовки кэширования: Ищем параметры вроде
X-Cacheили маркеры кэша страниц, чтобы убедиться, что настроенный кэш в оперативной памяти реально отрабатывает, а не гоняет запросы на диски.
Замер скорости отклика: Измеряем TTFB
Один из ключевых параметров производительности веб-сервера — это TTFB (Time to First Byte), время до получения первого байта ответа. Это чистая метрика того, как быстро сервер обработал запрос в памяти и начал отдавать данные. С помощью curl и флага -w (write-out) можно вытащить точные тайминги сетевых стадий в секундах:
curl -o /dev/null -s -w "DNS: %{time_namelookup}s | Connect: %{time_connect}s | TLS: %{time_appconnect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" https://phoenix901.ru
Разберем, что делает эта длинная конструкция:
-o /dev/null— отправляет тело ответа (HTML-код) в системную «черную дыру», чтобы оно не засоряло терминал.-s(silent) — отключает вывод дефолтного статус-бара загрузки curl.time_namelookup— время, затраченное на DNS-разрешение имени хоста в IP-адрес.time_starttransfer— тот самый **TTFB**. Время с момента отправки запроса до начала отдачи первых байт сервером. Если у вас настроен правильный RAM-кэш и Unix-сокеты, эта цифра будет стремиться к минимальным значениям (в районе 0.009s–0.020s).
Ультимативная таблица: Полезные флаги curl для сисадмина
| Флаг и пример синтаксиса | Что делает в системе | Инженерное применение |
|---|---|---|
curl -L https://site.ru |
Follow Redirects | Принудительно следует по цепочке редиректов (301/302). Без этого флага curl просто покажет заголовок перемещения и остановится. |
curl -k https://site.ru |
Insecure Mode | Игнорирует ошибки SSL-сертификата. Полезно, если вы только что подняли локальный сервис с самоподписанным сертификатом и нужно проверить его работоспособность. |
curl -v https://site.ru |
Verbose Mode | Максимально подробный вывод. Показывает весь процесс сетевого рукопожатия (Handshake), детали TLS-шифрования и заголовки в обе стороны (запрос и ответ). |
curl -H "Host: test.ru" https://127.0.0.1 |
Custom Header | Подменяет или добавляет кастомный HTTP-заголовок к запросу. Идеально для тестирования новых виртуальных хостов (Virtual Hosts) локально на сервере до того, как домен проделегирован в DNS. |
curl -u user:pass https://site.ru |
Basic Auth | Передает данные для авторизации, если папка на сервере закрыта базовой аутентификацией (HTTP Basic Authentication). |
Проверка SSL-сертификата
Если вам нужно быстро узнать, до какого числа валиден SSL-сертификат Let’s Encrypt на сайте, не раскапывая лог-файлы certbot, можно использовать связку curl в режиме подробного вывода с перенаправлением потока ошибок:
curl -vI https://phoenix901.ru 2>&1 | grep -i -E "expire|start date"
Система выдернет из TLS-соглашения точные даты выпуска и окончания действия сертификата. Это помогает мгновенно проверить, сработал ли автоматический выпуск ключей в системе.
Заключение
Утилита curl — это гибкий сетевой щуп. Умение пользоваться флагами фильтрации заголовков и вывода таймингов позволяет за секунды локализовать проблему: лежит ли сайт из-за медленного DNS, уперся ли бэкап в дисковый ввод-вывод (высокий TTFB) или прокси-сервер просто отдает ошибку конфигурации сокетов.

привет, игорь! огромное спасибо за очередную реально полезную и интересную статью! 🙂 в процессе прочтения вспомнился мне один достаточно старенький вопрос, которым я неоднократно задавался, но ответа, увы, не нашёл. вопрос вот какой: почему в инструкциях по подключению сторонних репозиториев или по установке пакетов с официальных сайтов curl используют для скачивания ключа подписи репозитория, файла с данными репозитория или самого пакета? почему curl, а не wget, что было бы, как на мой взгляд, и более логично, и более удобно? возможно в этом есть нюанс, о котором я не знаю. если можно, разъясни пожалуйста! 🙂
Привет, Тимофей!
Разница между ними сводится к логике работы со стримами и философии UNIX.
curl изначально спроектирован так, чтобы лить данные в стандартный вывод (stdout) по умолчанию. Команда curl [https://repo.url/key.gpg](https://repo.url/key.gpg) сразу выплевывает содержимое в терминал, что позволяет строить прямые конвейеры (pipes) и передавать ключ обработчику вообще без создания временных файлов на диске:
curl -fsSL https://repo.url/key.gpg | gpg --dearmor -o /etc/apt/keyrings/key.gpgwget же заточен под тупое скачивание файла на файловую систему. Чтобы заставить его выдать данные в поток, приходится вешать костыль в виде флага wget -O -. Меньше изящества, длиннее конструкция.
Кроме того, в чистых контейнерах (Docker, LXC) или минимальных инсталляциях дистрибутивов curl часто уже сидит в системе как базовая зависимость. wget там, как правило, вырезан ради экономии мегабайт. Авторы инструкций пишут под curl, чтобы команда завелась у всех без предварительного apt install.
Ну и по назначению: wget — это автономный рекурсивный краулер для выкачивания сайтов или тяжелых бинарников в фоне, а curl — гибкий сетевой интерфейс для точечной работы с API, заголовками и TLS. Для быстрой проброски одного ключа в пайплайн он тупо эффективнее.
игорь, огромное спасибо за разъяснение! вот уж действительно- век живи, век учись! 🙂