Настройка и установка Nginx: пример запуска nginx conf

Nginx — один из самых используемых веб-серверов. Он обогнал по популярности Apache, который много лет был лидером рынка. Согласно данным исследования W3Techs за сентябрь 2025 года, на Nginx размещено 33,2% сайтов. В статье разберемся в причинах такой популярности веб-сервера и расскажем, как его настроить и использовать.

Инструкции

Иллюстрация для статьи на тему «Настройка и установка Nginx: пример запуска nginx conf»

31 октября 2025 13 минут

Марина СувороваГлавный редактор блога

Время чтения13 минут

Дата публикации31 октября 2025

Продукты из этой статьи:

Evolution Compute

Содержание

Что такое Nginx, как он работает
Подготовка к установке
Подготовка окружения для установки Nginx
Установка Nginx
Структура каталогов Nginx
Конфигурирование nginx.conf
Основные команды для работы с Nginx и проверки конфигурации
Расширенная настройка Nginx
Управление и мониторинг Nginx
Распространенные ошибки и их устранение
Настройки для предотвращения DDoS-атак
Заключение

Что такое Nginx, как он работает

Nginx — веб-сервер на основе открытого исходного кода, разработанный в 2002 году Игорем Сысоевым. С 2004 года он доступен для свободного использования. Есть опенсорсная бесплатная версия и платные — Nginx Plus, Angie, OpenResty. Они позволяют применять дополнительные правила балансировки нагрузки и мониторить активность сервера.

Nginx может работать как обычный сервер — обрабатывать HTTP-запросы от браузера клиента и отправлять запрашиваемые файлы, например, фото, видео, текст, JS-скрипты.

Принцип работы Nginx

Дарим до 20 000 бонусов

4 000 бонусов — физическим лицам, 20 000 бонусов — юридическим

В отличие от большинства веб-серверов, Nginx не придерживается событийно-ориентированной модели обработки HTTP-запросов. Это значит, что он не блокирует ввод-вывод при поддержке множества соединений. То есть, если клиент запрашивает передачу «тяжелого» файла, Nginx запускает ее, но при этом продолжает получать и обрабатывать другие запросы. Таким образом, сервер может одновременно обслуживать большое количество запросов, что минимизирует время ожидания для клиента и оптимизирует использование ресурсов.

Принцип обработки запросов сервером Nginx

Nginx вышел далеко за рамки веб-сервера и предлагает комплексное решение для современных IT-инфраструктур:

Веб-сервер — статический контент и FastCGI.
Прокси — обратный прокси, кэширование, медиа-потоки.
Балансировщик нагрузки — распределение трафика + SSL-терминация.
Security Gateway — защита от атак, rate limiting, WAF.
API Gateway — маршрутизация, аутентификация, мониторинг API.
Nginx обрабатывает TLS-шифрование, снижает нагрузку на бэкенды и обеспечивает безопасность всего трафика в единой платформе.

Сравнение Nginx и Apache

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

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

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

Другие отличия представлены в таблице.

Характеристика	Nginx	Apache
Тип сервера	Асинхронный	Процессно-ориентированный сервер (Process-driven)
Производительность	Высокая производительность при обработке большого числа соединений, незначительные задержки	Хорошо работает для небольших сайтов, но может терять в производительности на высоких нагрузках
Обработка запросов	Обрабатывает запросы асинхронно, используя один рабочий процесс для множества соединений	Каждый запрос обрабатывается отдельным процессом или потоком, что не очень эффективно при многочисленных запросах
Масштабируемость	Простая масштабируемость благодаря асинхронной обработке	Масштабируемость ограничена из-за процессно-ориентированной модели
Конфигурация	Конфигурация простая и компактная, но с некоторыми ограничениями в гибкости	Гибкая конфигурация с множеством параметров и опций
Использование памяти	Низкое потребление памяти, так как используется один процесс для множества соединений	Более высокое потребление памяти из-за необходимости создания нового процесса или потока для каждого запроса
Поддержка протоколов	HTTP, HTTPS, TCP, UDP, WebSocket, FTP (в некоторых случаях)	HTTP, HTTPS, FTP, IMAP, POP3 и другие (через дополнительные модули)
Модульность	Поддерживает ограниченное количество модулей, встроенные функции намного быстрее	Высокая модульность, поддерживает множество сторонних модулей для разных нужд
Логирование	Логирование простое, но гибкое с поддержкой различных форматов	Логирование более гибкое, поддерживает расширенные функции и форматы
Поддержка серверов с динамическим содержимым	Подходит для статического контента, поддерживает динамические сайты через обратное проксирование	Работает с динамическим контентом благодаря поддержке различных языков (PHP, Perl, Python и т.д.)
Использование в качестве реверс-прокси	Подходит в качестве реверс-прокси для балансировки нагрузки и обратного проксирования	Редко используется в роли реверс-прокси, но поддерживает такую возможность через модули
Установка и настройка	Простота в установке и настройке для большинства случаев использования	Требует больше настроек для гибкости, но более универсален
Обновления и безопасность	Регулярные обновления и быстрые патчи безопасности	Регулярные обновления, но с большими усилиями на настройку безопасности
Поддержка OS	Поддерживает Linux, BSD, Windows (ограниченная поддержка)	Поддерживает Linux, BSD, Windows, macOS и другие ОС

Можно использовать для своего сайта оба веб-сервера. В этом случае Nginx будет обрабатывать статический контент, а Apache — динамический.

Подготовка к установке

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

Минимальные системные требования

Nginx поддерживает:

все основные дистрибутивы Linux: Ubuntu, Debian, CentOS, Red Hat Enterprise Linux, Fedora, Alpine Linux (в случае использования Docker);
на macOS он обычно используется для локальной разработки и тестирования;
с Windows сложнее, поскольку есть ограничения: версия Nginx под Windows пока рассматривается как бета-версия, но установить ее можно.

Что касается процессора, то нужна x86-64 архитектура или ARM. Тактовая частота — 1 ГГц и выше. Nginx не требует значительных вычислительных мощностей, но для большого количества соединений лучше использовать серверы с мощными процессорами.

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

Выбор инфраструктуры для развертывания Nginx

При планировании развертывания Nginx важно определиться с инфраструктурой. Для продакшен-среды, развития и тестирования оптимальным решением станут облачные виртуальные машины, которые обеспечивают гибкость масштабирования и высокую доступность. Сервис Evolution Compute предоставляет виртуальные машины с гибкими конфигурациями на базе актуальных процессоров Intel Gold 6248R и быстрыми NVMe-дисками, что критично для высокопроизводительной работы веб-сервера.

Виртуальные машины Evolution Compute

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

Узнать больше

Преимущества облачных виртуальных машин для Nginx включают возможность быстрого масштабирования в периоды высокой нагрузки, оплату по факту использования ресурсов и SLA на доступность 99,9%. Через удобный русскоязычный интерфейс, API или Terraform вы можете управлять инфраструктурой, создавать группы серверов для балансировки нагрузки и выделять изолированные окружения для разработки, тестирования и продакшена. Для начального тестирования доступна бесплатная конфигурация с 2 vCPU, 4 ГБ RAM и 30 ГБ дискового пространства.

Подготовка окружения для установки Nginx

Перед установкой Nginx обновите системные пакеты до последних версий:

Ubuntu/Debian: sudo apt update && sudo apt upgrade -y
CentOS/RHEL: sudo yum update -y

Для корректной работы и сборки Nginx могут потребоваться определенные зависимости — компилятор, библиотеки для работы с SSL, PCRE и сжатия. Рекомендуется ориентироваться на официальные инструкции по установке пакетов, так как перечень пакетов может отличаться в зависимости от версии системы и дистрибутива.

Если на сервере настроен фаервол (например, UFW на Ubuntu), откройте порты 80 и 443 для HTTP и HTTPS-трафика:

Для UFW на Ubuntu	Для firewalld на CentOS/RHEL
sudo ufw allow 'Nginx Full' sudo ufw enable	sudo firewall-cmd --permanent --zone=public --add-service=http sudo firewall-cmd --permanent --zone=public --add-service=https sudo firewall-cmd --reload

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

ping google.com

Перед установкой Nginx на всякий случай создайте резервные копии системных настроек и данных.

Установка Nginx

Процесс установки Nginx может отличаться в зависимости от операционной системы и дистрибутива. Рекомендуется ориентироваться на официальные инструкции с сайта nginx.org, где подробно описаны способы установки, актуальные для различных платформ. Ниже приведены основные шаги для популярных ОС с учетом рекомендуемых методов.

Установка на Ubuntu и Debian-подобных системах

Для устойчивой работы используйте официальные репозитории Nginx. Добавьте репозиторий и ключ:

sudo apt update
sudo apt install curl gnupg2 ca-certificates lsb-release
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list
sudo apt update

Установите Nginx:

sudo apt install nginx

Запустите и проверьте статус сервера:

sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl status nginx

При необходимости настройте фаервол для доступа к HTTP и HTTPS.

Добавьте репозиторий Nginx согласно инструкции на официальном сайте:

sudo yum install epel-release
sudo curl -o /etc/yum.repos.d/nginx.repo https://nginx.org/packages/centos/nginx.repo

Для Fedora используйте аналогичный подход с dnf.

Установите Nginx, затем запустите и активируйте автозапуск:

sudo yum install nginx
sudo systemctl start nginx
sudo systemctl enable nginx

Настройте фаервол, разрешив HTTP и HTTPS:

sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload

Установка на macOS

Установка через Homebrew — наиболее простой и рекомендуемый способ:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install nginx

Конфигурационный файл находится по пути: /usr/local/etc/nginx/nginx.conf.

Установка на Windows

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

Установка в Docker

Nginx можно запускать в Docker — платформе для контейнеризации приложений. Сначала нужно установить Docker Engine, следуя официальной инструкции для вашей операционной системы. На странице выберите свою ОС (Ubuntu, Debian, CentOS, macOS, Windows) и следуйте пошаговому руководству для корректной установки.

После установки Docker запустите Nginx с помощью официального образа из Docker Hub. Откройте терминал и выполните команду:

docker run --name nginx-container -p 8080:80 -d nginx

Параметры команды:

--name nginx-container — задает имя контейнера
-p 8080:80 — пробрасывает порт 80 контейнера на порт 8080 хоста
-d — запускает контейнер в фоновом режиме

После выполнения команды Docker автоматически загрузит образ Nginx (если его еще нет локально), создаст и запустит контейнер. Чтобы проверить работоспособность, откройте браузер и перейдите по адресу http://localhost:8080. Если на экране появится страница «Welcome to nginx!», значит, контейнер успешно запущен и работает.

Структура каталогов Nginx

Структура каталога включает несколько основных директорий:

etc/nginx — директория, где хранятся основные файлы настроек и /etc/nginx/nginx.conf — главный конфигурационный файл Nginx;
/etc/nginx/sites-available — каталог с конфигурациями для каждого сайта, который обслуживается Nginx;
/etc/nginx/sites-enabled — директория с конфигурациями для всех активных сайтов, которые обслуживаются Nginx;
/var/www/ssl — каталог, где хранятся файлы, связанные с SSL-сертификатами;
/etc/nginx/snippets — фрагменты конфигурационных файлов, включенных в nginx.conf;
/var/log/nginx — директория с лог-файлами. Сюда сохраняются все логи Nginx.

Могут быть и другие каталоги, например, /run/nginx/ для хранения временных файлов, связанных с работой Nginx или /usr/share/nginx/, куда сохраняются статические ресурсы.

Примерная структура каталогов Nginx на сервере может выглядеть так:

/etc/nginx/                          # Главная директория конфигурации Nginx
│
├── nginx.conf                       # Основной конфигурационный файл
│
├── conf.d/                          # Дополнительные конфигурации
│   └── default.conf                 # Конфигурация по умолчанию
│
├── sites-available/                 # Доступные сайты (неактивные)
│   └── example.com                  # Конфигурация сайта example.com
│
├── sites-enabled/                   # Активные сайты (символические ссылки)
│   └── example.com                  # -> /etc/nginx/sites-available/example.com
│
└── snippets/                        # Переиспользуемые фрагменты конфигурации
    └── ssl-params.conf              # Параметры SSL

/var/www/                            # Директория веб-контента
└── html/                            # HTML-файлы сайта
    └── index.html                   # Главная страница

/var/log/nginx/                      # Логи Nginx
├── access.log                       # Лог доступа к сайту
└── error.log                        # Лог ошибок

/run/nginx/                          # Рантайм-файлы
└── nginx.pid                        # Файл с ID процесса Nginx

/usr/share/nginx/                    # Системные файлы Nginx
└── html/                            # Стандартные страницы ошибок
    └── 404.html                     # Страница ошибки 404

Конфигурирование nginx.conf

Конфигурирование nginx.conf — настройка веб-сервера Nginx путем редактирования файла nginx.conf, который содержит все основные настройки. Оно включает работу со структурой конфигурационного файла и ключевыми директивами.

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

Main Context — глобальные настройки, которые будут влиять на работу сервера.

Main Context

HTTP Context — настройки для обработки запросов, проксирования, кеширования.

HTTP Context

Server Context — настройки для конкретных хостов.

Server Context

Error Pages — настройки отображения страниц ошибок.

Error Pages

SSL и HTTPS — настройка SSL-сертификатов.

SSL и HTTPS

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

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

Создадим простой конфигурационный файл для NGINX с базовой настройкой:

# Основные настройки
user www-data;              # Пользователь и группа для работы NGINX
worker_processes auto;      # Автоматическое определение числа рабочих процессов
pid /var/run/nginx.pid;     # Файл с PID процесса
include /etc/nginx/mime.types;  # Типы контента
default_type application/octet-stream;

# Логирование
error_log /var/log/nginx/error.log;
access_log /var/log/nginx/access.log;

# Настройки HTTP
http {
    include /etc/nginx/mime.types;  # Типы MIME
    default_type application/octet-stream;

    # Основные настройки для HTTPS
    server {
        listen 80;
        server_name example.com www.example.com;  # Домены

        # Перенаправление с HTTP на HTTPS
        return 301 https://$host$request_uri;
    }

    server {
        listen 443 ssl;
        server_name example.com www.example.com;  # Домены

        # Пути к SSL-сертификату и ключу
        ssl_certificate /etc/nginx/ssl/example.com.crt;  # Путь к SSL-сертификату
        ssl_certificate_key /etc/nginx/ssl/example.com.key;  # Путь к приватному ключу

        # Рекомендуемые SSL-настройки для безопасной связи
        ssl_protocols TLSv1.2 TLSv1.3;  # Использование только безопасных версий протокола TLS
        ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-RSA-AES128-GCM-SHA256';  # Рекомендуемые шифры
        ssl_prefer_server_ciphers on;

        # Настройка корня и индексного файла
        root /var/www/example.com;  # Путь к корневой директории сайта
        index index.html index.htm;  # Индексные файлы

        # Настройка локации (для обработки всех запросов)
        location / {
            try_files $uri $uri/ =404;  # Поиск запрашиваемого файла или ошибка 404
        }

        # Страница ошибки
        error_page 404 /404.html;
        location = /404.html {
            root /usr/share/nginx/html;
        }
    }
}

Расшифруем:

Основные настройки (Main Settings):

user: пользователь и группа, от имени которых будут работать процессы NGINX (обычно это www-data для Debian/Ubuntu);
worker_processes: количество рабочих процессов. Обычно ставят auto;
pid: путь к файлу с идентификатором процесса NGINX.

HTTP → HTTPS перенаправление:

Перенаправление с порта 80 на порт 443 с помощью директивы return 301 https://$host$request_uri;.

Настройки SSL:

listen 443 ssl;: сервер будет слушать порт 443 для безопасных HTTPS-соединений;
ssl_certificate и ssl_certificate_key: путь к SSL-сертификату и приватному ключу;
ssl_protocols и ssl_ciphers: безопасные протоколы и шифры для SSL-соединений;
ssl_prefer_server_ciphers on;: команда, которая указывает, что сервер предпочитает собственные шифры.

Корневая директория и индексы:

root: каталог, который будет корневой директорией для сайта. В примере это /var/www/example.com;
index: указывает, какие файлы будут индексными (например, index.html).

Обработка ошибок:

error_page 404 /404.html;: определяет страницу ошибки 404, которая будет отображаться, если запрошенного ресурса не существует.

Основные команды для работы с Nginx и проверки конфигурации

Для запуска Nginx используйте команду:

sudo systemctl start nginx

Для перезапуска используется команда:

sudo systemctl restart nginx

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

sudo systemctl stop nginx

Узнать, работает ли Nginx и увидеть текущий статус поможет команда:

sudo systemctl status nginx

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

sudo systemctl reload nginx

Для проверки конфигурации Nginx на ошибки используйте команду:

sudo nginx -t

Если конфигурация правильная, появится сообщение: syntax is okay и test is successful. Если есть что-то не так, Nginx укажет на ошибки.

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

sudo tail -f /var/log/nginx/access.log

Чтобы просмотреть логи ошибок:

sudo tail -f /var/log/nginx/error.log

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

sudo truncate -s 0 /var/log/nginx/access.log
sudo truncate -s 0 /var/log/nginx/error.log

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

sudo nginx -s reload

Расширенная настройка Nginx

После основных настроек следует позаботиться о безопасности: установить SSL-сертификаты, настроить перенаправление и кэширование.

Установка и настройка SSL-сертификатов

Если у вас уже есть сертификат и приватный ключ на локальной машине, скопируйте их на сервер в каталог /var/www/ssl с помощью команды scp:

scp {privkey.pem,cert.pem} username@SERVER-IP:/var/www/ssl/

Проверьте, что читать ключ может только root-пользователь:

# Установка владельца для приватного ключа
chown root:root /var/www/ssl/privkey.pem

# Установка прав 600 для приватного ключа (только владелец может читать и записывать)
chmod 600 /var/www/ssl/privkey.pem

# Установка прав 644 для публичного сертификата (владелец может читать/записывать, остальные только читать)
chmod 644 /var/www/ssl/cert.pem

Проверьте синтаксис:

sudo openssl pkey -in privkey.pem -check -noout

Проверьте соответствие ключа и сертификата:

sudo openssl x509 -in certificate.crt -noout -pubkey | openssl pkey -pubin -outform pem | sha256sum

sudo openssl pkey -in private.key -pubout -outform pem | sha256sum

Настройте SSL в Nginx:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /var/www/ssl/cert.pem;
    ssl_certificate_key /var/www/ssl/privkey.pem;
    
    location / {
        ...
    }
}

Можно настроить дополнительные параметры SSL-сессий, но сайт будет использовать SSL/TLS и без них.

Редиректы и перенаправления

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

Откройте файл конфигурации вашего сайта. Обычно он находится в директории /etc/nginx/sites-available/ или /etc/nginx/conf.d/ (например, /etc/nginx/sites-available/example.com). Добавьте блок конфигурации для перенаправления HTTP-трафика на HTTPS:

 server {
    listen 80;
    server_name example.com www.example.com;

    # Редирект с HTTP на HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    # Путь к SSL-сертификатам
    ssl_certificate /etc/ssl/certs/your_domain.crt;
    ssl_certificate_key /etc/ssl/private/your_domain.key;

    # Основные настройки сайта
    root /var/www/html;
    index index.html;

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

listen 80; — указывает на порт 80 (HTTP);
return 301 https://$host$request_uri; — директива, перенаправляющая все запросы на HTTPS с сохранением хоста и URI;
listen 443 ssl; — сервер будет слушать на порту 443 (HTTPS);
ssl_certificate и ssl_certificate_key — указывают на путь к SSL-сертификату и закрытому ключу.

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

Еще примеры редиректов — в таблице.

Сценарий	Пример конфигурации	Пояснение
Редирект с поддоменов на основной домен	server { listen 80; server_name www.example.com; return 301 $scheme://example.com$request_uri; }	Все запросы с www.example.com будут перенаправлены на example.com, при этом сохранятся все параметры запроса (например, http://www.example.com/page перенаправится на https://example.com/page). $scheme сохраняет протокол (http или https), а $request_uri сохраняет путь и параметры запроса
Редирект с одного порта на другой	server { listen 8080; server_name example.com; return 301 http://$host$request_uri; }	Все запросы к порту 8080 будут перенаправляться на стандартный HTTP порт 80. $host сохраняет имя хоста, а $request_uri сохраняет путь и параметры запроса.

Кэширование и оптимизация

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

Пример конфигурации:

server {
    listen 80;
    server_name example.com;

    location / {
        root /var/www/html;
        index index.html;
    }

    # Настройка кэширования статических файлов (изображений, CSS, JS)

    location ~* \.(jpg|jpeg|png|gif|css|js|ico|pdf|woff|woff2|ttf|svg)$ {
        expires 30d;  # Кэширование на 30 дней
        add_header Cache-Control "public, no-transform";
    }
}

expires 30d; — указывает, что период кэширования файлов с расширениями .jpg, .jpeg, .png, .css составляет 30 дней;
add_header Cache-Control "public, no-transform"; — добавляет заголовок Cache-Control, указывающий на возможность кэширования ресурсов.

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

Конфигурация:

http {
    # Определение кэширующей зоны
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static_cache:10m inactive=60m max_size=100m;

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend-server;  # Проксируем запросы на бэкенд сервер
            proxy_cache static_cache;          # Указываем кэш
            proxy_cache_valid 200 60m;        # Кэшируем успешные ответы на 60 минут
            proxy_cache_use_stale error timeout updating;  # Используем устаревший кэш, если сервер недоступен
            add_header X-Cache $upstream_cache_status;  # Добавление заголовка для отслеживания статуса кэша
        }
    }
}

proxy_cache_path — указывает директорию для хранения кэшированных данных, размер и параметры кэширования;
proxy_cache — активирует использование кэша;
proxy_cache_valid 200 60m; — указывает, что успешные ответы будут кэшироваться в течение 60 минут;
proxy_cache_use_stale — использование устаревшего кэша, если бэкенд-сервер недоступен;
add_header X-Cache $upstream_cache_status; — добавляет заголовок X-Cache в ответ, чтобы можно было увидеть, используется ли кэш.

Если используете PHP, можно настроить кэширование с помощью директивы fastcgi_cache.

Пример конфигурации:

http {
    # Определение кеширующей зоны
    fastcgi_cache_path /var/cache/nginx/fastcgi_cache levels=1:2 keys_zone=fastcgi_cache:10m inactive=60m;

    server {
        listen 80;
        server_name example.com;

        location / {
            fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
            fastcgi_cache fastcgi_cache;          # Указываем кэш для fastcgi
            fastcgi_cache_valid 200 60m;         # Кэширование на 60 минут для успешных запросов
            fastcgi_cache_use_stale error timeout updating;  # Использование устаревшего кэша при ошибках
            fastcgi_cache_key $scheme$host$request_uri;  # Уникальный ключ кэша
            add_header X-Cache $upstream_cache_status;  # Добавление заголовка для отслеживания кэширования
        }
    }
}

fastcgi_cache_path — указывает место для хранения кэша;
fastcgi_cache — активирует использование кэша для PHP;
fastcgi_cache_valid 200 60m; — указывает, что успешные ответы от сервера PHP будут кэшироваться на 60 минут;
fastcgi_cache_use_stale — указывает, что при проблемах с сервером PHP будет использоваться устаревший кэш;
fastcgi_cache_key — задает ключ кэширования для уникальности.

Балансировка нагрузки и проксирование

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

Основные методы методы балансировки в Nginx:

Round Robin — запросы распределяются между серверами поочередно. Например, первый запрос на первый сервер, второй на второй, третий — снова на первый и так дальше по циклу.
Least Connections — запросы направляются на сервер с меньшим числом активных соединений.
IP Hash — сервер для следующего запроса определяется на основе IP-адреса клиента с помощью хеш-функции.

Использование Round Robin:

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend;  # Перенаправление трафика на группу серверов
        }
    }
}

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

Использование Least Connections:

http {
    upstream backend {
        least_conn;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend;  # Перенаправление трафика на группу серверов
        }
    }
}
Использование IP Hash: 
http {
    upstream backend {
        ip_hash;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://backend;  # Перенаправление трафика на группу серверов
        }
    }
}

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

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

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend-server;  # Проксирование на сервер backend-server
        proxy_set_header Host $host;       # Устанавливаем оригинальный заголовок Host
        proxy_set_header X-Real-IP $remote_addr;  # Передача реального IP клиента
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # Передача цепочки IP-адресов
        proxy_set_header X-Forwarded-Proto $scheme;  # Протокол (http или https)
    }
}

Управление и мониторинг Nginx

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

Мониторинг осуществляется с помощью встроенных инструментов Nginx и сторонних сервисов. В таблице мы собрали основные варианты.

Метод мониторинга	Описание	Пример конфигурации
Использование модуля stub_status	Встроенный модуль Nginx для получения информации о текущем состоянии сервера, включая активные соединения, количество запросов и другие метрики	server { listen 127.0.0.1:8080; server_name localhost; location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } }
Prometheus + Grafana	Использование Nginx Exporter для сбора метрик с Nginx, которые передаются в Prometheus и отображаются в Grafana для визуализации и аналитики	wget https://github.com/nginxinc/nginx-prometheus-exporter/releases/download/v0.9.0/nginx-prometheus-exporter-0.9.0.amd64.tar.gz tar -xvzf nginx-prometheus-exporter-0.9.0.amd64.tar.gz Конфигурация Prometheus: scrape_configs: - job_name: 'nginx' static_configs: - targets: ['localhost:9113']
Datadog	Внешний сервис мониторинга, который интегрируется с Nginx для сбора и анализа метрик в реальном времени, включая ошибки, производительность и состояние сервера	Установка Datadog Agent: sudo apt-get install datadog-agent Конфигурация в datadog.yaml: nginx: nginx_status_url: http://localhost:8080/nginx_status
Логирование с использованием ELK Stack	Использование Elasticsearch, Logstash и Kibana (ELK) для сбора, хранения и визуализации логов Nginx. Это позволяет анализировать запросы, ошибки и другие параметры работы сервера	Конфигурация Nginx для логирования: access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log;
Netdata	Инструмент для мониторинга системных метрик (CPU, память, диск, сетевые соединения) в реальном времени. Netdata может быть использован для мониторинга Nginx и других серверных параметров	Установка Netdata: bash <(curl -Ss https://my-netdata.io/kickstart.sh) Доступ к интерфейсу: http://localhost:19999
Мониторинг с использованием top, htop, dstat	Простейшие инструменты для мониторинга системных метрик: использования CPU, памяти, сетевого трафика и т.д	Пример использования: htop dstat
Использование nginx -t для проверки конфигурации	Используется для проверки синтаксиса конфигурационного файла Nginx. Это помогает оперативно выявлять ошибки в конфигурации	Проверка конфигурации: sudo nginx -t Перезагрузка сервера: sudo systemctl reload nginx

Распространенные ошибки и их устранение

Для удобства мы собрали возможные проблемы с Nginx, их причины и решения в таблицу.

Ошибка	Описание	Возможные причины	Решение
502 Bad Gateway	Nginx не может получить правильный ответ от бэкэнд-сервера	1. Проблемы с бэкэнд-сервером (не отвечает или перегружен) 2. Неправильная конфигурация проксирования (например, неправильные параметры proxy_pass) 3. Бэкэнд-сервер не запущен или недоступен	1. Проверьте логи ошибок Nginx: sudo tail -f /var/log/nginx/error.log 2. Убедитесь, что бэкэнд-сервер работает и доступен 3. Проверьте параметры proxy_pass в конфиге Nginx 4. Увеличьте тайм-ауты: proxy_connect_timeout 600;, proxy_send_timeout 600;, proxy_read_timeout 600;.
504 Gateway Timeout	Nginx не получил ответ от бэкэнд-сервера в течение установленного времени	1. Бэкэнд-сервер работает медленно или перегружен 2. Низкая пропускная способность или проблемы с сетью 3. Тайм-ауты на уровне Nginx или бэкэнд-сервера слишком короткие	1. Проверьте логи ошибок Nginx: sudo tail -f /var/log/nginx/error.log 2. Увеличьте тайм-ауты на уровне Nginx и бэкэнд-сервера 3. Проверьте нагрузку на бэкэнд-сервер и его производительность
403 Forbidden	Ошибка доступа к ресурсу	1. Неправильные права доступа на файлы/каталоги. 2. Конфигурация безопасности блокирует доступ 3. Ошибки в .htaccess или настройках location.	1. Проверьте права доступа: sudo chmod -R 755 /var/www/html, sudo chown -R www-data:www-data /var/www/html 2. Проверьте конфигурацию Nginx на ограничения доступа 3. Убедитесь, что SELinux не блокирует доступ: sudo setenforce 0.
404 Not Found	Ошибка, когда запрашиваемый ресурс не найден	1. Неправильные пути в конфигурации Nginx 2. Ресурс был удален или перемещен 3. Неверная настройка маршрутизации для виртуальных хостов	1. Проверьте пути в конфигурации Nginx. 2. Убедитесь, что файл существует на сервере. 3. Перезапустите Nginx: sudo systemctl restart nginx.
500 Internal Server Error	Ошибка, указывающая на проблему на сервере при обработке запроса	1. Ошибки в коде бэкэнд-приложения 2. Проблемы с конфигурацией Nginx. 3. Неправильные разрешения на файлы/каталоги	1. Просмотрите логи ошибок Nginx: sudo tail -f /var/log/nginx/error.log 2. Проверьте логи бэкэнд-приложения 3. Проверьте права доступа к файлам: sudo chown -R www-data:www-data /var/www/html, sudo chmod -R 755 /var/www/html 4. Перезапустите Nginx: sudo systemctl restart nginx

Настройки для предотвращения DDoS-атак

DDoS-атаки или распределенный отказ в обслуживании — попытки хакеров «положить» серверы шквалом бессмысленных запросов. Следует предусмотреть вероятность такой атаки и подготовиться — ограничить количество запросов с одного IP-адреса за определенный промежуток времени. Это можно сделать с помощью модуля limit_req.

Откройте конфигурационный файл Nginx nginx.conf, добавьте блок для ограничения скорости запросов:

http {
    # Настройка лимита запросов
    limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=10r/s;

    server {
        # Применение лимита запросов
        location / {
            limit_req zone=req_limit_per_ip burst=20 nodelay;
            # Ваши остальные настройки
        }
    }
}

rate=10r/s — позволяет обрабатывать до 10 запросов в секунду от одного IP;
burst=20 — позволяет краткосрочно превышать лимит, например, на 20 запросов.

Ограничить количество одновременных соединений с одного IP-адреса можно с помощью модуля limit_conn. В nginx.conf добавьте следующую настройку:

 http {
    # Настройка лимита соединений
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    server {
        # Применение лимита соединений
        location / {
            limit_conn addr 1;  # Ограничение на 1 соединение от одного IP
            # Ваши остальные настройки
        }
    }
}

Комбинация limit_conn addr 1 ограничивает количество активных соединений с одного IP-адреса до 1.

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

server {
    location / {
        deny 192.168.1.1;   # Блокировка конкретного IP
        allow 127.0.0.1;     # Разрешение для локального хоста
        # Ваши остальные настройки
    }
  }

Заключение

Чтобы эффективно работать с Nginx, нужно разобраться со структурой конфигурационного файла nginx.conf и выполнить базовые настройки. Только после этого можно фокусироваться на безопасности и оптимизации производительности.