Какой опыт работы с Nginx и его особенности

Что проверяют

Можете ли вы сами поставить Python-приложение за Nginx и объяснить, что он берёт на себя вместо Gunicorn или Uvicorn. Следом часто спрашивают, откуда приложение узнаёт реальный IP клиента и почему после проксирования сломались редиректы на HTTPS.

Как отвечать

Схема такая: Nginx принимает соединения, завершает TLS, отдаёт статику и буферизует медленных клиентов, а за ним Gunicorn (WSGI, Django или Flask) или Uvicorn (ASGI, FastAPI) на 127.0.0.1 или unix-сокете. Nginx держит тысячи соединений малым числом воркеров за счёт событийной модели.

Ключевые директивы:

• proxy_pass: хвостовой слэш меняет поведение. С http://app/ префикс location заменяется, без слэша путь уходит как есть;
• заголовки: Host, X-Forwarded-For, X-Forwarded-Proto через proxy_set_header. Приложению их нужно разрешить: SECURE_PROXY_SSL_HEADER в Django, ProxyFix во Flask, --forwarded-allow-ips у Uvicorn;
• upstream: несколько экземпляров, по умолчанию round-robin, есть least_conn и ip_hash;
• статика: location /static/ с alias, чтобы Python не тратил воркеры на файлы;
• WebSocket: proxy_http_version 1.1 и заголовки Upgrade и Connection;
• лимиты: client_max_body_size (по умолчанию 1 МБ, отсюда 413 при загрузке файлов), proxy_read_timeout (60 секунд, отсюда 504), limit_req.

Упомяните nginx -t перед применением и nginx -s reload без разрыва соединений. Свой пример: какую ошибку ловили и как нашли её в error_log.

Где спотыкаются

Путают root и alias: root приклеивает путь из location к каталогу, alias его заменяет, и статика отдаёт 404.

Не пробрасывают X-Forwarded-Proto, и Django с SECURE_SSL_REDIRECT уходит в бесконечный редирект на HTTPS.

Считают, что Nginx заменяет Gunicorn. Nginx не исполняет Python, это два разных слоя, и нужны оба.