Работали ли вы с Nginx

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

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

Как отвечать

Перечислите роли, в которых использовали: отдача статики, обратный прокси к приложению, балансировка на несколько бэкендов, терминация TLS. Затем конкретика, по которой видно практику:

• блок server выбирается по адресу и порту, затем по server_name, при промахе берётся сервер по умолчанию;
• location разбираются не сверху вниз: сначала точное совпадение, затем префикс с запретом регулярных, затем регулярные по порядку, иначе самый длинный префикс;
• слеш в конце proxy_pass меняет путь: с ним префикс location отрезается, без него путь уходит бэкенду целиком;
• заголовки Host, X-Forwarded-For и X-Forwarded-Proto проставляются руками, иначе приложение видит всех клиентов с одного адреса и строит ссылки по незашифрованной схеме;
• таймауты подключения и чтения, буферизация ответа, client_max_body_size под загрузку файлов;
• в блоке upstream способ балансировки, keepalive к бэкендам, пассивные проверки через max_fails.

Про отладку скажите, что начинаете с error.log: отказ в соединении, истёкший таймаут и слишком большие заголовки ответа выглядят там по-разному и лечатся по-разному.

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

Правят конфигурацию и перезапускают сервис вместо проверки nginx -t и мягкого перечитывания. Опечатка в этот момент роняет сайт целиком, хотя проверка заняла бы секунду.

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

Третье: забывают про предел размера тела и получают отказ при загрузке файла, либо теряют исходную схему запроса при терминации TLS и ловят бесконечный редирект между защищённой и незащищённой версией страницы.