Вопрос проверяет понимание продакшн-архитектуры Django-приложений и роли каждого компонента в цепочке обработки запроса.
Nginx принимает HTTP-запросы и проксирует их в Gunicorn. Gunicorn — это WSGI-сервер, который запускает Django-приложение и обрабатывает Python-код. Django выполняет бизнес-логику и возвращает ответ. Nginx также может раздавать статику и выполнять балансировку.
В production Django обычно не работает напрямую с интернетом — перед ним ставят WSGI-сервер и reverse proxy.
Определение: WSGI-сервер — сервер, который умеет запускать Python-приложение и обрабатывать HTTP-запросы через интерфейс WSGI.
Последовательность:
Клиент → Nginx
Nginx → Gunicorn
Gunicorn → Django
Ответ возвращается обратно тем же путем
Отвечает за:
маршрутизацию
бизнес-логику
ORM
сериализацию
Отвечает за:
запуск нескольких worker-процессов
управление соединениями
обработку WSGI
Пример запуска:
gunicorn project.wsgi:application --workers 4
Отвечает за:
TLS/HTTPS
статику
проксирование
ограничение соединений
Встроенный сервер:
однопоточный по умолчанию
не оптимизирован для production
не рассчитан на высокую нагрузку
Nginx слушает порт 80/443
Gunicorn слушает localhost
Django работает внутри Gunicorn
Связка Django + Gunicorn + Nginx разделяет ответственность: Django — логика, Gunicorn — выполнение Python, Nginx — сеть и производительность.