Руководство к действию при ошибке 502 Bad Gateway hginx для пользователя
Просматривая странички всемирной сети Интернет, заходя по одним и тем же ссылкам, иногда появляется напрягающее пользователя сообщение – 502 Bad Gateway. При появлении сообщения об ошибке, пользователь не в состоянии просмотреть, что именно происходит на запрашивающей им страничке web-сайта. Очень часто сообщение появляется в том случае, когда есть какие-то проблемы с прокси-сервером, DNS-сервером либо с hosting-сервером на котором, собственно говоря, и размещен web-сайт.
Формально, это говорит о том, что браузеру был отправлен некорректный ответ с другого сервера, и поэтому идет вывод ошибки 502 Bad Gateway.
Как же поступать в этом случае?
Самое первое, что может пользователь, это набрать в адресной строке другой адрес сайта, и желательно такой, который бы работал, и чтобы этот сайт территориально находился там же, откуда у пользователя есть доступ в Интернет.
Таким образом, есть возможность проверить наличие доступа ко Всемирной сети вообще. Так, корпоративный доступ к Интернету идет через прокси-сервер, а не сразу через модем, который встроен в компьютер. В случае подключения к Интернету через модем, ошибка диагностируется детальнее, а вот когда происходит подключение по локальной сети, то система не в состоянии выйти за пределы выделенных ей прав, и по этой причине, она не может диагностировать появившуюся ошибку. Вот тогда пользователю ничего другого не остается, как прибегать не к прямым, а к косвенным методам.
В том случае, если доступ к Интернету присутствует, но, обратившись к конкретному сайту, появляется ошибка — 502, стоит попробовать удалить все cookies, имеющие отношение к сайту. Сделать это можно следующим образом:
— в Internet Explorer 7+: меню «Сервис» — «Свойства обозревателя» — «Удалить» — «Удалить cookies»
— для Internet Explorer ранних версий: меню «Tools» — «Internet options» — «Delete cookies»
— в браузере Firefox: в меню «Инструменты» — «Настройки» — «Cookies» — Очистить cookies
— в Opera: «Инструменты» — «Удалить личные данные» — «Подробности»
В том случае, если после этих действий, результат оказался таким же, как и прежде, значит, источник ошибки находится за пределами сети, к которой подключен компьютер пользователя. Вполне вероятно, что «лежит» сервер, к которому обращается запрос. В этом случае остается только ждать того момента, пока админ там сможет все наладить.
Ошибка 502 Bad Gateway nginx руководство к действию для web-мастера
Когда возникает сообщение о такой ошибке, это значит, что http-запросы, которые идут от клиентов к Вашему сайту, проходят через некий шлюз. К примеру, если на хостинге перед web-сервером Apache расположен web-сервер nginx, то последний как раз и является шлюзом.
Ошибка 502 означает, что запрос, посланный клиентом, прошел nginx, попал к Apache, но Apache его не смог обработать, о чем и сообщил nginx. После этого nginx обратно отсылает клиенту информацию об ошибке.
Apache не обработал запрос. Способы исправления ошибки
В том случае, если раньше сайт был рабочим, а теперь не открывается, то, скорее всего, проблему нужно искать не в конфигурации среды. Может выдаваться проблема и в том случае, когда не хватает оперативной памяти. Такая проблема может произойти на VPS либо на shared-хостинге.
В том случае, если PHP работает посредством FastCGI, то тогда на сервере может ощущаться нехватка php-cgi процессов в те моменты, когда на сайте много посетителей, либо когда сайт посещает робот поисковой системы, съедающий немалые ресурсы, или когда кто-то из посетителей скачивает весь сайт для просмотра его оффлайне. Памяти не хватает даже на то, чтобы пустить в ход элементарные процессы. Это означает только одно, что нужно добавлять память или по-другому расходовать ту память, которая имеется.
Если команда top показывает, что память есть, то, скорее всего, все дело в установленных лимитах на определенное количество php-cgi процессов. Тогда, вероятно, придется проверять конфигурационные файлы Apache и особенно секцию модуля, которая отвечает за FastCGI (mod_fastcgid или mod_fastcgi).
Если же очень часто появляются проблемы на обыкновенном shared-хостинге, то может быть вся причина в оверселлинге? Когда провайдер хостинга продает гораздо больше виртуальных машин, чем сервер может обработать, либо причина в том, что сервер не настроен соответствующим образом. В этом случае, лучше сменить провайдера.
Ошибка 504 Gateway Timeout nginx или что сделать, чтобы ее исправить?
Почему же возникает ошибка 504 Gateway Timeout? Довольно часто можно встретить эту ошибку на серверах, где nginx установлен, как фронтенд, а Apache в свою очередь, как бэкенд. Многим кажется, что вся проблема в nginx, но проблема скрыта в другом.
Когда появляется сообщение об ошибке – 504 Gateway Timeout, то это означает, что клиентский запрос nginx передал апачу, только апач не смог своевременно вернуть http-ответ.
Почему же так произошло, что Apache не смог ответить?
Все дело, скорее всего в том, что нагрузка на сайт выросла, и при такой нагрузке Apache просто не успевает отдавать http-ответы, поэтому новые запросы выстраиваются в огромную очередь. Клиенты находятся в длинной очереди, но все равно за отведенное на ответ время, которое лимитировано, соединение сбрасывается, оставив запросы без ответа. Для того, чтобы решить возникшую проблему, следует добавить некоторые ресурсы к серверу. Опять-таки, как выход – увеличение оперативной памяти, увеличение количества процессов httpd (Apache). Второй вариант – оптимизация работы скриптов сайта для того, чтобы быстрее выполнялись операции. В том случае, если сайт находится на обыкновенном виртуальном хостинге, то без участия администрации не обойтись. Если ситуация остается на том же уровне довольно длительный промежуток времени – то придется идти на крайнюю меру и менять хостинг-провайдера.
Еще одной причиной возникновения ошибки 504 является то, что выполняемый скрипт не укладывается в отведенный для него диапазон времени. Такая сложность возникает, когда скрипт запрашивает другие сайты, либо в это время занимается выполнением тяжелой работы, например такой, как строительство поискового индекса.
Для решения проблемы нужно либо облегчить скрипт, либо изменить в сторону увеличения значение параметра PHP max_execution_time.
Ошибка 500
Очень часто причина возникновения внутренней ошибки сервера — 500 (internal server error), является неправильный синтаксис файла .htaccess или же в файле имеются неподдерживаемые директивы. Для устранения проблемы чаще всего закомментируют директиву Options, для чего в начале строки ставится #.
Ошибка 500 еще возникает из-за того, что происходит неверное обращение с CGI-скриптами.
— CGI-скрипты обязательно должны иметь определенные окончания строк в формате UNIX (/n), но только не в формате Windows (/r/n). Для этого их загружают на сервер FTP в режиме ASCII
— CGI-скрипты и папки, в которых они расположены, могут быть доступны для записи только владельцу и у него должны быть права 0755 (drwxr-xr-x)
— после работы CGI-скрипта могут быть неверно сформированы заголовки ответа. Тогда для того, чтобы устраненить проблемы, обращаются к error_log, который находится в контрольной панели в разделе «Статистика/Лог-файлы/Лог ошибок».
Ошибка 503 Service Temporarily Unavailable
Каждый аккаунт, находящийся на сервере, имеет определенное количество рабочих процессов, которые занимаются обработкой запросов пользователей. Запросы поступают на сервер, выстраиваясь в очередь. Если запросы не сложные, тогда на их обработку уходит мало времени, а если запросы тяжелые, проблемные, так сказать, то, соответственно, на их обработку уходит много времени, из-за чего возникает торможение всей системы. Когда очередь из запросов достигает определенных пределов, то сервер перестает обрабатывать новые запросы, отдавая обратно ответ в виде ошибки 503 (Service Temporarily Unavailable, то есть информацию о том, что сервис временно недоступен).
В списке ниже приведены наиболее распространенные причины возникновения длинной очереди и пути решения проблемы.
1. Если зависают скрипты
— Происходит передача больших статичных файлов через PHP. Лучше всего такие файлы передавать напрямую и не использовать для этого скрипты. Время работы скриптов ограничено и после того, как время проходит, передача файла прекращается, и кроме этого, чтобы передать файл через PHP, используется отдельный рабочий процесс, а это значит, что он как бы «выпадает» из механизма обработки запросов посетителей. Для того, чтобы передавать файлы напрямую, задействован специальный многопоточный процесс, который в состоянии заниматься обработкой одновременно множества потоков, при этом, не оказывая влияния на скорость загрузки сайта. Применяя правила mod-rewrite в файле .htaccess можно реализовать функциональность большинства скриптов хранения файлов.
— Соединение с удаленным сервером.
Лучше всего это не использовать. Но, в крайнем случае, если ничего другого не остается, то нужно выставить небольшой time out, чтобы дождаться ответа и убедиться в том, что связь с удаленным сервером в норме. Если в PHP-скриптах применяются Include-функции, или загружающие части движка сервера, которые находятся на одном аккаунте, то следует удостовериться в том, что в них используется локальный путь, а не URL. Если присутствует URL-путь, то сервер требует дополнительный http-запрос, на что уходит еще один рабочий процесс.
— Большое число испорченных или тяжелых компонентов CMS. Нужно проверить все плагины и компоненты Вашей CMS. Для чего пользователь отключает их поочередно. Находит самые тяжелые и испорченные, из-за которых загрузка сайта становится медленнее. По возможности, нужно отказаться от испорченных или тяжелых компонентов системы. Следует убрать все ненужные компоненты, которые не используются.
— Выполняющееся долгое время задание mambot для Joomla. Когда есть mambot-задания, которые можно перенести в системный cron, то лучше это сделать. Задачи-mambot’ы решаются совместно с запросом пользователя и по этой причине загрузка сайта либо осуществляется очень медленно, либо сайт не загружается вообще.
— Почтовая рассылка. Лучше всего расположить запуск скрипта почтовой рассылки в системном cron. И управлять им из контрольной панели. А запуск скрипта назначить на то время, когда меньше всего происходит запросов и нагрузки на сервер, обычно выбирается ночное время. При этом учитываются те ограничения, которые накладываются при составлении договора-оферты, относительно количества получаемых писем в час или день.
— Большое число медленных запросов к MySQL. В том случае, если медленно выполняются запросы, в аккаунте пользователя в папке logs, создается файл mysql-slow.log. Информация этого файла обновляется раз в сутки и в ней находятся только проблемные SQL-запросы. Возможное решение проблемы:
а) установка в движок кеширующих компонентов, благодаря которым реально можно сократить число SQL-запросов
б) оптимизировать SQL-запросы
в) проиндексировать таблицу с базами данных по столбцам, которые участвуют в выборке
г) если ничего из вышеперечисленного не оказывает своего положительного влияния, рекомендуется сменить движок
2. Большое число запросов, направляемых к веб-серверу
— Если у загружаемого ресурса есть ссылки на большое число файлов, таких как картинки, таблицы, скрипты, которые подгружаются дополнительно через отдельные запросы, то лучше всего их объединить в один файл.
— На сайте есть элемент, который периодически отправляет AJAX-запросы (обычно это замечено в чате). Количество запросов зависит не только от того, сколько посетителей в чате, но еще и от того, сколько вкладок открыто в браузере.
— На сайте есть боты-индексаторы, которые в настоящее время производят сканирование ресурсов сайтов.
— Используются элементы ресурсов или скриптов на чужих сайтах. В этом случае лучше применять антилич-модули/настройки.
— Производятся DDoS-атаки.
