Как найти причину 500 в веб-почте и вернуть доступ

Ошибка 500 в веб-почте означает, что сервер не смог выполнить запрос, но сама цифра не называет виновника. Я начинаю диагностику с точного времени сбоя и журналов веб-сервера, PHP и системы, затем проверяю место, права и доступность зависимостей. Ниже — порядок действий без опасного ремонта наугад.

Что означает ошибка 500 в веб-почте

HTTP 500 — общий ответ о неожиданной ошибке, из-за которой сервер не выполнил запрос. Это описание результата, а не диагноз: код не сообщает, сломался ли PHP, не ответила база, не хватило места или приложение само вернуло ошибку. Сервер может показать пользователю короткую заглушку, а подробность оставить в журнале. Может и не оставить — например, если журналирование отдельно выключено или запись не удалась. Поэтому начинать с одной догадки вроде «это точно PHP» нельзя.

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

Для почтового веб-интерфейса HTTP-слой — только входная дверь. За ним могут стоять веб-сервер, PHP-FPM, код самой почты, база данных, хранилище сессий и файловая система. Поломка каждого слоя выглядит для сотрудника одинаково: страница не открылась. Я начинаю с корпоративной почты как сервиса целиком, а не с привычки винить последний компонент, который обновляли.

• Запишите URL или действие, на котором появляется сбой.
• Сравните результат для другой учётной записи и соседнего действия.
• Зафиксируйте время ошибки с часовым поясом.

Условный кейс: «Бриз-Сервис» и пустые журналы

Разберу условный кейс компании «Бриз-Сервис» — это учебный сценарий, а не история реального клиента. Представим офис на 30 сотрудников: утром часть людей видит 500 при входе в веб-почту, а локальный администратор не находит полезной строки в привычном журнале. Такая вводная не доказывает, что проблема в PHP-FPM. Она только задаёт границы поиска: выяснить, одинаково ли падают запросы и где заканчивается обработка.

Допустим, сбой совпал с исчерпанием места на разделе, куда пишет приложение. Если там же лежат журналы или настроено хранение файлов сессий, новые записи могут не появляться, а приложение — не сохранить состояние входа. Но каталог сессий не обязан быть /tmp: PHP использует настроенный обработчик, а session.save_path задаёт путь при файловом обработчике. И сам факт полного раздела нужно увидеть в выводе проверки, а не вывести из тишины в журнале. Пустая строка — улика слабая; точный замер диска уже полезнее.

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

Почему журналы молчат и где искать запись

У Apache путь журнала ошибок задаёт директива ErrorLog; журнал может быть файлом или системным логированием. Значит, имя error_log в инструкции не гарантирует, что именно этот файл используется на конкретном сервере. В PHP есть отдельные настройки для записи ошибок, а у PHP-FPM — собственный журнал и уровень подробности. Сначала выясните фактические значения и куда процессу разрешено писать. Не включайте показ подробных ошибок в публичном окне веб-почты: диагностический текст способен раскрыть внутренние сведения.

Я свожу журналы к одному временному отрезку. Сначала фиксирую время и действие, затем смотрю журнал веб-сервера, журнал PHP или пула FPM и системный журнал, если он используется. Запись «не удалось подключиться» и запись о падении рабочего процесса ведут в разные стороны; сам код 500 между ними не выбирает. Ищите не только слово error, но и время, маршрут запроса, завершение процесса, отказ доступа и сообщения файловой системы. Если перед глазами только «ошибка 500», это ещё не повод менять конфигурацию.

Пустой файл может означать, что выбран не тот журнал, ошибка попала в другой канал, нужный уровень не записывает событие либо запись невозможна. У Apache журнал ошибок отдельно настраивается в конфигурации сервера или виртуального узла; PHP-FPM тоже позволяет настроить свой error_log. В контейнерной установке вывод иногда забирает управляющая система, а не файл внутри приложения. Я проверяю схему развёртывания, прежде чем советовать путь вроде /var/log/php-fpm.log: это пример, не общий адрес для всех пакетов и образов.

Сопоставьте одинаковое действие с разными слоями. Если веб-сервер зарегистрировал запрос, а журнал приложения пуст, переходите к способу передачи запроса и журналу PHP-FPM. Если событие есть только в системном журнале, ищите отказ процесса или файловой системы. Если запись есть в приложении, следуйте её конкретному сообщению и не объявляйте любую ошибку соединения «падением PHP». В связанной статье я отдельно разбираю тайм-аут PHP-FPM; там важно отличать долгий ответ от сценария, в котором приложение сразу возвращает внутреннюю ошибку. Журнал, который никто не может найти, напоминает инструкцию в аварийном шкафу: красиво хранится, пока не понадобился.

Какие причины дают 500 в почтовом интерфейсе

В Apache ошибочная директива в .htaccess действительно может превратить запрос в 500; для другого веб-сервера этот файл вообще не является источником настройки. Даже в Apache не всякая ошибка «в конфиге» лечится переименованием .htaccess: сначала подтвердите, что запрос обслуживает Apache и что журнал указывает на этот файл. Делайте резервную копию, меняйте одну настройку за раз и проверяйте синтаксис поддерживаемым для вашей установки способом. Слепо отключить конфигурацию на работающей почте — способ добавить вторую аварию к первой.

Права тоже проверяют по фактическому пользователю процесса, а не по примеру из чужой инструкции. Имя www-data часто встречается в Debian-подобных системах, но не является обязательным для всех сборок. Важны права на проход по каталогам, чтение кода и запись именно в настроенные каталоги временных файлов, сессий или загрузок. Посмотрите владельца и режим доступа через ls -la, затем сверьте их с учётной записью веб-процесса. chmod 777 не диагностирует проблему; он лишь раздаёт запись всем и может создать отдельный риск. chmod 777 — не ремонт, а приглашение всем подряд проверить, что именно вы оставили доступным.

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

Наконец, после обновления или правки могли измениться код, модуль или конфигурация. Восстановите хронологию: что меняли непосредственно перед первым сбоем, на какой версии, каким способом и была ли проверка на копии. Сама близость двух событий не доказывает причинность, но это хороший фильтр для поиска. Для Zimbra WebUI есть отдельный разбор специфичных симптомов ошибки 500 в Zimbra; его шаги относятся к этой платформе, а не ко всякой веб-почте.

• Конфигурация веб-сервера или ошибка приложения.
• Недоступная база данных или другая обязательная зависимость.
• Заполненные блоки или inode файловой системы.
• Неверный доступ к каталогу сессий или временным файлам.

Порядок восстановления без ремонта наугад

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

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

df -h /var/log /tmp
df -i /var/log /tmp

Дальше проверьте журналы за интервал сбоя: Apache или Nginx по фактической конфигурации, PHP-FPM и системный журнал, если его использует хост. Для systemd можно обратиться к journalctl; имя юнита и способ запуска FPM зависят от дистрибутива и установки. Не копируйте команду с чужим именем службы. Если подозрение падает на Apache и .htaccess, сначала сохраните файл и подтвердите ошибку в журнале. Перед изменением конфигурации убедитесь, что у вас есть доступный откат.

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

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

Как не допустить повторения ошибки

Настройте журналирование заранее и проверьте его на реальном тестовом запросе: событие должно попасть в ожидаемый канал, а у ответственного администратора должен быть к нему доступ. В PHP разделяйте запись ошибок и показ ошибок посетителю; в производственной среде подробный вывод не должен раскрывать внутренности системы. Учитывайте ротацию, срок хранения и свободное место на томе с журналами. Журнал, который никто не может найти в день сбоя, формально существует, но практически бесполезен.

Мониторьте не только процент занятого диска, но и inode, состояние процесса веб-приложения и доступность критичных зависимостей. Порог срабатывания выбирают по скорости роста данных и времени реакции команды — универсального числа для всех почтовых серверов нет. Уведомление должно прийти до отказа, а не после первого звонка сотрудников. Периодически проверяйте, что оповещения доставляются ответственному человеку, а старые журналы не растут бесконтрольно.

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

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

Частые вопросы