Как разобраться с ошибкой ERR_CONNECTION_TIMED_OUT

Оглавление

Краткое описание ошибки

Браузер сообщает ERR_CONNECTION_TIMED_OUT, если не получает ответ от сервера в пределах ожидания (около 30 секунд). Причины могут быть как «пользовательской», так и «серверной». В этой статье рассматриваются основные факторы в контексте разных веб‑серверов и языков, а также особенности популярных дистрибутивов.

Общий чек‑лист диагностики

1. Проверка DNS‑записей (dig, nslookup).
2. Открытость портов (ss, netstat).
3. Состояние фаервола (ufw, firewalld, iptables).
4. Логи веб‑сервера (error.log, access.log).
5. Оценка ресурсов (top, free, htop).
6. Проверка статуса службы (systemctl status).
7. Сетевой тест из внешней сети (curl -v, telnet).

Проблемы и решения в конкретных веб‑серверах

Apache 2.x

Диагностика: убедитесь, что Listen присутствует в /etc/apache2/ports.conf и virtual‑host. Логи находятся в /var/log/apache2/. В CentOS используйте /etc/httpd/conf.d/.

Типичные причины таймаутов:

• Ограничения MaxRequestWorkers (в Debian в mpm_prefork.conf, в CentOS – httpd.conf).
• Неверно настроенный KeepAliveTimeout – если он выставлен > 30 сек, клиент может ждать дольше и получит таймаут.
• PHP‑модуль (mod_php, php‑fpm) перестал отвечать (проверить /var/log/php-fpm.log).

Nginx

Диагностика: проверить listen директивы в /etc/nginx/conf.d/ (Debian/Ubuntu) или /etc/nginx/nginx.conf (CentOS). Логи: /var/log/nginx/access.log и error.log.

Таймауты:

• Параметр send_timeout и keepalive_timeout – слишком маленькие значения приводят к разрыву соединения.
• Фронт‑энд кэш, upstream с таймаутах – если бекенд (PHP‑FPM, uWSGI, Node.js) не отвечает, Nginx завершает работу.
• Недостаточное worker_connections в nginx.conf.

PHP (mod_php, php‑fpm)

Ошибка возникает, если скрипт выполняется более 30 секунд (по умолчанию max_execution_time = 30) и не выводит ответ. Увеличьте время в php.ini и проверьте memory_limit. В CentOS конфиг находится в /etc/php.ini, в Arch - в /etc/php/conf.d.

Python (Flask, Django, Gunicorn)

При работе через Gunicorn настройте timeout (по умолчанию 30 сек). Flask без WSGI иногда «зависает» при длительной обработке. В systemd unit-файле укажите TimeoutStartSec=0, чтобы предотвратить падение сервисов.

Node.js (Express, Koa)

Node не имеет внутреннего таймаута, но обратные прокси (Nginx, Apache) могут его вызывать. Убедитесь, что client_body_timeout в Nginx совпадает с желаемыми лимитами. Также проверьте pm2 опцию max_memory_restart.

Прошивки «под операционную систему»

Debian & Ubuntu

Оба используют ufw по умолчанию и systemd для демонов. Файлы логов находятся в /var/log, а конфиги Apache – /etc/apache2, Nginx – /etc/nginx. В Ubuntu часто применяется php-fpm в режиме pm = dynamic, что может вызывать таймауты из‑за перенаправления к новым процессам.

CentOS 7/8

Фаервол – firewalld, который автоматически блокирует порты. Настройте правила через firewall-cmd --add-service=http --permanent. В CentOS 7 Apache лежит в /etc/httpd, Nginx в /etc/nginx, а PHP в /etc/php.ini. Технология SELinux добавляет дополнительный уровень защиты – проверьте audit.log и включите setenforce 0.

Arch Linux

Дистрибутив «сразу готов» – нет ufw, используется iptables вручную. При установке через pacman -S apache Apache использует /etc/httpd/conf.d (похожий на CentOS). Файловый менеджер pacman устанавливает systemd юниты, поэтому ошибки «service not started» проявляются в логах journalctl -u httpd.

Пошаговый план для конкретных сценариев

1. Стартовое состояние: проверьте, что веб‑сервер запущен (systemctl status httpd / apache2 / nginx).
2. Порт 80/443: ss -tulpn | grep :80. Если вывод пуст — сервер не слушает.
3. Firewall:
   • Debian/Ubuntu: sudo ufw status verbose
   • CentOS: sudo firewall-cmd --list-all
   • Arch: iptables -L -n -v
4. Логи:
   • Apache: /var/log/apache2/error.log
   • Nginx: /var/log/nginx/error.log
   • PHP‑FPM: /var/log/php7.4-fpm.log
   • Gunicorn: /var/log/gunicorn.log (если настроено)
   • Node: /var/log/${app}.log (если используется pm2)
5. Проверка откуда происходит запрос:

   curl -I http://example.com

   В ответе по полю Host стоит проверять, что правильный виртуальный хост выбран.
6. Мониторинг нагрузки:

   htop
   free -h
   			

   Если swap на 100 %, то все соединения замедляются.
7. Тест «подключения к порту»:

   telnet example.com 80

   Успешное соединение подтверждает, что порт открыт. На CentOS откройте правила: firewall-cmd --add-port=80/tcp --permanent; firewall-cmd --reload.
8. Отладка кода:
   • Для PHP: включите display_errors = On в тестовом файле.
   • Для Python: запустите python3 -m http.server 8000 и проверьте, таймаут сохраняется.
   • Для Node: запустите node app.js в режиме node --inspect и смотрите на колл‑стэк.

Рекомендации по профилактике

• Ограничьте max_requests_per_child в Apache, keepalive_timeout в Nginx, timeout в Gunicorn.
• Включите fail2ban с правилом apache-auth – это поможет отгонять боты, которые «чашат» сервер.
• Регулярно проверяйте системные логи /var/log/messages, journalctl -e -u nginx.
• Держите сервер ОС обновлённым (apt update && apt upgrade в Debian/Ubuntu; yum update в CentOS; pacman -Syu в Arch).
• Используйте systemd‑cgroup для ограничения ресурсов (CPU, RAM) отдельные сервисы.

Выводы

Ошибка ERR_CONNECTION_TIMED_OUT является сигнальной точкой: она говорит о том, что ответ не пришёл в течение времени ожидания. Причины могут лежать в любой части цепочки: от DNS‑записей до кода бекенда. На Ubuntu и Debian фаервол ufw и php‑fpm обычно «прячутся» в простые ограничения. CentOS скрывается за firewalld и SELinux, Arch – без изначального фаервола, но с более «подвиги» в системном менеджере. В любом случае, универсальный чек‑лист, перечисленный выше, быстро позволяет локализовать и устранить причину. И помните: хорошая практика – вести логи, мониторить ресурсы и регулярно обновлять систему.