Ошибки 504 Gateway Time-out, 500 Internal Server и 403 Forbidden: причины и как быстро исправить сайт

Содержание

• Анатомия серверных кодов: в чем разница между 504, 500 и 403
• Ошибка 504 Gateway Time-out: бэкенд не успевает ответить
• Ошибка 500 Internal Server Error: фатальный сбой PHP или .htaccess
• Ошибка 403 Forbidden: запрет прав доступа к файлам (chmod / chown)
• Где искать первопричину: главные логи Linux-сервера
• Чек-лист настроек php.ini для предотвращения таймаутов
• Автоматический контроль серверов через Novacom SRE

По данным поисковой аналитики Яндекс Вордстат, запросы «ошибка 504», «ошибка 500» и «ошибка 403» генерируют свыше 80 000 поисковых обращений в месяц. Из них более 13 500 запросов вводятся в точных формулировках администраторами и владельцами сайтов, которые прямо сейчас столкнулись с недоступностью веб-ресурса.

В отличие от ошибки 502 (когда бэкенд полностью недоступен), ошибки 504, 500 и 403 имеют более тонкую природу: скрипт запустился, но превысил временной лимит, фатально упал с синтаксической ошибкой или не имеет прав на чтение директории.

Разберем, как локализовать и устранить каждую из них.

Анатомия серверных кодов: в чем разница между 504, 500 и 403

Ошибка 504 Gateway Time-out: бэкенд не успевает ответить

Когда клиент открывает страницу (например, сложный фильтр каталога интернет-магазина), Nginx перенаправляет запрос в PHP-FPM и запускает таймер ожидания. По умолчанию в стандартных конфигурациях этот лимит составляет 30 или 60 секунд. Если за это время скрипт не вернул сформированный HTML — Nginx обрывает связь и выдает 504 Gateway Time-out.

Как исправить:

1. Увеличиваем тайм-ауты в блоке location Nginx

В файле /etc/nginx/sites-available/your-site.conf:

location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

    # Увеличиваем лимиты времени FastCGI до 300 секунд
    fastcgi_read_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_connect_timeout 60;
}

2. Увеличиваем лимит времени выполнения в php.ini

В файле /etc/php/8.2/fpm/php.ini:

max_execution_time = 300
max_input_time = 300

После изменения перезапустите службы: sudo systemctl restart php8.2-fpm && sudo systemctl reload nginx.

Ошибка 500 Internal Server Error: фатальный сбой PHP или .htaccess

Ошибка 500 — это защитный экран веб-сервера. Чтобы не показывать посторонним посетителям конфиденциальный стектрейс PHP с путями к файлам и логинами баз данных, сервер отдает стандартизированный код 500.

2 главные причины 500 ошибки:

1. Некорректная директива в файле .htaccess

Если сервер работает под управлением Apache или Nginx+Apache:

• Опечатка в RewriteRule или неподдерживаемая директива (например, попытка задать php_value на сервере с PHP-FPM).
• Тест: временно переименуйте файл: mv .htaccess .htaccess_bak. Если сайт открылся — проблема в правилах редиректа.

2. Нехватка оперативной памяти (Fatal error: Allowed memory size exhausted)

Когда PHP пытается обработать большую фотографию или тяжелый массив товаров, он упирается в лимит памяти.

• Откройте php.ini и увеличьте лимит:

memory_limit = 512M

Ошибка 403 Forbidden: запрет прав доступа к файлам (chmod / chown)

Ошибка 403 означает, что веб-сервер (пользователь www-data или bitrix) не имеет права прочитать запрашиваемый файл или зайти в директорию.

Как исправить права за 1 минуту:

# Переходим в корень сайта
cd /var/www/site.ru/public_html

# 1. Назначаем правильного владельца (для Ubuntu/Debian — www-data, для Bitrix — bitrix)
sudo chown -R www-data:www-data .

# 2. Устанавливаем безопасные стандартные права: 755 для папок, 644 для файлов
sudo find . -type d -exec chmod 755 {} \;
sudo find . -type f -exec chmod 644 {} \;

# 3. Убедитесь, что в корне есть файл index.php или index.html
ls -la index.*

Где искать первопричину: главные логи Linux-сервера

Не гадайте о причинах — они всегда записаны в системных логах. Откройте терминал и прочитайте последние 50 строк:

# Лог ошибок веб-сервера Nginx:
sudo tail -n 50 /var/log/nginx/error.log

# Лог ошибок PHP-FPM:
sudo tail -n 50 /var/log/php8.2-fpm.log

# Лог ядра системы (покажет, не убил ли процесс MySQL OOM-killer из-за нехватки RAM):
sudo dmesg -T | grep -i oom

Чек-лист настроек php.ini для предотвращения таймаутов

Для стабильной работы интернет-магазинов на 1С-Битрикс и WooCommerce рекомендуются следующие базовые параметры в /etc/php/8.2/fpm/php.ini:

memory_limit = 512M
max_execution_time = 300
upload_max_filesize = 64M
post_max_size = 64M
max_input_vars = 10000
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 100000

Автоматический контроль серверов через Novacom SRE

Если у вас нет штатного системного администратора, падение сайта из-за ошибки 504 или 500 в выходные дни оборачивается прямой потерей рекламного бюджета и заказов.

Автономный ИИ-вебмастер Novacom:

• Каждые 60 секунд замеряет коды ответа всех ключевых разделов сайта.
• При появлении 504 или 500 ошибки автоматически считывает error.log, выявляет упавший процесс и перезапускает службу за 12 секунд.
• При необходимости внесения правок — формирует безопасный изолированный патч с предварительным прогоном автотестов Playwright.

Стоимость страховки вашего сайта — всего 990 рублей в месяц.

👉 Проверьте текущее состояние вашего сайта на novacom.ru — экспресс-аудит выявит скрытые ошибки сервера и задержки загрузки за 10 секунд.