Ошибка нгинкс что это

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

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

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

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

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

Содержание

  1. Unable to connect/Refused to Connect
  2. The Connection Has Timed Out
  3. 404 Not Found
  4. 403 Forbidden
  5. 500 Internal Server Error
  6. Nginx показывает страницу по умолчанию
  7. 504 Gateway time-out
  8. Размер памяти исчерпан
  9. PR_END_OF_FILE_ERROR
  10. Resource temporarily unavailable
  11. Два файла виртуального хоста для одного и того же сайта
  12. PHP-FPM Connection reset by peer
  13. Утечки сокетов Nginx
  14. Заключение

Unable to connect/Refused to Connect

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

Firefox can’t establish a connection to the server at www.example.com

или

www.example.com refused to connect

или

The site can't be reached, www.example.com unexpectedly closed the connection.

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

  • 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={http,https}, затем 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, вашему серверу не хватает памяти:

fork() failed while spawning "worker process" (12: Cannot allocate memory)

404 Not Found

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

🌐 Как создать пользовательскую страницу ошибки 404 в 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 = 1024M
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_load_at_startup  = ON
innodb_log_file_size = 512M
innodb_log_buffer_size = 8M

#Improving disk I/O performance
innodb_file_per_table = 1
innodb_open_files = 400
innodb_io_capacity = 400
innodb_flush_method = O_DIRECT
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_buffer_pool_instances = 3

Где:

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

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

sudo systemctl restart mariadb

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

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

  proxy_connect_timeout       600;
  proxy_send_timeout          600;
  proxy_read_timeout          600;
  send_timeout                600;

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

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

 location ~ .php$ {
     try_files $uri /index.php$is_args$args;
     include snippets/fastcgi-php.conf;
     fastcgi_split_path_info ^(.+.php)(/.+)$;

     fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
     include fastcgi_params;
     fastcgi_read_timeout 300;
 }

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

sudo systemctl reload nginx

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

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

sudo nano /etc/php/7.4/fpm/php.ini

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

max_execution_time = 300

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

sudo systemctl restart php7.4-fpm

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

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

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 57134520 bytes)

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

memory_limit = 512M

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

sudo systemctl restart 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/).

connect() to unix:/run/php/php7.4-fpm.sock failed (11: Resource temporarily unavailable)

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

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

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

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

sudo /etc/php/7.4/fpm/pool.d/www.conf

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

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

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

  • PHP-FPM динамически создает дочерние процессы. Нет фиксированного количества дочерних процессов.
  • Создается не более 5 дочерних процессов.
  • При запуске PHP-FPM запускаются 2 дочерних процесса.
  • Есть как минимум 1 незанятый процесс.
  • Максимум 3 неработающих процесса.
pm = dynamic
pm.max_children = 20
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12

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

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

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

sudo systemctl restart php7.4-fpm

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

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

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

;pm.status_path = /status

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

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

sudo systemctl restart php7.4-fpm

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

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

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

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

location ~ ^/(status|ping)$ {
        allow 127.0.0.1;
        allow your_other_IP_Address;
        deny all;

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_index index.php;
        include fastcgi_params;
        #fastcgi_pass 127.0.0.1:9000;
        fastcgi_pass   unix:/run/php/php7.4-fpm.sock;
}

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

sudo nginx -t

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

sudo systemctl reload nginx

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

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

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

listen.backlog = 511

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

listen queue:         0
max listen queue:     0

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

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

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

$ sysctl net.core.somaxconn
net.core.somaxconn = 128

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

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

sudo nano /etc/sysctl.cnf

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

net.core.somaxconn = 20000
net.core.netdev_max_backlog = 65535

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

sudo sysctl -p

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

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

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

nginx: [warn] conflicting server name "example.com" on [::]:443, ignored
nginx: [warn] conflicting server name "example.com" on 0.0.0.0:443, ignored

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

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

PHP-FPM Connection reset by peer

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

recv() failed (104: Connection reset by peer) while reading response header from upstream

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

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

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

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

2021/09/28 13:27:41 [alert] 321#321: *120606 open socket #16 left in connection 163
2021/09/28 13:27:41 [alert] 321#321: *120629 open socket #34 left in connection 188
2021/09/28 13:27:41 [alert] 321#321: *120622 open socket #9 left in connection 213
2021/09/28 13:27:41 [alert] 321#321: *120628 open socket #25 left in connection 217
2021/09/28 13:27:41 [alert] 321#321: *120605 open socket #15 left in connection 244
2021/09/28 13:27:41 [alert] 321#321: *120614 open socket #41 left in connection 245
2021/09/28 13:27:41 [alert] 321#321: *120631 open socket #24 left in connection 255
2021/09/28 13:27:41 [alert] 321#321: *120616 open socket #23 left in connection 258
2021/09/28 13:27:41 [alert] 321#321: *120615 open socket #42 left in connection 269
2021/09/28 13:27:41 [alert] 321#321: aborting

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

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

Заключение

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

см. также:

  • 🌐 Как контролировать доступ на основе IP-адреса клиента в NGINX
  • 🐉 Настройка http-сервера Kali Linux
  • 🌐 Как парсить логи доступа nginx
  • 🌐 Ограничение скорости определенных URL-адресов с Nginx
  • 🛡️ Как использовать обратный прокси Nginx для ограничения внешних вызовов внутри веб-браузера
  • 🔏 Как настроить Nginx с Let’s Encrypt с помощью ACME на Ubuntu
  • 🌐 Как собрать NGINX с ModSecurity на Ubuntu сервере

Источник

2 декабря, 2022 12:20 пп
107 views
| Комментариев нет

LEMP Stack

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

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

Проверка лога ошибок Nginx

В этом мануале мы рассмотрим самые распространенные ошибки и способы их устранения. Синтаксические ошибки нарушают структуру, которую Nginx распознает как допустимую. Часто одна ошибка переходит в другую и становится причиной более серьезной или отдельной проблемы. Поэтому конкретные обстоятельства и настройки в реальной среде могут отличаться от тех, что приведены в данном мануале.

Помните, что вы всегда можете обратиться к логу ошибок Nginx, чтобы просмотреть текущий список:

sudo cat /var/log/nginx/error.log

В этом мануале позже будет рассказано, как разобрать и понять сообщения об ошибках Nginx.

Проверка файла конфигурации на наличие ошибок

Давайте посмотрим на пример domain block в Nginx с разными ошибками в файле конфигурации. Эти ошибки сделаны намеренно, чтобы показать вам, как их можно исправить. Чтобы проверить, есть ли в настройке какие-либо синтаксические ошибки, запустите следующую команду:

sudo nginx -t

Если ошибок нет, вывод будет следующим:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

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

Выявление структурных синтаксических ошибок

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

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

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

Ошибка Invalid parameter

Файл конфигурации Nginx очень требователен к структуре и синтаксису. Одна из самых частых проблем с синтаксисом связана с точкой с запятой. Например, рассмотрим такое сообщение об ошибке:

[emerg] invalid parameter "root" in /etc/nginx/sites-enabled/your_domain:5
nginx: configuration file /etc/nginx/nginx.conf test failed

Прежде чем решать эту проблему, нужно понять сообщение об ошибке Nginx. В нем есть подсказки, которые помогают определить причину ошибки. В этом случае [emerg] означает “emergency” — это связано с нестабильностью системы. Значит, Nginx столкнулся с проблемой, которая не позволяет ему работать.

Это сообщение об ошибке дополнительно указывает место, где обнаружена ошибка. Имейте в виду, что в настройках Nginx у вас будет свой файл конфигурации, связанный симликом с /etc/nginx/nginx.conf. Если вы следовали мануалу Установка Nginx в Ubuntu 20.04, то в пункте 5 вы видели, как это делается. Указана точная строка в конфигурационном файле с ошибкой: /etc/nginx/sites-enabled/your_domain:5. Также в этом файле есть invalid parameter “root”.

Теперь, когда у вас есть информация, где искать ошибку, вы можете открыть файл в любом текстовом редакторе. Мы будем работать с nano:

sudo nano /etc/nginx/sites-available/your_domain

Примечание: Все конфигурационные файлы можно найти в каталоге /etc/nginx/. 

Внутри файла найдите строку 5, на которую ссылается сообщение об ошибке:

server {
        listen 80;
        listen [::]:80;

       root /var/www/your_domain/html
        index index.html index.htm index.nginx-debian.html;

        server_name your_domain www.your_domain;

        location / {
                try_files $uri $uri/ =404;
        }
}

Ошибка может быть не совсем очевидна. Напоминаем, из сообщения об ошибке следует, что проблема заключается в invalid parameter. Параметры — это аргументы, которые предоставляются директивам Nginx. В этом сценарии /var/www/your_domain/html – и есть это недействительный параметр. Он не работает потому, что в синтаксической структуре отсутствует символ, в данном случае – точка с запятой в конце строки.

Многие строки в этом файле также заканчиваются точкой с запятой. Точка с запятой должна стоять в конце каждой строки, которая содержит директиву. В этом примере у нас присутствует директива root, которая указывает на root каталог, который будет использоваться при поиске файла. Наличие root необходимо для того, чтобы Nginx мог найти определенный URL. Разберем важность директив в следующем разделе.

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

…

       root /var/www/your_domain/html;
        index index.html index.htm index.nginx-debian.html;

…

После исправления сохраните и закройте файл. 

Чтобы убедиться, что синтаксическая ошибка исправлена, выполните команду sudo nginx -t.

Неправильно поставленные фигурные скобки

Еще одна распространенная ошибка, которая может возникнуть в синтаксической структуре Nginx, связана с фигурными скобками { }. В отличие от предыдущей ошибки, в которой не было указано, как исправить недопустимый параметр, это сообщение указывает на ее причину:

nginx: [emerg] unexpected "}" in /etc/nginx/sites-enabled/your_domain:15
nginx: configuration file /etc/nginx/nginx.conf test failed

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

server {
        listen 80;
        listen [::]:80;

       root /var/www/your_domain/html;
        index index.html index.htm index.nginx-debian.html;

        server_name your_domain www.your_domain;

        location / {
                try_files $uri $uri/ =404;
       }

Внизу файла вы найдете фигурную скобку }. Сначала суть проблемы может быть непонятна, поскольку фигурная скобка вроде бы присутствует на своем месте. Однако при детальном разборе оказывается, что после этой фигурной скобки не хватает еще одной скобки. Правильное количество фигурных скобок в файле конфигурации Nginx очень важно, поскольку они указывают на открытие и закрытие определенного блока. Фигурная скобка в конце файла является закрывающей скобкой для следующего вложенного блока location:

…

 location / {
                try_files $uri $uri/ =404;
       }

…

Если просмотреть файл конфигурации еще дальше, то окажется, что в server block также отсутствует закрывающая фигурная скобка. Server block в Nginx важен, поскольку он предоставляет детали конфигурации, необходимые Nginx для определения того, какой виртуальный сервер будет обрабатывать получаемые запросы. Важно отметить, что location blocks вложены в server block, поскольку он имеет приоритет при обработке входящих запросов. Учитывая все это, для завершения server block в конце файла нужно добавить закрывающую фигурную скобку. Теперь содержимое этого файла будет выглядеть следующим образом:

server {
        listen 80;
        listen [::]:80;

        root /var/www/your_domain/html;
        index index.html index.htm index.nginx-debian.html;

        server_name your_domain www.your_domain;

        location / {
                try_files $uri $uri/ =404;
        }
}

После редактирования не забудьте сохранить и закрыть файл. Чтобы убедиться, что синтаксическая ошибка устранена, запустите sudo nginx -t.

Ошибка invalid host

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

Отметим, что в этом сценарии действует директива host, но при недопустимых параметрах любая директива может быть подвержена этой ошибке. Соответственно, изменится и сообщение об ошибке:

[emerg] invalid host in "[::]80" of the "listen" directive in /etc/nginx/sites-enabled/your_domain:3
nginx: configuration file /etc/nginx/nginx.conf test failed

Сообщение объясняет, что установленная директива порта 80 недействительна. Сообщение об ошибке дополнительно указывает место обнаружения ошибки и точную строку в файле конфигурации: /etc/nginx/sites-enabled/your_domain:3. Обладая информацией о том, где найти ошибку, можно открыть файл в текстовом редакторе. Найдите строку 3, на которую ссылается сообщение:

server {
        listen 80;
        listen [::]80;

        root /var/www/your_domain/html;
        index index.html index.htm index.nginx-debian.html;

        server_name your_domain www.your_domain;

        location / {
                try_files $uri $uri/ =404;
        }
}

Два двоеточия в скобках представляют собой обозначение IPv6 или 0.0.0.0; без дополнительного двоеточия после скобки он не сможет привязаться к порту 80. В результате директива listen не будет работать, поскольку без двоеточия неясно, какой порт должен прослушивать сервер.

В общем, конкретная синтаксическая ошибка здесь заключается в том, что после скобки [::] не хватает двоеточия, а это делает параметр недействительным. После добавления пропущенного двоеточия, фрагмент кода в файле будет выглядеть следующим образом:

server {
        listen 80;
        listen [::]:80;
…

После обновления этой строки обязательно сохраните и закройте файл и убедитесь, что синтаксическая ошибка исправлена, выполнив команду sudo nginx -t.

В целом, при получении подобных синтаксических ошибок, связанных с параметрами, точками с запятой ; или фигурными скобками { }, рекомендуем обратить особое внимание на точное местоположение и детали в сообщении [emerg].

Выявление неправильных директив – ключевые слова в конфигурационном файле Nginx

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

Ошибка unknown directive

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

nginx: [emerg] unknown directive "serve_name" in /etc/nginx/sites-enabled/your_domain:8
nginx: configuration file /etc/nginx/nginx.conf test failed

Эта ошибка указывает на unknown directive “serve_name” в строке 8 файла конфигурации. Откройте файл с помощью текстового редактора:

server {
        listen 80;
        listen [::]:80;

        root /var/www/your_domain/html;
        index index.html index.htm index.nginx-debian.html;

        serve_name your_domain www.your_domain;

        location / {
                try_files $uri $uri/ =404;
        }
}

В данном примере ошибка — это неправильно написанное слово “server” в имени директивы server_name. В нем пропущена буква “r” и по этой причине директива не распознается. Это серьезная ошибка, поскольку в директиве server_name хранятся конкретные названия серверов, к которым будет обращаться server block при получении запроса. Без корректной работы этой директивы запрос не будет выполнен. Казалось бы, незначительная опечатка, но она нарушает синтаксис и вызывает ошибку. Обновите фрагмент кода в файле конфигурации следующим образом:

…

        server_name your_domain www.your_domain;

…

Сохраните и закройте файл. Проверьте его с помощью команды sudo nginx -t.

Ошибка directive is not allowed here

Теперь предположим, что возникла ошибка с той же директивой, но на этот раз сообщение выглядит так:

nginx: [emerg] "server" directive is not allowed here in /etc/nginx/sites-enabled/your_domain:8
nginx: configuration file /etc/nginx/nginx.conf test failed

Ошибка возникает в том же месте, что и предыдущая, причина проблемы подробно описана в этом сообщении. Поэтому важно понимать, на что указывает сообщение об ошибке. Эта ошибка указывает, что directive is not allowed here. Откройте файл конфигурации в текстовом редакторе:

server {
        listen 80;
        listen [::]:80;

        root /var/www/your_domain/html;
        index index.html index.htm index.nginx-debian.html;

        server name your_domain www.your_domain;

        location / {
                try_files $uri $uri/ =404;
        }
}

Здесь слово “server” написано правильно, но теперь тут отсутствует символ подчеркивания. Поэтому server воспринимается как дубликат, что недопустимо, о чем и говорит сообщение об ошибке. Это связано с различием между простыми и блочными директивами, о котором мы говорили ранее.

Эта ошибка связана с тем, что без подчеркивания server name читается просто как server и таким образом конфликтует с первой директивой server block в начале файла. Это сложная синтаксическая ошибка, которая может возникнуть из-за иерархической структуры Nginx в файле конфигурации среди блочных директив и вложенных простых директив. Исправить эту ошибку можно, добавив знак подчеркивания:

…

        server_name your_domain www.your_domain;

…

После внесения исправлений сохраните и закройте файл. Затем проверьте правильность синтаксиса с помощью команды sudo nginx -t. Если в файле конфигурации нет ошибок, должно появиться сообщение syntax is ok.

Примечание: В конфигурационных файлах Nginx есть определенная гибкость в отношении интервалов или разделения строк, что не приведет к возникновению ошибок. Однако все, что явно связано с директивами, приведет к ошибке, поскольку для правильной работы необходимы точная формулировка или синтаксическая структура.

Последнее, что нужно рассказать: если файл конфигурации содержит несколько ошибок, сообщения об ошибках будут появляться по одному в последовательном порядке. Это означает, что если вы получили сообщение об одной ошибке и исправили ее, а затем снова запустили команду проверки синтаксиса, то в выводе появится следующая ошибка (если таковая встречается в файле). Так будет продолжаться, пока все ошибки не будут исправлены.

Здесь вы узнали о самых распространенных синтаксических ошибках, которые могут возникнуть с определенными директивами в файле конфигурации веб-сервера. Важно отметить, что все эти примеры представлены в среде терминала. Вы также можете использовать редактор кода, например Visual Studio Code, который может проверять и выделять ошибки в коде, не отправляя многочисленных уведомлений, что позволит исправить их все сразу или даже избежать их на ранней стадии.

Читайте также: Установка командной строки Visual Studio Code

Подводим итоги

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

Читайте также: Структура и контексты конфигурационного файла Nginx

Tags: NGINX

Источник

«403 Forbidden» — наиболее распространенная ошибка при работе с NGINX. В этой статье мы расскажем о причинах возникновения 403 forbidden NGINX, а также о том, как найти ее причину и исправить основную проблему.

  • Об ошибке
  • Поиск файла конфигурации NGINX
  • Некорректный индексный файл
  • Автоиндекс
  • Права доступа к файлам
  • Идентификация пользователя NGINX
  • Установите права собственности на файл
  • Установите права доступа

«403 Forbidden» — это универсальная ошибка NGINX, которая указывает на то, что вы запросили что-то, а NGINX (по ряду причин) не может это предоставить. «403» является кодом состояния HTTP, который означает, что веб-сервер получил и понял ваш запрос, но не может предпринять никаких дальнейших действий.

По умолчанию файлы конфигурации NGINX находятся в папке /etc/nginx. Если вы просмотрите этот каталог, то найдете несколько конфигурационных файлов для различных модулей сервера.

Главный файл конфигурации — /etc/nginx/nginx.conf. Он содержит основные директивы для NGINX и является аналогом файла httpd.conf для Apache.

Чтобы отредактировать этот файл, используйте команду:

CentOS 7: sudo nano /etc/nginx/conf.d/test.example.com.conf
Ubuntu 16.04: sudo nano /etc/nginx/sites-available/test.example.com.conf

Одна из наиболее распространенных причин ошибки 403 forbidden NGINX — некорректная настройка индексного файла.
nginx.conf указывает, какие индексные файлы должны загружаться, и в каком порядке. Например, приведенная ниже строка указывает NGINX искать index.html, затем index.htm, затем index.php:

index index.html index.htm index.php;

Если ни один из этих трех файлов не будет найден в каталоге, NGINX вернет ошибку «403 Forbidden».

Примечание. Имена файлов чувствительны к регистру. Если nginx.conf указывает index.html, а файл называется Index.html, это приведет к ошибке «403 Forbidden».

Если вы хотите использовать имя индексного файла, которое ваш веб-сервер NGINX не распознает, отредактируйте nginx.conf и добавьте имя файла в строку конфигурации индекса.

Например, чтобы добавить index.py в список распознаваемых индексных файлов, отредактируйте эту строку следующим образом:

index index.html index.htm index.php index.py;

Сохраните изменения, а затем перезапустите NGINX командой:

Альтернативным решением является разрешение индекса директории. Индекс директории означает, что если индексный файл не найден, сервер отобразит все содержимое директории.

По соображениям безопасности индекс директории в NGINX по умолчанию отключен.

При «403 forbidden NGINX», если вы хотите показать индекс директории в ситуациях, когда NGINX не может найти (идентифицировать) файл, отредактируйте nginx.conf, как описано выше, и добавьте в него две следующие директивы:

Autoindex on;
Autoindex_exact_size off;

Эти директивы должны быть добавлены в блок location. Можно либо добавить их в существующий блок location/, либо добавить новый. Окончательный результат должен выглядеть так:

location / {
  [pre-existing configurations, if applicable]
  autoindex on;
  autoindex_exact_size off;
  }

Также можно активировать индексирование директории в определенной папке, если не хотите, чтобы она была доступна для всего сайта:

location /myfiles {
  autoindex on;
  autoindex_exact_size off;
  }

Сохраните изменения в файле, затем перезапустите NGINX командой:

Некорректные права доступа к файлам являются еще одной причиной ошибки «403 Forbidden NGINX». Для использования с NGINX рекомендуется стандартная настройка: для каталогов — 755 и для файлов — 644. Пользователь NGINX также должен быть владельцем файлов.

Для начала нужно определить, от имени какого пользователя запущен NGINX. Для этого используйте команду:

В этом примере рабочий процесс NGINX работает от имени пользователя nginx.

Перейдите на уровень выше корневой директории документа сайта. Например, если корневая директория вашего сайта /usr/share/nginx/example.com, перейдите в /usr/share/nginx с помощью команды:

Измените права собственности на все файлы в директориях нижних уровней на пользователя nginx с помощью команды:

sudo chown -R nginx:nginx *

403 forbidden NGINX — как исправить: установите права доступа для каждой директории на 755 с помощью команды:

sudo chmod 755 [имя директории]

Например, чтобы установить права доступа для директории example.com, используется команда:

sudo chmod 755 example.com

Затем перейдите в корневой каталог веб-документа:

sudo chmod 755 example.com

Измените права доступа для всех файлов в этой директории с помощью команды:

Источник

И рядовые пользователи, и веб-мастера зачастую сталкиваются с проблемой доступа к отдельным страницам или даже целым сайтам в Интернете. При этом вместо запрашиваемого ресурса в веб-браузере выдается сбой 403 Forbidden Nginx. Что это за ошибка и как ее исправить, читайте далее. В статье мы предложим решения и для обычных юзеров, и для администраторов сайтов.

Что значит 403 Forbidden Nginx?

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

403 forbidden nginx

Но вот само сообщение в прямом смысле не указывает на ошибку. Дело в том, что 403 Forbidden Nginx – это обычный статус-код состояния ресурса. Наиболее часто такое предупреждение выдается в системах Ubuntu, но и в Windows его появление тоже можно встретить.

Причины появления сбоя у пользователей и веб-мастеров

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

В случае с рядовыми юзерами называются следующие причины:

  • нарушения в работе самого интернет-ресурса;
  • ввод некорректного адреса сайта;
  • блокирование ресурса (например, согласно директивам Роскомнадзора);
  • блокирование пользователя или IP его компьютера в связи с нарушениями правил сайта (бан);
  • ошибки браузера (куки, кэш и т. д.).

ошибка 403 forbidden nginx

Для администраторской группы причины появления предупреждения 403 Forbidden Nginx выглядят несколько иначе:

  • использование некорректного имени или поврежденного файла главной страницы index;
  • открытие директории, для которой параметр Autoindex имеет активное значение Off;
  • отсутствие корректных прав на папку;
  • неправильно указанный путь к файлу;
  • ошибка обновления DNS-кэша при смене хостинга;
  • запрет на просмотр содержимого в файле .htaccess или в общей конфигурации сервера.

При таком положении дел для обеих групп можно использовать несколько унифицированных решений по исправлению ситуации.

Ошибка 403 Forbidden Nginx: как исправить пользователю?

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

  • проверьте правильность написания адреса ресурса, чтобы в нем не было заглавных букв и символов на кириллице;
  • произведите очистку файлов cookie и кэша веб-браузера;
  • попробуйте использовать другой браузер;
  • убедитесь, что вы не забанены на сайте;
  • попробуйте использовать доступ с применением утилит для сокрытия своего внешнего IP (Free Hide IP);
  • свяжитесь с администрацией ресурса и уточните проблему его работоспособности;
  • подождите некоторое время и повторите попытку доступа, если проблема состоит в функциональности интернет-ресурса.

Некоторые советы по исправлению для веб-мастеров

что значит 403 forbidden nginx

Для устранения сбоя 403 Forbidden Nginx администраторам пригодятся следующие советы:

  • проверьте правильность задания имени индексных файлов index.html, index.htm, index.php, index.shtml и т. д., чтобы в них не было заглавных литер или кириллических символов;
  • установите права доступ на папку 755, на файлы – 644;
  • проверьте корректность заданных путей к файлам и каталогам;
  • выдержите паузу примерно в течение суток, если проблема состоит в том, что кэш DNS не успел обновиться;
  • добавьте в файл .htaccess строчку Options +Indexes;
  • если корневой каталог имеет название Home, переименуйте страницу согласно стандартам и в файле .htaccess пропишите строку DirectoryIndex home.php.

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

С юзерами все просто, а вот администраторам в некоторых случаях придется, что называется, попотеть.

Источник

Unable to connect/Refused to Connect

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

Firefox can’t establish a connection to the server at www.example.com

или

www.example.com refused to connect

или

The site can’t be reached, www.example.com unexpectedly closed the connection.

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

  • 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={http,https}, затем 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, ваше­му сер­ве­ру не хва­та­ет памяти:

fork() failed while spawning «worker process» (12: Cannot allocate memory)

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 = 1024M

innodb_buffer_pool_dump_at_shutdown = ON

innodb_buffer_pool_load_at_startup  = ON

innodb_log_file_size = 512M

innodb_log_buffer_size = 8M

#Improving disk I/O performance

innodb_file_per_table = 1

innodb_open_files = 400

innodb_io_capacity = 400

innodb_flush_method = O_DIRECT

innodb_read_io_threads = 64

innodb_write_io_threads = 64

innodb_buffer_pool_instances = 3

Где:

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

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

sudo systemctl restart mariadb

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

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

  proxy_connect_timeout       600;

  proxy_send_timeout          600;

  proxy_read_timeout          600;

  send_timeout                600;

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

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

location ~ .php$ {

     try_files $uri /index.php$is_args$args;

     include snippets/fastcgi-php.conf;

     fastcgi_split_path_info ^(.+.php)(/.+)$;

     fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;

     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

     include fastcgi_params;

     fastcgi_read_timeout 300;

}

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

sudo systemctl reload nginx

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

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

sudo nano /etc/php/7.4/fpm/php.ini

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

max_execution_time = 300

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

sudo systemctl restart php7.4-fpm

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

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

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 57134520 bytes)

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

memory_limit = 512M

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

sudo systemctl restart 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/).

connect() to unix:/run/php/php7.4-fpm.sock failed (11: Resource temporarily unavailable)

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

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

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

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

sudo /etc/php/7.4/fpm/pool.d/www.conf

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

pm = dynamic

pm.max_children = 5

pm.start_servers = 2

pm.min_spare_servers = 1

pm.max_spare_servers = 3

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

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

pm = dynamic

pm.max_children = 20

pm.start_servers = 8

pm.min_spare_servers = 4

pm.max_spare_servers = 12

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

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

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

sudo systemctl restart php7.4-fpm

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

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

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

;pm.status_path = /status

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

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

sudo systemctl restart php7.4-fpm

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

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

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

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

location ~ ^/(status|ping)$ {

        allow 127.0.0.1;

        allow your_other_IP_Address;

        deny all;

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        fastcgi_index index.php;

        include fastcgi_params;

        #fastcgi_pass 127.0.0.1:9000;

        fastcgi_pass   unix:/run/php/php7.4-fpm.sock;

}

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

sudo nginx -t

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

sudo systemctl reload nginx

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

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

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

listen.backlog = 511

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

listen queue: 0
max listen queue: 0

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

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

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

$ sysctl net.core.somaxconn
net.core.somaxconn = 128

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

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

sudo nano /etc/sysctl.cnf

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

net.core.somaxconn = 20000
net.core.netdev_max_backlog = 65535

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

sudo sysctl -p

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

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

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

nginx: [warn] conflicting server name «example.com» on [::]:443, ignored

nginx: [warn] conflicting server name «example.com» on 0.0.0.0:443, ignored

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

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

PHP-FPM Connection reset by peer

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

recv() failed (104: Connection reset by peer) while reading response header from upstream

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

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

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

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

2021/09/28 13:27:41 [alert] 321#321: *120606 open socket #16 left in connection 163

2021/09/28 13:27:41 [alert] 321#321: *120629 open socket #34 left in connection 188

2021/09/28 13:27:41 [alert] 321#321: *120622 open socket #9 left in connection 213

2021/09/28 13:27:41 [alert] 321#321: *120628 open socket #25 left in connection 217

2021/09/28 13:27:41 [alert] 321#321: *120605 open socket #15 left in connection 244

2021/09/28 13:27:41 [alert] 321#321: *120614 open socket #41 left in connection 245

2021/09/28 13:27:41 [alert] 321#321: *120631 open socket #24 left in connection 255

2021/09/28 13:27:41 [alert] 321#321: *120616 open socket #23 left in connection 258

2021/09/28 13:27:41 [alert] 321#321: *120615 open socket #42 left in connection 269

2021/09/28 13:27:41 [alert] 321#321: aborting

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

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

Источник

  • Что такое nginx

  • Как используется и работает nginx

  • Как проверить, установлен ли NGINX

  • Как установить NGINX

  • Где расположен nginx

  • Как правильно составить правила nginx.conf

  • NGINX WordPress Multisite

  • Как заблокировать по IP в NGINX

  • Как в NGINX указать размер и время

  • Настройка отладки в NGINX

  • Добавление модулей NGINX в Linux (Debian/CentOS/Ubuntu)

  • Основные ошибки nginx и их устранение

  • 502 Bad Gateway

  • 504 Gateway Time-out

  • Upstream timed out (110: Connection timed out) while reading response header from upstream

  • 413 Request Entity Too Large

  • 304 Not Modified не устанавливается

  • Client intended to send too large body

  • Как перезагрузить nginx

  • В чём разница между reload и restart

  • Как вместо 404 ошибки делать 301 редирект на главную

  • Как в NGINX сделать редирект на мобильную версию сайта

  • Как в NGINX включить поддержку WebP

  • Полезные материалы и ссылки

  • Настройка NGINX под WP Super Cache

  • Конвертер правил .htaccess (Apache) в NGINX

NGINX — программное обеспечение, написанное для UNIX-систем. Основное назначение — самостоятельный HTTP-сервер, или, как его используют чаще, фронтенд для высоконагруженных проектов. Возможно использование NGINX как почтового SMTP/IMAP/POP3-сервера, а также обратного TCP прокси-сервера.

Как используется и работает nginx

NGINX является широко используемым продуктом в мире IT, по популярности уступая лишь Apache.
Как правило, его используют либо как самостоятельный HTTP-сервер, используя в бекенде PHP-FPM, либо в связке с Apache, где NGINX используется во фронтэнде как кеширующий сервер, принимая на себя основную нагрузку, отдавая статику из кеша, обрабатывая и отфильтровывая входящие запросы от клиента и отправляя их дальше к Apache. Apache работает в бекэнде, работая уже с динамической составляющей проекта, собирая страницу для передачи её в кеш NGINX и запрашивающему её клиенту. Это если в общих чертах, чтобы понимать суть работы, так-то внутри всё сложнее.

Как проверить, установлен ли NGINX

Пишете в консоль SSH следующую команду, она покажет версию NGINX

nginx -v

Если видите что-то навроде
nginx version: nginx/1.10.3
Значит, всё в порядке, установлен NGINX версии 1.10.3. Если нет, установим его.

Как установить NGINX

Если вы сидите не под root, предваряйте команды apt-get префиксом sudo, например sudo apt-get install nginx

  1. Обновляем порты (не обязательно) 
    apt-get update && apt-get upgrade
  2. Установка NGINX 
    apt-get install nginx
  3. Проверим, установлен ли NGINX 
    nginx -v

    Команда должна показать версию сервера, что-то подобное:
    nginx version: nginx/1.10.3

Где расположен nginx

Во FreeBSD NGINX располагается в /usr/local/etc/nginx.
В Ubuntu, Debian NGINX располагается тут: /etc/nginx. В ней располагается конфигурационный файл nginx.conf — основной конфигурационный файл nginx.
Чтобы добраться до него, выполняем команду в консоли

nano /etc/nginx/nginx.conf

По умолчанию, файлы конфигураций конкретных сайтов располагаются в /etc/nginx/sites-enabled/

cd /etc/nginx/sites-enabled/

или в /etc/nginx/vhosts/

cd /etc/nginx/vhosts/

Как правильно составить правила nginx.conf

Идём изучать мануалы на официальный сайт.
Пример рабочей конфигурации NGINX в роли кеширующего проксирующего сервера с Apache в бекенде

 # Определяем пользователя, под которым работает nginx
user www-data;

 # Определяем количество рабочих процессов автоматически
 # Параметр auto поддерживается только начиная с версий 1.3.8 и 1.2.5.
worker_processes auto;


 # Определяем, куда писать лог ошибок и уровень логирования
error_log  /var/log/nginx/error.log warn;

 # Задаём файл, в котором будет храниться номер (PID) основного процесса
pid /var/run/nginx.pid;


events {
    # Устанавливает максимальное количество соединений одного рабочего процесса. Следует выбирать значения от 1024 до 4096.
    # Как правило, число устанавливают в зависимости от числа ядер процессора по принципу n * 1024. Например, 2 ядра дадут worker_connections 2048.
    worker_connections  1024;

    # Метод обработки соединений. Наличие того или иного метода определяется платформой.
    # Как правило, NGINX сам умеет определять оптимальный метод, однако, его можно указать явно.
    # use epoll - используется в Linux 2.6+
    # use kqueue - FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 и Mac OS X
    use epoll;


    # Будет принимать максимально возможное количество соединений 
    multi_accept on;
}


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;

    # Для нормального ответа 304 Not Modified;
    if_modified_since before;

    # Включаем поддержку WebP
    map $http_accept $webp_ext {
        default "";
        "~*webp" ".webp";
    }

    ##
    # Basic Settings
    ##
  
    # Используется, если количество имен серверов большое
    #server_names_hash_max_size 1200;
    #server_names_hash_bucket_size 64;


    ### Обработка запросов ###

    # Метод отправки данных sendfile более эффективен, чем стандартный метод read+write 
    sendfile on;
    # Будет отправлять заголовки и и начало файла в одном пакете 
    tcp_nopush on;
    tcp_nodelay on;


    ### Информация о файлах ###

    # Максимальное количество файлов, информация о которых будет содержаться в кеше
    open_file_cache max=200000 inactive=20s;
    # Через какое время информация будет удалена из кеша
    open_file_cache_valid 30s;
    # Кеширование информации о тех файлах, которые были использованы хотя бы 2 раза
    open_file_cache_min_uses 2;
    # Кеширование информации об отсутствующих файлах
    open_file_cache_errors on;


    # Удаляем информацию об nginx в headers
    server_tokens off;

    # Будет ждать 30 секунд перед закрытием keepalive соединения 
    keepalive_timeout 30s;    
    ## Максимальное количество keepalive запросов от одного клиента 
    keepalive_requests 100;

    # Разрешает или запрещает сброс соединений по таймауту 
    reset_timedout_connection on;
    # Будет ждать 30 секунд тело запроса от клиента, после чего сбросит соединение 
    client_body_timeout 30s;
    # В этом случае сервер не будет принимать запросы размером более 200Мб 
    client_max_body_size 200m;
    # Если клиент прекратит чтение ответа, Nginx подождет 30 секунд и сбросит соединение 
    send_timeout 30s;

    # Proxy #
    # Задаёт таймаут для установления соединения с проксированным сервером. 
    # Необходимо иметь в виду, что этот таймаут обычно не может превышать 75 секунд. 
    proxy_connect_timeout 30s;
    # Задаёт таймаут при передаче запроса проксированному серверу. 
    # Таймаут устанавливается не на всю передачу запроса, а только между двумя операциями записи. 
    # Если по истечении этого времени проксируемый сервер не примет новых данных, соединение закрывается. 
    proxy_send_timeout 30s;
    # Задаёт таймаут при чтении ответа проксированного сервера. 
    # Таймаут устанавливается не на всю передачу ответа, а только между двумя операциями чтения. 
    # Если по истечении этого времени проксируемый сервер ничего не передаст, соединение закрывается. 
    proxy_read_timeout 30s;

    
  
    ##
    # Gzip Settings
    ##

    # Включаем сжатие gzip
    gzip on;
    # Для IE6 отключить
    gzip_disable "msie6";
     # Добавляет Vary: Accept-Encoding в Headers
     gzip_vary on;
     # Cжатие для всех проксированных запросов (для работы NGINX+Apache)
     gzip_proxied any;
     # Устанавливает степень сжатия ответа методом gzip. Допустимые значения находятся в диапазоне от 1 до 9
     gzip_comp_level 6;
     # Задаёт число и размер буферов, в которые будет сжиматься ответ
     gzip_buffers 16 8k;
     # Устанавливает минимальную HTTP-версию запроса, необходимую для сжатия ответа. Значение по умолчанию
     gzip_http_version 1.1;
     # MIME-типы файлов в дополнение к text/html, которые нужно сжимать
     gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml;
     # Минимальная длина файла, которую нужно сжимать
     gzip_min_length 10;

  # Подключаем конфиги конкретных сайтов 
  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/vhosts/*/*;

  ### Далее определяем localhost
  ### Сюда отправляются запросы, для которых не был найден свой конкретный блок server в /vhosts/
  server {
     server_name localhost; # Тут можно ввести IP сервера
     disable_symlinks if_not_owner;
     listen 80 default_server; # Указываем, что это сервер по умолчанию на порту 80

     ### Возможно, понадобится чётко указать IP сервера
     # listen      192.168.1.1:80 default_server;

     ### Можно сбрасывать соединения с сервером по умолчанию, а не отправлять запросы в бекенд
     #return      444;

    include /etc/nginx/vhosts-includes/*.conf;
    location @fallback {
       error_log /dev/null crit;
       proxy_pass http://127.0.0.1:8080;
       proxy_redirect http://127.0.0.1:8080 /;
       proxy_set_header Host $host;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       access_log off ;
    }
  }
}

Строка include /etc/nginx/vhosts/*; указывает на поддиректорию vhosts, в которой содержатся файлы конфигураций конкретно под каждый домен.
Пример того, что может содержаться там — example.com.conf
Ниже пример для Apache в бекенде:

server {
  # Домен сайта и его алиасы через пробел
  server_name example.com www.example.com;
  # Кодировка сайта. Содержимое заголовка "Content-Type". off отключает этот заголовок. Можно указать стандартные uft-8, windows-1251, koi8-r, либо же использовать свою.
  charset off;
  disable_symlinks if_not_owner from=$root_path;
  index index.html;
  root $root_path;
  set $root_path /var/www/example/data/www/example.com;
  access_log /var/www/httpd-logs/example.com.access.log ;
  error_log /var/www/httpd-logs/example.com.error.log notice;
  #IP:Port сервера NGINX
  listen 192.168.1.1:80;
  include /etc/nginx/vhosts-includes/*.conf;
  location / {
    location ~ [^/].ph(pd*|tml)$ {
      try_files /does_not_exists @fallback;
    }
    # WebP
    location ~* ^.+.(png|jpe?g)$ {
      expires 365d;
      add_header Vary Accept;
      try_files $uri$webp_ext $uri =404;
    }
    location ~* ^.+.(gif|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
      expires 365d;
      try_files $uri =404;
    }
    location / {
      try_files /does_not_exists @fallback;
    }
  }
  location @fallback {
    proxy_pass http://127.0.0.1:8080;
    proxy_redirect http://127.0.0.1:8080 /;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    access_log off ;
  }
}

А вот вариант для PHP-FPM:

server {
  # Домен сайта и его алиасы через пробел
  server_name example.com www.example.com;
  # Кодировка сайта. Содержимое заголовка "Content-Type". off отключает этот заголовок. Можно указать стандартные uft-8, windows-1251, koi8-r, либо же использовать свою.
  charset off;
  disable_symlinks if_not_owner from=$root_path;
  index index.html;
  root $root_path;
  set $root_path /var/www/example/data/www/example.com;
  access_log /var/www/httpd-logs/example.com.access.log ;
  error_log /var/www/httpd-logs/example.com.error.log notice;
  #IP:Port сервера NGINX
  listen 192.168.1.1:80;
  include /etc/nginx/vhosts-includes/*.conf;
  location / {
    location ~ [^/].ph(pd*|tml)$ {
      try_files /does_not_exists @php;
    }
    # WebP
    location ~* ^.+.(png|jpe?g)$ {
      expires 365d;
      add_header Vary Accept;
      try_files $uri$webp_ext $uri =404;
    }
    location ~* ^.+.(gif|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
      expires 365d;
      try_files $uri =404;
    }
    location / {
      try_files $uri $uri/ @php;
    }
  }
  location @php {
    try_files $uri =404;
    include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f [email protected]";
    # Путь к сокету php-fpm сайта
    fastcgi_pass unix:/var/www/php-fpm/example.sock;
    fastcgi_split_path_info ^((?U).+.ph(?:pd*|tml))(/?.+)$;
  }
}

NGINX WordPress Multisite

Ниже конфигурация под WordPress Multisite с сайтами в поддиректориях:

#user 'example' virtual host 'example.com' configuration file
server {
  server_name example.com www.example.com;
  charset off;
  disable_symlinks if_not_owner from=$root_path;
  index index.html index.php;
  root $root_path;
  set $root_path /var/www/example/data/www/example.com;
  access_log /var/www/httpd-logs/example.com.access.log ;
  error_log /var/www/httpd-logs/example.com.error.log notice;
  listen 1.2.3.4:80;
  include /etc/nginx/vhosts-includes/*.conf;

  # А вот тут блок специально для MU subdirectories
  if (!-e $request_filename) {
      rewrite /wp-admin$ $scheme://$host$uri/ permanent;
      rewrite ^(/[^/]+)?(/wp-.*) $2 last;
      rewrite ^(/[^/]+)?(/.*.php) $2 last;
  }

  location / {
      try_files $uri $uri/ /index.php?$args ;
  }

  location ~ .php {
    try_files $uri =404;
    include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f [email protected]";
    fastcgi_pass unix:/var/www/php-fpm/example.sock;
    fastcgi_split_path_info ^((?U).+.ph(?:pd*|tml))(/?.+)$;
  }
}

Как заблокировать по IP в NGINX

Блокировать можно с помощью директив allow и deny.

Правила обработки таковы, что поиск идёт сверху вниз. Если IP совпадает с одним из правил, поиск прекращается.
Таким образом, вы можете как забанить все IP, кроме своих, так и заблокировать определённый IP:

  deny 1.2.3.4 ; # Здесь мы вводим IP нарушителя
  deny 192.168.1.1/23 ; # А это пример того, как можно добавить подсеть в бан
  deny 2001:0db8::/32 ; # Пример заблокированного IPv6
  allow all ; # Всем остальным разрешаем доступ

Приведу пример конфигурации, как можно закрыть доступ к панели администратора WordPress по IP:

### https://sheensay.ru/?p=408
################################

location = /wp-admin/admin-ajax.php { # Открываем доступ к admin-ajax.php. Это нужно, чтобы проходили ajax запросы в WordPress
  try_files $uri/ @php ;
}
 
location = /adminer.php { # Закрываем Adminer, если он есть
  try_files /does_not_exists @deny ;
}
 
location = /wp-login.php { # Закрываем /wp-login.php
  try_files /does_not_exists @deny ;
}
  
location ~* /wp-admin/.+.php$ { # Закрываем каталог /wp-admin/
  try_files /does_not_exists @deny ;
}
 
 
location @deny { # В этом location мы определяем правила, какие IP пропускать, а какие забанить

  allow 1.2.3.4 ; # Здесь мы вводим свой IP из белого списка
  allow 192.168.1.1/23 ; # А это пример того, как можно добавить подсеть IP
  allow 2001:0db8::/32 ; # Пример IPv6

  deny all ; # Закрываем доступ всем, кто не попал в белый список
 
  try_files /does_not_exists @php; # Отправляем на обработку php в бекенд
}
 
location ~ .php$ { ### Файлы PHP обрабатываем в location @php
    try_files /does_not_exist @php;  
}

location @php{ 
    ### Обработчик php, PHP-FPM или Apache
}

Ещё один неплохой вариант. Правда, по умолчанию определяются только статичные IP. А чтобы разрешить подсеть, придётся использовать дополнительный модуль GEO:

	
### Задаём таблицу соответсткий
map $remote_addr $allowed_ip {

   ### Перечисляете разрешённые IP
   1.2.3.4 1; ### 1.2.3.4 - это разрешённый IP
   4.3.2.1 1; ### 4.3.2.1 - это ещё один разрешённый IP

   default 0; ### По умолчанию, запрещаем доступ
}
 
server {

   ### Объявляем переменную, по которой будем проводить проверку доступа
   set $check '';
 
   ### Если IP не входит в список разрешённых, отмечаем это
   if ( $allowed_ip = 0  ) {
      set $check "A";
   }
 
   ### Если доступ идёт к wp-login.php, отмечаем это
   if ( $request_uri ~ ^/wp-login.php ) {
      set $check "${check}B";
   }

   ### Если совпали правила запрета доступа - отправляем соответствующий заголовок ответа 
   if ( $check = "AB" ) {
      return 444; ### Вместо 444 можно использовать стандартный 403 Forbidden, чтобы отслеживать попытки доступа в логах

   ### Остальные правила server ####
}

Как в NGINX указать размер и время

Размеры:

  • Байты указываются без суффикса. Пример: 
    directio_alignment 512;
  • Килобайты указываются с суффиксом k или K. Пример: 
    client_header_buffer_size 1k;
  • Мегабайты указываются с суффиксом m или M. Пример: 
    client_max_body_size 100M;
  • Гигабайты указываются с суффиксом g или G. Пример: 
    client_max_body_size 1G;

Время задаётся в следующих суффиксах:

  • ms — миллисекунды
  • s — секунды
  • m — минуты
  • h — часы
  • d — дни
  • w — недели
  • M — месяцы, 30 дней
  • Y — годы, 365 дней

В одном значении можно комбинировать различные единицы, указывая их в порядке от более к менее значащим, и по желанию отделяя их пробелами. Например, 1h 30m задаёт то же время, что и 90m или 5400s. Значение без суффикса задаёт секунды.

Рекомендуется всегда указывать суффикс

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

Настройка отладки в NGINX

В целях отладки настройки NGINX вы можете писать данные в логи, но я советую воспользоваться директивой add_header. С её помощью вы можете выводить различные данные в http headers.
Пример, как можно определить, в каком location обрабатывается правило:

  location ~ [^/].ph(pd*|tml)$ {
    try_files /does_not_exists @fallback;
    add_header X-debug-message "This is php" always;
  }

  location ~* ^.+.(jpe?g|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ {
    expires 365d; log_not_found off; access_log off;
    try_files $uri $uri/ @fallback;
    add_header X-debug-message "This is static file" always;
  }

Теперь, если проверить, какие заголовки отдаёт статичный файл, например https://sheensay.ru/wp-content/uploads/2015/06/nginx.png, то вы увидите среди них и наш X-debug-message

Отладочная информация NGINX в заголовках HTTP headers

Отладочная информация NGINX в заголовках HTTP headers

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

Добавление модулей NGINX в Linux (Debian/CentOS/Ubuntu)

Функционал NGINX возможно расширить с помощью модулей. С их списком и возможным функционалом можно ознакомиться на официальном сайте http://nginx.org/ru/docs/. Также, существуют интересные сторонние модули, например, модуль NGINX для защиты от DDoS
Приведу пример установки модуля ngx_headers_more.

Все команды выполняются в консоли, используйте Putty или Far Manager с NetBox/WinSCP. Установка будет происходить под Debian

  1. nginx -V

    В результате увидите что-то навроде

    nginx version: nginx/1.8.0
built by gcc 4.9.1 (Debian 4.9.1-19)
built with OpenSSL 1.0.1k 8 Jan 2015
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/etc/nginx/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/ngin
x/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/p
roxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=ng
inx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-htt
p_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-htt
p_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-securi
ty' --with-ld-opt=-Wl,-z,relro --with-ipv6

    Результат запишем в блокнот, пригодится при компиляции 

  2. wget http://nginx.org/download/nginx-1.8.0.tar.gz
    tar xvf nginx-1.8.0.tar.gz
    rm -rf nginx-1.8.0.tar.gz
    cd nginx-1.8.0

    Тут мы скачиваем нужную версию NGINX. 

  3. wget https://github.com/openresty/headers-more-nginx-module/archive/v0.29.tar.gz
    tar xvf v0.29.tar.gz

    Скачиваем и распаковываем последнюю версию модуля из источника, в моём случае, с GitHub 

  4. aptitude install build-essential

    Установим дополнительные пакеты.
    Если выходит ошибка aptitude: команда не найдена, нужно предварительно установить aptitude:

    apt-get install aptitude
  5. Теперь приступаем к конфигурированию NGINX с модулем headers-more-nginx-module
    Ещё раз запускаем nginx -V и копируем, начиная с —prefix= и до первого —add-module= (все присутствующие в результате —add_module= нам не нужны). После чего пишем в консоли ./configure и вставляем скопированное из редактора:

    ./configure --prefix=/etc/nginx --sbin-path=/etc/nginx/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security' --with-ld-opt=-Wl,-z,relro --with-ipv6 --add-module=./headers-more-nginx-module-0.29

    —add-module={Тут надо добавить путь до распакованного модуля, абсолютный или относительный}

  6. Во время конфигурирования могут возникнуть ошибки
    • Ошибка 
      ./configure: error: the HTTP rewrite module requires the PCRE library.
You can either disable the module by using --without-http_rewrite_module
option, or install the PCRE library into the system, or build the PCRE library
statically from the source with nginx by using --with-pcre=<path> option.

      Эта проблема решается установкой libpcre++-dev:

      aptitude install libpcre++-dev
    • Ошибка 
      ./configure: error: SSL modules require the OpenSSL library.
You can either do not enable the modules, or install the OpenSSL library
into the system, or build the OpenSSL library statically from the source
with nginx by using --with-openssl=<path> option.

      Эта проблема решается так:

      aptitude install libssl-dev
  7. В случае успеха, вы увидите что-то навроде 
    Configuration summary
  + using system PCRE library
  + using system OpenSSL library
  + md5: using OpenSSL library
  + sha1: using OpenSSL library
  + using system zlib library

  nginx path prefix: "/etc/nginx"
  nginx binary file: "/etc/nginx/sbin/nginx"
  nginx configuration prefix: "/etc/nginx"
  nginx configuration file: "/etc/nginx/nginx.conf"
  nginx pid file: "/var/run/nginx.pid"
  nginx error log file: "/var/log/nginx/error.log"
  nginx http access log file: "/var/log/nginx/access.log"
  nginx http client request body temporary files: "/var/cache/nginx/client_temp"
  nginx http proxy temporary files: "/var/cache/nginx/proxy_temp"
  nginx http fastcgi temporary files: "/var/cache/nginx/fastcgi_temp"
  nginx http uwsgi temporary files: "/var/cache/nginx/uwsgi_temp"
  nginx http scgi temporary files: "/var/cache/nginx/scgi_temp"
  8. Пришло время собрать бинарный файл nginx 
    make install clean
  9. Теперь нужно проверить, собрался ли бинарник с нужным модулем. 
    /usr/sbin/nginx -V

    В результате должны увидеть модуль на месте

    nginx version: nginx/1.8.0
built by gcc 4.9.2 (Debian 4.9.2-10)
built with OpenSSL 1.0.1k 8 Jan 2015
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/etc/nginx/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security' --with-ld-opt=-Wl,-z,relro --with-ipv6 --add-module=./headers-more-nginx-module-0.29
  10. Останавливаем nginx 
    service nginx stop
  11. Сделаем бекап текущего бинарника nginx на всякий случай, чтобы откатить его назад при необходимости 
    mv /usr/sbin/nginx /usr/sbin/nginx_back
  12. Свежесобранный бинарник nginx ставим на место старого 
    mv /etc/nginx/sbin/nginx /usr/sbin/nginx
  13. Проверяем, что вышло в итоге, что ничего не перепутано, и нужные модули на месте 
    nginx -V
  14. Запускаем NGINX 
    service nginx start
  15. Подчищаем за собой 
    cd ../
    rm -rf nginx-1.8.0
    rm -rf /etc/nginx/sbin

Основные ошибки nginx и их устранение

502 Bad Gateway

Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Довольно часто эта ошибка появляется, когда NGINX работает в связке с Apache, Varnish, Memcached или иным сервисом, а также обрабатывает запросы PHP-FPM.
Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его) либо, если они находятся на разных серверах, проверить пинг между ними, так как, возможно, отсутствует связь между ними.
Также, для PHP-FPM нужно проверить права доступа к сокету.
Для этого убедитесь, что в /etc/php-fpm.d/www.conf прописаны правильные права

listen = /tmp/php5-fpm.sock 
listen.group = www-data
listen.owner = www-data

504 Gateway Time-out

Ошибка означает, что nginx долгое время не может получить ответ от какого-то сервиса. Такое происходит, если Apache, с которым NGINX работает в связке, отдаёт ответ слишком медленно.
Проблему можно устранить с помощью увеличения времени таймаута.
При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения:

server { 
... 
   send_timeout 800;
   proxy_send_timeout 800;
   proxy_connect_timeout 800;  
   proxy_read_timeout 800;  
... 
}

Тут мы выставили ожидание таймаута в 800 секунд.

Upstream timed out (110: Connection timed out) while reading response header from upstream

Причиной может быть сложная и потому долгая обработка php в работе PHP-FPM.
Здесь тоже можно увеличить время ожидания таймаута

location ~ .php$ { 
   include fastcgi_params;
   fastcgi_index index.php; 
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
   fastcgi_pass unix:/tmp/php5-fpm.sock;  
   fastcgi_read_timeout 800;
}

800 секунд на ожидание ответа от бекенда.

Это лишь временные меры, так как при увеличении нагрузки на сайт ошибка снова станет появляться. Устраните узкие места, оптимизируйте работу скриптов php

413 Request Entity Too Large

Ошибка означает, что вы пытались загрузить слишком большой файл. В настройках nginx по умолчанию стоит ограничение в 1Mb.
Для устранения ошибки в nginx.conf нужно найти строку

client_max_body_size 1m;

и заменить значение на нужное. Например, мы увеличим размер загружаемых файлов до 100Mb

client_max_body_size 100m;

Также, можно отключить проверку размера тела ответа полностью значением ноль:

client_max_body_size 0;

Следует помнить, зачем ввели это ограничение: если любой пользователь может загружать файлы на неподготовленный сайт, можно сравнительно легко провести DDOS-атаку на него, перегружая входной поток большими файлами.

После каждого внесённого изменения в конфигурационный файл необходимо перезагружать nginx

304 Not Modified не устанавливается

Если возникает проблема с правильным отображением ответного заголовка сервера 304 Not Modified, то проблема, скорее всего, в пунктах:

  • В секции server конкретного сайта включен ssi on (Подробнее в документации). По умолчанию, ssi отключен, но некоторые хостеры и ISPManager любят его прописывать в дефолтную конфигурацию сайта включенным. Его нужно обязательно отключить, закомментировав или удалив эту строку;
  • if_modified_since установить в before, то есть на уровне http или конкретного server прописать: if_modified_since before;

Правильность ответа 304 Not Modified можно проверить с помощью:

  • Консоли разработчика браузера (F12) в разделе Network (Cеть) (не забываем перезагружать страницу);
    Как проверить заголовки сервера NGINX
  • Или сторонних сервисов, например last-modified.com.

Client intended to send too large body

Решается с помощью увеличения параметра client_max_body_size 

client_max_body_size 200m;

Как перезагрузить nginx

Для перезагрузки NGINX используйте restart или reload.
Команда в консоли:

service nginx reload

либо

/etc/init.d/nginx reload

либо

nginx -s reload

Эти команды остановят и перезапустят сервер NGINX.

Перезагрузить конфигурационный файл без перезагрузки NGINX можно так:

nginx -s reload

Проверить правильность конфигурации можно командой

nginx -t

В чём разница между reload и restart

Как происходит перезагрузка в NGINX:

  1. Команда посылается серверу
  2. Сервер анализирует конфигурационный файл
  3. Если конфигурация не содержит ошибок, новые процессы открываются с новой конфигурацией сервера, а старые плавно прекращают свою работу
  4. Если конфигурация содержит ошибки, то при использовании
    1. restart процесс перезагрузки сервера прерывается, сервер не запускается
    2. reload сервер откатывается назад к старой конфигурации, работа продолжается

Короче говоря, restart обрывает работу резко, reload делает это плавно.
Restart рекомендуется использовать, только когда внесены глобальные изменения, например, заменено ядро сервера, либо нужно увидеть результат внесённых изменений прямо здесь и сейчас. В остальных случаях используйте reload.

Ещё лучше, если вы будете предварительно проверять правильность конфигурации командой nginx -t, например:

nginx -t && service nginx reload

или

nginx -t && nginx -s reload

Как вместо 404 ошибки делать 301 редирект на главную

error_page 404 = @gotomain;

location @gotomain {
  return 301 /;
}

Как в NGINX сделать редирект на мобильную версию сайта

Данный код вставляется на уровне server в самое начало файла (не обязательно в самое начало, но главное, чтобы перед определением обработчика скриптов php, иначе редирект может не сработать).

### Устанавливаем переменную в 0. В неё пишем 1, если обнаружили мобильную версию браузера
set $mobile_rewrite 0;

if ($http_user_agent ~* "(android|bbd+|meego).+mobile|avantgo|bada/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)/|plucker|pocket|psp|series(4|6)0|symbian|treo|up.(browser|link)|vodafone|wap|windows ce|xda|xiino") {
  set $mobile_rewrite 1;
}

if ($http_user_agent ~* "^(1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw-(n|u)|c55/|capi|ccwa|cdm-|cell|chtm|cldc|cmd-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc-s|devi|dica|dmob|do(c|p)o|ds(12|-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(-|_)|g1 u|g560|gene|gf-5|g-mo|go(.w|od)|gr(ad|un)|haie|hcit|hd-(m|p|t)|hei-|hi(pt|ta)|hp( i|ip)|hs-c|ht(c(-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i-(20|go|ma)|i230|iac( |-|/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |/)|klon|kpt |kwc-|kyo(c|k)|le(no|xi)|lg( g|/(k|l|u)|50|54|-[a-w])|libw|lynx|m1-w|m3ga|m50/|ma(te|ui|xo)|mc(01|21|ca)|m-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|-([1-8]|c))|phil|pire|pl(ay|uc)|pn-2|po(ck|rt|se)|prox|psio|pt-g|qa-a|qc(07|12|21|32|60|-[2-7]|i-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55/|sa(ge|ma|mm|ms|ny|va)|sc(01|h-|oo|p-)|sdk/|se(c(-|0|1)|47|mc|nd|ri)|sgh-|shar|sie(-|m)|sk-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h-|v-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl-|tdg-|tel(i|m)|tim-|t-mo|to(pl|sh)|ts(70|m-|m3|m5)|tx-9|up(.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas-|your|zeto|zte-)") {
  set $mobile_rewrite 1;
}
### Мобильный барузер обнаружен, редиректим на мобильный поддомен, в моём случае, m.example.com
if ($mobile_rewrite = 1) {
    rewrite ^ http://m.example.com/$request_uri redirect;
    break;
}

Как в NGINX включить поддержку WebP

Чтобы включить поддержку WebP, нужно прописать в секции http:

    # Прописываем маппинг для WebP, если он поддерживается браузером
    map $http_accept $webp_ext {
        default "";
        "~*webp" ".webp";
    }

Теперь, в секции server можно использовать:

location ~* ^.+.(png|jpe?g)$ {
    expires 365d; # Включаем браузерный кеш на год для изображений
    add_header Vary Accept; # Даём заголовок, что акцептируем запрос
    try_files $uri$webp_ext $uri =404; # Пробуем сначала искать версию изображения .webp
}

Полезные материалы и ссылки

Настройка NGINX под WP Super Cache

Конвертер правил .htaccess (Apache) в NGINX

Весьма полезный сервис, который поможет cконвертировать правила из .htaccess в NGINX. Результат, возможно, придётся донастроить вручную, но, в целом, он весьма удобен в применении.
Вот как описывают сервис сами авторы:

Сервис предназначен для перевода конфигурационного файла Apache .htaccess в инструкции конфигурационного файла nginx.

В первую очередь, сервис задумывался как переводчик инструкций mod_rewrite с htaccess на nginx. Однако, он позволяет переводить другие инструкции, которые можно и резонно перевести из Apache в nginx.

Инструкции, не относящиеся к настройке сервера (например, php_value), игнорируются.

Переводчик не проверяет правильность входящего конфига, в том числе регулярные выражения и логические ошибки.

Результат перевода следует обязательно проверить вручную, а затем разместить в секции server {} конфигурационного файла nginx.

Замечания и предложения по улучшению ждем, как обычно, на [email protected] ;)

Перейти в конвертер из .htaccess Apache в NGINX

Загрузка…

Источник

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

В этой краткой статье рассматривается типичная ошибка при работе с серверами (403 Forbidden), ее причины и способы ее устранения.

Ошибка Nginx 403 Forbidden – это код состояния, сгенерированный и отображаемый пользователю, когда клиент пытается получить доступ к части веб-сервера с недостаточными разрешениями. Например, NGINX защищает список каталогов и приведет к ошибке 403.

Причины ошибки Nginx 403 на стороне сервера

Прежде чем мы начнем, стоит отметить, что ошибка может исходить от клиента, а не от самого сервера. Сначала мы рассмотрим ошибки на стороне сервера, а затем ошибки на стороне клиента.

Причина 1: неправильный индексный файл

Самая первая и частая причина ошибки NGINX 403 Forbidden – это неправильная конфигурация индексного файла.

Файл конфигурации Nginx указывает, какие индексные файлы загружать и в каком порядке их загружать. Однако, если указанные индексные файлы отсутствуют в каталоге, Nginx вернет ошибку 403 Forbidden.

Например, конфигурация ниже определяет индексные файлы и способ их загрузки.

location / {
index index.html index.htm index.html inde.php;
}

Один из способов решения этой проблемы – добавить индексный файл, указанный в файле конфигурации, или добавить доступный индексный файл в файл конфигурации.

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

location / {
autoindex on;
autoindex_exact_size on;
}

Примечание

Мы не рекомендуем этот метод на общедоступных серверах.

Для получения дополнительной информации о том, как обслуживать статический контент, рассмотрите ресурс документации Nginx, представленный ниже:

https://docs.nginx.com/nginx/admin-guide/web-server/serving-static-content/

Причина 2: неправильно настроенные разрешения

ошибка Nginx 403Forbidden также может возникать из-за неверно установленных разрешений для файлов и каталогов. Чтобы Nginx мог успешно передать клиенту определенный файл и ресурс, Nginx должен иметь разрешения RWX – чтение, запись и выполнение – на всем пути.

Чтобы устранить эту ошибку, измените разрешение каталогов на 755 и разрешение файла на 644. Убедитесь, что пользователь, запускающий процесс Nginx, владеет файлами. Например, установите пользователя на www-data:

sudo chown -R www-data:www-data *

Наконец, установите права доступа к каталогу и файлу как:

sudo chmod 755 {dir}
sudo chmod 644 {files}

Причина ошибки на стороне клиента 403

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

  • Убедитесь, что вы получаете доступ к правильному веб-адресу
  • Очистить кеш браузера
  • Убедитесь, что брандмауэр или прокси-сервер разрешает вам доступ к веб-ресурсу.

Заключение

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Понравилась статья? Поделить с друзьями:
  • Ошибка нбп bmw
  • Ошибка наушники или динамики не подключены windows 10
  • Ошибка настройки шасси ниссан кашкай что это
  • Ошибка настройки шасси на ниссан кашкай j11
  • Ошибка настройки шасси nissan x trail т32