Готовые конфигурации Nginx: практические шаблоны для DevOps и сисадминов | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Готовые конфигурации Nginx: практические шаблоны для DevOps и сисадминов

03 мая 2026 10 мин. чтения
Содержание статьи

Почему готовые шаблоны Nginx - ваш инструмент для скорости и надежности

Ручная настройка Nginx отнимает время. Сложность официальной документации создает риск ошибок в production-среде. Решение - проверенные шаблоны как строительные блоки для стандартных задач.

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

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

Базовый шаблон: структура конфигурационного файла и виртуальные хостов

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

Основной файл конфигурации - nginx.conf. Виртуальные хосты обычно размещаются в директориях sites-available и симлинкуются в sites-enabled. Вот минимальный рабочий шаблон виртуального хоста с комментариями:

# /etc/nginx/sites-available/example.com
server {
    # Директива listen: порт 80 для HTTP, IPv6, параметр default_server
    listen 80;
    listen [::]:80;
    
    # Директива server_name: точное имя домена
    server_name example.com www.example.com;
    
    # Корневая директория сайта и файл индекса
    root /var/www/example.com/html;
    index index.html index.htm;
    
    # Логирование: access_log и error_log
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;
    
    location / {
        try_files $uri $uri/ =404;
    }
}

Ключевые директивы базового server блока: что нужно знать обязательно

Понимание этих директив критично для уверенной работы.

  • listen: Определяет порт и адрес для прослушивания. Параметр default_server делает этот блок обработчиком запросов по умолчанию для IP-адреса.
  • server_name: Сопоставляет имена доменов. Поддерживает точные имена (example.com), поддомены (www.example.com), wildcard (*.example.com) и регулярные выражения.
  • root: Задает корневую директорию для запросов. Используйте абсолютные пути. Относительные пути вычисляются от директории конфигурации.
  • index: Определяет файлы, которые Nginx будет искать при обращении к директории. Порядок имеет значение.
  • access_log и error_log: Настройте раздельное логирование для каждого виртуального хоста. Это упрощает диагностику проблем.

Практический пример: создание двух виртуальных хостов для test1.domain.com и test2.domain.com.

  1. Создайте файлы /etc/nginx/sites-available/test1 и /etc/nginx/sites-available/test2 с разными server_name и root.
  2. Создайте симлинки: ln -s /etc/nginx/sites-available/test1 /etc/nginx/sites-enabled/.
  3. Проверьте синтаксис: nginx -t.
  4. Перезагрузите конфигурацию: nginx -s reload.

Важное предупреждение: Всегда проверяйте синтаксис командой nginx -t перед перезагрузкой. Это предотвратит падение сервера из-за ошибки в конфиге.

Оптимизация скорости: шаблон для раздачи статического контента

Этот шаблон решает конкретную задачу - ускорение загрузки HTML, CSS, JavaScript и изображений. Он снижает нагрузку на сервер и улучшает пользовательский опыт.

server {
    listen 80;
    server_name static.example.com;
    
    root /var/www/static;
    index index.html;
    
    # Включение файла MIME-типов для правильных Content-Type
    include /etc/nginx/mime.types;
    
    # Оптимизация отправки файлов
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    
    # Таймаут на отправку данных клиенту
    send_timeout 30s;
    
    location / {
        # Базовый кэш для статики - 1 день
        expires 1d;
        add_header Cache-Control "public, immutable";
        
        try_files $uri $uri/ =404;
    }
    
    # Отдельный блок для изображений с более долгим кэшем
    location ~* \.(jpg|jpeg|png|gif|ico|svg)$ {
        expires 1M;
        add_header Cache-Control "public, immutable";
    }
    
    # Блок для CSS и JS
    location ~* \.(css|js)$ {
        expires 7d;
        add_header Cache-Control "public, immutable";
    }
}

Комментарии к ключевым параметрам:

  • sendfile on: Включает прямую передачу файлов из ядра в сетевой буфер, минуя пользовательское пространство. Это основной метод оптимизации.
  • tcp_nopush on: Заставляет Nginx отправвать полные TCP-пакеты. Работает только с sendfile on.
  • tcp_nodelay on: Отключает алгоритм Нейгла для немедленной отправки небольших пакетов. Важно для интерактивного контента.
  • expires: Устанавливает заголовок Expires для браузера. Значение 1M - один месяц, 7d - семь дней.
  • add_header Cache-Control: Современная альтернатива expires. Параметр immutable сообщает браузеру, что файл не изменится до истечения срока кэша.

Кэширование статики: как настроить expires и Cache-Control для максимального эффекта

Директива expires устанавливает устаревший заголовок Expires для совместимости. Заголовок Cache-Control - современный стандарт с большей гибкостью.

Практические шаблоны значений для разных типов файлов:

  • Изображения (JPG, PNG, SVG, ICO): expires 1M; и add_header Cache-Control "public, immutable, max-age=2592000"; (30 дней).
  • CSS и JavaScript: expires 7d; и add_header Cache-Control "public, immutable, max-age=604800"; (7 дней).
  • Часто меняющиеся файлы (HTML, JSON): expires 1h; или add_header Cache-Control "public, max-age=3600, must-revalidate"; (1 час).
  • Файлы без кэша (админка, API): add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate"; и expires 0;.

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

map $uri $expires {
    default 1h;
    ~*\.(jpg|jpeg|png|gif|ico|svg)$ 30d;
    ~*\.(css|js)$ 7d;
}

server {
    ...
    location / {
        expires $expires;
        ...
    }
}

Этот подход централизует управление кэшем и упрощает поддержку.

Reverse Proxy: шаблоны для приложений на Node.js, Python и Java

Reverse proxy - основной сценарий использования Nginx в DevOps. Он проксирует трафик к backend-приложениям, обеспечивает балансировку нагрузки и SSL termination.

Базовый шаблон location блока:

location /app/ {
    # Адрес backend-приложения
    proxy_pass http://localhost:3000/;
    
    # Передача оригинальных заголовков
    proxy_set_header Host $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 $scheme;
    
    # Перенаправление заголовков Location из ответов бэкенда
    proxy_redirect off;
    
    # Таймауты
    proxy_connect_timeout 60s;
    proxy_send_timeout 60s;
    proxy_read_timeout 60s;
}

Передача заголовков и WebSocket: критичные настройки для proxy_set_header

Правильная передача заголовков решает частые проблемы: приложение не видит реальный IP-адрес клиента или не понимает протокол (HTTP/HTTPS).

Обязательные заголовки:

  • Host $host: Передает оригинальное имя хоста из запроса клиента.
  • X-Real-IP $remote_addr: Реальный IP-адрес клиента.
  • X-Forwarded-For $proxy_add_x_forwarded_for: Цепочка прокси. Критично для правильного аудита.
  • X-Forwarded-Proto $scheme: Оригинальный протокол (http или https). Нужен для генерации правильных URL в приложении.

Для поддержки WebSocket в приложениях на Node.js (Socket.IO) или Python (Django Channels) добавьте:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Полный блок для приложения с WebSocket:

location /ws/ {
    proxy_pass http://backend_app;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $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 $scheme;
}

Балансировка нагрузки: простой шаблон для нескольких backend-серверов

Этот шаблон расширяет reverse proxy для масштабируемых архитектур.

# Определение группы backend-серверов
upstream backend_app {
    # Метод балансировки по умолчанию - round-robin
    server 10.0.1.1:8080 weight=3;
    server 10.0.1.2:8080;
    server 10.0.1.3:8080 backup;
    
    # Базовая проверка здоровья
    max_fails=3 fail_timeout=30s;
}

server {
    location / {
        proxy_pass http://backend_app;
        ... # остальные proxy_* директивы
    }
}

Методы балансировки:

  • round-robin: Равномерное распределение запросов по серверам (по умолчанию).
  • least_conn: Запрос отправляется на сервер с наименьшим числом активных соединений.
  • ip_hash: Клиент фиксируется за одним сервером на основе его IP-адреса. Полезно для сессий.

Параметры max_fails и fail_timeout реализуют базовую проверку здоровья. Если сервер не отвечает 3 раза за 30 секунд, он временно исключается из балансировки.

Адаптированные шаблоны для разных технологий:

Node.js (обычное приложение): Используйте базовый шаблон. Для приложений с долгими запросами увеличьте proxy_read_timeout.

Python (Django/Flask через Gunicorn): Добавьте настройки для работы с медленными клиентами:

proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;

Java (Spring Boot): Увеличьте буферы для обработки больших JSON или XML ответов:

proxy_buffer_size 256k;
proxy_buffers 8 512k;

Типичная ошибка - неправильные заголовки для WebSocket. Если соединение обрывается, проверьте наличие Upgrade и Connection.

Безопасность и контроль: шаблоны редиректов, аутентификации и базовой защиты

Эти шаблоны решают задачи безопасности и организации трафика: закрытие части сайта, перенос домена, защита от простых атак.

Редиректы: постоянные (301) и временные (302) - когда и какой использовать

Редирект 301 - постоянный. Поисковые системы переносят вес страницы на новый URL. Используйте для окончательного переезда домена или изменения структуры URL.

# Перенаправление всего сайта на новый домен
server {
    listen 80;
    server_name old-domain.com www.old-domain.com;
    return 301 https://new-domain.com$request_uri;
}

# Перенаправление HTTP на HTTPS для конкретного хоста
server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

Редирект 302 - временный. Поисковики не переносят вес. Используйте для A/B тестирования или временного перенаправления.

# Временный редирект на страницу техработ
location / {
    return 302 https://example.com/maintenance.html;
}

Для перенаправления с одного URL на другой внутри сайта:

location = /old-page.html {
    return 301 /new-page.html;
}

Базовая аутентификация через htpasswd:

# Создайте файл паролей
# htpasswd -c /etc/nginx/.htpasswd username

location /admin/ {
    auth_basic "Administrator Area";
    auth_basic_user_file /etc/nginx/.htpasswd;
    
    # Дополнительно ограничьте по IP
    allow 192.168.1.0/24;
    allow 10.0.0.1;
    deny all;
}

limit_req и limit_conn: практические лимиты для защиты от перегрузки

Эти директивы реализуют базовую защиту от DDoS и перегрузки сервера.

Ограничение частоты запросов (limit_req):

# Определение зоны для хранения состояния
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=blog_limit:10m rate=30r/s;

server {
    # Публичное API: 10 запросов в секунду с одного IP
    location /api/ {
        limit_req zone=api_limit burst=20 nodelay;
        ...
    }
    
    # Блог: 30 запросов в секунду с одного IP
    location / {
        limit_req zone=blog_limit burst=50;
        ...
    }
}

Параметр burst определяет размер очереди для временного превышения лимита. nodelay немедленно отклоняет запросы сверх лимита.

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

limit_conn_zone $binary_remote_addr zone=addr_conn:10m;

location /downloads/ {
    # Не более 1 одновременного соединения с IP для скачивания
    limit_conn addr_conn 1;
    limit_rate 500k; # Ограничение скорости скачивания
}

Практические значения лимитов:

  • Публичное API: 10-20 запросов в секунду с IP, burst=20-30.
  • Блог или сайт-визитка: 30-50 запросов в секунду с IP, burst=50-100.
  • Страница входа: 5 запросов в секунду с IP, burst=10, nodelay для защиты от брутфорса.
  • Скачивание файлов: 1-2 одновременных соединения с IP, limit_rate 100k-1M в зависимости от пропускной способности.

Важный комментарий: не устанавливайте слишком агрессивные лимиты для статического контента. Это блокирует легальных пользователей. Используйте limit_req и limit_conn для динамических частей сайта (API, админка, формы).

Для комплексной защиты веб-серверов, включая настройку WAF и защиту от SQL-инъекций, изучите наше руководство по полной защите Nginx и Apache.

Сборка финальной конфигурации и проверка: пошаговый план

Этот алгоритм превращает отдельные шаблоны в готовое решение. Он закрывает последний страх - "Не упустил ли я важный шаг?".

  1. Выбор шаблонов. Определите, какие задачи решает ваш сайт: раздача статики, проксирование приложения, защита. Выберите соответствующие шаблоны из статьи.
  2. Адаптация. Замените в шаблонах домены, пути к файлам, IP-адреса и порты на свои значения. Проверьте, что все пути существуют на сервере.
  3. Комбинирование. Объедините блоки в один файл конфигурации. Пример итогового файла для сайта со статикой и API:
# /etc/nginx/sites-available/myapp
upstream api_backend {
    server 127.0.0.1:8000;
}

server {
    listen 80;
    server_name myapp.com;
    
    root /var/www/myapp/static;
    index index.html;
    
    # Статика с кэшем
    location /static/ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
    
    # API с ограничением запросов
    location /api/ {
        limit_req zone=api_limit burst=20;
        
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
    
    # Базовая защита админки
    location /admin/ {
        auth_basic "Admin Area";
        auth_basic_user_file /etc/nginx/.htpasswd_admin;
        allow 10.0.0.0/8;
        deny all;
    }
}
  1. Проверка синтаксиса. Выполните команду: nginx -t. Убедитесь, что вывод содержит "nginx: configuration file /etc/nginx/nginx.conf test is successful".
  2. Применение конфигурации. Если проверка прошла успешно, перезагрузите Nginx: nginx -s reload. Эта команда применяет изменения без прерывания работы.
  3. Мониторинг логов. В течение первых минут после применения следите за логами ошибок: tail -f /var/log/nginx/error.log. Это поможет быстро обнаружить проблемы.

Типичные ошибки и их решение:

  • "permission denied" для статики: Убедитесь, что пользователь Nginx (обычно www-data или nginx) имеет права на чтение файлов в директории root.
  • Ошибки подключения к proxy (502 Bad Gateway): Проверьте, что backend-приложение запущено на указанном порту. Увеличьте proxy_connect_timeout.
  • Слишком много открытых файлов: Увеличьте лимит в системе: worker_rlimit_nofile в nginx.conf и ulimit -n в системе.

Критическая рекомендация: Всегда тестируйте конфигурацию в отдельной среде (staging) перед применением на production. Используйте инструменты вроде ab (Apache Benchmark) или wrk для нагрузочного тестирования.

Для глубокого анализа работы сервера после настройки используйте готовые команды grep и awk для анализа логов Nginx. Они помогут найти ошибки, медленные запросы и признаки атак.

Эти шаблоны - основа для большинства задач DevOps. Для сложных сценариев балансировки нагрузки с health checks и graceful shutdown изучите наше руководство по продвинутой настройке Nginx как балансировщика.

Если вы работаете с ИИ-моделями и ищете единый интерфейс для доступа к GPT, Gemini и Claude без VPN, рассмотрите сервис AiTunnel. Он агрегирует API более 200 моделей и позволяет управлять бюджетами в рублях.

Поделиться:
Сохранить гайд? В закладки браузера