curl (28): Operation timed out — причины и проверка

Ошибка «curl: (28) Operation timed out» или «Connection timed out» означает, что операция не завершилась за отведённое время. Curl либо не дождался установления соединения, либо не получил ответа, либо загрузка шла слишком медленно. По тексту после двоеточия можно понять, на каком этапе: например, указано число полученных байтов или сказано, что ожидание соединения истекло.

Важно, что таймаут — это отсутствие ответа, а не отказ. Сервер не ответил ничего, что отличает код 28 от кода 7.

Сообщение может иметь формы «Connection timed out after N milliseconds» либо «Operation timed out after N milliseconds with 0 bytes received». Первое говорит о соединении, второе — об ожидании ответа после установки соединения, и различие помогает сузить поиск.

Самые частые: сервер не отвечает или перегружен, пакеты отбрасываются межсетевым экраном, а не отклоняются, маршрут до сервера нарушен. Далее — слишком медленное соединение и большая нагрузка на канал, а также значение таймаута, заданное слишком жёстко.

Кроме того, причиной бывают проблемы с IPv6, когда curl сначала пытается подключиться по IPv6 и долго ждёт, прежде чем перейти на IPv4, недоступный прокси и медленный DNS.

Бывает, что таймаут вызван не сетью, а самим приложением на сервере: запрос принят, но обработка идёт слишком долго, например из-за тяжёлого запроса к базе. Вы увидите, что соединение установилось быстро, а ответа нет: этап ожидания первого байта занимает основное время.

Запустите curl с подробным выводом и параметром вывода времени этапов. Вы увидите, сколько заняло разрешение имени, установление соединения, рукопожатие TLS и получение первого байта. Если долго разрешается имя, проблема в DNS. Если долго устанавливается соединение, виноваты маршрут или фильтрация. Если долго идёт рукопожатие или ожидание ответа, сервер перегружен или медленно обрабатывает запрос.

Эта простая разбивка избавляет от гаданий и сужает поиск до одного этапа.

Если у вас есть возможность, повторите запрос с другой машины и из другой сети, а также на другой адрес того же сервиса. Совпадение результатов указывает на сервис, различие — на путь и локальную сеть.

Проверьте связь с сервером с помощью ping и трассировки маршрута: где обрываются или растут задержки. Проверьте доступность порта другой утилитой. Попробуйте обратиться из другой сети, чтобы исключить проблему на вашей стороне. Если запрос идёт через прокси, проверьте и его.

Если проблема в IPv6, принудительное использование IPv4 сократит ожидание. Также проверьте, не идёт ли загрузка больших файлов по слабому каналу, для которого нужен более длинный таймаут.

Учтите, что медленный DNS тоже приводит к таймауту: если разрешение имени занимает десять секунд, а общий таймаут задан в пять, запрос закончится ошибкой ещё до попытки соединения. Поэтому изучайте этапы, а не только итоговое сообщение.

У curl есть отдельные параметры для максимального времени соединения и общего времени операции. Если вы скачиваете большие файлы, общий таймаут не стоит задавать жёстко. Для скриптов полезны повторные попытки с паузой, и они отлично защищают от кратких сбоев.

Не увеличивайте таймауты бездумно: если сервер действительно недоступен, длинный таймаут лишь замедлит скрипт. Сначала выясните, где именно возникает задержка.

Полезно также задавать таймауты явно и раздельно в скриптах, а не полагаться на значения по умолчанию, которые различаются в версиях и в средах запуска.

Если проверка из разных сетей показывает одно и то же, сервер, скорее всего, перегружен, недоступен или отбрасывает ваши соединения. Проверьте журнал и нагрузку, если сервер ваш. Убедитесь, что не сработали лимиты соединений и что межсетевой экран не отбрасывает пакеты.

Если сервер чужой, остаётся попробовать позже и сообщить владельцу время и адрес, откуда шёл запрос.

Запишите результаты замеров, когда всё работает: нормальное время соединения и ответа. Такое сравнение помогает быстро замечать деградацию, пока она не превратилась в таймауты.