QWARTA.RU - индивидуальный подход

Ошибки 5xx на хостинге, виртуальных серверах и серверах и способы их устранения.

На данный момент самой популярной связкой HTTP серверов является Nginx совместно с Apache или Fast-cgi. Рассмотрим причины возникновения распространённых 500-x ошибок и способы их устранения.

Ошибки:

• 500 Internal Server Error - внутренняя ошибка сервера
• 502 Bad Gateway - ошибка шлюза
• 503 Service Unavailable - сервис не доступен
• 504 Gateway Timeout – Шлюз не отвечает за определенное время

Ошибка 500 Internal Server Error

Данная ошибка возникает в случае, если сервером отдается неверный http заголовок. Это может произойти по следующим причинам:

• Ошибка в правилах mod_rewrite в файле .htaccess
• В файле .htaccess используются директивы, содержащие ошибки в командах или случайные синтаксические ошибки (вместо латинского символа “C” - кириллица).
• При превышении лимита открытых файлов на сервере, Nginx выдает 500 ошибку.
• При работе скриптов Perl, если скрипт не выдает в заголовок такой ответ: print "Content-type: text/html\n\n";
• При наличии в Nginx или Apache правила rewrite, которое вызывает зацикливание (вечный редирект). После некоторого количества циклов в браузер будет выдана 500 ошибка.
• Сайт может создавать при работе неправильный http заголовок и в браузер будет выдана 500 ошибка. Например, при ошибке в скрипте php отдается ошибочный неверный http заголовок, в результате чего Apache показывает 500 ошибку.
• По каким-либо причинам на в браузере сохранились ошибочные cookies и при новом соединении к сайту «битые» cookies передаются через http заголовок и вызывают данную ошибку. В этом случае помогает чистка cookies в браузере или можно попробовать зайти другим браузером.

Ошибка 502 Bad Gateway

При использовании на сервере связки Nginx+ бэкенд (Apache или Fast-cgi) эта ошибка означает, что запрос от браузера пришел в Nginx. Он же, в свою очередь, пытается отправить этот запрос дальше в бэкенд, но не получает ответа. То есть Apache (или Fast-cgi) не доступен.
Такое бывает в следующих ситуациях:

• Apache или Fast-cgi в данный момент не запущены или перезапускаются. Необходимо посмотреть, почему это происходит.
• Если на сайт идет много запросов и Nginx успевает их обработать, а бэкенд нет, то Nginx’у не куда отправить запрос и он отдает 502 ошибку. Исправить ситуацию поможет увеличение числа «воркеров» у Apache или у Fast-cgi. Вдобавок не лишним будет Так же помогает уменьшение параметра KeepAlive, таким образом «воркеры» будут быстрее освобождаться от предыдущих запросов.
• Если на сервер идет DDOS атака или просто у вас очень посещаемый сайт – сайт имеет огромную посещаемость (миллионы посещений в сутки), то нужно необходимо настроить ядро операционной системы, чтобы оно быстрее освобождало быстрее освобождались коннекты от старых запросов:
  • net.ipv4.ip_local_port_range=16384 64000 (увеличение диапазона портов TCP - внутренние порты на сервере, через которые общаются между собой процессы)
  • net.ipv4.tcp_fin_timeout=10 (временной интервал попытки определения жизнеспособности соединения, по умолчанию 7200, то есть пользователь ушел, а коннект ждет его еще 2 часа и занимает ресурсы сервера)
  • net.ipv4.tcp_max_syn_backlog=4096 (размер очереди не установленных соединений, по умолчанию 512, если очередь маленькая, то до сайта запросы не будут доходить)
  • net.ipv4.tcp_synack_retries=1 (максимальное число попыток установить пассивное TCP-соединение, если внешних запросов много, а сервер дает много попыток соединится с хоста, нормальные запросы могут и не получить место в очереди)
  • net.ipv4.tcp_tw_recycle=1 (разрешает быструю утилизацию сокетов, находящихся в состоянии TIME-WAIT. посмотреть можно через netstat С помощью netstat можно узнать сколько на сервере таких соединений)
  • net.ipv4.tcp_tw_reuse=1 (если ваш сервер создает множество исходящих соединений, то ваша система сможет использовать порты TIME_WAIT в случае исчерпания свободных)
  • fs.file-max=999999 (максимальное значение открытых файлов, чтобы его узнать, выполните команду cat /proc/sys/fs/file-max)
  • net.ipv4.tcp_keepalive_time=60 (определяет, как часто следует проверять соединение, если оно не используется)
  • net.ipv4.tcp_keepalive_probes=2 (кол-во проверок)
  • net.ipv4.tcp_keepalive_intvl=10 (определяет интервал между проверками соединения)
  • net.core.somaxconn = 65535 (максимальное число открытых сокетов, ждущих соединения)
  • net.core.rmem_max = 16777216 (максимальный размер буфера приема данных для всех соединений)
  • net.core.wmem_max = 16777216 (максимальный размер буфера передачи данных для всех соединений)
  • net.ipv4.tcp_rmem = 4096 87380 16777216 (размер приемного буфера сокетов в байтах - минимальный гарантированный размер буфера, размер по умолчанию и максимальный размер, больше которого буферу система не даст вырасти)
  • net.ipv4.tcp_wmem = 4096 65536 16777216 (размер буфера сокетов для передачи в байтах - минимальный гарантированный размер буфера, размер по умолчанию и максимальный размер, больше которого буферу система не даст вырасти)
  • net.core.netdev_max_backlog = 4096 (определяет размер очереди на обработку, если интерфейс получает пакеты быстрее, чем ядро может их обработать)
  • net.ipv4.tcp_window_scaling = 0 (запрещяем динамическое изменение размера окна TCP стека)
  • net.ipv4.tcp_max_orphans=131072 (определяет максимальное число допустимых в системе сокетов TCP)

  Внимание! Перед изменением этих параметров рекомендуется более подробно изучить действие каждого из них.