Nginx proxy 500 internal server error

Sometimes NGINX server may give 500 Internal Server Error due to various reasons. In this article we will look at what does 500 Internal Server Error mean in NGINX and how to fix 500 Internal Server Error in NGINX.

NGINX gives 500 Internal Server Error when there is a server-side error that prevents NGINX from returning a proper response. It can be due to many different reasons such as faulty script, missing files referenced by code, inadequate file permissions, etc. NGINX is typically used as a reverse proxy server, so the most common reason for 500 Internal server is an error in one of its web servers like Apache that has encountered an issue and returned a 500 error response to NGINX, which is then returned to client browsers. There are various ways to fix internal server error in NGINX.

Bonus Read : How To Fix 504 Gateway Timeout Error in NGINX

How to Fix 500 Internal Server Error in NGINX

Here are the steps to fix 500 Internal Server Error in NGINX on localhost, CPanel, PHP, Ubuntu and other platforms.

1. Hard Refresh

Sometimes you may get 500 internal server error in NGINX because your server is being restarted at that moment, or there are too many requests for web server to handle.

So it doesn’t have enough resources to serve your request.

In such cases, you can simply do a hard refresh of your page to force the browser to get latest web page version and fix 500 internal server error in NGINX. You can do this by pressing

• Windows: Ctrl + F5
• Mac: Apple + R or Cmd + R
• Linux: F5

Bonus Read : How to Fix 502 Bad Gateway Error in NGINX

2. Examine Server Logs

Open your server log in a text editor to analyze the most recent requests. Every server log contains information about requested URLs and response code for each request.

Find out which requests result in 500 internal server error. It may be that only one page, or a few pages give this error while others work fine.

Find out which requests cause 500 internal server error. Once you have identified the problematic URLs, open a browser and request them again to confirm that is indeed the case.

Bonus Read : How to Increase Request Timeout in NGINX

3. Examine Your Script

Next, analyze the script to process the problematic requests. Is it actually present at the right location? Are you referencing it properly, in your URL mapping/routing file?

If your script refers to another file, find out if that file path is correct. If you have referenced any program/function, have you called it correctly?

4. Check File/Folder Permission

This can also be due to improper file/folder permissions. Did you add/modify any file/folder recently?

Typically, files need a 644 permission and folders need a 755 permission. You can use FileZilla (Windows) and Chmod (Linux) to modify file permissions.

You can also look at the permissions of other files & folders in your code and update the same for your files/folders accordingly.

Bonus Read : How to Increase File Upload Size in NGINX

5. Check redirections

If you have incorrectly setup any redirections in web server, it can give 500 internal server error. For example, if you use Apache web server, make sure you have properly configured mod_rewrite module and .htaccess file.

Also use a third-party tool to check the syntax of redirection/URL rewrite rules in your server configuration file.

6. Increase Script Timeout

You may also get 500 internal server error in NGINX if your web server (e.g Apache) is timing out on the request. In such cases, increase your web server (not NGINX) timeout value so that it stays connected to NGINX longer, and returns a proper response.

Hopefully, the above tips will help you fix 500 internal server error in NGINX.

Ubiq makes it easy to visualize data in minutes, and monitor in real-time dashboards. Try it Today!

I added both www.example.com and example.com to the [envvars], it seems like example.com pointed to my IP address (from the dns) but www.example.com pointed to nothing. Seems like nginx-letsencrypt just crashes when receiving a «NoneType» instead of creating a certificate for example.com and ignoring www.example.com. (Should create cert for example.com, but catch Exception for www.example.com)

Output:

/etc/nginx/certs/example.com /app
Creating/renewal example.com certificates... (example.com www.example.com)
2020-10-07 08:48:29,767:INFO:simp_le:1414: Generating new certificate private key
2020-10-07 08:48:31,505:ERROR:simp_le:1396: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Are all your domains accessible from the internet? Please check your domains' DNS entries, your host's network/firewall setup and your webserver config. If a domain's DNS entry has both A and AAAA fields set up, some CAs such as Let's Encrypt will perform the challenge validation over IPv6. If your DNS provider does not answer correctly to CAA records request, Let's Encrypt won't issue a certificate for your domain (see https://letsencrypt.org/docs/caa/). Failing authorizations: https://acme-v02.api.letsencrypt.org/acme/authz-v3/7725902331
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1370, in finalize_order
    finalized_order = client.poll_and_finalize(order)
  File "/usr/lib/python3.7/site-packages/acme/client.py", line 712, in poll_and_finalize
    orderr = self.poll_authorizations(orderr, deadline)
  File "/usr/lib/python3.7/site-packages/acme/client.py", line 736, in poll_authorizations
    raise errors.ValidationError(failed)
acme.errors.ValidationError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1443, in persist_new_data
    order = finalize_order(client, order)
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1397, in finalize_order
    raise Error('Challenge validation has failed, see error log.')
simp_le.Error: Challenge validation has failed, see error log.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1565, in main
    return main_with_exceptions(cli_args)
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1549, in main_with_exceptions
    persist_new_data(args, existing_data)
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1464, in persist_new_data
    chain=None,
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 1128, in persist_data
    plugin.save(new_data)
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 557, in save
    key = self.dump_key(data.key)
  File "/usr/lib/python3.7/site-packages/simp_le.py", line 455, in dump_key
    return OpenSSL.crypto.dump_privatekey(self.typ, data.wrapped).strip()
AttributeError: 'NoneType' object has no attribute 'wrapped'
Unhandled error has happened, traceback is above
Debugging tips: -v improves output verbosity. Help is available under --help.
/app
Sleep for 3600s

After I pointed www.example.com to the correct IP, flushed my DNS server and restarted the container running the website it worked:

/etc/nginx/certs/example.com /app
Creating/renewal example.com certificates... (example.com www.example.com)
2020-10-07 09:03:17,482:INFO:simp_le:1414: Generating new certificate private key
2020-10-07 09:03:22,328:INFO:simp_le:396: Saving key.pem
2020-10-07 09:03:22,329:INFO:simp_le:396: Saving fullchain.pem
2020-10-07 09:03:22,329:INFO:simp_le:396: Saving cert.pem

I have no clue why it worked before and stopped working when nginx.tmpl got update…

I am trying to do basic auth on Nginx. I have version 1.9.3 up and running on Ubuntu 14.04 and it works fine with a simple html file.

Here is the html file:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title></title>
</head>
<body>
  "Some shoddy text"
</body>
</html>

And here is my nginx.conf file:

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
    server {
        listen 80;
        server_name 192.168.1.30;
        location / {
            root /www;
            index index.html;
            auth_basic "Restricted";
            auth_basic_user_file /etc/users;
        }
    }
}

I used htpasswd to create two users in the «users» file under /etc (username «calvin» password «Calvin», and username «hobbes» password «Hobbes»). It’s encrypted by looks like this:

calvin:$apr1$Q8LGMfGw$RbO.cG4R1riIfERU/175q0
hobbes:$apr1$M9KoUUhh$ayGd8bqqlN989ghWdTP4r/

All files belong to root:root. The server IP address is 192.168.1.30 and I am referencing that directly in the conf file.

It all works fine if I comment out the two auth lines and restart nginx, but if I uncomment them, then I do indeed get the username and password prompts when I try to load the site, but immediately thereafter get an Error 500 Internal Server error which seems to persist and I have to restart nginx.

Anybody can see what I’m doing wrong here? I had the same behaviour on the standard Ubuntu 14.04 apt-get version of Nginx (1.4.something) so I don’t think it’s the nginx version.

Nginx — это веб-сервер, на котором работает треть всех сайтов в мире. Но если забыть или проигнорировать некоторые ошибки в настройках, можно стать отличной мишенью для злоумышленников. Detectify Crowdsource подготовил список наиболее часто встречающихся ошибок, делающих сайт уязвимым для атак.

Nginx — один из наиболее часто используемых веб-серверов в Интернете, поскольку он модульный, отзывчивый под нагрузкой и может масштабироваться на минимальном железе. Компания Detectify регулярно сканирует Nginx на предмет неправильных настроек и уязвимостей, из-за которых могут пострадать пользователи. Найденные уязвимости потом внедряются в качестве теста безопасности в сканер веб-приложений.

Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных удалось выяснить,  какие ошибки в конфигурациях встречаются чаще всего. Эта статья прольёт свет на следующие неправильные настройки Nginx:

1. Отсутствует корневой каталог

2. Небезопасное использование переменных

3. Чтение необработанного ответа сервера

4. merge_slashes отключены

Отсутствует корневой каталог

server {
        root /etc/nginx;

        location /hello.txt {
                try_files $uri $uri/ =404;
                proxy_pass http://127.0.0.1:8080/;
        }
}

Root-директива указывает корневую папку для Nginx. В приведённом выше примере корневая папка /etc/nginx, что означает, что мы можем получить доступ к файлам в этой папке. В приведенной выше конфигурации нет места для / (location / {...}), только для /hello.txt. Из-за этого root-директива будет установлена ​​глобально, а это означает, что запросы к / перенаправят вас на локальный путь /etc/nginx.

Такой простой запрос, как GET /nginx.conf, откроет содержимое файла конфигурации Nginx, хранящегося в /etc/nginx/nginx.conf. Если корень установлен в /etc, запрос GET на /nginx/nginx.conf покажет файл конфигурации. В некоторых случаях можно получить доступ к другим файлам конфигурации, журналам доступа и даже зашифрованным учётным данным для базовой аутентификации HTTP.

Из почти 50 000 файлов конфигурации Nginx, которые мы проанализировали, наиболее распространёнными корневыми путями были следующие:

Потерявшийся слеш

server {
        listen 80 default_server;

        server_name _;
        location /static {
                alias /usr/share/nginx/static/;
        }
        location /api {
                proxy_pass http://apiserver/v1/;
        }
}

При неправильной настройке off-by-slash можно перейти на один шаг вверх по пути из-за отсутствующей косой черты. Orange Tsai поделился информацией об этом в своём выступлении на Blackhat «Нарушение логики парсера!». Он показал, как отсутствие завершающей косой черты в location директиве в сочетании с alias директивой позволяет читать исходный код веб-приложения. Менее известно то, что это также работает с другими директивами, такими как proxy_pass. Давайте разберёмся, что происходит и почему это работает.

location /api {
                proxy_pass http://apiserver/v1/;
        }

Если на Nginx запущена следующая конфигурация, доступная на сервере, можно предположить, что доступны только пути в http://apiserver/v1/.

http://server/api/user -> http://apiserver/v1//user

Когда запрашивается http://server/api/user, Nginx сначала нормализует URL. Затем он проверяет, соответствует ли префикс /api URL-адресу, что он и делает в данном случае. Затем префикс удаляется из URL-адреса, поэтому остаётся путь /user. Затем этот путь добавляется к URL-адресу proxy_pass, в результате чего получается конечный URL-адрес http://apiserver/v1//user.

Обратите внимание, что в URL-адресе есть двойная косая черта, поскольку директива местоположения не заканчивается косой чертой, а путь URL-адреса proxy_pass заканчивается косой чертой. Большинство веб-серверов нормализуют http://apiserver/v1//user до http://apiserver/v1/user, что означает, что даже с этой неправильной конфигурацией всё будет работать так, как ожидалось, и это может остаться незамеченным.

Эта неправильная конфигурация может быть использована путём запроса http://server/api../, из-за чего Nginx запросит URL-адрес http://apiserver/v1/../, который нормализован до http://apiserver/. Уровень вреда от такой ошибки определяется тем, чего можно достичь, если использовать эту неправильную конфигурацию. Например, это может привести к тому, что статус сервера Apache будет отображаться с URL-адресом http://server/api../server-status, или он может сделать доступными пути, которые не должны быть общедоступными.

Одним из признаков того, что сервер Nginx имеет неправильную конфигурацию, является возврат сервером одинакового же ответа при удалении косой черты в URL-адресе. То есть, если http://server/api/user и http://server/apiuser возвращают один и тот же ответ, сервер может быть уязвимым. Он позволяет отправлять следующие запросы:

http://server/api/user -> http://apiserver/v1//user
http://server/apiuser -> http://apiserver/v1/user

Небезопасное использование переменных

Некоторые фреймворки, скрипты и конфигурации Nginx небезопасно используют переменные, хранящиеся в Nginx. Это может привести к таким проблемам, как XSS, обход HttpOnly-защиты, раскрытие информации и в некоторых случаях даже RCE.

SCRIPT_NAME

С такой конфигурацией, как эта:

        location ~ .php$ {
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_pass 127.0.0.1:9000;
        }

основная проблема будет заключаться в том, что Nginx отправит интерпретатору PHP любой URL-адрес, заканчивающийся на .php, даже если файл не существует на диске. Это распространённая ошибка во многих конфигурациях Nginx, и об этом говорится в документе «Ловушки и распространенные ошибки», созданном Nginx.

XSS возможен, если PHP-скрипт попытается определить базовый URL на основе SCRIPT_NAME;

<?php

if(basename($_SERVER['SCRIPT_NAME']) ==
basename($_SERVER['SCRIPT_FILENAME']))
   echo dirname($_SERVER['SCRIPT_NAME']);
?>
GET /index.php/<script>alert(1)</script>/index.php
SCRIPT_NAME  =  /index.php/<script>alert(1)</script>/index.php

Использование $uri может привести к CRLF-инъекции

Другая неправильная конфигурация, связанная с переменными Nginx, заключается в использовании $uri или $document_uri вместо $request_uri.

$uri и $document_uri содержат нормализованный URI, тогда как нормализация в Nginx включает URL-декодирование URI. В блоге Volema рассказывалось, что $uri обычно используется при создании перенаправлений в конфигурации Nginx, что приводит к внедрению CRLF.

Пример уязвимой конфигурации Nginx:

location / {
  return 302 https://example.com$uri;
}

Символами новой строки для HTTP-запросов являются r (возврат каретки) и n (перевод строки). URL-кодирование символов новой строки приводит к следующему представлению символов  %0d%0a. Когда эти символы включены в запрос типа http://localhost/%0d%0aDetectify:%20clrf на сервер с неправильной конфигурацией, сервер ответит новым заголовком с именем Detectify, поскольку переменная $uri содержит новые URL-декодированные строчные символы.

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://example.com/
Detectify: clrf

Произвольные переменные

В некоторых случаях данные, предоставленные пользователем, можно рассматривать как переменную Nginx. Непонятно, почему это происходит, но это встречается не так уж редко, а проверяется довольно-таки сложным путём, как видно из этого отчёта. Если мы поищем сообщение об ошибке, то увидим, что оно находится в модуле фильтра SSI, то есть это связано с SSI.

Одним из способов проверки является установка значения заголовка referer:

$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’

Мы просканировали эту неправильную конфигурацию и обнаружили несколько случаев, когда пользователь мог получить значение переменных Nginx. Количество обнаруженных уязвимых экземпляров уменьшилось, что может указывать на то, что уязвимость исправлена.

Чтение необработанного ответа сервера

С proxy_pass Nginx есть возможность перехватывать ошибки и заголовки HTTP, созданные бэкендом (серверной частью). Это очень полезно, если вы хотите скрыть внутренние сообщения об ошибках и заголовки, чтобы они обрабатывались Nginx. Nginx автоматически предоставит страницу пользовательской ошибки, если серверная часть ответит ей. А что происходит, когда Nginx не понимает, что это HTTP-ответ?

Если клиент отправляет недопустимый HTTP-запрос в Nginx, этот запрос будет перенаправлен на серверную часть как есть, и она ответит своим необработанным содержимым. Тогда Nginx не распознает недопустимый HTTP-ответ и просто отправит его клиенту. Представьте себе приложение uWSGI, подобное этому:

def application(environ, start_response):
   start_response('500 Error', [('Content-Type',
'text/html'),('Secret-Header','secret-info')])
   return [b"Secret info, should not be visible!"]

И со следующими директивами в Nginx:

http {
   error_page 500 /html/error.html;
   proxy_intercept_errors on;
   proxy_hide_header Secret-Header;
}

proxy_intercept_errors будет обслуживать пользовательский ответ, если бэкенд имеет код ответа больше 300. В нашем приложении uWSGI выше мы отправим ошибку 500, которая будет перехвачена Nginx.

proxy_hide_header почти не требует пояснений; он скроет любой указанный HTTP-заголовок от клиента.

Если мы отправим обычный GET-запрос, Nginx вернёт:

HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3
Content-Type: text/html
Content-Length: 34
Connection: close

Но если мы отправим неверный HTTP-запрос, например:

GET /? XTTP/1.1
Host: 127.0.0.1
Connection: close

То получим такой ответ:

XTTP/1.1 500 Error
Content-Type: text/html
Secret-Header: secret-info

Secret info, should not be visible!

merge_slashes отключены

Для директивы merge_slashes по умолчанию установлено значение «on», что является механизмом сжатия двух или более слешей в один, поэтому/// станет /. Если Nginx используется в качестве обратного прокси и проксируемое приложение уязвимо для включения локального файла, использование дополнительных слешей в запросе может оставить место для его использования. Об этом подробно рассказывают Дэнни Робинсон и Ротем Бар.

Мы нашли 33 Nginx-файла, в которых для параметра merge_slashes установлено значение «off».

Попробуйте сами

Мы создали репозиторий GitHub, где вы можете использовать Docker для настройки своего собственного уязвимого тестового сервера Nginx с некоторыми ошибками конфигурации, обсуждаемыми в этой статье, и попробуйте найти их самостоятельно!

Вывод

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

Вторая часть будет позднее.

Что ещё интересного есть в блоге Cloud4Y

→ Пароль как крестраж: ещё один способ защитить свои учётные данные

→ Тим Бернерс-Ли предлагает хранить персональные данные в подах

→ Подготовка шаблона vApp тестовой среды VMware vCenter + ESXi

→ Создание группы доступности AlwaysON на основе кластера Failover

→ Как настроить SSH-Jump Server

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

To start talking about the 500 internal server error Nginx, let’s clarify some terms.

This is a term applicable to a kind of server, characterized by belonging to the open source classification, additionally, Nginx provides the possibility of very low memory consumption, and allow without problems high concurrences, higher than 10,000 simultaneous connections.

500 internal server error, meaning

They are the acronym used to notify irregularities, inconveniences in a server, and that due to these, it is not possible to carry out the requested action.

The errors like this one, are notified according to the browsers in which one works, to the technical variety, to the functional that exists between the servers, since all are different, as far as structure, architecture, and capacities, also to the websites, these count on characteristics that most of the time are not similar, all these considerations are the cause so that the mentioned errors are shown in a variety of ways.

Although all variations convey the existence of a problem, 500 internal server error Nginx will always be understood, as the message displayed is explicit.

In addition, they are complemented through fragments with text with detailed data of what happens with this server, and why it is not possible to execute the action you want to perform, these details, and the way they are displayed vary depending on the type of server, being able to be completely blank screens, others are displayed customized, as the case of some famous sites, YouTube is one of them, Airbnb, and so each brand uses its customization to identify this message differentiating itself from others.

500 internal server error Nginx, what causes it?

Among the situations that originate the appearance of an error of this type, can be cataloged from various sources, there are a variety that occur very frequently, and the chances that these are the origin of the error are usually high.

• Problems that prevent the proper functioning of the browser’s fastest storage layer.
• Corruption problems, this occurs when trying to work with databases.
• Some corrupted file, this occurs when requesting access to the website.
• The server is not able at a given time.
• With the login you try to access, this happens when you use it wrongly.
• Folders and files with attributes different from the ones they have.
• When it is on the PHP side, it happens directly because of trying to make use of a larger memory range than the established one.
• Defective Htacces, these files in these conditions prevent the operation of the site.
• Plugins, if they fail, the following error will appear

500 internal server error Nginx, Solutions for this error

They can appear in the part of the area corresponding to the user, or the part corresponding to the server, the important thing is to attack the problem quickly, so that the damages are minor, these can be some solutions:

Reload the page

You should start with an action that is recommended, and that in many cases is the fastest eliminating the problem, very simple, load the page again, just wait about 50 to 60 seconds, then proceed to the restart to display the page, just press F5, in some sites Ctrl followed by F5, the error will disappear if it was generated by the server not being protected against overload, after the action is done, it will be restored immediately.

Check where the problem is with a third party service

Downforeveryoneorjustme is an alternative to find an efficient way to eliminate this error, just copy the URL of the site where the error occurred, and you will get the information you need, the information you get will let you know which side is the problem, on yours, or if it is the server out of operation.

You can also check CloudFlare service status, as this very famous Cloud provider is protecting and redirecting most of the Internet traffic, as they act as a security layer between visitors browsers, like yourself experiencing this 500 Internal Server Error and the Web server to which you’ve requested a webpage.

If CloudFlare is actually not working and is experiencing a service issue, it will most likely be reflected by this issue on your browser — all you can do, is request a website that isn’t using CloudFlare, or, if it is your website, you can temporarily bypass CloudFlare with your own server configuration, however you will be exposed to security issues.

Clear cache

A 500 internal server error, can also be solved by eliminating the information that is in the Cache of the browser on which you are working, and additionally in your CDN cache if you are using one – if not, starting using a CDN caching solution would probably spare you from experiencing this issue.

Check server logs

Verification of the Server Logs, there are tools in each host, if you do not find them, there are codes to verify these records.

Increase PHP memory

In the cPanel of the page, you have the alternative of modifying the limit of the PHP memory, increasing the value that you have established.

Deactive plugins

Another option is to deactivate the set of Plugins.

To do it fast, simply change the names of the Plugins folders if you are using  the WordPress   CMS and your website will directly be accessible without any plugin activated.

Change server host

In last resort, if the issue is related to your webserver, it might be a good solution to switch to a better web hosting that will offer better performances and save you the trouble of finding why you are getting this error.

Conclusion: Solve problems

Errors like these can cause many damaging problems, and it is best to act immediately to eliminate them urgently.

Frequently Asked Questions

What does the server error code mean?

The error code indicates internal problems with the server that need to be diagnosed. A malfunction has occurred or the system configuration has been violated. In case of such an error, it is not necessary to immediately write to technical support. You can try to solve this problem yourself.

При разработке веб-сайтов и веб-приложений можно столкнуться с ошибкой 500 internal server error. Сначала она может испугать и ввести в заблуждение, поскольку обычно веб-сервер выдает более конкретные ошибки, в которых указана точная причина проблемы, например, превышено время ожидания, неверный запрос или файл не найден, а тут просто сказано что, обнаружена внутренняя ошибка.

Но не все так страшно и в большинстве случаев проблема вполне решаема и очень быстро. В этой статье мы разберем как исправить ошибку Internal server error в Nginx.

Дословно Internal server error означает внутренняя ошибка сервера. И вызвать её могут несколько проблем. Вот основные из них:

• Ошибки в скрипте на PHP — одна из самых частых причин;
• Превышено время выполнения PHP скрипта или лимит памяти;
• Неправильные права на файлы сайта;
• Неверная конфигурация Nginx.

А теперь рассмотрим каждую из причин более подробно и разберем варианты решения.

1. Ошибка в скрипте PHP

Мы привыкли к тому, что если в PHP скрипте есть ошибки, то сразу же видим их в браузере. Однако на производственных серверах отображение сообщений об ошибках в PHP отключено, чтобы предотвратить распространение информации о конфигурации сервера для посторонних. Nginx не может отобразить реальную причину ошибки, потому что не знает что за ошибка произошла, а поэтому выдает универсальное сообщение 500 internal server error.

Чтобы исправить эту ошибку, нужно сначала понять где именно проблема. Вы можете включить отображение ошибок в конфигурационном файле php изменив значение строки display_errors с off на on. Рассмотрим на примере Ubuntu и PHP 7.2:

vi /etc/php/7.2/php.ini

display_errors = On

Перезапустите php-fpm:

sudo systemctl restart php-fpm

Затем обновите страницу и вы увидите сообщение об ошибке, из-за которого возникла проблема. Далее его можно исправить и отключить отображение ошибок, тогда все будет работать. Ещё можно посмотреть сообщения об ошибках PHP в логе ошибок Nginx. Обычно он находится по пути /var/log/nginx/error.log, но для виртуальных доменов может настраиваться отдельно. Например, смотрим последние 100 строк в логе:

tail -n 100 -f /var/log/nginx/error.log

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

2. Превышено время выполнения или лимит памяти

Это продолжение предыдущего пункта, так тоже относится к ошибкам PHP, но так, как проблема встречается довольно часто я решил вынести её в отдельный пункт. В файле php.ini установлены ограничения на время выполнения скрипта и количество оперативной памяти, которую он может потребить. Если скрипт потребляет больше, интерпретатор PHP его убивает и возвращает сообщение об ошибке.

Также подобная ошибка может возникать, если на сервере закончилась свободная оперативная память.

Если же отображение ошибок отключено, мы получаем error 500. Обратите внимание, что если время ожидания было ограничено в конфигурационном файле Nginx, то вы получите ошибку 504, а не HTTP ERROR 500, так что проблема именно в php.ini.

Чтобы решить проблему увеличьте значения параметров max_execution_time и memory_limit в php.ini:

sudo vi /etc/php/7.2/php.ini

max_execution_time 300
memory_limit 512M

Также проблема может быть вызвана превышением других лимитов установленных для скрипта php. Смотрите ошибки php, как описано в первом пункте. После внесения изменений в файл перезапустите php-fpm:

sudo systemctl restart php-fpm

3. Неверные права на файлы

Такая ошибка может возникать, если права на файлы, к которым обращается Nginx установлены на правильно. Сервисы Nginx и php-fpm должны быть запущены от имени одного и того же пользователя, а все файлы сайтов должны принадлежать этому же пользователю. Посмотреть от имени какого пользователя запущен Nginx можно командой:

nginx -T | grep user

Чтобы узнать от какого пользователя запущен php-fpm посмотрите содержимое конфигурационного файла используемого пула, например www.conf:

sudo vi /etc/php-fpm.d/www.conf

В моем случае это пользователь nginx. Теперь надо убедится, что файлы сайта, к которым вы пытаетесь обратиться принадлежат именно этому пользователю. Для этого используйте команду namei:

namei -l /var/www/site

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

sudo chown nginx:nginx -R /var/www/site

Этой командой мы меняем владельца и группу всех файлов в папке на nginx:nginx. Добавить права на чтение для всех пользователей для каталога можно командой chmod. Например:

sudo chmod o+r /var/www/

Далее все должно работать. Также, проблемы с правами может вызывать SELinux. Настройте его правильно или отключите:

setenforce 0

Выводы

В этой статье мы разобрали что делать если на вашем сайте встретилась ошибка 500 internal server error nginx. Как видите проблема вполне решаема и в большинстве случаев вам помогут действия описанные в статье. А если не помогут, напишите свое решение в комментариях!

How To Fix – “HTTP 500 Server Error” When Setting DEBUG = False in Django on AzureAWS ?

How To Fix – “HTTP 500 Server Error” When Setting DEBUG = False in Django on AzureAWS ?

In this post, we will see How To Fix – “HTTP 500 Server Error” When Setting DEBUG = False in Django. How the error might look like in the terminal or application. You might also find this error when you upgrade your Django version and start working with the newer version.

Coming to the error, it so happens that when you use DEBUG=TRUE, you get no error. But when you set DEBUG=FALSE, you get the error.

Let’s do some primitive checks.

Primitive Checks :

• Is the error happening at all the urls routes (apps) of your site ?
• Is the admin url working ?
• Are all your Static files in place ?

Once you are done with the Primitive Checks, you can proceed ahead with the more specific checks.

Check 1:

Some static files might also cause this problem when Debug was set to False.

The server might not be able to find some of the static files.

If the statics are not collected, in such cases also this error might occur.

• Verify your Static configs in Settings.py file and cross-check if their values are correct.
  • STATIC_URL = ‘/static/’
  • STATICFILES_DIRS =
  • STATIC_ROOT

• Check your Static File configs in Settings.py. Try using below. Sometimes whitenoise is not able to find some static imagesfiles and throws ValueError. Try each of the below one by one and see if that solves the error. But use only one at a time for Setting.py.

• Do a collectstatic when you launch the server.

Check 2:

Have you used ALLOWED_HOSTS in Settings.py ?

ALLOWED_HOSTS is required in Production. This setting is MUST whenever you set DEBUG=False.

Because ALLOWED_HOSTS setting validates the request’s Host header and Safeguards against any kind of host-impacting attacks.

If you don’t use this , SuspiciousOperation is raised. That means when a user performs some operation, that is considered as suspicious from a security perspective e.g. tampering with a session cookie.

And if such a SuspiciousOperation exception reaches the WSGI handler level, then it is logged at the Error level.

Check 3:

Are you using the ADMINS in Settings.py ?

A list of all the people who get code error notifications.

Let’s see some interesting facts first.

First thing first, your Django app can actually send email to the users listed in the ADMINS setting whenever any an internal server error occurs (for HTTP status code of 500 or greater). That way, the ADMINS gets description of the error, complete Python traceback, details about the HTTP request that caused the error, the details of exceptions raised in the request/response cycle etc.

It is advisable to set this up by –

• Specifying EMAIL_HOST , EMAIL_HOST_USER and EMAIL_HOST_PASSWORD, SERVER_EMAIL
• Put the email addresses of the addressees in the ADMINS setting.
• Refer Django settings documentation for complete list of email settings.
• By default, Django will send email from [email protected] – modify the SERVER_EMAIL setting, for setting a different user.

Источник

Ошибка 500 internal server error Nginx

При разработке веб-сайтов и веб-приложений можно столкнуться с ошибкой 500 internal server error. Сначала она может испугать и ввести в заблуждение, поскольку обычно веб-сервер выдает более конкретные ошибки, в которых указана точная причина проблемы, например, превышено время ожидания, неверный запрос или файл не найден, а тут просто сказано что, обнаружена внутренняя ошибка.

Но не все так страшно и в большинстве случаев проблема вполне решаема и очень быстро. В этой статье мы разберем как исправить ошибку Internal server error в Nginx.

Как исправить 500 internal server error Nginx

Дословно Internal server error означает внутренняя ошибка сервера. И вызвать её могут несколько проблем. Вот основные из них:

• Ошибки в скрипте на PHP — одна из самых частых причин;
• Превышено время выполнения PHP скрипта или лимит памяти;
• Неправильные права на файлы сайта;
• Неверная конфигурация Nginx.

А теперь рассмотрим каждую из причин более подробно и разберем варианты решения.

1. Ошибка в скрипте PHP

Мы привыкли к тому, что если в PHP скрипте есть ошибки, то сразу же видим их в браузере. Однако на производственных серверах отображение сообщений об ошибках в PHP отключено, чтобы предотвратить распространение информации о конфигурации сервера для посторонних. Nginx не может отобразить реальную причину ошибки, потому что не знает что за ошибка произошла, а поэтому выдает универсальное сообщение 500 internal server error.

Чтобы исправить эту ошибку, нужно сначала понять где именно проблема. Вы можете включить отображение ошибок в конфигурационном файле php изменив значение строки display_errors с off на on. Рассмотрим на примере Ubuntu и PHP 7.2:

sudo systemctl restart php-fpm

Затем обновите страницу и вы увидите сообщение об ошибке, из-за которого возникла проблема. Далее его можно исправить и отключить отображение ошибок, тогда все будет работать. Ещё можно посмотреть сообщения об ошибках PHP в логе ошибок Nginx. Обычно он находится по пути /var/log/nginx/error.log, но для виртуальных доменов может настраиваться отдельно. Например, смотрим последние 100 строк в логе:

tail -n 100 -f /var/log/nginx/error.log

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

2. Превышено время выполнения или лимит памяти

Это продолжение предыдущего пункта, так тоже относится к ошибкам PHP, но так, как проблема встречается довольно часто я решил вынести её в отдельный пункт. В файле php.ini установлены ограничения на время выполнения скрипта и количество оперативной памяти, которую он может потребить. Если скрипт потребляет больше, интерпретатор PHP его убивает и возвращает сообщение об ошибке.

Также подобная ошибка может возникать, если на сервере закончилась свободная оперативная память.

Если же отображение ошибок отключено, мы получаем error 500. Обратите внимание, что если время ожидания было ограничено в конфигурационном файле Nginx, то вы получите ошибку 504, а не HTTP ERROR 500, так что проблема именно в php.ini.

Чтобы решить проблему увеличьте значения параметров max_execution_time и memory_limit в php.ini:

sudo vi /etc/php/7.2/php.ini

max_execution_time 300
memory_limit 512M

Также проблема может быть вызвана превышением других лимитов установленных для скрипта php. Смотрите ошибки php, как описано в первом пункте. После внесения изменений в файл перезапустите php-fpm:

sudo systemctl restart php-fpm

3. Неверные права на файлы

Такая ошибка может возникать, если права на файлы, к которым обращается Nginx установлены на правильно. Сервисы Nginx и php-fpm должны быть запущены от имени одного и того же пользователя, а все файлы сайтов должны принадлежать этому же пользователю. Посмотреть от имени какого пользователя запущен Nginx можно командой:

nginx -T | grep user

Чтобы узнать от какого пользователя запущен php-fpm посмотрите содержимое конфигурационного файла используемого пула, например www.conf:

sudo vi /etc/php-fpm.d/www.conf

В моем случае это пользователь nginx. Теперь надо убедится, что файлы сайта, к которым вы пытаетесь обратиться принадлежат именно этому пользователю. Для этого используйте команду namei:

namei -l /var/www/site

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

sudo chown nginx:nginx -R /var/www/site

Этой командой мы меняем владельца и группу всех файлов в папке на nginx:nginx. Добавить права на чтение для всех пользователей для каталога можно командой chmod. Например:

sudo chmod o+r /var/www/

Далее все должно работать. Также, проблемы с правами может вызывать SELinux. Настройте его правильно или отключите:

Выводы

В этой статье мы разобрали что делать если на вашем сайте встретилась ошибка 500 internal server error nginx. Как видите проблема вполне решаема и в большинстве случаев вам помогут действия описанные в статье. А если не помогут, напишите свое решение в комментариях!

Похожие записи

Нет похожих записей.

Оцените статью

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.

2 комментария к “Ошибка 500 internal server error Nginx”

Чушь.
1. header(«http/1.1 500 Internal Server Error») ;
И логи не помогут.
2. Если скрипт превышает лимиты, то, вероятнее всего, в коде что-то не так. Бесконечный цикл, например. С ним, кстати, и увеличение этих лимитов не спасёт.

статья однобока. проблема к nginx вряд ли имеет отношение, зря в заголовок вынесено название этого великолепного сервера. nginx может работать, и работает, в связке не только с PHP. а на PHP свет клином не сошёлся. если уж пишете о PHP то и выносите в заголовок PHP, а не nginx.

инициировать такую ошибку можно элементарно. например, отключаем сервис PostgreSQL и вуаля. Welcome home, dear!

Источник

How to Fix 500 Internal Server Error in NGINX

Sometimes NGINX server may give 500 Internal Server Error due to various reasons. In this article we will look at what does 500 Internal Server Error mean in NGINX and how to fix 500 Internal Server Error in NGINX.

What is 500 Internal Server Error in NGINX

NGINX gives 500 Internal Server Error when there is a server-side error that prevents NGINX from returning a proper response. It can be due to many different reasons such as faulty script, missing files referenced by code, inadequate file permissions, etc. NGINX is typically used as a reverse proxy server, so the most common reason for 500 Internal server is an error in one of its web servers like Apache that has encountered an issue and returned a 500 error response to NGINX, which is then returned to client browsers. There are various ways to fix internal server error in NGINX.

How to Fix 500 Internal Server Error in NGINX

Here are the steps to fix 500 Internal Server Error in NGINX on localhost, CPanel, PHP, Ubuntu and other platforms.

1. Hard Refresh

Sometimes you may get 500 internal server error in NGINX because your server is being restarted at that moment, or there are too many requests for web server to handle.

So it doesn’t have enough resources to serve your request.

In such cases, you can simply do a hard refresh of your page to force the browser to get latest web page version and fix 500 internal server error in NGINX. You can do this by pressing

• Windows: Ctrl + F5
• Mac: Apple + R or Cmd + R
• Linux: F5

2. Examine Server Logs

Open your server log in a text editor to analyze the most recent requests. Every server log contains information about requested URLs and response code for each request.

Find out which requests result in 500 internal server error. It may be that only one page, or a few pages give this error while others work fine.

Find out which requests cause 500 internal server error. Once you have identified the problematic URLs, open a browser and request them again to confirm that is indeed the case.

3. Examine Your Script

Next, analyze the script to process the problematic requests. Is it actually present at the right location? Are you referencing it properly, in your URL mapping/routing file?

If your script refers to another file, find out if that file path is correct. If you have referenced any program/function, have you called it correctly?

4. Check File/Folder Permission

This can also be due to improper file/folder permissions. Did you add/modify any file/folder recently?

Typically, files need a 644 permission and folders need a 755 permission. You can use FileZilla (Windows) and Chmod (Linux) to modify file permissions.

You can also look at the permissions of other files & folders in your code and update the same for your files/folders accordingly.

5. Check redirections

If you have incorrectly setup any redirections in web server, it can give 500 internal server error. For example, if you use Apache web server, make sure you have properly configured mod_rewrite module and .htaccess file.

Also use a third-party tool to check the syntax of redirection/URL rewrite rules in your server configuration file.

6. Increase Script Timeout

You may also get 500 internal server error in NGINX if your web server (e.g Apache) is timing out on the request. In such cases, increase your web server (not NGINX) timeout value so that it stays connected to NGINX longer, and returns a proper response.

Hopefully, the above tips will help you fix 500 internal server error in NGINX.

Ubiq makes it easy to visualize data in minutes, and monitor in real-time dashboards. Try it Today!

Источник

🌐 Как исправить распространенные ошибки веб-сервера Nginx

Nginx – очень популярный веб-сервер в наши дни.

В этой статье мы расскажем вам о некоторых распространенных ошибках при работе веб-сервера Nginx и возможных решениях.

Это не полный список.

Если вы все еще не можете устранить ошибку, попробовав предложенные решения, пожалуйста, проверьте логи сервера Nginx в каталоге /var/log/nginx/ и поищите в Google, чтобы отладить проблему.

Unable to connect/Refused to Connect

Если при попытке получить доступ к вашему сайту вы видите следующую ошибку:

Это может быть потому, что:

• Nginx не запущен. Вы можете проверить состояние Nginx с помощью sudo systemctl status nginx. Запустите Nginx с помощью sudo systemctl start nginx. Если Nginx не удается запустить, запустите sudo nginx -t, чтобы выяснить, нет ли ошибок в вашем конфигурационном файле. И проверьте логи (sudo journalctl -eu nginx), чтобы выяснить, почему он не запускается.
• Брандмауэр блокирует порты 80 и 443. Если вы используете брандмауэр UFW на Debian/Ubuntu, выполните sudo ufw allow 80,443/tcp, чтобы открыть TCP порты 80 и 443. Если вы используете Firewalld на RHEL/CentOS/Rocky Linux/AlmaLinux, выполните sudo firewall-cmd –permanent –add-service=, затем sudo systemctl reload firewalld, чтобы открыть TCP порты 80 и 443.
• Fail2ban. Если ваш сервер использует fail2ban для блокировки вредоносных запросов, возможно, fail2ban запретил ваш IP-адрес. Выполните команду sudo journalctl -eu fail2ban, чтобы проверить, не заблокирован ли ваш IP-адрес. Вы можете добавить свой IP-адрес в список fail2ban ignoreip, чтобы он больше не был забанен.
• Nginx не прослушивает нужный сетевой интерфейс. Например, Nginx не прослушивает публичный IP-адрес сервера.

The Connection Has Timed Out

Это может означать, что ваш сервер находится в автономном режиме или Nginx работает неправильно.

Однажды у меня возникла проблема нехватки памяти, из-за чего Nginx не смог запустить рабочие процессы.

Если вы увидите следующее сообщение об ошибке в файле /var/log/nginx/error.log, вашему серверу не хватает памяти:

404 Not Found

404 not found означает, что Nginx не может найти ресурсы, которые запрашивает ваш веб-браузер.

Причина может быть следующей:

• Корневой каталог web не существует на вашем сервере. В Nginx корневой веб-каталог настраивается с помощью директивы root, например, так: root /usr/share/nginx/linuxbabe.com/;. Убедитесь, что файлы вашего сайта (HTML, CSS, JavaScript, PHP) хранятся в правильном каталоге.
• PHP-FPM не запущен. Вы можете проверить статус PHP-FPM с помощью sudo systemctl status php7.4-fpm (Debian/Ubuntu) или sudo systemctl status php-fpm.
• Вы забыли включить директиву try_files $uri /index.php$is_args$args; в конфигурационный файл сервера Nginx. Эта директива необходима для обработки PHP-кода.
• На вашем сервере нет свободного дискового пространства. Попробуйте освободить немного дискового пространства. Вы можете использовать утилиту ncdu (sudo apt install ncdu или sudo dnf install ncdu), чтобы узнать, какие каталоги занимают огромное количество дискового пространства.

403 Forbidden

Эта ошибка означает, что вам не разрешен доступ к ресурсам запроса.

Возможный сценарий включает:

• Администратор сайта блокирует публичный доступ к запрашиваемым ресурсам с помощью белого списка IP-адресов или других методов.
• На сайте может использоваться брандмауэр веб-приложения, например ModSecurity, который обнаружил атаку вторжения, поэтому заблокировал запрос.
  Некоторые веб-приложения могут показывать другое сообщение об ошибке, когда происходит запрет 403. Оно может сказать вам, что “secure connection failed, хотя причина та же.

500 Internal Server Error

Это означает, что в веб-приложении произошла какая-то ошибка.

Это может быть следующее

• Сервер базы данных не работает. Проверьте состояние MySQL/MariaDB с помощью sudo systemctl status mysql. Запустите его с помощью sudo systemctl start mysql. Запустите sudo journalctl -eu mysql, чтобы выяснить, почему он не запускается. Процесс MySQL/MariaDB может быть завершен из-за проблем с нехваткой памяти.
• Вы не настроили Nginx на использование PHP-FPM, поэтому Nginx не знает, как выполнять PHP-код.
• Если ваше веб-приложение имеет встроенный кэш, вы можете попробовать очистить кэш приложения, чтобы исправить эту ошибку.
• Ваше веб-приложение может создавать свой собственный журнал ошибок. Проверьте этот файл журнала, чтобы отладить эту ошибку.
• Возможно, в вашем веб-приложении есть режим отладки. Включите его, и вы увидите более подробные сообщения об ошибках на веб-странице. Например, вы можете включить режим отладки в почтовом сервере хостинг-платформы Modoboa, установив DEBUG = True в файле /srv/modoboa/instance/instance/settings.py.
• PHP-FPM может быть перегружен. Проверьте журнал PHP-FPM (например, /var/log/php7.4-fpm.log). Если вы обнаружили предупреждение [pool www] seems busy (возможно, вам нужно увеличить pm.start_servers, или pm.min/max_spare_servers), вам нужно выделить больше ресурсов для PHP-FPM.
• Иногда перезагрузка PHP-FPM (sudo systemctl reload php7.4-fpm) может исправить ошибку.

Nginx показывает страницу по умолчанию

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

• Вы не использовали реальное доменное имя для директивы server_name в виртуальном хосте Nginx.
• Вы забыли перезагрузить Nginx.

504 Gateway time-out

Это означает, что апстрим, такой как PHP-FPM/MySQL/MariaDB, не может обработать запрос достаточно быстро.

Вы можете попробовать перезапустить PHP-FPM, чтобы временно исправить ошибку, но лучше начать настраивать PHP-FPM/MySQL/MariaDB для более быстрой работы.

Вот конфигурация InnoDB в моем файле /etc/mysql/mariadb.conf.d/50-server.cnf.

Это очень простая настройка производительности.

• InnoDB buffer pool size должен быть не менее половины вашей оперативной памяти. (Для VPS с небольшим объемом оперативной памяти я рекомендую установить размер буферного пула на меньшее значение, например 400M, иначе ваш VPS будет работать без оперативной памяти).
• InnoDB log file size должен составлять 25% от размера буферного пула.
• Установите потоки ввода-вывода для чтения и записи на максимум (64).
• Заставьте MariaDB использовать 3 экземпляра буферного пула InnoDB. Количество экземпляров должно соответствовать количеству ядер процессора в вашей системе.
• После сохранения изменений перезапустите MariaDB.

После сохранения изменений перезапустите MariaDB.

Вы также можете установить более длительное значение тайм-аута в Nginx, чтобы уменьшить вероятность тайм-аута шлюза.

Отредактируйте файл виртуального хоста Nginx и добавьте следующие строки в блок server <…>.

Если вы используете Nginx с PHP-FPM, то установите для параметра fastcgi_read_timeout большее значение, например 300 секунд.

По умолчанию это 60 секунд.

Затем перезагрузите Nginx.

PHP-FPM также имеет максимальное время выполнения для каждого скрипта.

Отредактируйте файл php.ini.

Вы можете увеличить это значение до 300 секунд.

Затем перезапустите PHP-FPM

Размер памяти исчерпан

Если вы видите следующую строку в журнале ошибок Nginx, это означает, что PHP достиг лимита памяти в 128 МБ.

Вы можете отредактировать файл php.ini (/etc/php/7.4/fpm/php.ini) и увеличить лимит памяти PHP.

Затем перезапустите PHP7.4-FPM.

Если ошибка все еще существует, скорее всего, в вашем веб-приложении плохой PHP-код, который потребляет много оперативной памяти.

PR_END_OF_FILE_ERROR

1. Вы настроили Nginx на перенаправление HTTP-запросов на HTTPS, но в Nginx нет блока сервера, обслуживающего HTTPS-запросы.
2. Может быть, Nginx не запущен?
3. Иногда основной бинарник Nginx запущен, но рабочий процесс может не работать и завершиться по разным причинам. Для отладки проверьте логи ошибок Nginx (/var/log/nginx/error.log).

Resource temporarily unavailable

Некоторые пользователи могут найти следующую ошибку в файле логов ошибок Nginx (в разделе /var/log/nginx/).

Обычно это означает, что на вашем сайте много посетителей и PHP-FPM не справляется с обработкой огромного количества запросов.

Вы можете изменить количество дочерних процессов PHP-FPM, чтобы он мог обрабатывать больше запросов.

Отредактируйте файл PHP-FPM www.conf.

(Путь к файлу зависит от дистрибутива Linux).

По умолчанию конфигурация дочернего процесса выглядит следующим образом:

Приведенная выше конфигурация означает.

• PHP-FPM динамически создает дочерние процессы. Нет фиксированного количества дочерних процессов.
• Создается не более 5 дочерних процессов.
• При запуске PHP-FPM запускаются 2 дочерних процесса.
• Есть как минимум 1 незанятый процесс.
• Максимум 3 неработающих процесса.

Убедитесь, что у вас достаточно оперативной памяти для запуска дополнительных дочерних процессов.

Сохраните и закройте файл.

Затем перезапустите PHP-FPM. (Возможно, вам потребуется изменить номер версии).

Чтобы следить за состоянием PHP-FPM, вы можете включить страницу status .

Найдите следующую строку в файле PHP-FPM www.conf.

Обратите внимание, что

Уберите точку с запятой, чтобы включить страницу состояния PHP-FPM.

Затем перезапустите PHP-FPM.

Затем отредактируйте файл виртуального хоста Nginx.

Добавьте следующие строки.

Директивы allow и deny используются для ограничения доступа.

Только IP-адреса из “белого списка” могут получить доступ к странице состояния.

Сохраните и закройте файл. Затем протестируйте конфигурацию Nginx.

Если проверка прошла успешно, перезагрузите Nginx, чтобы изменения вступили в силу.

В файле PHP-FPM www.conf дается хорошее объяснение того, что означает каждый параметр.

Если PHP-FPM очень занят и не может обслужить запрос немедленно, он поставит его в очередь.

По умолчанию может быть не более 511 ожидающих запросов, определяемых параметром listen.backlog.

Если вы видите следующее значение на странице состояния PHP-FPM, это означает, что в очереди еще не было ни одного запроса, т.е. ваш PHP-FPM может быстро обрабатывать запросы.

Если в очереди 511 ожидающих запросов, это означает, что ваш PHP-FPM очень загружен, поэтому вам следует увеличить количество дочерних процессов.

Вам также может понадобиться изменить параметр ядра Linux net.core.somaxconn, который определяет максимальное количество соединений, разрешенных к файлу сокетов в Linux, например, к файлу сокетов PHP-FPM Unix.

По умолчанию его значение равно 128 до ядра 5.4 и 4096 начиная с ядра 5.4.

Если у вас сайт с высокой посещаемостью, вы можете использовать большое значение.

Отредактируйте файл /etc/sysctl.conf.

Добавьте следующие две строки.

Сохраните и закройте файл. Затем примените настройки.

Примечание: Если ваш сервер имеет достаточно оперативной памяти, вы можете выделить фиксированное количество дочерних процессов для PHP-FPM, как показано ниже.

Два файла виртуального хоста для одного и того же сайта

Если вы запустите sudo nginx -t и увидите следующее предупреждение.

Это означает, что есть два файла виртуальных хостов, содержащих одну и ту же конфигурацию server_name.

Не создавайте два файла виртуальных хостов для одного сайта.

PHP-FPM Connection reset by peer

В файле логов ошибок Nginx отображается следующее сообщение.

Это может быть вызвано перезапуском PHP-FPM.

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

Утечки сокетов Nginx

Если вы обнаружили следующее сообщение об ошибке в файле /var/log/nginx/error.log, значит, у вашего Nginx проблема с утечкой сокетов.

Вы можете перезапустить ОС, чтобы решить эту проблему.

Если это не помогает, вам нужно скомпилировать отладочную версию Nginx, которая покажет вам отладочную информацию в логах.

Заключение

Надеюсь, эта статья помогла вам исправить распространенные ошибки веб-сервера Nginx.

Источник