Всем доброе время суток. Сегодня рассмотрим пример по устранению ошибки nginx “SSL_ERROR_RX_RECORD_TOO_LONG”, которая появилась после обновления ключей ssl в админ панели VestaCP.

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

Что же делать. Вроде всё работает. В админку VestaCP заходит, сам nginx тоже отрабатывает без ошибок

sudo /etc/init.d/nginx restart
[sudo] password for user:
[[ ok  Restarting nginx (via systemctl): nginx.service.

но вот сайт работать отказывается.

Ну, интернет мне в помощь. А он мне говорит, что данная ошибка связана с SSL протоколом. SSL получила запись, длина которой превышает максимально допустимую величину. Тут я задумался, недавно настраивал nginx на получения статуса A+ на сайте ssllab. Ладно, лезу в настройке nginx. Открываю файл nginx.conf и выключаю stapling и add_header Strict-Transport-Security. Перезагружаю web сервер, а не тут то было. Ошибка все равно осталась. Посидев около часа на форумах набрёл на рекомендацию в добавлении записи ssl и http2 в конфигурационный файл сайта. Так, лезу и добавляю запись:

listen 11.11.11.11:443 ssl http2

После рестарта web сервера сайт заработал в обычном режиме.

Ура!!! Ошибка исправлена.

[endtxt]

Netcraft недавно опубликовал исследование сайтов SSL/TLS, которые они отслеживают, и заметил, что только 5% из них правильно реализуют HTTP Strict Transport Security (HSTS). В этой статье описывается настройка NGINX и NGINX Plus для реализации политики HSTS.

Что такое HSTS?

HTTPS (HTTP, зашифрованный SSL или TLS) является неотъемлемой частью мер по обеспечению безопасности трафика на веб-сайт, что делает его очень трудным для злоумышленника, чтобы перехватить, изменить или поддельный трафик между Пользователем и веб-сайта.

Когда пользователь вводит веб-домен вручную (предоставляя имя домена без префикса http:// или https://) или следует простой ссылке http://, первый запрос на веб-сайт отправляется незашифрованным, используя простой HTTP. Большинство защищенных веб‑сайтов немедленно отправляют перенаправление для обновления пользователя до HTTPS‑соединения, но хорошо расположенный злоумышленник может смонтировать атаку “человек в середине” (MITM) для перехвата первоначального HTTP‑запроса и может контролировать сеанс пользователя с этого момента.

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

Как работает HSTS?

Политика HSTS публикуется путем отправки следующего заголовка ответа HTTP с защищенных (HTTPS) веб-сайтов:

Strict-Transport-Security: max-age=31536000

Когда браузер видит этот заголовок с веб-сайта HTTPS, он “узнает”, что этот домен должен быть доступен только с помощью HTTPS (SSL или TLS). Он кэширует эту информацию на максимальный период (обычно 31536000 секунд – это примерно 1 год).

Необязательный параметр includeSubDomains сообщает браузеру, что политика HSTS также применяется ко всем поддоменам текущего домена.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Например, ответ HTML для https://www.example.com может включать запрос к ресурсу от https://example.com, чтобы убедиться, что HSTS установлен для всех поддоменов example.com

Настройка HSTS в NGINX и NGINX Plus

Настройка заголовка ответа Strict Transport Security (STS) в NGINX и NGINX Plus относительно проста. Добавте параметр в конфигурационный файл nginx.conf:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Параметр always гарантирует, что заголовок задан для всех ответов, включая ответы на внутренние ошибки. Более старые версии NGINX (до версии 1.7.5 или NGINX Plus R5) не поддерживают параметр always и не устанавливают заголовок для внутренних ответов об ошибках.

Правила наследования для директив add_header

Блоки конфигурации NGINX наследуют директивы add_header от своих вложенных блоков, поэтому вам просто нужно поместить директиву add_header в серверный блок верхнего уровня. Существует одно важное исключение: если блок включает в себя директиву add_header, он не наследует заголовки от вложенных блоков, и вам нужно повторно объявить все директивы add_header:

server {     
    listen 443 ssl;     
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;     
# This 'location' block inherits the STS header     
    location / {         
        root /usr/share/nginx/html;     
    }     
# Because this 'location' block contains another 'add_header' directive,     
# we must redeclare the STS header     
    location /servlet {         
        add_header X-Served-By "My Servlet Handler";         
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;         
        proxy_pass http://localhost:8080;     
    } 
}

Тестируйте HTTP Strict Transport Security с осторожностью

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

Очень сложно отказаться от политики HSTS, чтобы удалить HTTPS-версию веб-сайта или службы. Когда вы тестируете HSTS, используйте очень короткий максимальный тайм-аут и убедитесь, что вам комфортно с эффектами и обязательством поддерживать HTTPS-версию вашего сайта. Когда вы впервые начнете жить с вашей политикой HSTS, держите max-age маленьким и увеличивайте его только тогда, когда вы уверены в этом.

Должен ли каждый ответ HTTPS иметь заголовок STS?

Цель состоит в том, чтобы представить политику HSTS пользователям как можно скорее, когда они начинают сеанс HTTPS. Если они не получают политику HSTS во время сеанса, они останутся уязвимыми для будущих атак захвата HTTP.

Браузер должен наблюдать за заголовком STS только один раз, поэтому нет необходимости добавлять его в каждый блок местоположения и каждый ответ. Однако добавление его только на домашнюю страницу или страницу входа в систему, вероятно, недостаточно, и если вы добавите заголовок только к кэшируемым ответам, клиент может не увидеть его. Убедитесь, что вы покрываете как можно больше своего URL‑пространства, уделяя особое внимание динамическому (не кэшируемому) контенту.

Запуск HTTP и HTTPS версий веб-сайта бок-о-бок

Некоторые сайты запускают HTTP и HTTPS версии веб-сайта на одном сервере NGINX или NGINX Plus, чтобы сделать его содержимое доступным по любому протоколу:

server {     
    listen  80;     
    listen  443 ssl http2;     
# ... 
}

Это не подходит при использовании HSTS, поэтому в файле конфигурации WEB домена прописываем редирект на протакол HTTPS:

server {     
    listen 80 default_server;     
    listen [::]:80 default_server;     
    server_name _;     
    return 301 https://$host;    
# Либо 
  # return 301 https://$host$request_uri; 
} 
server {     
    listen 443 ssl http2;     
    server_name www.example.com;     
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; 
}

Укрепление HSTS

Клиент защищен от перехвата HTTP после того, как он увидел заголовок STS для соответствующего домена в течение объявленного периода максимального возраста.

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

• Никогда раньше не посещал сайт
• Недавно переустановил свою операционную систему
• Недавно переустановил свой браузер
• Перешел на новый браузер
• Перешли на новое устройство (например, мобильный телефон)
• Удалил кэш браузера
• Не посещал сайт в последнее время, и время max-age прошло

Чтобы решить эту проблему, Google поддерживает “список предварительной загрузки HSTS” веб-доменов и поддоменов, которые используют HSTS и представили свои имена https://hstspreload.appspot.com/. Этот список доменов распространяется и жестко закодирован в основных веб-браузерах. Клиенты, обращающиеся к веб-доменам в этом списке, автоматически используют HTTPS и отказываются обращаться к сайту по протоколу HTTP.

Имейте в виду, что после установки заголовка STS или отправки доменов в список предварительной загрузки HSTS удалить его невозможно. Это одностороннее решение сделать ваши домены доступными через HTTPS.

Если вы планируете добавить заголовок STS в конфигурацию NGINX, сейчас также самое время рассмотреть возможность использования других HTTP‑заголовков, ориентированных на безопасность, таких как X-Frame-Options и X-XSS-Protection.

NGINX Plus имеет дополнительные функции для защиты вашего сайта от угроз безопасности и других проблем, таких как распределенные атаки типа “отказ в обслуживании” (DDoS).

[endtxt]

RSS

Распределенная атака типа “отказ в обслуживании” (DDoS) представляет собой попытку сделать службу, обычно веб‑сайт, недоступным путем бомбардировки его таким количеством трафика с нескольких машин, что сервер, предоставляющий службу, больше не может функционировать правильно из‑за исчерпания ресурсов.

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

Использование NGINX для борьбы с DDoS-атаками

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

Защита архитектуры NGINX по событиям

NGINX сконструирован так, чтобы он мог быть “амортизатором при ударе” DDOS на ваш сервер.

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

Ограничение скорости запросов в nginx

Можно ограничить скорость, с которой NGINX принимает входящие запросы, значением, типичным для реальных пользователей. Например: реальный пользователь, обращающийся к странице входа, может делать запрос только каждые 2 секунды. Исходя из этого настроим NGINX так, чтобы разрешить одному IP-адресу клиента пытаться войти в систему только каждые 2 секунды (эквивалентно 30 запросам в минуту):

limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;

server {
# ... 
     location /login.html {
         limit_req zone=one;
     }
}

• limit_req_zone – Директива настраивает вызываемую зону общей памяти для хранения состояния запросов для указанного ключа, в данном случае IP-адреса клиента ( $binary_remote_addr).
• limit_req – Директива в location блоке для /login.html ссылается на зону общей памяти.

Ограничение количества соединений

Можно ограничить число соединений, которые могут быть открыты одним IP-адресом клиента, снова значением, соответствующим реальным пользователям. Например, можно разрешить каждому IP-адресу клиента открывать не более 10 подключений к области /store вашего веб-сайта:

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {     
# ...     
    location /store/ {         
        limit_conn addr 10;        
    } 
}

• limit_conn_zone– Директива настраивает зону общей памяти с именем addr для хранения запросов на указанный ключ, в этом случае (как и в предыдущем примере) IP-адрес клиента,$binary_remote_addr. 
• limit_conn– Директива в locationблоке for /store ссылается на зону общей памяти и устанавливает максимум 10 соединений от каждого IP-адреса клиента.

Закрытие Медленных Соединений

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

client_header_timeout           30s;
client_body_timeout             30s;

По умолчанию данный параметр равен 60 секундам

[endtxt]

Сегодня разберем как можно изменить шаблоны VestaCP у Web сервера Nginx для получения рейтинга A+.

Лучше всего отредактировать /usr/local/vesta/data/templates/web/nginx/default.stpl тем более, что VestaCP перезапишет сделанные вручную в конфигурационном файле изменения.

sudo nano /usr/local/vesta/data/templates/web/nginx/default.stpl

Поддержка SSl и HTTP2

Добавляем следующие два фрагмента:

После %ip%:%proxy_ssl_port% в той же строке:

ssl http2

Также открываем на редактирование файл основной конфигурации nginx:

sudo nano /etc/nginx/nginx.conf

С марта 2020 года все популярные браузеры отключают поддержку TLS 1.0 и TLS 1.1, поэтому в примере приведу два варианта конфигурации.

Находим секцию #SSL PCI Compliance и редактируем в соответствии с моим листингом:

 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
 add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report";
 ssl_stapling on;
## ##Раскомментируйте если нужна поддержка старых протоколов
 #ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
## ## Закомментируйте если включили поддержку старых протоколов
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_prefer_server_ciphers on;
## ## Раскомментируйте для старых протоколов
 #ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
## ## Закомментируйте если включили поддержку старых протоколов
 ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA512:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256";
 ssl_dhparam /home/admin/conf/web/dhparams.pem;
 ssl_session_tickets off;

Также нужно сгенерировать dhparams.pem и положить в нужную папку:

sudo openssl dhparam -out /home/admin/conf/web/dhparams.pem 4096

Вывод

Сегодня научились редактировать конфигурационный файл Web сервера Nginx в админ-панели VestaCP.

Также приведу пример полного конфигурационного файла для VestaCP и секцию SSL для Nginx:

Пример файла default.stpl

server {

listen %ip%:%proxy_ssl_port% ssl http2;
server_name %domain_idn% %alias_idn%;
ssl_certificate %ssl_pem%;
ssl_certificate_key %ssl_key%;
error_log /var/log/%web_system%/domains/%domain%.error.log error;
location / {     
      proxy_pass  https://%ip%:%web_ssl_port%;
      location ~* ^.+.(%proxy_extentions%)$ 
      {
          root %sdocroot%;
          access_log /var/log/%web_system%/domains/%domain%.log combined;
          access_log /var/log/%web_system%/domains/%domain%.bytes bytes;
          expires max;
          try_files $uri @fallback;
      }
}
location /error/ {
     alias %home%/%user%/web/%domain%/document_errors/;
}
location @fallback {
     proxy_pass https://%ip%:%web_ssl_port%;
}
location ~ /.ht {return 404;}
location ~ /.svn/ {return 404;}
location ~ /.git/ {return 404;}
location ~ /.hg/ {return 404;}
location ~ /.bzr/ {return 404;}
include %home%/%user%/conf/web/snginx.%domain%.conf*;

Пример файла nginx.conf

Привожу кусок файла nginx.conf непосредственно секцию SSL PCI Compliance

Включим параметр HSTS, OCSP, dhparam, а также поддержу TLSv1.2 и TLSv.1.3 и алгоритмы шифрования:

### SSL PCI Compliance ###
 ssl_session_cache   shared:SSL:10m;
 ssl_prefer_server_ciphers on;
 ssl_stapling on;
## ## Раскомментируйте если нужна поддержка старых протоколов
 #ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
## ## Закомментируйте если включили поддержку старых протоколов
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_prefer_server_ciphers on;
## ## Раскомментируйте для старых протоколов
 #ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
## ## Закомментируйте если включили поддержку старых протоколов
 ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA512:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256";
 ssl_dhparam /home/admin/conf/web/dhparams.pem;
 ssl_session_tickets off;

После внесения данных изменений на сайте ssllab проверка будет показывать рейтинг A+ для ваших сайтов.

[endtxt]

Сегодня в статье разберём как включить OCSP на web-сервере Nginx с сертификатами от Let`s Encrypt.

Но сперва что же такое OCSP?

OCSP (Online Certificate Status Protocol) – это интернет протокол для проверки статуса SSL-сертификата, который работает быстрее и надежнее, чем это осуществлялось ранее с помощью списков САС (или CRL списков) с отозванными SSL сертификатами.

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

Метод OCSP Stapling помогает быстро и безопасно установить достоверность SSL-сертификата.

Извлекаем промежуточный сертификат Let’s Encrypt

Коннектимся под root:

sudo su

Скачиваем промежуточные сертификаты ЦА

cd /etc/ssl/private && wget -O - https://letsencrypt.org/certs/isrgrootx1.pem https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem https://letsencrypt.org/certs/letsencryptauthorityx1.pem https://www.identrust.com/certificates/trustid/root-download-x3.html | tee -a ca-certs.pem> /dev/null

Настройка OCSP stapling на Nginx с админ-панелью VestaCP

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

sudo nano /home/admin/conf/web/example.com.nginx.ssl.conf

и внесите в раздел server {} следующий блок кода:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/private/ca-certs.pem;

Перезагружаем nginx:

sudo /etc/init.d/nginx restart

Тестируем OCSP на Ubuntu Server

echo QUIT | openssl s_client -connect obu4alka.ru:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update'

Данная команда выдаст следующий результат:

OCSP response:
================================================================ 
 OCSP Response Data:
     OCSP Response Status: successful (0x0)
     Response Type: Basic OCSP Response
     Version: 1 (0x0)
     Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
     Produced At: Sep 14 01:40:00 2019 GMT
     Responses:
     Certificate ID:
       Hash Algorithm: sha1
       Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
       Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
       Serial Number: 03E2EA3D34CED68F180CD2179ABB275275C5
     Cert Status: good
     This Update: Sep 14 01:00:00 2019 GMT
     Next Update: Sep 21 01:00:00 2019 GMT

Онлайн-тест Qualys

Чтобы проверить работу OCSP stapling онлайн, перейдите на этот сайт. Когда тестирование будет завершено, найдите строку OCSP stapling в разделе Protocol Details.

Тестирование ALPN

testsite="obu4alka.ru"; echo | openssl s_client -alpn h2 -connect $testsite:443 -servername $testsite 2>&1 | grep -q "ALPN protocol: h2" && echo "ALPN поддерживается" || echo "ALPN не поддерживается"

либо так:

echo | openssl s_client -alpn h2 -connect obu4alka.ru:443 | grep ALPN

Можете также воспользоваться ещё одним способом проверки, вот ссылка

[endtxt]

RSS

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

Динамический контент Nginx передает CGI, FastCGI или другим веб-серверам, например, Apache. Затем этот контент возвращается Nginx для отправки клиенту. В данном руководстве мы рассмотрим базовые принципы и параметры конфигурации Nginx.

Директивы, блоки и контексты

Все файлы конфигурации Nginx располагаются в директории /etc/nginx/. Основной файл конфигурации – /etc/nginx/nginx.conf.

Опции конфигурации Nginx называются директивами. Директивы организованы в группы, называемые блоками или контекстами (эти два понятия являются синонимами).

Строки, начинающиеся с символа «решетки» (#) – это комментарии. Они не интерпретируются Nginx. Строки с директивами должны оканчиваться на точку с запятой, иначе конфигурация не будет загружена, и вы получите сообщение об ошибке.

Ниже приведена сокращенная копия файла /etc/nginx/nginx.conf, который входит в состав установки. Он начинается с 4 директив: user, worker_processes, error_log, и pid. Они не входят в состав блока, поэтому говорят, что они находятся в контексте main. Блоки events и http содержат дополнительные директивы и также расположены в контексте main.

user nginx;

worker_processes 1;

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

pid /var/run/nginx.pid;



events {

. . .

}



http {

. . .

}

Блок http

Блок http содержит директивы управления веб-трафиком. Они часто называются универсальными, потому что используются для конфигурации всех веб-сайтов, содержащихся на сервере. Полный список всех доступных директив и их параметров для этого блока можно посмотреть в документации Nginx. В /etc/nginx/nginx.conf можно увидить примерно следующий блок http

http {

include /etc/nginx/mime.types;

default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for"';

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

sendfile on;

#tcp_nopush on;

keepalive_timeout 65;

#gzip on;

include /etc/nginx/conf.d/*.conf;

}

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

include – указывает расположение дополнительных файлов конфигурации

default_type – задает MIME-тип ответов по умолчанию

log_format – задает поля, которые будут сохраняться в логе сервера

access_log – путь к файлу лога доступа к серверу

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

tcp_nopush – настройка формирования TCP-пакетов, ускоряющая работу сервера (в данном случае закомментировано)

keepalive_timeout – максимальное время поддержания соединения, если пользователь ничего не запрашивает

gzip – включение компрессии (в данном случае закомментировано)

• Как уже было сказано, блок http содержит директиву include, которая указывает расположение файлов конфигурации Nginx.
  
  Если установка выполнялась из официального репозитория Nginx, эта строка, как и в рассмотренном примере, будет иметь вид include /etc/nginx/conf.d/*.conf;. У каждого веб-сайта на вашем сервере в этой директории должен быть свой файл конфигурации с именем формата example.com.conf. Для отключенных сайтов (не отображаемых Nginx) он может быть переименован в формате example.com.conf.disabled.
• При установке из репозиториев Debian или Ubuntu данная строка будет иметь вид include /etc/nginx/sites-enabled/*;. Директория /sites-enabled/ содержит символические ссылки на файлы конфигурации, которые хранятся в /etc/nginx/sites-available/. Отключение сайта осуществляется удалением символической ссылки на sites-enabled.
• В зависимости от источника установки в /etc/nginx/conf.d/default.conf или /etc/nginx/sites-enabled/default есть пример файла конфигурации.

Серверные блоки

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

server {

listen 80 default_server;

listen [::]:80 default_server;

server_name example.com www.example.com;

root /var/www/example.com;

index index.html;

try_files $uri /index.html;

}

Директива server_name позволяет размещать несколько доменов на одном IP-адресе (виртуальные хосты). Выбор домена осуществляется на основании информации в заголовке полученного запроса.

Директива listen задает Nginx имя или IP-адрес узла и TCP-порт, который он должен прослушивать для HTTP-соединений. Аргумент default_server означает, что этот виртуальный хост будет отвечать на все запросы на порт 80, в которых в явном виде не будет указан другой виртуальный хост. Вторая такая директива устанавливает аналогичное поведение для IPv6-соединений.

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

1.Обработка запросов к example.com и www.example.com:

server_name example.com www.example.com;

2.В директиве server_name можно использовать маски. Например, *.example.com и .example.com указывают серверу обрабатывать запросы на все поддомены example.com:

server_name *.example.com;

server_name .example.com;

3.Обработка запросов ко всем доменным именам, начинающимся с example.:

server_name example.*;

Nginx разрешает указывать имена сервера, не соответствующие правилам доменных имен. Для ответа на запросы используется имя из заголовка HTTP вне зависимости от того, является ли оно допустимым доменным именем.

Это полезно, если ваш сервер работает в локальной сети или вы точно знаете все клиенты, которые будут осуществлять запросы, например, front-end прокси-серверы, у которых записи в /etc/hosts настроены на IP-адрес Nginx.

Блоки Location

Блоки location позволяют настроить, как Nginx будет отвечать на запросы к ресурсам на сервере. Подобно тому, как директива server_name определяет обработку запросов к доменам, директивы location охватывают запросы к конкретным файлам и папкам, таким как http://example.com/blog/. Вот несколько примеров:

location / { }

location /images/ { }

location /blog/ { }

location /planet/ { }

location /planet/blog/ { }

Указанные выше расположения – это точно определенные строки, которые соответствуют части HTTP-запроса после имени узла.

Запрос: http://example.com/

Ответ: Если для example.com есть запись server_name, обработка данного запроса будет определяться директивой location /.

Nginx всегда выполняет запрос, находя наиболее точное соответствие:

Запрос: http://example.com/planet/blog/ или http://example.com/planet/blog/about/

Ответ: Обработку запроса будет определять директива location /planet/blog/, потому что она соответствует точнее, хотя location /planet/ также удовлетворяет условиям запроса.

location ~ IndexPage.php$ { }

location ~ ^/BlogPlanet(/|/index.php)$ { }

Когда после директивы location указана тильда (~), Nginx определяет соответствие по регулярному выражению. Этот поиск всегда чувствителен к регистру. Таким образом, страница IndexPage.php будет соответствовать первому из приведенных выше примеров, а indexpage.php – нет. Во втором примере регулярному выражению будут соответствовать запросы к /BlogPlanet/ и /BlogPlanet/index.php, но не /BlogPlanet, /blogplanet/, или /blogplanet/index.php. В Nginx используются Perl-совместимые регулярные выражения.

Если вы хотите, чтобы поиск не был чувствителен к регистру, после тильды нужно указать звездочку (~*).

location ^~ /images/IndexPage/ { }

location ^~ /blog/BlogPlanet/ { }

Если указать перед тильдой символ «крышки» (^~), при соответствии запроса указанной строке сервер прекратит поиск более точных соответствий (даже если они есть) и будет использовать эти директивы. Во всем остальном они аналогичны рассмотренным выше директивам.

location = / { }

Знак равенства (=) после директивы location означает необходимость точного соответствия указанному пути. В случае его наличия поиск прекращается. Например, запрос http://example.com/ будет соответствовать указанному выше примеру, а http://example.com/index.html — нет. Использование точных соответствий может ускорить время обработки запроса, если какие-то запросы распространены больше других.

Директивы обрабатываются в следующем порядке:

1. Сначала обрабатываются точные соответствия строк. Если соответствие найдено, Nginx прекращает поиск и отвечает на запрос.
2. Обрабатываются оставшиеся директивы с точно заданными строками. Если Nginx находит соответствие директиве с аргументом ^~, он прекращает поиск и отвечает на запрос. В противном случае обработка директив location продолжается.
3. Обрабатываются директивы location с регулярными выражениями (~ и ~*). Если запрос соответствует регулярному выражению, Nginx прекращает поиск и отвечает на запрос.
4. Если соответствия регулярным выражениям не найдено, используется наиболее точное соответствие из жестко заданных строк.

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

Внутри блока location указываются собственные директивы, например:

location / {

root html;

index index.html index.htm;

}

В данном примере корень документов находится в директории html/. При установке Nginx в месторасположение по умолчанию она находится в /etc/nginx/html/. В директиве root также можно использовать абсолютный путь.

Запрос: http://example.com/blog/includes/style.css

Ответ: Nginx попытается передать клиенту файл /etc/nginx/html/blog/includes/style.css

Переменная index сообщает Nginx, какой файл передавать, если клиент не указал конкретное имя, например:

Запрос: http://example.com

Ответ: Nginx попытается передать файл /etc/nginx/html/index.html.

Если в директиве index указано несколько файлов, Nginx пройдет по списку и передаст первый существующий файл. Если файла index.html в соответствующей директории нет, будет передан index.htm. В случае если ни один из файлов не существует, будет отправлено сообщение об ошибке 404.

Вот более сложный пример набора директив location для сервера example.com:

location / {

root /srv/www/example.com/public_html;

index index.html index.htm;

}

location ~ .pl$ {

gzip off;

include /etc/nginx/fastcgi_params;

fastcgi_pass unix:/var/run/fcgiwrap.socket;

fastcgi_index index.pl;

fastcgi_param SCRIPT_FILENAME /srv/www/example.com/public_html$fastcgi_script_name;

}

В данном примере все запросы ресурсов, которые заканчиваются на расширение .pl, будут обработаны вторым блоком location, в котором для ответа на эти запросы задан обработчик fastcgi. Ресурсы расположены в файловой системе /srv/www/example.com/public_html/. Если имя файла в запросе не указано, Nginx найдет и передаст файл index.html или index.htm. Если их нет, он выдаст ошибку 404.

Разберем ответы на некоторые запросы

Запрос: http://example.com/

Ответ: /srv/www/example.com/public_html/index.html если файл существует. Если нет, сервер передаст /srv/www/example.com/public_html/index.htm. Если и этот файл не существует, Nginx выдаст ошибку 404.

Запрос: http://example.com/blog/

Ответ: /srv/www/example.com/public_html/blog/index.html если файл существует. Если нет, сервер передаст /srv/www/example.com/public_html/blog/index.htm. Если и этот файл не существует, Nginx выдаст ошибку 404.

Запрос: http://example.com/tasks.pl

Ответ: Nginx воспользуется обработчиком FastCGI для выполнения файла /srv/www/example.com/public_html/tasks.pl и выдаст результат.

Запрос: http://example.com/username/roster.pl

Ответ: Nginx воспользуется обработчиком FastCGI для выполнения файла /srv/www/example.com/public_html/username/roster.pl и выдаст результат.

Заключение

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