Траблшутинг веб-сервера: как найти и устранить ошибки

06 Sep 2026, 12:49:42

Веб-сервер отвечает за обработку HTTP/HTTPS-запросов и передачу содержимого сайта пользователям. Если сайт перестал открываться, работает медленно, возвращает ошибки 4xx/5xx или периодически становится недоступным, необходимо определить причину сбоя.
Траблшутинг веб-сервера — это последовательная диагностика, которая позволяет определить проблемный компонент и устранить неисправность без лишних изменений конфигурации.

Какие проблемы встречаются чаще всего

Наиболее распространённые проблемы:

сайт полностью недоступен;
ошибки 403, 404, 500, 502 или 504;
медленная работа сайта;
веб-сервер не запускается;
не работает HTTPS или SSL-сертификат;
высокая загрузка CPU или оперативной памяти;
заканчивается место на диске;
PHP-FPM или другой backend перестаёт отвечать;
большое количество запросов создаёт нагрузку на сервер.

Главное правило диагностики — сначала определить причину проблемы и только после этого изменять конфигурацию или перезапускать сервисы.

1. Проверка доступности сервера

Сначала необходимо убедиться, что сервер доступен из сети:
ping SERVER_IPПри этом отсутствие ответа на ping не всегда означает недоступность сервера — ICMP может блокироваться firewall.
Поэтому дополнительно стоит проверить TCP-порты:

nc -zv SERVER_IP 80

nc -zv SERVER_IP 443

или:
nmap -p 80,443 SERVER_IPЕсли порты недоступны, необходимо проверить firewall, сетевые правила и состояние веб-сервера.

2. Проверка состояния веб-сервера

Следующий шаг — проверить, запущен ли Nginx или Apache.
Для Nginx:
systemctl status nginxДля Apache:
systemctl status apache2На AlmaLinux и RHEL сервис обычно называется httpd:
systemctl status httpdЕсли сервис остановлен или завершился с ошибкой, необходимо посмотреть системный журнал:
journalctl -u nginx -n 100В первую очередь обращайте внимание на сообщения failed, bind, permission denied, connection refused и другие ошибки.

3. Проверка конфигурации

Ошибки в конфигурации могут привести к тому, что веб-сервер не сможет запуститься или применить изменения.
Для Nginx:
nginx -tДля Apache:
apachectl configtestЕсли проверка завершилась успешно, можно применить изменения:
systemctl reload nginxПроверять конфигурацию перед перезапуском особенно важно после ручного редактирования файлов.

4. Анализ логов

Логи веб-сервера позволяют определить, что именно происходит во время сбоя.
Основные файлы Nginx:

/var/log/nginx/access.log

/var/log/nginx/error.log

Для Apache:

/var/log/apache2/access.log

/var/log/apache2/error.log

На AlmaLinux/RHEL:

/var/log/httpd/access_log

/var/log/httpd/error_log

Последние ошибки Nginx можно посмотреть так:
tail -n 100 /var/log/nginx/error.logДля наблюдения в реальном времени:
tail -f /var/log/nginx/error.logПри диагностике желательно смотреть логи непосредственно в момент возникновения проблемы. Это позволяет связать конкретную ошибку с недоступностью или замедлением сайта.

5. Проверка HTTP-ответа через curl

Команда curl позволяет проверить сайт напрямую и получить HTTP-статус:
curl -I https://example.comОсновные коды:

Код	Значение
200	Успешный запрос
301/302	Редирект
403	Доступ запрещён
404	Страница не найдена
500	Внутренняя ошибка сервера
502	Ошибка связи с backend
503	Сервис временно недоступен
504	Тайм-аут backend

Для более подробной диагностики используется:
curl -v https://example.comОна показывает процесс подключения, TLS-соединение и HTTP-запрос, что помогает определить, на каком этапе возникает ошибка.

6. Проверка DNS

Если сайт не открывается, необходимо проверить, куда указывает домен:
dig example.com AДля IPv6:
dig example.com AAAAТакже можно использовать:
nslookup example.comЕсли домен указывает на старый или неправильный IP-адрес, пользователи будут обращаться не к тому серверу.
При использовании Cloudflare или другого CDN DNS может возвращать IP-адреса CDN. В таком случае необходимо отдельно проверять соединение клиент → CDN и CDN → сервер.

7. Проверка SSL-сертификата

Проблемы с HTTPS могут быть связаны с истёкшим или неправильно установленным сертификатом.
Проверить сертификат можно с помощью OpenSSL:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Команда покажет владельца сертификата, издателя и срок его действия.
Также полезно выполнить:
curl -Iv https://example.comЕсли сайт работает через Cloudflare или другой CDN, сертификат, который видит посетитель, может отличаться от сертификата, установленного непосредственно на сервере.

8. Проверка портов

Чтобы узнать, слушает ли веб-сервер необходимые порты:
ss -lntp | grep -E ':80|:443'В результате должны присутствовать 80 и/или 443. Если порт 443 отсутствует, веб-сервер непосредственно на этом сервере не принимает HTTPS-соединения. В таком случае нужно проверить конфигурацию Nginx/Apache и наличие SSL-виртуального хоста.

9. Проверка PHP-FPM и backend

Для сайтов на PHP важно проверять не только Nginx или Apache. Веб-сервер может работать нормально, а PHP-FPM — не отвечать.
Например:
systemctl status php8.3-fpmНазвание сервиса зависит от установленной версии PHP.
Проблемы с PHP-FPM часто приводят к ошибкам: 502 Bad Gateway, 504 Gateway Timeout.
В error.log могут появляться сообщения:
connect() failed
upstream timed out
connection refused
В таком случае необходимо проверить состояние PHP-FPM, его socket или TCP-порт, количество процессов и доступную оперативную память.

10. Проверка ресурсов сервера

Если сайт работает медленно, необходимо проверить загрузку системы:

uptime

free -h

top

df -h

df -i

Эти команды позволяют проверить нагрузку CPU, использование RAM, свободное место на диске и inode.
При высокой нагрузке важно определить конкретный процесс, который потребляет ресурсы. Это может быть Apache, Nginx, PHP-FPM, MariaDB или само приложение.

11. Проверка firewall

Если веб-сервер работает, но подключиться к нему невозможно, необходимо проверить firewall.
Для UFW:
ufw statusДля firewalld:
firewall-cmd --list-allТакже правила могут находиться в iptables или nftables.
Убедитесь, что разрешены входящие TCP-соединения на порты: 80 и 443.
Если используется внешний firewall или сетевой фильтр провайдера, необходимо проверить правила и на этом уровне.

12. Проверка виртуального хоста

Иногда веб-сервер работает, но открывается неправильный сайт или появляется 404. Причиной может быть неверная конфигурация виртуального хоста.
Необходимо проверить:

доменное имя;
server_name в Nginx;
ServerName и ServerAlias в Apache;
корневую директорию сайта;
наличие файлов;
права доступа;
настройки PHP;
SSL-конфигурацию.

Например:

server {

    server_name example.com;

    root /var/www/example.com;

}

Если root указывает на неправильную директорию, веб-сервер может работать нормально, но сайт будет возвращать 404.

13. Что проверять при 502 и 504

Ошибки 502 Bad Gateway и 504 Gateway Timeout часто возникают из-за проблем с backend.
Последовательно проверьте:

работает ли PHP-FPM;
доступен ли его socket или TCP-порт;
хватает ли оперативной памяти;
нет ли слишком большого количества PHP-процессов;
не выполняются ли скрипты слишком долго;
доступна ли база данных.

Для поиска соответствующих сообщений в логе:
grep -iE "error|timeout|refused|upstream" /var/log/nginx/error.log

14. Проверка OOM Killer

Если процессы неожиданно завершаются, причиной может быть нехватка оперативной памяти.
Проверить сообщения ядра:
dmesg -T | grep -i "oom\|out of memory\|killed process"Также:
journalctl -k | grep -i oomЕсли обнаружен OOM Killer, необходимо определить процесс, потреблявший слишком много памяти, и проверить настройки PHP-FPM, Apache, базы данных и других сервисов.

15. Проверка большого количества соединений

Большое количество одновременных соединений может перегрузить веб-сервер.
Проверить общую статистику:
ss -sКоличество соединений к HTTPS:
ss -ant | grep ':443' | wc -lЧтобы определить IP-адреса с наибольшим количеством запросов:
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | headЭто помогает обнаружить чрезмерную активность отдельных IP-адресов или ботов.

Практический алгоритм диагностики

При недоступности сайта удобно проверять систему последовательно:
DNS → IP → Firewall → порты 80/443 → веб-сервер → Virtual Host → PHP-FPM/backend → база данных → приложение
Такой подход позволяет быстро определить уровень, на котором возникает проблема, и не менять конфигурацию вслепую.

Основные команды

dig example.com

ss -lntp

systemctl status nginx

nginx -t

journalctl -u nginx -n 100

tail -f /var/log/nginx/error.log

curl -I https://example.com

curl -v https://example.com

free -h

df -h

top

dmesg -T | grep -i oom

Заключение

Траблшутинг веб-сервера следует начинать со сбора информации, а не с бездумного перезапуска сервисов или изменения конфигурации.
Проверка DNS, портов, состояния веб-сервера, логов, SSL, PHP-FPM и системных ресурсов позволяет последовательно локализовать неисправность.
Сначала определите, на каком уровне возникает проблема, а затем изменяйте только тот компонент, который является её причиной. Такой подход снижает риск дополнительных ошибок и ускоряет восстановление работы сайта.

Категории

Социальные сети