wget против curl: чем отличаются и что когда брать

Две утилиты делают, казалось бы, одно и то же — забирают что-то по HTTP. На деле они решают разные задачи, по-разному ведут себя при ошибках и в скриптах дают противоположные коды выхода на одном и том же 404. Разбираем различия по пунктам и собираем таблицу соответствия ключей.

curl — универсальный клиент для передачи данных по двум десяткам протоколов, который по умолчанию печатает ответ в терминал; wget — загрузчик файлов, который по умолчанию сохраняет их на диск и умеет рекурсивно скачивать сайты целиком. Отсюда и разделение: curl — для запросов и диагностики, wget — для загрузки и зеркалирования.

Главные различия в одной таблице

Про версии: curl выходит примерно раз в восемь недель, последняя на момент написания — 8.22.0 от сентября 2026. У классического wget последний релиз 1.25.0 датирован ноябрём 2024 — ветка живёт в режиме поддержки. Преемник называется wget2 (версия 2.2.1), он умеет HTTP/2 и многопоточную загрузку, но drop-in-заменой не является: часть опций 1.x в нём не реализована.

Одни и те же задачи двумя командами

Одна деталь про тихий режим curl: голый -s глушит и прогресс, и сообщения об ошибках. В скриптах почти всегда нужен -sS — прогресса нет, ошибки видны.

Коды выхода: главная ловушка в скриптах

Это различие ломает больше всего скриптов. На ответе 404 или 500 wget вернёт код 8, а curl — код 0, потому что с его точки зрения передача прошла успешно: ответ получен. Чтобы curl реагировал на HTTP-ошибки, нужен ключ -f.

Замер таймингов: то, что умеет только curl

У curl есть ключ -w, который печатает переменные по итогам запроса. Все времена кумулятивные, от старта передачи, в секундах.

Разности между соседними значениями и есть ответ на вопрос «где тормозит»:

curl -sS -L -o /dev/null \
  -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} | code=%{http_code} ip=%{remote_ip} bytes=%{size_download}\n' \
  https://example.com

# Весь набор одним JSON-объектом
curl -sS -o /dev/null -w '%{json}' https://example.com | jq

Зеркалирование сайта: то, что умеет только wget

curl принципиально не умеет рекурсию — разработчики считают это задачей другого инструмента. У wget для этого есть целый набор ключей.

# Полное зеркало сайта для локального просмотра
wget --mirror --convert-links --adjust-extension \
     --page-requisites --no-parent https://example.com/

# Скачать только PDF из раздела, не уходя выше по дереву
wget -r -np -nd -A pdf https://example.com/docs/

# Вежливое зеркалирование: пауза между запросами
wget -r -l 3 --wait=1 --random-wait --limit-rate=500k https://example.com/

Почему --spider не заменяет нормальную проверку

Ключ --spider у wget проверяет, существует ли ресурс, не скачивая его. Звучит идеально для мониторинга, но у него четыре ограничения, о которых стоит знать до того, как построить на нём проверку.

Для проверки доступности честнее команда curl, которая печатает и код, и время:

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com

Что стоит по умолчанию в вашей системе

Скрипт, написанный на ноутбуке с macOS, может не завестись на сервере — и наоборот. Картина по системам такая.

Почему нельзя отключать проверку сертификата

Ключи -k у curl и --no-check-certificate у wget отключают не только проверку цепочки до доверенного центра, но и сверку имени хоста с сертификатом. Соединение остаётся зашифрованным, но подтверждения, что вы говорите с нужным сервером, больше нет — любой на пути может подставить свой сертификат и читать всё, включая пароли и токены.

Правильные решения вместо отключения: curl --cacert /path/ca.pem для своего центра сертификации, wget --ca-certificate= для того же у wget, обновление системного хранилища через update-ca-certificates. И отдельная частая причина: сбитые системные часы — при них валидный сертификат выглядит просроченным.

Что выбрать: короткий ответ

Почему curl в cron — это не мониторинг

Схема «curl в кроне плюс отправка письма при ненулевом коде» выглядит бесплатной, пока не столкнёшься с тремя вещами. Проверка идёт из одной точки — если у вас проблема с маршрутом до конкретного региона, вы её не увидите. Сервер, с которого запускается cron, сам иногда падает, и тогда молчание означает не «всё хорошо», а «проверка не запускалась». И одиночный неудачный ответ неотличим от настоящего инцидента — нужен кворум по нескольким точкам.

Эти три вещи и составляют разницу между разовой командой и сервисом: проверка доступности делает тот же GET-запрос, но из разных локаций и сверяет код с ожидаемым, а HEAD-проверка — то же самое экономнее, без скачивания тела страницы.