Nginx 1.2.1: Как проанализировать 500 Внутренних Ошибок Сервера

Вы можете проверить внешние подключения из конфигурации nginx (прокси, FCGI ...) и проверить их журналы.

Вот контрольный список nginx, который я использую при диагностике ошибок.

1. проверьте конфигурацию вашего nginx, используя

   sudo nginx -t
   

   это очень простой шаг, но он всегда должен быть сделан первым.

2. проверка того, что nginx запущен

   sudo service nginx.
   

3. Проверьте лог-файлы, указанные в настройках сайта

   найдите /etc/nginx - имя '*.conf' | xargs grep -i log
   

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

Чтобы зафиксировать любые внешние запросы / ошибки, которые могут возникнуть и вызвать ошибку 500: Вы также можете ввести свой адрес, к которому вы пытаетесь получить доступ, в браузере Chrome, открыв страницу chrome: // net-internals в меню «События».

Там вы можете проанализировать больше внешних запросов / ответы (информация DNS, отправленные заголовки и т. д.)

Первое, что спросите себя: что испускает ответ 500. Заголовки ответов и стиль страницы многое расскажут о том, откуда он взялся. Например. Есть ли в ответе заголовок X-Powered-By? Если это так, то это могло бы быть не из Apache (например).

Страница с ошибкой Tomcat сильно отличается от страницы Nginx, по сравнению с Apache и т. Д. Вот почему я обучаю людей на работе, чтобы они дали мне хороший снимок экрана.

Кроме того, если вы видите журналы 500, но ничего не видите в журнале ошибок, то, скорее всего, оно пришло из бэкэнда, и вам следует посмотреть там.

Кроме того, почему ваш тестовый и рабочий nginx версии разные? Вы ничего не сказали об использовании одной и той же версии в рабочей среде, что и в тестовой.

Остерегайтесь изменений поведения по умолчанию в разных версиях программного обеспечения. Мне напомнили об этом несколько раз, когда я недавно переходил на Apache 2.4 с 2.2.

Наконец, вы говорите, что серверная часть одинакова (действительно, как в одном и том же экземпляре?) Для теста и продукта, но это не обязательно означает, что запрос будет обрабатываться одинаково (например, другой заголовок хоста или сервер SNI имя передается)

Надеюсь, это поможет вам справиться с отладкой обратного прокси.