Try nginx plus and nginx app protect

2. Настройка Nginx

Первым делом следует рассмотреть структуру конфигурационного файла. На первый взгляд, тут все может показаться очень запутанным, но там все достаточно логично:

Сначала идут глобальные опции, которые задают основные параметры программы, например, от какого пользователя она будет запущена и количество процессов. Дальше есть секция events, в которой описано как Nginx будет реагировать на входящие подключения, затем идет секция http, которая объединяет все настройки касаемо работы протокола http

В ней находится секция server, каждая такая секция отвечает за отдельный домен, в секции server размещаются секции location, каждая из которых отвечает за определенный URL запроса, обратите внимание, что не файл на сервере, как в Apache, а именно URL запроса

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

  • user — пользователь, от имени которого будет запущен сервер, должен быть владельцем каталога с файлами сайта, и от имени его же нужно запускать php-fpm;
  • worker_processes — количество процессов Nginx, которые будут запущены, нужно установить ровно столько, сколько у вас есть ядер, например, у меня — 4;
  • worker_cpu_affinity — этот параметр позволяет закрепить каждый процесс за отдельным ядром процессора, установите значение auto, чтобы программа сама выбрала что и к чему крепить;
  • worker_rlimit_nofile — максимальное количество файлов, которые может открыть программа, на каждое соединение нужно как минимум два файла и каждый процесс будет иметь указанное вами количество соединений, поэтому формула такая: worker_processes * worker_connections* 2, параметр worker_connections разберем чуть ниже;
  • pcre_jit — включите этот параметр для ускорения обработки регулярных выражений с помощью JIT компиляции;

В секции events стоит настроить два параметра:

worker_connections — количество соединений для одного процесса, должно быть достаточным для обработки входящих соединений. Сначала нам нужно знать сколько этих входящих соединений есть, для этого смотрим статистику по адресу ip_сервера/nginx_status. Как включить рассмотрим ниже. В строке Active Connections видим количество активных соединений с сервером, также нужно учесть что соединения с php-fpm тоже считаются

Дальше обратите внимание на поля accepted и handled, первое отображает обработанных подключений, второе — количество принятых. Из значения должны быть одинаковыми

Если отличаются значит соединений не хватает. Смотрите примеры, первый снимок проблема, второй — порядок. Для моей конфигурации оптимальной может быть цифра в 200 соединений (всего 800, учитывая 4 процесса):

  • multi_accept — позволяет программе принимать несколько соединений одновременно, тоже ускоряет работу, при большом количестве соединений;
  • accept_mutex — установите значение этого параметра в off, чтобы сразу все процессы получали уведомление про новые соединения;

Также в секции events рекомендуется использовать директиву use epoll, так как этот самый эффективный метод обработки входящих соединений для Linux, но этот метод применяется по умолчанию, поэтому не вижу смысла добавлять его вручную. Рассмотрим еще несколько параметров из секции http:

  • sendfile — использовать метод отправки данных sendfile. Самый эффективный метод для Linux.
  • tcp_nodelay, tcp_nopush — отправляет заголовки и тело запроса одним пакетом, работает немного быстрее;
  • keepalive_timeout — таймаут поддержания соединения с клиентом, если у вас нет очень медленных скриптов, то будет достаточно будет 10 секунд, устанавливаем значение сколько нужно чтобы пользователь мог быть подключен к серверу;
  • reset_timedout_connection — разрывать соединения после таймаута.
  • open_file_cache — кэшировать информацию об открытых файлах. Например, open_file_cache max=200000 inactive=120s; max — максимальное количество файлов в кэше, время кэширования.
  • open_file_cache_valid — когда нужно проверить актуальность файлов. Например: open_file_cache_valid 120s;
  • open_file_cache_min_uses — кэшировать только файлы, которые были открыты указанное количество раз;
  • open_file_cache_errors — запоминать ошибки открытия файлов.
  • if_modified_since — устанавливает каким образом будут обрабатываться заголовки if-modified-since. С помощью этого заголовка браузер может получить ответ 304 если страница не изменилась с момента последнего просмотра. Возможны варианты — не отправлять — off, отправлять при точном совпадении времени — exact, отправлять если время совпадает точно или больше — before;

Вот как-то так будет выглядеть настройка nginx conf:

Шаг 5. Настройка nginx

Откройте файл c:\nginx\conf\nginx.conf в любом текстовом редакторе (я рекомендую Notepad++).

1. Измените строку:

worker_processes  1;

Здесь вместо 1 укажите количество рабочих процессов nginx. Рекомендуется указывать число, равное количеству ядер процессора.

2. Уберите символ комментария (решётку) у строки:

error_log  logs/error.log;

Это позволит включить запись логов ошибок в файл error.log, который Вы всегда найдёте в каталоге c:\nginx\logs\.

3. Измените значение директивы server{} для nginx без использования SSL:

server {
 listen 80 default;
 server_name localhost;

 server_tokens off;

 #charset koi8-r;

 #access_log logs/access.log  main;

 location / {
 root c:/nginx/public_html;
 index index.html index.htm index.php;
 }

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

 location ~ /\.ht {
 deny all;
 }

 #error_page 404 /404.html;

 error_page 500 502 503 504 /50x.html;
 location = /50x.html {
 root html;
 }
}

Если Вы хотите использовать SSL, Вам потребуется совсем иной конфиг:

server {
 listen 443 default;
 server_name localhost;

 server_tokens off;

 ssl on;
 ssl_certificate C:/nginx/private/ssl_cert_domain.pem;
 ssl_certificate_key C:/nginx/private/ssl_cert_domain.key;

 ssl_session_timeout 5m;

 ssl_protocols SSLv2 SSLv3 TLSv1;
 ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
 ssl_prefer_server_ciphers on;

 #charset koi8-r;

 #access_log logs/access.log  main;

 location / {
 root c:/nginx/public_html;
 index index.html index.htm index.php;
 }

 location ~ \.php$ {
 fastcgi_pass 127.0.0.1:9000;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 include fastcgi_params;
 fastcgi_param HTTPS on;
 }

 #error_page 404 /404.html;

 error_page 500 502 503 504 /50x.html;
 location = /50x.html {
 root html;
 }

 location ~ /\.ht {
 deny all;
 }
}

Здесь C:/nginx/private/ssl_cert_domain.pem — файл сертификата SSL, а C:/nginx/private/ssl_cert_domain.key — закрытый ключ для него

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

Вы можете включить ведение логов доступа (access.log), убрав символ комментария у строки #access_log  logs/access.log  main;.

Вы также можете переопределить страницы ошибок 404, 500, 502, 503, 504 и 403 путём указания в директиве error_page кода ошибки и имени файла, который будет отображаться при её возникновении.

Встречается в статьях

Инструкции:

  1. Установка Nginx + PHP + MySQL на Astra Linux
  2. Как оптимизировать веб-сервер NGINX
  3. Как настроить NGINX с поддержкой HTTP/2
  4. Как вручную настроить сервер хостинга на CentOS 7
  5. Как настроить связку Apache + HTTP/2 на Linux CentOS 7
  6. Трансляция видео с веб-сервера с помощью NGINX + rtmp
  7. Как настроить почту на базе Postfix для корпоративной среды
  8. Настройка веб-сервера на CentOS 7 со всем необходимым для правильной работы
  9. Настройка почтового сервера iRedMail на Ubuntu
  10. Настройка безопасности Linux с помощью Fail2ban
  11. Как установить и настроить iRedMail на Linux CentOS
  12. Настройка портала TeamPass для совместного хранения паролей
  13. Инструкция по установке и использованию GLPI на Linux CentOS
  14. Настройка веб-сервера на Ubuntu со всем необходимым для правильной работы
  15. Использование playbook и роли в Ansible на примере установки NGINX
  16. Установка и настройка системы мониторинга Prometheus на Linux
  17. Настройка веб-сервера на CentOS 8 со всем необходимым для правильной работы
  18. Как настроить почту для корпоративной среды на CentOS 8
  19. Как установить и настроить связку Asterisk + FreePBX на CentOS 8

Мини-инструкции:

  1. Как настраивать перенаправления в сервере NGINX
  2. Как установить NGINX на CentOS 7
  3. Как пользоваться командой systemctl
  4. Как работать с симлинками в Windows и Linux
  5. Как настроить Apache для работы по HTTPS (SSL)
  6. Как настроить HTTP/2 на Windows Server 2016 и выше
  7. Как установить PHP 7 на Linux CentOS 7
  8. Инструкция по установке и настройке PostfixAdmin на CentOS 7
  9. Получение бесплатного сертификата Lets Encrypt
  10. Как настроить лимиты и ограничения в веб-сервере NGINX
  11. Настройка logrotate в примерах
  12. Установка и настройка OwnCloud на CentOS 7 или 8
  13. Как управлять процессами в операционной системе Linux
  14. Инструкция по установке и настройке phplist
  15. Как и где настраивать время сессии PHP
  16. Инструкция по переходу на новую версию GLPI
  17. Как установить и настроить сервер Haproxy на Linux CentOS 7
  18. Анализ и мониторинг нагрузки веб-сервера на базе Linux
  19. Установка, настройка и использование NGINX Amplify для мониторинга веб-сервера
  20. Установка сервера для сбора тревожных событий Alerta на Linux Ubuntu
  21. Настройка проксирования почты с NGINX для IMAP, POP3 и SMTP
  22. Установка и настройка Nextcloud + NGINX на Ubuntu
  23. Настройка сервера мониторинга Zabbix на Linux CentOS
  24. Настройка сервера мониторинга Zabbix на Ubuntu
  25. Инструкция по настройке сервера IOT VEGA с веб-интерфейсом под Ubuntu
  26. Установка и настройка своего локального репозитория CentOS
  27. Настройка Autodiscover для автоматического конфигурирования почтовых программ
  28. Использование Roundcube для нескольких почтовых серверов
  29. Как создать свой собственный образ для Docker
  30. Инструкция по развертыванию Nextcloud с Apache на Ubuntu
  31. Отправка логов на удаленный сервер с помощью journald
  32. Установка обновления phplist с сохранением данных предыдущей версии
  33. Настройка rsyslog для хранения логов на удаленном сервере Linux
  34. Установка веб-интерфейса phpMyAdmin на CentOS для управления MySQL
  35. Установка платформы .NET Framework на Linux Ubuntu
  36. Включение кеширования ответа от backend в Nginx
  37. Установка и настройка SARG на CentOS для анализа логов прокси-сервера SQUID
  38. Установка и использование сервера Freeradius на Linux CentOS 8
  39. Установка и настройка сервера Rocket.Chat на Ubuntu
  40. Как пройти SSL-проверку при настройке https в NGINX
  41. Инструкция по установке и настройке phplist на Linux Ubuntu
  42. Установка и настройка сервера NextCloud на CentOS 8
  43. Установка и настройка модуля PageSpeed для NGINX и Apache
  44. Установка и использование почтового клиента WebMail Lite на Linux CentOS
  45. Установка и настройка сервера Collabora в связке с Nextcloud/Owncloud
  46. Настройка сервера мониторинга Zabbix 5 на Linux CentOS 8
  47. Организация сервиса календаря и адресной книги на базе Baikal
  48. Настройка аутентификации доменных пользователей в Nextcloud
  49. Синхрониация каталогов в Linux с помощью Lsyncd
  50. Отправка почты из Битрикс24 без попадания в СПАМ

Замена RewriteRule в nginx

Итак, имеем веб сервер Nginx в качестве фронтэнда, на бакэндах Apache и какой-нибудь fastcgi (spawn-fcgi или php-fpm). Функциональные возможности серверов, nginx и apache, несколько различаются, и одно из различий как раз в том, что nginx не поддерживает обработку файлов htaccess, которые в apache используются практически повсеместно. Большинство сайтовых движков (CMS), поддерживают возможность генерировать так называемые ЧПУ(человекопонятный урл, в оригинале, SEF — search engines friendly url), но для этого, веб сервер, должен обрабатывать строку запроса определенным образом, что apache и делает с помощью mod_rewrite и правил в файле .htaccess. Задача: заменить правила .htaccess, соответствующими директивами в конфигурационном файле nginx.conf.

3. Запустите Nginx на Windows 10

Шаг 1 После установки Nginx, как мы видели, мы перейдем к функции Windows, используя один из следующих параметров:

Используя следующие ключи и выполнив команду appwiz.cpl

+ R

В пути Панель управления \ Программы \ Программы и компоненты и там, нажав на строку «Активировать или деактивировать функции Windows»

Шаг 2 Во всплывающем окне мы найдем строку «Информационные службы Интернета», отобразим раздел «Инструменты веб-администрирования», а затем активируем окно «Консоль администрирования IIS»:

примечание

Этот шаг очень важен, поскольку для запуска Nginx в Windows 10 необходимо будет использовать Internet Information Services (IIS), который является веб-сервером Microsoft, с которого можно управлять страницами или файлами HTML.

Шаг 3 Как только мы выберем это поле, нажмите кнопку ОК, и это уступит процессу активации этой функции Windows 10:

Шаг 4 После проверки файлов изменения будут применены:

Шаг 5 Когда это закончится, мы увидим следующее. Нажмите Закрыть, чтобы выйти из помощника.

Шаг 6 Мы можем получить доступ к IIS Manager из меню «Пуск»:

Шаг 7 При доступе мы увидим следующее:

Шаг 8 По умолчанию путь к серверу — inetpub wwwroot:

Шаг 9 Если мы хотим, мы можем отредактировать этот маршрут, щелкнув правой кнопкой мыши по строке «Default Web Site» и выбрав «Basic configuration»:

Шаг 10 Затем мы добавляем нужный путь в поле «Физический путь»:

Шаг 11 Мы нажимаем ОК, чтобы сохранить изменения:

Шаг 12 После этого мы перейдем по пути C: \ Program Files \ nginx-1.16.1 \ conf и там щелкнем правой кнопкой мыши по файлу nginx.conf и выберем текстовый редактор для редактирования:

Шаг 13 В файле мы найдем строку «location» и установим маршрут, который мы определили ранее:

Шаг 14 Мы сохраняем изменения и теперь перейдем в папку HTM и откроем файл «index» в текстовом редакторе:

Шаг 15 Получив доступ к файлу, мы можем отредактировать нужный текст:

Шаг 16 Вернувшись в браузер и снова запустив localhost, мы увидим сообщение, которое мы предусмотрели:

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

Установка NGINX

Для тюнинга установка из пакетов или портов не подходит. Лучше всего выполнять сборку и установку из исходников.

Скачайте последнюю стабильную версию nginx (актуальную ссылку можно посмотреть по адресу http://nginx.org/ru/download.html):

… и с помощью данной ссылки скачиваем исходник.

а) во FreeBSD:

fetch http://nginx.org/download/nginx-1.16.1.tar.gz

б) в Linux:

wget http://nginx.org/download/nginx-1.16.1.tar.gz

* На момент обновления статьи актуальная версия nginx — 1.16.1.

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

tar -xvf nginx-*.tar.gz && \rm nginx-*.tar.gz

И перейдите в распакованную директорию:

cd nginx-*

Сконфигурируйте исходники для установки:

а) для FreeBSD:

Сначала устанавливаем пакеты, необходимые для сборки:

pkg install pcre

Приступаем к конфигурированию:

./configure \
    —prefix=/usr/local/etc/nginx \
    —with-cc-opt=’-I /usr/local/include’ \
    —with-ld-opt=’-L /usr/local/lib’ \
    —conf-path=/usr/local/etc/nginx/nginx.conf \
    —sbin-path=/usr/local/sbin/nginx \
    —pid-path=/var/run/nginx.pid \
    —error-log-path=/var/log/nginx-error.log \
    —user=www \
    —group=www \
    —http-client-body-temp-path=/var/tmp/nginx/client_body_temp \
    —http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp \
    —http-proxy-temp-path=/var/tmp/nginx/proxy_temp \
    —http-scgi-temp-path=/var/tmp/nginx/scgi_temp \
    —http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp \
    —http-log-path=/var/log/nginx-access.log \
    —with-http_ssl_module \
    —with-file-aio \
    —with-pcre \
    —with-http_stub_status_module \
    —without-http_charset_module \
    —without-http_ssi_module \
    —without-http_userid_module \
    —without-http_autoindex_module \
    —without-http_geo_module \
    —without-http_map_module \
    —without-http_split_clients_module \
    —without-http_referer_module \
    —without-http_empty_gif_module \
    —without-http_browser_module \
    —without-http_upstream_hash_module \
    —without-http_upstream_ip_hash_module \
    —without-http_upstream_least_conn_module \
    —without-http_upstream_keepalive_module \
    —without-mail_pop3_module \
    —without-mail_imap_module \
    —without-mail_smtp_module

а) для CentOS:

Сначала устанавливаем пакеты, необходимые для сборки:

yum install gcc pcre-devel openssl-devel make

Приступаем к конфигурированию:

./configure \
    —prefix=/etc/nginx \
    —sbin-path=/usr/sbin/nginx \
    —pid-path=/var/run/nginx.pid \
    —error-log-path=/var/log/nginx/error.log \
    —lock-path=/var/run/nginx.lock \
    —user=nginx \
    —group=nginx \
    —http-log-path=/var/log/nginx-access.log \
    —with-http_ssl_module \
    —with-file-aio \
    —with-pcre \
    —with-http_stub_status_module \
    —without-http_charset_module \
    —without-http_ssi_module \
    —without-http_userid_module \
    —without-http_autoindex_module \
    —without-http_geo_module \
    —without-http_map_module \
    —without-http_split_clients_module \
    —without-http_referer_module \
    —without-http_empty_gif_module \
    —without-http_browser_module \
    —without-http_upstream_hash_module \
    —without-http_upstream_ip_hash_module \
    —without-http_upstream_least_conn_module \
    —without-http_upstream_keepalive_module \
    —without-mail_pop3_module \
    —without-mail_imap_module \
    —without-mail_smtp_module

* Данный список опций подойдет для большинства серверов, но не помешает узнать о всех возможностях при помощи команды ./configure —help

Теперь запустите сборку дистрибутива из исходника:

make

И установите nginx:

make install

Теперь можно запустить и проверить наш веб-сервер.

а) во FreeBSD необходимо разрешить запуск демона nginx:

echo ‘nginx_enable=»YES»‘ >> /etc/rc.conf

service nginx start

б) в CentOS действий больше.

Создаем учетную запись nginx и в качестве владельца каталога для его настроек:

useradd nginx

chown -R nginx:nginx /etc/nginx

Создаем юнит для systemd:

vi /etc/systemd/system/nginx.service

Description=nginx — high performance web server
Documentation=https://nginx.org/en/docs/
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target

Type=forking
PIDFile=/var/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/conf/nginx.conf
ExecStart=/usr/sbin/nginx -c /etc/nginx/conf/nginx.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID
Restart=on-failure

WantedBy=multi-user.target

Применяем изменения в systemd:

systemctl daemon-reload

Разрешаем автозапуск сервиса и стартуем его:

systemctl enable nginx

systemctl start nginx

Шаг 4. Создание скриптов запуска и остановки

Для быстрого запуска набора Вам потребуется создать в каталоге c:\nginx\ 3 файла: start.cmd, shutdown.cmd и restart.cmd, предназначенные соответственно для запуска, остановки и перезапуска серверов.

Листинг файла start.cmd (запуск сервера):

@echo off
echo Starting servers...
set PHP_FCGI_MAX_REQUESTS=0
set SRVPATH=C:\nginx
net start MySQL
start /D%SRVPATH% nginx.exe
%SRVPATH%\RunHiddenConsole.exe %SRVPATH%\php\php-cgi.exe -b 127.0.0.1:9000 -c %SRVPATH%/php/php.ini

Листинг файла shutdown.cmd (остановка сервера):

@echo off
echo Shutting down servers...
taskkill /IM nginx.exe /F
taskkill /IM php-cgi.exe /F
net stop MySQL

Листинг файла restart.cmd (перезапуск сервера):

@echo off
echo Shutting down servers...
taskkill /IM nginx.exe /F
taskkill /IM php-cgi.exe /F
net stop MySQL
echo Starting servers...
set PHP_FCGI_MAX_REQUESTS=0
set SRVPATH=C:\nginx
net start MySQL
start /D%SRVPATH% nginx.exe
%SRVPATH%\RunHiddenConsole.exe %SRVPATH%\php\php-cgi.exe -b 127.0.0.1:9000 -c %SRVPATH%/php/php.ini

Если Вы изменили путь со стандартного C:\nginx\, на что-то другое, внесите соответствующие правки в скрипты.

Если требуется запускать сервер nginx+php+mysql при загрузке системы, то добавьте задание на автозапуск скрипта start.cmd с помощью оснастки Назначенные задания Windows.

Шаг 3. Создание сертификата

Поддержка HTTP/2 со стороны браузера осуществляется только по протоколу https, поэтому для работы ресурса необходим сертификат.

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

Создаем каталог, в котором будем хранить cert-файлы:

mkdir /etc/nginx/ssl

Создаем сертификаты:

openssl req -new -x509 -days 1461 -nodes -out /etc/nginx/ssl/cert.pem -keyout /etc/nginx/ssl/cert.key -subj «/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=test.dmosk.local/CN=test»

* данная команда создаст сертификат на 4 года для URL test.dmosk.local или test

Все стандартные редиректы в nginx

Рассмотрю типовой пример, когда у нас одновременно присутствуют следующие редиректы:

  1. С http на https.
  2. С www на без www для обоих протоколов.
  3. Без слеша на конце на урл со слешем.

Наша цель будет реализовать все преобразования url в одном месте и выдать клиенту только один 301-й редирект.

server {
    listen 443 ssl http2;
    server_name site.ru;
    root /web/sites/site.ru/www/;
    index index.php index.html index.htm;
    access_log /web/sites/site.ru/log/access.log main;
    error_log /web/sites/site.ru/log/error.log;

    ssl_certificate		/etc/letsencrypt/live/site.ru/fullchain.pem;
    ssl_certificate_key		/etc/letsencrypt/live/site.ru/privkey.pem;

    location / {
	rewrite ^(*)$ $1/ permanent;
	try_files $uri/ /index.php?$args;
	}

    location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
	access_log off;
	expires max;
	}

    location ~* ^/(\.ht|xmlrpc\.php)$ {
	return 404;
	}

    location ~ \.php$ {
	try_files  $uri =404;
	fastcgi_pass   unix:/var/run/php-fpm/php7-fpm.sock;
	fastcgi_index index.php;
	fastcgi_param DOCUMENT_ROOT /web/sites/site.ru/www/;
	fastcgi_param SCRIPT_FILENAME /web/sites/site.ru/www$fastcgi_script_name;
	fastcgi_param PATH_TRANSLATED /web/sites/site.ru/www$fastcgi_script_name;
	include fastcgi_params;
	fastcgi_param QUERY_STRING $query_string;
	fastcgi_param REQUEST_METHOD $request_method;
	fastcgi_param CONTENT_TYPE $content_type;
	fastcgi_param CONTENT_LENGTH $content_length;
	fastcgi_param HTTPS on;
	fastcgi_intercept_errors on;
	}

    location = /favicon.ico {
	log_not_found off;
	access_log off;
	}

    location = /robots.txt {
	allow all;
	log_not_found off;
	access_log off;
	}
}

server {
    listen 443 ssl http2;
    server_name www.site.ru;

    location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
	return 301 https://site.ru$request_uri;
    }
    
    location / {
	rewrite ^/(.*)/$ /$1;
	return 301 https://site.ru$uri/;
    }
}

server {
    listen 80;
    server_name site.ru www.site.ru;

    location ~* ^.+.(js|css|png|jpg|jpeg|gif|webp|ico|woff|txt)$ {
	return 301 https://site.ru$request_uri;
    }
    
    location / {
	rewrite ^/(.*)/$ /$1;
	return 301 https://site.ru$uri/;
    }
}

Получилось примерно так. Призываю не копировать бездумно конфиг, а проверить то, что я предлагаю. Хотя я сам внимательно проверил, как мог, но все равно не застрахован от ошибки. На мой взгляд здесь рассмотрены все основные моменты с редиректами. На выходе всегда один 301 редирект, какой бы запрос мы не сделали. При этом все реализовано средствами самого веб сервера, а значит, будет работать максимально быстро.

Управление nginx

Управлять nginx можно с помощью сигналов. Номер главного процесса по умолчанию
записывается в файл .
Изменить имя этого файла можно при конфигурации сборки или же в
директивой
.
Главный процесс поддерживает следующие сигналы:

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

Для того чтобы nginx перечитал файл конфигурации, нужно послать
главному процессу сигнал HUP. Главный процесс сначала проверяет
синтаксическую правильность конфигурации, а затем пытается применить
новую конфигурацию, то есть, открыть лог-файлы и новые listen сокеты.
Если ему это не удаётся, то он откатывает изменения и продолжает работать
со старой конфигурацией.
Если же удаётся, то он запускает новые рабочие процессы, а старым
шлёт сообщение о плавном выходе. Старые рабочие процессы закрывают listen
сокеты и продолжают обслуживать старых клиентов. После обслуживания всех
клиентов старые рабочие процессы завершаются.

Предположим, на FreeBSD команда

показывает примерно такую картину:

Если послать сигнал HUP главному процессу, то картина может быть такой:

Один старый рабочий процесс 33129 всё ещё продолжает работать. По истечении
некоторого времени он завершается:

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

Для обновления исполняемого файла сервера вначале нужно записать
на место старого файла новый.
Затем нужно послать сигнал USR2 главному процессу — он
переименует свой файл с номером процесса в файл
с суффиксом , например,
,
после чего запустит новый исполняемый файл, а тот в свою
очередь — свои рабочие процессы:

Теперь все рабочие процессы наравне принимают запросы.
Если послать сигнал WINCH первому главному процессу, то он пошлёт своим
рабочим процессам сообщение о плавном выходе, и они будут постепенно выходить:

По истечении времени запросы будут обрабатывать только новые рабочие процессы:

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

  • Послать старому главному процессу сигнал HUP.
    Старый главный процесс, не перечитывая конфигурации,
    запустит новые рабочие процессы.
    После этого можно плавно завершить все новые процессы,
    послав новому главному процессу сигнал QUIT.

  • Послать новому главному процессу сигнал TERM.
    В ответ на это он пошлёт сообщение о немедленном выходе своим
    рабочим процессам, и все они практически сразу же завершатся.
    (Если новые процессы по каким-то причинам не завершаются,
    нужно послать им сигнал KILL, который заставит их завершиться.)
    По завершению нового главного процесса старый главный процесс
    автоматически запустит новые рабочие процессы.

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

Если же обновление прошло удачно, то старому процессу нужно послать сигнал
QUIT, и останутся только новые процессы:

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

502 Bad Gateway

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

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 секунд на ожидание ответа от бекенда.

413 Request Entity Too Large

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

client_max_body_size 1m;

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

client_max_body_size 100m;

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

client_max_body_size 0;

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

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

  • В секции конкретного сайта включен (). По умолчанию, ssi отключен, но некоторые хостеры и ISPManager любят его прописывать в дефолтную конфигурацию сайта включенным. Его нужно обязательно отключить, закомментировав или удалив эту строку;
  • установить в , то есть на уровне или конкретного прописать:
Оцените статью
Рейтинг автора
5
Материал подготовил
Андрей Измаилов
Наш эксперт
Написано статей
116
Добавить комментарий