Правильная настройка ssl в nginx

Введение

Немного расскажу своими словами о том, как работает модуль ngx_http_proxy_module. Именно он реализует весь функционал, о котором пойдет речь. Допустим, у вас в локальной или виртуальной сети есть какие-то сервисы, не имеющие прямого доступа из интернета. А вы хотите таковой иметь. Можно пробрасывать нужные порты на шлюзе, можно что-то еще придумывать. А можно сделать проще всего — настроить единую точку входа на все свои сервисы в виде nginx сервера и с него проксировать различные запросы к нужным серверам.

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

1. Ранее я рассказывал о настройке чат серверов — matrix и mattermost. В этих статьях я как раз рассказывал о том, как проксировать запросы в чат с помощью nginx. Прошелся по теме вскользь, не останавливаясь подробно. Суть в том, что вы настраиваете на любом виртуальном сервере эти чаты, помещаете их в закрытые периметры сети без лишних доступов и просто проксируете запросы на эти сервера. Они идут через nginx, который у вас смотрит во внешний интернет и принимает все входящие соединения.
2. Допустим, у вас есть большой сервер с множеством контейнеров, например докера. На нем работает множество различных сервисов. Вы устанавливаете еще один контейнер с чистым nginx, на нем настраиваете проксирование запросов на эти контейнеры. Сами контейнеры мапите только к локальному интерфейсу сервера. Таким образом, они будут полностью закрыты извне, и при этом вы можете гибко управлять доступом.
3. Еще один популярный пример. Допустим, у вас есть сервер с гипервизором proxmox или любым другим. Вы настраиваете на одной из виртуальных машин шлюз, создаете локальную сеть только из виртуальных машин без доступа в нее извне. Делаете в этой локальной сети для всех виртуальных машин шлюз по-умолчанию в виде вашей виртуальной машины со шлюзом. На виртуальных серверах в локальной сети размещаете различные сервисы и не заморачиваетесь с настройками фаервола на них. Вся их сеть все равно не доступна из интернета. А доступ к сервисам проксируете с помощью nginx, установленным на шлюз или на отдельной виртуальной машине с проброшенными на нее портами.
4. Мой личный пример. У меня дома есть сервер synology. Я хочу организовать к нему простой доступ по https из браузера по доменному имени. Нет ничего проще. Настраиваю на сервере nginx получение бесплатного сертификата , настраиваю проксирование запросов на мой домашний ip, там на шлюзе делаю проброс внутрь локалки на synology сервер. При этом я могу фаерволом ограничить доступ к серверу только одним ip, на котором работает nginx. В итоге на самом synology вообще ничего не надо делать. Он и знать не знает, что к нему заходят по https, по стандартному порту 443.
5. Допустим, у вас большой проект, разбитый на составные части, которые живут на разных серверах. К примеру, на отдельном сервере живет форум, по пути /forum от основного домена. Вы просто берете и настраиваете проксирование всех запросов по адресу /forum на отдельный сервер. Точно так же можно без проблем все картинки перенести на другой сервер и проксировать к ним запросы. То есть вы можете создать любой location и переадресовывать запросы к нему на другие сервера.

Надеюсь в общем и целом понятно, о чем идет речь. Вариантов использования много. Я привел самые распространенные, которые пришли в голову и которые использую сам. Из плюсов, которые считаю наиболее полезными именно из своих кейсов, отмечу 2:

• Без проблем можете настроить https доступ к сервисам, при этом совершенно не трогая эти сервисы. Вы получаете и используете сертификаты на nginx сервере, используете https соединение с ним, а сам nginx уже передает информацию на сервера со службами, которые могут работать по обычному http и знать не знают о https.
• Вы очень легко можете менять адреса, куда проксируете запросы. Допустим у вас есть сайт, его запросы проксируются на отдельный сервер. Вы подготовили обновление или переезд сайта. Отладили все на новом сервере. Теперь вам достаточно на сервере nginx изменить адрес старого сервера на новый, куда будут перенаправляться запросы. И все. Если что-то пойдет не так, можете оперативно вернуть все обратно.

С теорией закончил. Перейдем теперь к примерам настройки. В своих примерах я буду использовать следующие обозначения:

blog.zeroxzed.ru	доменное имя тестового сайта
nginx_srv	имя внешнего сервера с установленным nginx
blog_srv	локальный сервер с сайтом, куда проксируем соединения
94.142.141.246	внешний ip nginx_srv
192.168.13.31	ip адрес blog_srv
77.37.224.139	ip адрес клиента, с которого я буду заходить на сайт

Настройка proxy_pass в nginx

Рассмотрим самый простой пример. Буду использовать свой технический домен zeroxzed.ru в этом и последующих примерах. Допустим, у нас есть сайт blog.zeroxzed.ru. В DNS создана A запись, указывающая на ip адрес сервера, где установлен nginx — nginx_srv. Мы будем проксировать все запросы с этого сервера на другой сервер в локальной сети blog_srv, где реально размещается сайт. Рисуем конфиг для секции server.

Заходим по адресу http://blog.zeroxzed.ru. Мы должны попасть на blog_srv, где тоже должен работать какой-то веб сервер. В моем случае это будет тоже nginx. У вас должно открыться содержимое, аналогичное тому, что вы увидите, набрав http://192.168.13.31 в локальной сети. Если что-то не работает, то проверьте сначала, что по адресу директивы proxy_pass у вас все корректно работает.

Посмотрим логи на обоих сервера. На nginx_srv вижу свой запрос:

Проверяем blog_srv:

Как мы видим, запрос сначала пришел на nginx_srv, был переправлен на blog_srv, куда он пришел уже с адресом отправителя 94.142.141.246. Это адрес nginx_srv. Реальный же ip адрес клиента мы видим только в самом конце лога. Это неудобно, так как директива php REMOTE_ADDR не будет возвращать настоящий ip адрес клиента. А он очень часто бывает нужен. Мы это дальше исправим, а пока создадим в корне сайта на chat_srv тестовую страничку для проверки ip адреса клиента следующего содержания:

Назовем ее myip.php. Перейдем по адресу http://blog.zeroxzed.ru/myip.php и проверим, как сервер определит наш адрес. Никак не определит 🙂 Он покажет адрес nginx_srv. Исправляем это и учим nginx передавать реальный ip адрес клиента на сервер.

What is a Redirect?

A redirect is a web server function that will redirect traffic from one URL to another. Redirects are an important feature when the need arises. There are several different types of redirects, but the more common forms are temporary and permanent. In this article, we will provide some examples of redirecting through the vhost file, forcing a secure HTTPS connection, redirection to www and non-www as well as the difference between temporary and permanent redirects.

Note
As this is an Nginx server, any .htaccess rules will not apply. If your using the other popular web server, Apache, you’ll find this article useful.

3:05 Why Set Up HTTPS?

Well, the main reason is user privacy. In the case of the service communication, it’s privacy of information – how much do you trust the networks you’re using to transmit this information? Do you trust these networks to not inject things into your traffic and to be able to read what gets transmitted over? Also recently, if you’re using this for a public website, it provides an SEO advantage so Google will more highly rank sites that support HTTPS than those that do not.

Another thing you can do for HTTPS (this is one of the main use cases for NGINX) is to put it in front of services that don’t necessarily support HTTPS natively or don’t support the most modern, up‑to‑date version of SSL and TLS. So, what you get with NGINX is the best, state‑of‑the‑art implementations of all the crypto algorithms that you don’t really need to think about, and in general it’s good practice.

So, if someone’s going to a site, they like to see that little happy lock icon. In this case this is nginx.com, which has HTTPS enabled as well as HSTS (a feature I’ll talk about later). You can’t really go to the regular HTTP version of the site anymore; the browser knows to always go to HTTPS. Another thing you see here is there’s a nice NGINX, Inc with the that just shows this is an Extended Validation Cert – essentially, a certificate that says NGINX is who it says it is. They paid a little bit extra for that and did some vetting.

Как установить SSL-сертификат на Nginx

После активации сертификата вам будут доступны необходимые данные для его установки, подробнее в статье Где взять данные для установки SSL-сертификата.

Также вы можете использовать для установки сертификат, купленный в сторонней компании.

Рассмотрим, как выполняется установка и настройка Nginx SSL:

1.

Объедините три сертификата (сам SSL-сертификат, корневой и промежуточный сертификаты) в один файл. Для этого создайте на ПК новый текстовый документ с именем your_domain.crt (your_domain — доменное имя сайта, который вы хотите защитить). Создать его можно при помощи блокнота или другого текстового редактора.
Поочередно скопируйте и вставьте в созданный документ каждый сертификат

После вставки всех сертификатов файл должен иметь вид:

Обратите внимание: один сертификат идёт следом за другим, без пустых строк.

2.
Создайте файл your_domain.key и скопируйте в него содержание приватного ключа сертификата.

3.
Загрузите созданные файлы your_domain.crt и your_domain.key на сервер в директорию /etc/ssl/. Директория может быть иной, например /etc/nginx/ssl/your_domain.com.

4.

Откройте конфигурационный файл Nginx и отредактируйте виртуальный хост вашего сайта, который вы хотите защитить сертификатом

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

Где:
your_domain.com — домен сайта,
/etc/ssl/your_domain.crt — путь до созданного файла с тремя сертификатами,
/etc/ssl/your_domain.key — путь до файла с приватным ключом.
Минимальная установка и настройка выполнена. Далее вы можете добавить расширенные настройки конфигурационного файла либо сразу перейти к шагу 12.

5.

Если вы хотите, чтобы сайт работал не только по защищённому соединению (https://), но и по незащищенному (http://), то нужно создать единый HTTP/HTTPS сервер. Для этого в конфигурационном файле Nginx необходимо иметь две секции server{} для каждого типа соединения.
Добавьте в секцию server{}, которую вы создали на шаге 4, следующую строку:

6.

Также вы можете дополнительно оптимизировать работу Nginx HTTPS-сервера. SSL-операции задействуют дополнительные ресурсы сервера. Чтобы снизить количество операций, можно повторно использовать параметры SSL-сессий. Они хранятся в кеше SSL-сессий. Можно задать тип кеша (в примере это shared-кеш, разделяемый между всеми рабочими процессами) и его размер в байтах (в 1 Мб кеша помещается около 4000 сессий) с помощью директивы ssl_session_cache. Также можно увеличить таймаут кеша (время, в течение которого клиент повторно использует параметры сессии) директивой ssl_session_timeout: по умолчанию он равен 5 минутам. Можно настроить время работы одного keepalive-соединения с помощью директивы keepalive_timeout.
Добавьте в конфигурационном файле в секции server{} строки:

7.

Вы можете указать протоколы SSL, которые поддерживает сервер:

8.

Чтобы при использовании протоколов SSLv3 и TLS серверные шифры были более приоритетны, чем клиентские, добавьте следующую строку:

9.

Чтобы уменьшить время загрузки страниц у пользователей сайта, нужно разрешить серверу прикреплять OCSP-ответы для валидации сертификата. При этом необходимо указать путь к файлу корневого сертификата и DNS-сервер.
Создайте файл ca.crt и скопируйте в него содержимое корневого сертификата. Загрузите этот файл на сервер в директорию, где хранятся ранее созданные файлы. В нашем примере это /etc/ssl/.
Затем добавьте в конфигурационном файле в секции server{} строки:

Где:
/etc/ssl/ca.crt — путь до файла с корневым сертификатом,
8.8.8.8 — DNS-сервер.

10.
Сохраните и закройте конфигурационный файл Nginx.

11.

Если вы не остановились на шаге 4, то секция server{} в конфигурационном файле с расширенными настройками будет выглядеть так:

12.

Чтобы изменения вступили в силу, перезагрузите сервер Nginx:

Готово, вы установили SSL-сертификат на Nginx.

HTTP to HTTPS Redirect

To enforce an HTTP to HTTPS redirect, you need to edit the Nginx configuration file.

In most cases, you can locate the file in the /etc/nginx/sites-available directory. If not found, search for it here: /etc/nginx/nginx.conf, /usr/local/nginx/conf, or /usr/local/etc/nginx.

Once you have located the Nginx configuration file, open it in a text editor with the command:

Replace the location with the actual location and name of your configuration file.

Note: If you are connecting remotely, make sure you’re logged in through SSL first. Also, if you are using a graphical interface, you can browse to the file location instead of using terminal commands.

Once the configuration file is open for editing, insert one of the code blocks below. Once you are finished editing, save the file and exit. Then, restart the Nginx service with the following command:

Nginx Redirect all HTTP traffic to HTTPS

Open the Nginx configuration file for editing, then insert the following code:

Here is a breakdown of the commands:

• : This instructs the system to catch all HTTP traffic on Port 80
• : This will match any hostname
• : This tells the browser (and search engines) that this is a permanent redirect
• : This is a short code to specify the HTTPS version of whatever the user has typed

After editing, all traffic for the HTTP default server redirects to HTTPS.

Note: This should be the only server block listening on Port 80. (A server block is a unit of configuration code in Nginx. It’s marked by a name and curly brackets.)

Redirect a Specific Site

You may have multiple servers, but only some of them may require HTTPS. Specify server name in the server block to redirect the selected traffic:

Replace the name my_app.com with the name of the server you intend to redirect. You may also want to add additional sites by adding another server block. Simply copy the code, and switch out the name of the server.

Accept Only SSL Connections

Add this code to be sure that the server will only accept SSL connections on Port 443:

This code block will set two websites, my_app.com and my_website.com, to accept only SSL connections. You can add additional sites by using additional server blocks.

Note: Let’s Encrypt is a free certificate authority that allows you to set up SSL/TLS encryption on your NGINX server. Check out our article on how to set up Let’s Encrypt to secure your Nginx server.

Nginx Page Redirects

You can use the rewrite code to quickly manage a 301 (permanent) or 302 (temporary) redirect:

Most of the time, the location will be index.html, but you can specify any path/pattern.

Make note that the command should only be used with 301 or 302 redirects.

How to Redirect a Domain With Nginx

This is useful if you have changed from a vanity extension (like .biz or .net) to a standard .com address. It can also be used to redirect from an old domain name to a new domain name.

For most instances, the command is preferred to the rewrite command.

Reasons to Redirect Traffic

There are several reasons to redirect HTTP traffic to HTTPS. You may need to:

• Force a more secure, encrypted connection.
• Keep a page with good SEO ranking, but send its traffic to a new page.
• Notify and temporarily send traffic to an “under maintenance” page.
• Permanently send traffic from one website to another, i.e. after a corporate merger.

Conclusion

Now you know how to redirect HTTP to HTTPS in Nginx. By editing the configuration file, you can send traffic from a specific destination to a different site and enforce the use of Nginx SSL certificates. This helps you safely manage changes to your website without disrupting the user experience.

Настройка обратного прокси на Nginx

Под обратным проксированием обычно понимается процесс, в котором сервер, получающий запрос от клиента, не обрабатывает его полностью самостоятельно, а частично или целиком отправляет этот запрос для обработки другим (upstream) серверам. Иными словами, он не перенаправляет клиента, а самостоятельно отправляет запрос и возвращает полученный ответ обратно клиенту.

Настройте обратный прокси example.org, взаимодействующий с внутренним HTTP-сервисом, использующим порт 8080:

/etc/nginx/sites-enables/example.org.conf

server {
  listen 80;
  server_name www.example.org example.org;
  access_log /var/log/nginx/proxy.log;

  location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Nginx-Proxy true;

    proxy_redirect off;
  }
}

Приоритеты

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

Синтаксис при указании веса:

server <имя сервера> weight=<числовой эквивалент веса>;

По умолчанию приоритет равен 1.

Также мы можем указать опции:

• backup, которая будет говорить о наличие резервного сервера, к которому будет выполняться подключение только при отсутствии связи с остальными.
• down, при указании которой, сервер будет считаться постоянно недоступным. Может оказаться полезной, чтобы остановить временно запросы для проведения обслуживания.

Давайте немного преобразуем нашу настройку upstreams:

vi /etc/nginx/conf.d/upstreams.conf

upstream dmosk_backend {
    server 192.168.10.10 weight=100;
    server 192.168.10.11 weight=10;
    server 192.168.10.12;
    server 192.168.10.13 backup;
}

* итак, мы указали нашему серверу:

• переводить на сервер 192.168.10.10 в 10 раз больше запросов, чем на 192.168.10.11 и в 100 раз больше — чем на 192.168.10.12.
• переводить на сервер 192.168.10.11 в 10 раз больше запросов, чем на 192.168.10.12.
• на сервер 192.168.10.13 запросы переводятся, только если не доступны все три сервера.

18:02 Certificate Chain

Certificates don’t get signed directly by the certificate authority; there’s this kind of chain of trust that gets built up. So, if you have a certificate, it’s usually signed by an intermediate certificate authority, and that intermediate certificate authority is signed by the real certificate authority.

So in this case, you can kind of think of it this way (this is CloudFlare but imagine this is a certificate authority): you get a certificate and you have this whole chain of certificates that you present. Not all browsers necessarily know what the next one in the chain is, and browsers are really only bundled with the top (the real offline root certificates). So when you get a certificate, you also need to have the whole chain of trust along with it.

There’s a tool we built called CFSSL Bundle that allows you to create this if your CA doesn’t give it to you. Typically your CA will give you this chain.

Настройка правильной работы SSL

Дальше рассмотрим как выполняется настройка https прокси Nginx. Как я уже сказал, для правильной работы SSL нам понадобится модуль Apache mod_rpaf. Он устанавливает заголовки и переменные таким образом, чтобы прокси мог без проблем использовать https. Его можно установить из официальных репозиториев:

Затем создайте конфигурационный файл для этого модуля:

Строка RPAFProxyIPs задает IP адрес вашего прокси. После завершения настройки активируйте модуль:

Осталось перезапустить Apache:

Дальше нам нужно создать наши сертификаты с помощью OpenSSL:

А файл виртуальных хостов с поддержкой SSL теперь будет выглядеть во так:

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

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

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

Поддержка защищенного протокола включена и SERVER_PORT имеет значение 443, все работает прозрачно, как бы проксирование nginx не осуществляется, а мы направляем запросы непосредственно к Apache.

Пример двойного редиректа

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

http://site.ru/catalog -> https://site.ru/catalog

Допустим, у вас сначала был настроен редирект на https подобным образом:

server {
 listen 80;
 root   /var/www/site.ru/public;

 location / {
  return 301 https://site.ru$request_uri;
 }
}

А потом вас попросили добавить редирект всех урлов без слеша на тот же урл только со слешем на конце. Вы идете в секцию c listen 443 и добавляете редирект.

server {
 listen 443 http2;
...................
 location / {
  rewrite ^(*)$ $1/ permanent;
...................
}

# curl -I -L http://site.ru/catalog

HTTP/1.1 301 Moved Permanently
Server: nginx
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://site.ru/catalog

HTTP/2 301 
server: nginx
content-type: text/html
content-length: 162
location: https://site.ru/catalog/

HTTP/2 200 
server: nginx
content-type: text/html; charset=utf-8
vary: Accept-Encoding

На выходе у вас 2 редиректа вместо одного, что плохо для СЕО. Надо по возможности все реализовать в одном. В данном случае напрашивается простое и очевидное решение:

server {
 listen 80;
 server_name site.ru www.site.ru;
 root   /var/www/site.ru/public;

 location / {
  return 301 https://site.ru$request_uri/;
 }
}

Вроде бы все нормально. Теперь редирект будет автоматически добавлять слеш в конец запроса. Но проблемы начнутся со ссылками на медиа файлы. Например, запрос http://site.ru/catalog/img.png будет превращаться в https://site.ru/catalog/img.png, что нам совершенно не нужно. Чтобы это исправить, надо сделать так.

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 / {
  return 301 https://site.ru$request_uri/;
 }
}

Теперь все будет нормально, так как location со статикой указан в виде регулярного выражения. В случае попадания запроса в указанное правило, будет выполнен редирект без слеша. Все остальное попадет в следующий префиксный /. То же самое можно сделать с помощью if и одного location, но c if работать будет медленнее. Там где можно обходиться без if, лучше его не использовать.

nginx documentation

• Installing nginx
• Building nginx from Sources
• Beginner’s Guide
• Admin’s Guide
• Controlling nginx
• Connection processing methods
• Setting up hashes
• A debugging log
• Logging to syslog
• Configuration file measurement units
• Command-line parameters
• nginx for Windows

• How nginx processes a request
• Server names
• Using nginx as HTTP load balancer
• Configuring HTTPS servers

How nginx processes a TCP/UDP session

Scripting with njs

Chapter “nginx” in
“The Architecture of Open Source Applications”

• Building nginx on the Win32 platform with Visual C
• Setting up NGINX Plus environment on Amazon EC2
• Debugging nginx with DTrace pid provider

• Converting rewrite rules
• WebSocket proxying

• Contributing Changes
• Development guide

• Alphabetical index of directives
• Alphabetical index of variables

Core functionality

• ngx_http_core_module

• ngx_http_access_module

• ngx_http_addition_module

• ngx_http_api_module

• ngx_http_auth_basic_module

• ngx_http_auth_jwt_module

• ngx_http_auth_request_module

• ngx_http_autoindex_module

• ngx_http_browser_module

• ngx_http_charset_module

• ngx_http_dav_module

• ngx_http_empty_gif_module

• ngx_http_f4f_module

• ngx_http_fastcgi_module

• ngx_http_flv_module

• ngx_http_geo_module

• ngx_http_geoip_module

• ngx_http_grpc_module

• ngx_http_gunzip_module

• ngx_http_gzip_module

• ngx_http_gzip_static_module

• ngx_http_headers_module

• ngx_http_hls_module

• ngx_http_image_filter_module

• ngx_http_index_module

• ngx_http_js_module

• ngx_http_keyval_module

• ngx_http_limit_conn_module

• ngx_http_limit_req_module

• ngx_http_log_module

• ngx_http_map_module

• ngx_http_memcached_module

• ngx_http_mirror_module

• ngx_http_mp4_module

• ngx_http_perl_module

• ngx_http_proxy_module

• ngx_http_random_index_module

• ngx_http_realip_module

• ngx_http_referer_module

• ngx_http_rewrite_module

• ngx_http_scgi_module

• ngx_http_secure_link_module

• ngx_http_session_log_module

• ngx_http_slice_module

• ngx_http_spdy_module

• ngx_http_split_clients_module

• ngx_http_ssi_module

• ngx_http_ssl_module

• ngx_http_status_module

• ngx_http_stub_status_module

• ngx_http_sub_module

• ngx_http_upstream_module

• ngx_http_upstream_conf_module

• ngx_http_upstream_hc_module

• ngx_http_userid_module

• ngx_http_uwsgi_module

• ngx_http_v2_module

• ngx_http_xslt_module

• ngx_mail_core_module

• ngx_mail_auth_http_module

• ngx_mail_proxy_module

• ngx_mail_realip_module

• ngx_mail_ssl_module

• ngx_mail_imap_module

• ngx_mail_pop3_module

• ngx_mail_smtp_module

• ngx_stream_core_module

• ngx_stream_access_module

• ngx_stream_geo_module

• ngx_stream_geoip_module

• ngx_stream_js_module

• ngx_stream_keyval_module

• ngx_stream_limit_conn_module

• ngx_stream_log_module

• ngx_stream_map_module

• ngx_stream_proxy_module

• ngx_stream_realip_module

• ngx_stream_return_module

• ngx_stream_set_module

• ngx_stream_split_clients_module

• ngx_stream_ssl_module

• ngx_stream_ssl_preread_module

• ngx_stream_upstream_module

• ngx_stream_upstream_hc_module

• ngx_stream_zone_sync_module

ngx_google_perftools_module

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:

Постоянный и Временный Nginx Redirect

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

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

Посетитель–> Страница сайта–> Сайт находится на обслуживании

В свою очередь, постоянное перенаправление Nginx сообщает веб-браузеру, что он должен постоянно связывать старую страницу или домен с новым местоположением или доменом. Для обозначения постоянного перемещения страницы используется код ответа 301. Такие перенаправления полезны, когда пользователь хочет изменить имя домена и больше не хочет, чтобы браузер обращался к нему.

Например, если вы хотите изменить домен вашего сайта или создать новую страницу, чтобы заменить старую:

Посетитель –> Нажимает на www.devisers.in/home –> Перенаправлен на www.devisers.in/home1

Перенаправления Страниц в Nginx

Обратите внимание, что сначала вы должны получить доступ к вашему VPS через SSH. Если у вас возникли проблемы, ознакомьтесь с нашим руководством по PuTTY

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

Перенаправить страницы на временное или постоянное местоположение на веб-сервере Nginx довольно просто. Вставьте следующий код в /etc/nginx/sites-enabled/default, заменив переменные необходимыми данными: 

Location path_pattern {
       rewrite ^/oldURL$ https://www.domainone.com/newURL redirect;
}

Если вы хотите перенаправить страницу на другую ссылку навсегда, просто используйте “permanent” (“постоянно”) вместо “redirect” (“перенаправить”) в приведённой выше команде. Между тем, path_patern обычно является /index.html.

Перенаправление домена в Nginx

Для перенаправления одного домена на другой введите в терминале указанную ниже команду:

server {
      listen 80;
      hostname devisers.in www.devisers.in;
      rewrite ^ http://www.devisers.com$request_uri? permanent;
}

Здесь мы используем два домена. Тот, который мы хотим перенаправить – www.devisers.in, а новый – www.devisers.com.

Nginx Redirect с HTTP на HTTPS (SSL)

HTTP и HTTPS используют разные порты – HTTP-порт 80 и HTTPS-порт 443. HTTPS означает безопасное соединение, защищённое от MITM-атак, которые могут перехватить ваш сеанс

Обратите внимание, что для того, чтобы этот метод работал, вам нужно настроить SSL. Таким образом, чтобы защитить информацию, которая циркулирует между вами и вашими посетителями, следует перенаправлять все запросы, поступающие с HTTP на HTTPS

Для этого мы можем добавить следующую модификацию в тот же файл:

server {
listen 80 default_server;
server_name _;
return 301 https://$host$request_uri;
}

Теперь весь трафик на дефолтный HTTP-сервер перенаправляется на HTTPS.

Nginx Redirect Определённых Сайтов

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

server { 
listen 80; 
server_name devisers.in;
     return 301 https://devisers.in$request_uri; 
}

В этом примере мы перенаправляем сайт http://www.devisers.in на https://www.devisers.in.

Переадресация с www на без www

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

В Nginx есть много способов переадресации с www на без www. Вот один из самых простых:

server {
    server_name www.devisers.in;
    return 301 $scheme://devisers.in$request_uri;
}

Важно: это постоянный, или “301 редирект”. Чтобы увидеть изменения, перезапустите веб-сервер Nginx, используя команду:

Чтобы увидеть изменения, перезапустите веб-сервер Nginx, используя команду:

sudo systemctl restart Nginx

Для редиректа с без www на www, просто замените URL сайта в примере выше. Вместо www.devisers.in укажите devisers.in.