Когда вы сталкиваетесь с сообщением connect timeout 118, это обычно сигнализирует о том, что сервер-клиент не смог установить соединение с удаленным хостом в течение отведенного времени. В контексте веб-серверов, таких как Nginx или Apache, код 118 часто ассоциируется с истечением времени ожидания соединения, хотя в строгой спецификации HTTP стандартных кодов с номером 118 не существует. Чаще всего под этим подразумевают специфические коды ошибок прокси-серверов или таймауты на уровне TCP/IP стека операционной системы.
Суть проблемы кроется в сетевом взаимодействии: ваш сервер пытается «постучаться» к бэкенду или внешнему API, но ответ не приходит вовремя. Это может быть вызвано перегрузкой удаленного ресурса, проблемами маршрутизации в сети или неправильно настроенными параметрами таймаута в конфигурации вашего программного обеспечения. Понимание механизма возникновения этой ошибки — первый шаг к её устранению.
Важно не путать таймаут соединения с таймаутом чтения. В первом случае соединение даже не успевает установиться (рукопожатие TCP не завершено), во втором — соединение есть, но данные не передаются. Именно ситуация, когда connect timeout достигает своего лимита, приводит к разрыву запроса и появлению ошибки, которую пользователи видят как недоступность сайта или сервиса.
Техническая природа таймаута соединения
Протокол TCP, лежащий в основе большинства интернет-соединений, предполагает установление надежного канала связи перед передачей данных. Этот процесс называется «рукопожатием» (three-way handshake). Если сервер-отправитель отправляет SYN-пакет, но не получает SYN-ACK в ответ в течение определенного времени, он повторяет попытку. Когда суммарное время ожидания превышает заданный лимит, инициируется событие connect timeout.
В операционных системах Linux, на которых базируется большинство веб-серверов, параметры повторных попыток и таймаутов регулируются ядром. Однако приложения уровня Nginx или PHP часто имеют собственные, более приоритетные настройки. Код 118 в некоторых реализациях (например, в старых версиях библиотек или специфичных прокси) может указывать именно на истечение времени ожидания при попытке соединиться с upstream-сервером.
⚠️ Внимание: Частые ошибки таймаута могут свидетельствовать не только о сетевых проблемах, но и о正在进行 DDoS-атаке, когда сервер заваливают ложными запросами, исчерпывая пулы соединений.
Длительность ожидания по умолчанию часто составляет 60 секунд, но в высоконагруженных системах или при работе с медленными внешними API этот порог может быть недостаточным. И наоборот, слишком большие значения таймаутов могут привести к тому, что потоки сервера будут простаивать в ожидании, блокируя обработку других запросов.
- Ежедневно
- Раз в неделю
- Редко
- Никогда не видел
Основные причины возникновения ошибки 118
Существует множество факторов, способных спровоцировать сбой соединения. Чаще всего проблема кроется в сетевой инфраструктуре или конфигурации программного обеспечения. Анализ логов помогает сузить круг поисков, но понимание типовых причин ускоряет диагностику.
Одной из главных причин является недоступность целевого хоста. Если сервер, к которому вы обращаетесь, выключен, перезагружается или его сетевой интерфейс не работает, соединение установить невозможно. Также стоит учитывать работу межсетевых экранов (firewalls): они могут silently drop пакеты, создавая иллюзию зависания сети, что и приводит к таймауту.
- 🔥 Перегрузка сервера-получателя: процессор или память занята обработкой других задач, и он не успевает ответить на SYN-запрос.
- 🌐 Проблемы DNS: если доменное имя не resolves в IP-адрес достаточно быстро, это может быть интерпретировано как таймаут соединения.
- 🛡️ Блокировка фаерволом: правила iptables или cloud firewall запрещают входящие соединения с вашего IP-адреса.
- 📉 Проблемы провайдера: обрывы канала или высокая латентность на маршруте следования пакетов.
Отдельного внимания заслуживает ситуация с PHP-FPM. Если пул процессов переполнен и все воркеры заняты, новые запросы будут ждать в очереди. Если время ожидания в очереди превысит значение, заданное в конфиге веб-сервера (например, proxy_connect_timeout), пользователь получит ошибку соединения.
Диагностика проблемы с помощью системных утилит
Для точного определения места сбоя необходимо использовать инструменты командной строки. Они позволяют отделить проблемы сети от проблем приложения. Первым делом следует проверить доступность хоста и портов.
Утилита curl является незаменимым помощником. С её помощью можно увидеть детальную информацию о процессе соединения, включая время установления связи. Используйте ключ -v для verbose режима или --connect-timeout для эмуляции поведения вашего приложения.
curl -v --connect-timeout 10 http://example.com/apiТакже полезен инструмент telnet или nc (netcat). Они позволяют проверить, открыт ли конкретный порт на удаленном сервере. Если соединение устанавливается мгновенно, проблема, скорее всего, в уровне приложения, а не сети.
| Инструмент | Команда | Что показывает |
|---|---|---|
| curl | curl -I -m 10 URL |
Время подключения и получения первого байта |
| ping | ping -c 4 IP |
Доступность хоста и потерю пакетов |
| traceroute | traceroute -n IP |
Маршрут следования пакетов и узлы задержки |
| nc | nc -zv IP port |
Статус открытости конкретного TCP порта |
Если ping проходит успешно, но соединение по порту 80 или 443 не устанавливается, значит, проблема локализована на уровне конкретного сервиса или блокируется фаерволом. Это важный диагностический признак.
☑️ Диагностика сети
Настройка Nginx: устранение таймаутов
Веб-сервер Nginx часто выступает в роли reverse proxy. Если бэкенд отвечает медленно, Nginx должен ждать. По умолчанию значения таймаутов могут быть слишком короткими для тяжелых операций. Необходимо настроить директивы в блоке location или http.
Ключевым параметром является proxy_connect_timeout. Он определяет, сколько секунд Nginx будет ждать установления соединения с проксируемым сервером. Если за это время соединение не установлено, Nginx вернет ошибку 502 или 504 клиенту. Значение по умолчанию часто составляет 60 секунд.
Также важно настроить proxy_read_timeout и proxy_send_timeout. Первый отвечает за время ожидания ответа от бэкенда, второй — за время передачи запроса. Для длинных запросов (например, загрузка больших файлов или сложные отчеты) эти значения нужно увеличивать.
location /api/ {
proxy_pass http://backend_server;
proxy_connect_timeout 120s;
proxy_read_timeout 300s;
proxy_send_timeout 120s;
}
⚠️ Внимание: Бездумное увеличение таймаутов до тысяч секунд может привести к исчерпанию ресурсов сервера (memory leak, exhaustion of worker connections), так как «висячие» соединения будут занимать память.
После внесения изменений в конфигурационный файл nginx.conf обязательно проверьте синтаксис командой nginx -t и выполните перезагрузку конфигурации nginx -s reload, чтобы изменения вступили в силу.
Оптимизация keepalive
Настройка keepalive_connections позволяет сохранять соединения открытыми, что снижает накладные расходы на установление нового TCP-соединения для каждого запроса. Добавьте: proxy_http_version 1.1; proxy_set_header Connection ""; upstream { keepalive 32; }
Оптимизация PHP-FPM и Apache
Если вашим бэкендом является PHP-FPM, то он также имеет свои лимиты времени выполнения скриптов. Директива max_execution_time в php.ini ограничивает время выполнения скрипта. Если скрипт выполняется дольше, он будет прерван, что может привести к разрыву соединения с точки зрения веб-сервера.
В пулах PHP-FPM существует параметр request_terminate_timeout. Он устанавливает жесткий лимит на время выполнения запроса. Если этот таймаут меньше, чем таймаут в Nginx, то PHP завершит процесс, и Nginx получит ошибку соединения или разрыва.
- ⚙️ Увеличьте
max_execution_timeвphp.iniдо значения, превышающего таймаут веб-сервера. - ⚙️ Проверьте параметр
request_terminate_timeoutв конфигурации пулаwww.conf. - ⚙️ Убедитесь, что количество доступных процессов (pm.max_children) достаточно для обработки пиковых нагрузок.
Для Apache актуальны директивы Timeout и ProxyTimeout. Они работают аналогично настройкам Nginx. Если Apache выступает фронтендом перед приложением, эти значения должны быть согласованы с настройками самого приложения.
Частой ошибкой является рассинхронизация настроек. Например, Nginx ждет 300 секунд, а PHP настроен на завершение через 60 секунд. В таком случае пользователь будет видеть ошибку таймаута, хотя на стороне PHP скрипт просто silently умирает.
Синхронизация таймаутов на всех уровнях стека (Nginx -> PHP -> Database) — критически важный этап настройки стабильного сервера.
Сетевые проблемы и влияние инфраструктуры
Не всегда проблема кроется в конфигурации ПО. Физическая сеть, маршрутизаторы и провайдеры играют огромную роль. Если ваш сервер находится в одном дата-центре, а база данных — в другом, задержки могут быть существенными.
Используйте traceroute для выявления проблемных узлов. Если пакеты теряются на одном из промежуточных хопов, увеличение таймаутов на сервере не поможет — нужно решать проблему с сетевым провайдером или менять маршрутизацию.
Также стоит проверить нагрузку на сетевой интерфейс. Утилиты вроде iftop или nload покажут, не уперлись ли вы в пропускную способность канала. Переполненный сетевой буфер приводит к потере пакетов и, как следствие, к ретрансляциям и таймаутам.
В облачных инфраструктурах (AWS, Google Cloud, Azure) существуют ограничения на количество соединений и пропускную способность в зависимости от тарифа инстанса. Превышение этих лимитов может приводить к throttling (искусственному замедлению), который выглядит как таймаут.
Используйте утилиту mtr (My Traceroute) для постоянного мониторинга пути до сервера. Она объединяет функции ping и traceroute, показывая потерю пакетов в динамике.
Частые вопросы (FAQ)
Что означает ошибка 118 в браузере?
В браузерах код 118 не является стандартным HTTP кодом. Обычно это внутренний код ошибки конкретного браузера или плагина, означающий «Connection Timed Out». Это говорит о том, что браузер не смог установить соединение с сайтом в отведенное время.
Как увеличить таймаут в Nginx?
Необходимо добавить или изменить директивы proxy_connect_timeout, proxy_read_timeout и proxy_send_timeout в конфигурационном файле nginx.conf или в блоке server/location, а затем перезагрузить сервер.
Может ли антивирус вызывать connect timeout?
Да, антивирусное ПО или фаервол на клиенте или сервере может сканировать входящие/исходящие пакеты, задерживая их передачу. Если задержка превысит лимит ожидания, возникнет таймаут.
Почему таймаут возникает только периодически?
Периодичность часто указывает на пиковые нагрузки, когда заканчиваются свободные порты или процессы воркеров, либо на нестабильность сетевого канала (packet loss), которая усиливается в определенное время суток.
Как отличить таймаут сети от таймаута приложения?
Сетевой таймаут (connect timeout) возникает до установления соединения (TCP handshake). Таймаут приложения (read timeout) возникает после соединения, когда сервер ждет данные. Логи TCP (tcpdump) помогут увидеть, было ли завершено рукопожатие.