Настройка nginx для Django: пошаговое руководство с примерами конфигов

Развертывание Django приложения — это больше, чем просто запуск сервера разработки. В production среде вам нужен надежный веб-сервер, который будет обрабатывать статические файлы, балансировать нагрузку и обеспечивать безопасность. Давай разберем, как правильно настроить nginx для работы с Django, чтобы твое приложение работало быстро и стабильно.

Архитектура связки nginx + Django

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

Nginx — фронтенд-сервер, принимает HTTP/HTTPS запросы от клиентов
Gunicorn/uWSGI — WSGI-сервер, запускает Python код Django
Django — собственно твое приложение
Статические файлы — обслуживаются напрямую nginx для скорости
Медиа файлы — могут обслуживаться nginx или через Django

Важно: В production никогда не используй встроенный сервер разработки Django (runserver). Он не предназначен для production нагрузки.

Шаг 1: Установка и базовая настройка

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

bash

# Для Ubuntu/Debian
sudo apt update
sudo apt install nginx python3-pip python3-venv

# Установка Gunicorn в виртуальное окружение
pip install gunicorn

# Проверка версии nginx
nginx -v

Подготовка Django проекта

Убедись, что твой проект готов к production:

bash

# Собираем статические файлы
python manage.py collectstatic

# Настраиваем ALLOWED_HOSTS в settings.py
ALLOWED_HOSTS = ['your-domain.com', 'localhost', '127.0.0.1']

# Отключаем DEBUG режим
DEBUG = False

Шаг 2: Настройка Gunicorn

Gunicorn будет запускать твое Django приложение. Создадим systemd сервис для управления:

bash

# Создаем systemd сервис файл
sudo nano /etc/systemd/system/gunicorn.service

config

[Unit]
Description=gunicorn daemon for Django
After=network.target

[Service]
User=www-data
Group=www-data
WorkingDirectory=/path/to/your/django/project
ExecStart=/path/to/venv/bin/gunicorn \
    --access-logfile - \
    --workers 3 \
    --bind unix:/run/gunicorn.sock \
    your_project.wsgi:application

[Install]
WantedBy=multi-user.target

bash

# Запускаем и включаем сервис
sudo systemctl start gunicorn
sudo systemctl enable gunicorn
sudo systemctl status gunicorn

Шаг 3: Конфигурация nginx для Django

Основной конфигурационный файл

config

server {
    listen 80;
    server_name your-domain.com www.your-domain.com;
    
    # Логи
    access_log /var/log/nginx/django_access.log;
    error_log /var/log/nginx/django_error.log;
    
    # Максимальный размер загружаемых файлов
    client_max_body_size 100M;
    
    # Статические файлы
    location /static/ {
        alias /path/to/your/django/project/staticfiles/;
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
    
    # Медиа файлы
    location /media/ {
        alias /path/to/your/django/project/media/;
        expires 30d;
        add_header Cache-Control "public";
    }
    
    # Проксирование к Gunicorn
    location / {
        proxy_pass http://unix:/run/gunicorn.sock;
        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;
        
        # Таймауты
        proxy_connect_timeout 300s;
        proxy_send_timeout 300s;
        proxy_read_timeout 300s;
    }
    
    # Запрещаем доступ к скрытым файлам
    location ~ /\. {
        deny all;
    }
    
    # Запрещаем доступ к敏感 файлам
    location ~* \.(py|sql|log|env)$ {
        deny all;
    }
}

Внимание: Всегда проверяй конфигурацию nginx перед применением: sudo nginx -t. Ошибки в конфиге могут привести к остановке сервера.

Активация конфигурации

bash

# Копируем конфиг в sites-available
sudo cp django.conf /etc/nginx/sites-available/django-project

# Создаем символическую ссылку в sites-enabled
sudo ln -s /etc/nginx/sites-available/django-project /etc/nginx/sites-enabled/

# Проверяем конфигурацию
sudo nginx -t

# Перезагружаем nginx
sudo systemctl reload nginx

Шаг 4: Настройка SSL с Let's Encrypt

HTTPS обязателен для production. Используем Certbot для автоматического получения сертификатов:

bash

# Установка Certbot
sudo apt install certbot python3-certbot-nginx

# Получение SSL сертификата
sudo certbot --nginx -d your-domain.com -d www.your-domain.com

# Автоматическое обновление
sudo certbot renew --dry-run

Шаг 5: Оптимизация производительности

Ключевые параметры оптимизации:

Параметр	Рекомендуемое значение	Описание
worker_processes	auto	Количество worker процессов (обычно равно количеству CPU ядер)
worker_connections	1024	Максимальное количество соединений на worker
keepalive_timeout	65	Таймаут keep-alive соединений в секундах
gzip	on	Включение сжатия для уменьшения трафика

config

# /etc/nginx/nginx.conf - оптимизация
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 1024;
    multi_accept on;
    use epoll;
}

http {
    # Базовые настройки
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    
    # Gzip сжатие
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_types text/plain text/css application/json application/javascript;
    
    # Кэширование файловых дескрипторов
    open_file_cache max=1000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;
}

Шаг 6: Мониторинг и логирование

bash

# Просмотр логов nginx в реальном времени
sudo tail -f /var/log/nginx/django_access.log
sudo tail -f /var/log/nginx/django_error.log

# Просмотр логов Gunicorn
sudo journalctl -u gunicorn -f

# Проверка статуса сервисов
sudo systemctl status nginx
sudo systemctl status gunicorn

Частые проблемы и их решения

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

502 Bad Gateway — проверь, что Gunicorn запущен и сокет существует
403 Forbidden — проверь права доступа к статическим файлам
Статические файлы не отображаются — проверь путь в конфиге nginx
Слишком медленная загрузка — включи gzip и проверь кэширование

bash

# Проверка прав доступа
sudo chown -R www-data:www-data /path/to/your/django/project
sudo chmod -R 755 /path/to/your/django/project/staticfiles

# Проверка сокета Gunicorn
ls -la /run/gunicorn.sock

# Перезапуск всех сервисов
sudo systemctl restart gunicorn
sudo systemctl reload nginx

Дополнительные улучшения

Для enterprise-проектов рассмотри:

Балансировка нагрузки — несколько инстансов Gunicorn за nginx
Кэширование — Redis/Memcached для кэширования ответов
CDN — Cloudflare или аналоги для статических файлов
Мониторинг — Prometheus + Grafana для метрик
Docker — контейнеризация для consistency

Профессиональный совет: Всегда тестируй конфигурацию на staging окружении перед deployment в production. Используй инструменты like Apache Bench или wrk для нагрузочного тестирования.

FAQ: Ответы на частые вопросы

Чем отличается Gunicorn от uWSGI?

Gunicorn проще в настройке и хорошо работает для большинства проектов. uWSGI предлагает больше возможностей для тонкой настройки и лучше подходит для высоконагруженных систем. Для старта рекомендуем Gunicorn.

Сколько worker процессов использовать в Gunicorn?

Общее правило: (2 × количество ядер CPU) + 1. Для 4-ядерного процессора: (2 × 4) + 1 = 9 workers. Начинай с 3-4 workers и мониторь нагрузку.

Как обслуживать медиа файлы в production?

Для небольших проектов — через nginx (как в примере выше). Для больших объемов — используй облачные хранилища (S3, Google Cloud Storage) с CDN.

Нужно ли настраивать кэширование в nginx для Django?

Для статических файлов — обязательно. Для динамического контента — осторожно, так как это может кэшировать персонализированные данные. Используй proxy_cache только для публичных страниц.

Заключение

Правильная настройка nginx для Django — это фундамент стабильного production окружения. Помни основные принципы:

Всегда используй WSGI сервер (Gunicorn/uWSGI) вместо runserver
Статические файлы должны обслуживаться nginx напрямую
Настрой HTTPS с помощью Let's Encrypt
Мониторь логи и метрики производительности
Тестируй изменения на staging перед production

Эта конфигурация покрывает 90% use cases для Django проектов. Для специфичных требований (высокая нагрузка, микросервисы, геораспределение) потребуются дополнительные настройки, но база останется той же.