Соблазн «внешних блокировок»
Пользователи жалуются на тормоза, обрывы, большой пинг. Соблазн — списать всё на «внешние блокировки, фильтрацию, троттлинг» и закрыть тикет. Такой диагноз почти всегда уводит от реальной причины, которая лежит в зоне вашего контроля.
Внешние факторы — удобная, но чаще всего ложная гипотеза: её нельзя проверить со своей стороны и на неё нельзя повлиять. Она снимает ответственность вместо того, чтобы искать причину там, где её можно найти и устранить. В подавляющем большинстве разобранных инцидентов реальные причины лежали в конкретных слоях:
- сервер — лимит nofile, память и OOM, conntrack, congestion control, зависшая утечка ресурсов;
- конфигурация — транспорт, балансировщик, маршрутизация, SNI-рассогласование, пустой outbounds;
- сеть, маршрут, хостер — DNAT-перехват, ARP flux, порезанные хостером порты;
- нода — образ с багом, перегруз, слетевший модуль ядра.
Дисциплина слоёв
Диагностировать сверху вниз, единым воспроизводимым протоколом: хост → docker и приложение → конфигурация (включая пустой outbounds) → парк нод и дрейф между ними → on-node проверки (утечки, congestion control, conntrack, FD) → проверка глазами клиента → сертификаты, DNS, бэкапы. Протокол read-only: сам ничего не исправляет, а указывает на слой и рецепт.
Приёмы, которые повторяются во всех разборах:
- Воспроизводить проблему инструментом, идентичным клиенту — эмулятором клиента или headless-клиентом, а не «на глаз». «Каждая нода по отдельности здорова» и «связка работает» — разные утверждения.
- Проверять весь парк единообразно, а не только «жалобную» ноду: выборочный дефект прячется среди здоровых соседей (классика — BBR, слетевший в cubic на двух серверах из десяти).
- Отличать декларацию конфигурации от фактического рантайма: «записано в конфигурации» не значит «применилось».
- Не путать hot-reload с рестартом и не верить логам как индикатору живости — оба канала врут в обе стороны.
Вывод. Хорошая диагностика — это дисциплина слоёв и воспроизводимости, а не поиск удобного внешнего виновника. Гипотеза, которую нельзя проверить и на которую нельзя повлиять, бесполезна как рабочая версия. Начинайте с того, что в вашей зоне контроля и измеримо: сервер, конфигурация, сеть, узел. Формализованный протокол превращает реактивное «ловим баги руками» в проактивную проверку.