Конфиг nginx под задачу

«В учебном стенде location обслуживает /api/, а backend знает только /orders. Для GET /api/orders ожидаю обращение к /orders. Сравни proxy_pass с URI и без него, покажи итоговый путь». Вставьте действующий фрагмент целиком: регулярные location, переменные и переписывание могут менять поведение. Таблица из нескольких адресов полезнее совета добавить слеш во всех местах сразу.

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

Сначала проверьте конфигурацию средствами вашей сборки nginx, затем на стенде выполните таблицу запросов. Для примера это существующий API-метод, отсутствующий метод, файл статики и отсутствующий файл. Сверьте статус, тело и путь в журнале приложения. Успешная проверка синтаксиса не подтверждает маршрутизацию и доступность upstream; она решает только одну часть задачи перед применением.

Укажите, где завершается TLS и какие прокси находятся перед nginx. Для ошибки 413 полезны согласованный размер загрузки и ограничения всех звеньев, включая приложение. Передавать закрытый ключ сертификата не требуется: достаточно путей и текстов ошибок без секретов. Модель не проверяет ваш сертификат или сервер автоматически, поэтому окончательный результат подтверждается запросами из вашего окружения.