Ошибка 503 на сайте: что проверить в хостинге, Nginx и PHP-FPM

Начните с проверки статуса хостинга и запишите время появления ошибки. Код 503 Service Unavailable означает, что сервер сейчас не может обработать запрос: причиной бывают перегрузка, технические работы или ограничения ресурсов. Чтобы найти источник сбоя, нужно проверить хостинг, журналы Nginx и работу PHP-FPM, который выполняет PHP-код сайта. Ниже — порядок действий для владельца бизнеса и администратора: как собрать сведения, отличить временную недоступность от постоянной проблемы и восстановить сайт без случайных изменений настроек.

Что проверить до входа на сервер?

Откройте главную страницу и одну внутреннюю страницу сайта. Запишите, где появляется ошибка: во всём магазине, только в каталоге или при оформлении заказа. Если публичные страницы работают, а ошибка возникает при конкретном действии, передайте администратору последовательность, которая её вызывает. Не отправляйте повторно реальный заказ ради проверки.

Посмотрите уведомления в панели хостинга и сообщения о технических работах. Ошибка 503 встречается при перегрузке и во время обслуживания, поэтому сама надпись ещё не доказывает нехватку мощности тарифа. Такое значение кода разбирает материал «Ошибка 503 на сайте: что значит и что проверить» (KalinkinDev).

Для первого обращения в поддержку соберите короткую сводку:

• Адрес страницы, на которой возникает ошибка.
• Время сбоя с часовым поясом, например по Минску.
• Снимок экрана с полным текстом сообщения.
• Последнее изменение перед сбоем: обновление сайта, перенос или правка настроек.
• Характер ошибки: постоянная или периодическая.

На виртуальном хостинге попросите поддержку проверить ограничения аккаунта и серверные журналы за это время. На VPS сначала уточните, кто отвечает за администрирование. Доступ к панели управления сам по себе не означает, что провайдер следит за приложением и исправляет его ошибки.

Как найти источник 503 в Nginx и PHP-FPM?

Nginx принимает запросы посетителей. PHP-FPM выполняет PHP-код, например код WordPress, и возвращает результат веб-серверу. Ответ 503 может сформировать сам Nginx, приложение или промежуточный сервис перед сайтом. Надпись Nginx на странице ошибки не позволяет сразу выбрать виновника.

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

1. Найдите в журнале доступа запрос к проблемной странице за время сбоя.
2. Сопоставьте его с журналом ошибок Nginx.
3. Проверьте состояние службы PHP-FPM нужной версии.
4. Посмотрите журнал PHP-FPM за тот же промежуток.
5. Проверьте, нет ли режима обслуживания в самом приложении.

В Nginx ищут сообщения об ограничении запросов и проблемах обращения к приложению. При настроенном ограничении частоты запросов сервер тоже может возвращать 503: это зависит от конфигурации. Если ошибка появляется во время наплыва запросов, полезно отдельно разобрать настройку Rate Limiting в Nginx на VPS. Слишком жёсткий лимит способен отсечь обычных покупателей вместе с нежелательным трафиком.

В PHP-FPM проверяют сообщения о достижении лимита рабочих процессов и медленных запросах. Каждый рабочий процесс занимает память. Поэтому увеличение их количества без расчёта памяти способно усугубить перегрузку.

Посмотрите и на точный код ответа. Ошибки 502 и 503 требуют разных проверок, хотя посетитель в обоих случаях не получает страницу. Если журнал показывает другой код, используйте отдельный разбор: что проверить при ошибке 502 на хостинге и VPS.

Как проверить память, диск и нагрузку на VPS?

Сопоставляйте показатели со временем ошибки. Нормальная нагрузка после восстановления сайта ничего не говорит о том, что происходило во время сбоя. Если есть мониторинг, откройте историю; если его нет, зафиксируйте текущие показатели и настройте сбор данных для следующего случая.

Администратор с доступом по SSH может начать с команд просмотра. Они не удаляют файлы и не меняют настройки:

• free -h — показывает использование оперативной памяти и области подкачки.
• df -h — показывает свободное место в файловых системах.
• df -i — помогает проверить, не исчерпан ли запас файловых записей.
• top — показывает текущую нагрузку и процессы, которые потребляют ресурсы.

Полный диск мешает приложениям записывать временные файлы и журналы. Однако наличие занятого места ещё не объясняет причину: его могли занять резервные копии, журналы или файлы самого сайта. До удаления определите, какой каталог вырос и какие данные в нём лежат. Для этого подойдёт инструкция как найти и удалить мусор на VPS, замедляющий сайт.

Если память заканчивается при запуске фоновой задачи, проверьте её расписание и потребление ресурсов. Если нагрузка растёт при открытии определённой страницы, исследуйте запросы приложения и работу кэша. Переход на более мощный VPS имеет смысл после такой проверки: иначе ресурсы снова займёт та же причина.

Для бизнеса результат диагностики должен звучать конкретно: какой процесс упёрся в ограничение, когда это произошло и чем это подтверждается. Такая запись полезнее рекомендации «увеличить тариф» без журналов и показателей.

Как восстановить сайт и проверить результат?

Сначала сохраните сведения о сбое, затем выбирайте исправление. Перед изменением конфигурации сделайте её копию. Если планируется восстановление сайта из резервной копии, отдельно проверьте, какие новые заказы и изменения появились после её создания: откат затронет и их.

Работайте с причиной, которую подтвердили журналы. Для разных ситуаций действия будут разными:

• При технических работах у провайдера уточните ожидаемое время восстановления и способ получить уведомление.
• При зависшем PHP-FPM администратор проверяет журнал и выполняет контролируемый перезапуск службы.
• При заполненном диске сначала определяют содержимое крупных каталогов и сохраняют нужные данные.
• При ограничении запросов проверяют правила и то, какие обращения они блокируют.
• При сбое после обновления приложения рассматривают откат с учётом изменений в базе данных.

После правки Nginx администратор проверяет конфигурацию командой nginx -t. Применять изменения следует только после успешной проверки. Перезапуск служб без понимания причины иногда временно возвращает сайт, но оставляет источник сбоя на месте.

Проверьте не только главную страницу. Откройте страницу услуги или товара, выполните поиск, отправьте тестовую заявку, если это допустимо для вашего сайта. Затем убедитесь, что заявка дошла до получателя. Сообщение «успешно отправлено» в браузере ещё не подтверждает весь путь обращения.

Если ошибка повторяется, задачу полезно разделить: администратор проверяет сервер, разработчик — приложение, а специалист по подбору инфраструктуры сопоставляет фактическую нагрузку с ресурсами и условиями обслуживания. Для аналитики провайдеров нужны те же сведения: доступность журналов, порядок обращения в поддержку и состав администрирования. Подбор сервера на основе этих данных даёт понятное обоснование решения.

Типичные ошибки при устранении 503

• Перезапускать весь VPS при каждом сбое. Сначала сохраните журналы и показатели: после перезапуска часть текущей картины исчезнет.
• Удалять журналы и резервные копии вслепую. Сначала выясните назначение файлов и убедитесь, что нужная копия доступна отдельно.
• Одновременно менять настройки Nginx, PHP-FPM и приложения. Меняйте один параметр за раз и проверяйте результат, чтобы связать действие с эффектом.
• Считать открывшуюся главную страницу полным восстановлением. Проверьте действие, на котором возникал сбой, и получение тестовой заявки.
• Покупать ресурсы без диагностики. Сначала установите, какое ограничение сработало и почему.

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