Диагностика и устранение ошибок веб-сервера: 403, 404, 500 и проблемы виртуальных хостов

Шпаргалка для немедленного решения: алгоритм действий по ошибке

Столкнувшись с ошибкой веб-сервера, вы хотите действовать быстро и точно. Эта шпаргалка содержит три четких алгоритма для немедленной диагностики и устранения ошибок 403, 404 и 500. Выполняйте шаги последовательно, чтобы локализовать проблему.

Ошибка 403 Forbidden: проверка прав доступа и конфигурации

1. Проверьте права на файлы и каталоги. Убедитесь, что процесс веб-сервера (пользователь www-data для Apache или nginx для Nginx) имеет доступ к DocumentRoot и его содержимому.

   ls -la /var/www/your_site/
   chown -R www-data:www-data /var/www/your_site/
   chmod -R 755 /var/www/your_site/
   chmod -R 644 /var/www/your_site/*.php

2. Проанализируйте логи ошибок. Найдите записи, указывающие на отказ в доступе.

   tail -f /var/log/nginx/error.log | grep -i "403\|permission denied"
   tail -f /var/log/apache2/error.log | grep -i "client denied"

3. Проверьте конфигурацию виртуального хоста. Убедитесь в отсутствии директив deny all и правильности указания DocumentRoot. Для более глубокого анализа ошибок авторизации и настройки CORS в сложных стеках изучите наш практический гайд по ошибкам 401/403 в Nginx, Docker и Kubernetes.

Ошибка 404 Not Found: поиск файла и проверка маршрутов

1. Подтвердите физическое существование файла. Сравните путь из запроса с фактическим расположением файла в DocumentRoot.

   ls -la /var/www/your_site/path/to/requested/file.html

2. Изучите логи. Найдите записи о ненайденном файле.

   tail -f /var/log/nginx/error.log | grep -i "404\|not found"
   tail -f /var/log/apache2/error.log | grep -i "file does not exist"

3. Верифицируйте конфигурацию виртуального хоста. Убедитесь, что директива root (в Nginx) или DocumentRoot (в Apache) указывает на правильную корневую директорию.
4. Для динамических приложений проверьте маршрутизацию. Убедитесь, что бэкенд-приложение (например, на PHP или Python) корректно обрабатывает запрошенный URL.

Ошибка 500 Internal Server Error: диагностика конфигурации и бэкенда

1. Проверьте синтаксис конфигурации веб-сервера. Используйте встроенные инструменты валидации.

   nginx -t
   apachectl configtest

2. Анализируйте логи веб-сервера. Ищите ошибки синтаксиса, таймауты или сбои подключения к бэкенду.

   tail -50 /var/log/nginx/error.log
   tail -50 /var/log/apache2/error.log

3. Проверьте работоспособность бэкенда. Убедитесь, что службы вроде PHP-FPM запущены и отвечают.

   systemctl status php-fpm
   journalctl -u php-fpm --since "5 minutes ago"

Проверка базовой конфигурации виртуального хоста

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

DNS и сеть: убеждаемся, что запросы попадают на сервер

Проблема может находиться вне веб-сервера.

1. Проверьте резолвинг доменного имени. Убедитесь, что домен указывает на правильный IP-адрес вашего сервера.

   dig @8.8.8.8 yourdomain.com
   dig yourdomain.com A +short
   nslookup yourdomain.com

2. Убедитесь, что веб-сервер слушает нужный порт. Проверьте, запущен ли процесс и слушает ли он порты 80 и/или 443.

   ss -tlnp | grep :80
   ss -tlnp | grep :443
   # Альтернатива:
   netstat -tlnp | grep :80

Синтаксис и параметры конфигурационного файла

Типичные ошибки в конфигурации виртуального хоста:

• Неправильный путь в DocumentRoot/root: Используйте абсолютные пути (/var/www/site), а не относительные.
• Опечатка в имени домена: Директива server_name (Nginx) или ServerName (Apache) должна точно соответствовать запрашиваемому домену.
• Конфликтующие директивы listen: Убедитесь, что два виртуальных хоста не пытаются слушать один порт с одним IP.
• Отсутствие или ошибка в директиве index: Укажите индексный файл, например, index.php index.html.

Всегда проверяйте синтаксис перед перезагрузкой: nginx -t или apachectl configtest.

Диагностика через логи ошибок: читаем сообщения сервера

Логи - главный источник информации для диагностики. Умение их читать экономит часы работы.

Логи Nginx: разбор типичных записей для 403, 404, 500

Примеры записей из /var/log/nginx/error.log и их расшифровка:

• Ошибка 403 (Права доступа):
  2026/05/04 10:15:30 [error] 12345#0: *678 open() "/var/www/site/index.php" failed (13: Permission denied)
  Решение: Проверьте права (chmod, chown) на файл /var/www/site/index.php.
• Ошибка 404 (Файл не найден):
  2026/05/04 10:16:00 [error] 12345#0: *679 open() "/var/www/site/missing-page.html" failed (2: No such file or directory)
  Решение: Убедитесь, что файл существует по указанному пути или проверьте конфигурацию корневой директории.
• Ошибка 500 (Проблема с бэкендом):
  2026/05/04 10:17:00 [error] 12345#0: *680 connect() failed (111: Connection refused) while connecting to upstream, client: ..., server: ..., request: "GET /api/ HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000"
  Решение: Проверьте статус и настройки службы бэкенда (например, PHP-FPM). Убедитесь, что она слушает на 127.0.0.1:9000.

Логи Apache: анализ сообщений error.log

Примеры записей из /var/log/apache2/error.log:

• Ошибка 403:
  [Tue May 04 10:18:00.123456 2026] [authz_core:error] [pid 23456] [client 192.168.1.100:54321] AH01630: client denied by server configuration: /var/www/site/admin/
  Решение: Проверьте директивы <Directory> и Require в конфигурации хоста или .htaccess.
• Ошибка 404:
  [Tue May 04 10:19:00.123456 2026] [core:error] [pid 23456] [client 192.168.1.100:54321] File does not exist: /var/www/site/wrong-path.jpg
  Решение: Очевидно указывает на отсутствующий файл. Проверьте путь.
• Ошибка 500 (Синтаксис PHP):
  [Tue May 04 10:20:00.123456 2026] [php7:error] [pid 23456] [client 192.168.1.100:54321] PHP Parse error: syntax error, unexpected '}' in /var/www/site/broken.php on line 15
  Решение: Исправьте синтаксическую ошибку в указанном файле PHP.

Для более глубокого анализа логов, поиска паттернов атак и настройки мониторинга изучите наше практическое руководство по анализу логов Nginx и Apache с готовыми командами grep и awk.

Решение проблем с правами доступа: от chmod до SELinux

Если стандартная проверка прав не помогает, проблема может быть глубже.

Стандартные права файлов и каталогов (chmod, chown)

Рекомендуемые настройки для безопасности и функциональности:

• Директории: Права 755 (rwxr-xr-x). Это позволяет владельцу всё делать, а другим - читать и заходить в директорию.
• Файлы (HTML, CSS, JS, изображения): Права 644 (rw-r--r--). Владелец может читать и писать, остальные - только читать.
• Исполняемые скрипты (PHP, Python): Права 755, но критически важна правильная настройка обработчика (например, PHP-FPM).
• Владелец: Файлы должен владеть пользователь, от имени которого работает веб-сервер. Для Apache в Debian/Ubuntu это www-data:www-data. Для Nginx в тех же системах - www-data:www-data или nginx:nginx.

Мандаты SELinux и AppArmor: диагностика и исправление

Когда права chmod верны, а доступ запрещён, виновником часто выступает SELinux (в RHEL/CentOS/Fedora) или AppArmor (в Debian/Ubuntu).

Диагностика SELinux:

# Проверьте, включен ли SELinux
getenforce
# Режим: Enforcing (включен), Permissive (ведет лог, но не блокирует), Disabled (отключен).

# Ищите записи об отказах в аудитных логах
tail -f /var/log/audit/audit.log | grep -i "avc.*denied"
# Или используйте утилиту для удобного просмотра
sealert -a /var/log/audit/audit.log | tail -100

# Узнайте текущий контекст файлов в DocumentRoot
ls -laZ /var/www/your_site/

Временное решение для тестирования: Переведите SELinux в режим Permissive. Не оставляйте сервер в этом режиме в production!

setenforce 0

Постоянное исправление (предпочтительный метод):

# 1. Установите правильный контекст для файлов веб-сервера
semanage fcontext -a -t httpd_sys_content_t "/var/www/your_site(/.*)?"
restorecon -Rv /var/www/your_site/

# 2. Если скриптам нужен доступ на запись в определенную папку (например, кэш)
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/your_site/cache(/.*)?"
restorecon -Rv /var/www/your_site/cache

# 3. Включите необходимые булевы флаги (например, для сетевого доступа PHP)
getsebool -a | grep httpd
setsebool -P httpd_can_network_connect 1

AppArmor: Проверьте статус профиля Apache или Nginx: aa-status. Ошибки логируются в /var/log/syslog или /var/log/kern.log. Для добавления правил отредактируйте профиль в /etc/apparmor.d/ и выполните apparmor_parser -r /etc/apparmor.d/profile.name.

Валидация конфигурации и безопасное применение изменений

Применяйте изменения конфигурации безопасно, чтобы избежать простоя.

1. Всегда проверяйте синтаксис перед перезагрузкой.

   nginx -t
   # Результат: "nginx: configuration file /etc/nginx/nginx.conf test is successful"
   apachectl configtest
   # Результат: "Syntax OK"

2. Используйте reload вместо restart, когда это возможно.
   • systemctl reload nginx или nginx -s reload - применяет новую конфигурацию, не разрывая установленные соединения. Это graceful перезагрузка.
   • systemctl restart nginx - полностью останавливает, а затем запускает службу, что приводит к кратковременному разрыву всех соединений.
   • Для Apache: systemctl reload apache2 или apachectl graceful.
3. Следуйте порядку: Внесли правки → выполнили configtest → применили изменения через reload.

Диагностика ошибок, связанных с бэкендом (PHP-FPM, FastCGI)

Ошибка 500 часто возникает из-за сбоя в обработчике бэкенда, а не в самом веб-сервере.

1. Проверьте статус службы бэкенда.

   systemctl status php-fpm
   # Ищите статус "active (running)". Если "failed", смотрите логи:
   journalctl -u php-fpm -n 50 --no-pager

2. Проверьте соответствие пользователей. Пользователь и группа, от имени которых работает пул PHP-FPM (опция user и group в www.conf), должны иметь права на чтение файлов скриптов. Частая ошибка - несоответствие с пользователем веб-сервера.
3. Диагностируйте проблемы с сокетом или портом. В конфигурации Nginx проверьте, что директива fastcgi_pass указывает на корректный адрес (например, unix:/run/php/php8.2-fpm.sock или 127.0.0.1:9000). Убедитесь, что сокет существует и права на него позволяют веб-серверу подключаться.

   ls -la /run/php/php8.2-fpm.sock
   ss -lnp | grep 9000

4. Анализируйте логи PHP-FPM. Они часто содержат конкретные ошибки скриптов.

   tail -f /var/log/php8.2-fpm.log

Типичная ошибка в логах Nginx: "Primary script unknown". Она указывает, что PHP-FPM не может найти скрипт по переданному пути. Решение - проверить и исправить директивы fastcgi_param SCRIPT_FILENAME в конфигурации Nginx.

Для полного понимания работы стека, от развертывания до тонкой настройки, рекомендуем наше пошаговое руководство по развертыванию веб-сервера на Linux (Nginx, PHP-FPM, MySQL).

Эти инструкции помогут вам системно подходить к диагностике и быстро восстанавливать работоспособность сайтов. Для автоматизации работы с API различных AI-моделей, что может быть полезно для создания скриптов мониторинга или анализа логов, вы можете использовать сервис AiTunnel. Он предоставляет единый интерфейс для доступа к более чем 200 моделям, включая GPT и Claude, с оплатой в рублях и без необходимости VPN.