engineer@northline:~$ less articles/reverse-proxy.md

Nginx as a stable reverse proxy layerNginx как стабильный слой reverse proxy

For small infrastructure, Nginx stays useful because it is boring in the best possible way. Configuration is explicit, reloads are predictable, and the operational surface is small enough to understand after a long gap.Для небольшой инфраструктуры Nginx остается полезным именно потому, что он скучный в хорошем смысле. Конфигурация явная, reload предсказуемый, а operational-поверхность достаточно мала, чтобы в ней можно было снова разобраться даже после долгого перерыва.

Why I keep the proxy layer simpleПочему я держу proxy-слой простым

A reverse proxy often ends up carrying certificates, redirects, headers, request limits, and routing logic for multiple services. Once this layer becomes too clever, outages get harder to diagnose because every problem looks like a transport problem first.Reverse proxy часто начинает нести сертификаты, редиректы, заголовки, лимиты запросов и маршрутизацию сразу для нескольких сервисов. Когда этот слой становится слишком умным, аварии сложнее разбирать, потому что любая проблема сначала выглядит как транспортная.

My default pattern is one server block per application, one upstream target, explicit timeouts, and as little conditional logic as possible.Мой базовый паттерн: один server block на приложение, одна upstream-цель, явные таймауты и минимум условной логики.

Operational checklistOperational-чеклист

• Keep access and error logs separate per service.Держать access и error логи раздельно по каждому сервису.
• Document every non-default header you forward.Документировать каждый нестандартный заголовок, который прокидывается дальше.
• Reload config after validation, not before.Перезагружать конфиг только после валидации, а не до нее.
• Treat TLS renewal as a scheduled maintenance routine, not as a surprise.Воспринимать обновление TLS как плановую процедуру обслуживания, а не как неожиданность.

/articles /notes