<b>Прокси ломается не на трафике, а на рассинхроне конфигураций</b>

<b>Прокси ломается не на трафике, а на рассинхроне конфигураций</b>

Когда прокси живет на нескольких узлах, ручные правки быстро превращаются в источник дрейфа. Один сервер уже с новым ACL, второй — со старым upstream, третий — с измененным таймаутом. Анализ показал, что такие расхождения проявляются не сразу: сначала растет доля нестабильных сессий, затем появляются «случайные» 502 и неочевидные маршрутизационные аномалии.

Для управления конфигурацией нужен не «файл на машине», а единый источник истины. Практика обычно сводится к трем слоям: шаблоны параметров, проверка синтаксиса до выката и атомарное применение. Если конфиг нельзя валидировать автоматически, это не конфиг для fleet-управления, а ручная договоренность между инженерами.

В IaC для прокси особенно важно разделять:
— статическую часть: ACL, upstream-группы, лимиты, timeouts;
— динамическую часть: списки адресов, маршруты, сертификаты, секреты;
— runtime-настройки, которые можно менять без полного рестарта.
Рекомендуется обратить внимание на метрику конфигурационного дрейфа: число узлов, где фактическое состояние не совпадает с эталоном. Это дешевле, чем разбирать инцидент по журналам.

Хорошая схема проста: описать состояние декларативно, прогонять план изменений в CI, выкатывать поэтапно и хранить откат как первую операцию, а не как последнюю надежду.

<b>Если прокси управляется как код, инциденты чаще упираются в данные, а не в память оператора.</b>