error_page 401 403 404 405 500 502 503 = @fallback;
location @fallback {
proxy_pass https://127.0.0.1:4443;
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 HTTPS YES;
}
Открою вам секрет что если есть место не важно где но по дороге без шифрования, канал не может считаться защищеным.
В идиале нужно шифровать и бэк и фронт и тунель между ними.
НО последнее это как вы уже заметили возможно маразм для обычного веба.
Однако если у вас в ajax будет ифка с какой протокол то у вас будут проблемы.
если у вас будет АПИША с ожидаемым кодом 200 а у вас будет 301 то тоже проблемы
если у вас будет редирект с http_host = site.ru а он по факту на бэке будет site.ru:82 то тоже будут проблемы, и тд и тп.
я сейчас не говорю о самом шифрование канала я говорю о реальном определение бэком какой сейчас протокол. Посколку идет его подмена на фронте частично это исправляется но бэк работает на незащищеном и это полностью скрыть нельзя, в результате может быть все что угодно.
От зацикливания редиректов, котоырй гоняет по кругу один и тот-же урл вообще не еняя его.
Это не критично и на 95% проектов это вообще не заметно.
Но с точки зрения постороения архитектуру грубейшая ошибка.
Сделайте все правильно, дабы разница в 6 строк конфига.
В чем костыльность проброса сертификатов? никто вам не запрещяет кстати юзать разные.