Reverse-proxy простыми словами: разобрался, зачем он между миром и приложением

Считал reverse-proxy «надстройкой для сеньоров» и пугался. Пока не понял на своей коже: самому приложению не хочется торчать в интернет прямо — терминировать TLS, держать сертификаты и раздавать статику гораздо удобнее снаружи отдельному процессу, а приложение пусть смотрит на внутренний порт. Когда картинка сложилась, страх улетучился.

Нейтрально: reverse-proxy принимает запросы извне (порт 443/80) и передаёт их бэкенду через внутренний порт/сеть. Так прокси берёт на себя TLS и немного статики, а Django занимается логикой. Типичная связка.

# пример для понимания роли (Caddy-подобная идея, упрощённо)
example.com {
    handle_path /media/* { root * /srv/app/media ; file_server }
    reverse_proxy localhost:8000
}

Разложив по ролям «кто держит TLS» и «кто решает бизнес», я увидел знакомую картину из вакансий, где упоминаются nginx/caddy. Теперь не стесняюсь говорить, что понимаю, зачем прокси между интернетом и приложением.