Симптом
У части пользователей — в разобранном случае сотня-полторы — подключение «тупит»: дёргается, не встаёт с первого раза, конфликтует. У остальных всё в порядке. Локация в целом выглядит проблемной, хотя сама нода жива и трафик по ней идёт.
Причина
На одну физическую ноду (один сетевой адрес) в подписке выдано два клиентских хоста-локации. Например «Быстрый» (:443, vision) и «Сильный» (:8443, xhttp), оба указывают на один и тот же address. Клиент получает две записи фактически одной локации и начинает метаться между ними — переключается, переустанавливает соединение. У части пользователей это выливается в устойчивый тупняк.
Важное исключение: скрытые хосты-плечи балансировщика (isHidden: true) — не дубль. Они не выдаются пользователю как отдельная локация и спокойно сосуществуют с видимым хостом на той же ноде.
Решение
- Правило: один инбаунд ноды = один видимый клиентский хост в подписке. Не плодить «быстрый/сильный» варианты одной ноды как две локации.
- При жалобах на тупняк у части пользователей — сгруппировать хосты по address и проверить, нет ли двух видимых хостов на один адрес (скрытые плечи балансировщика не считаются).
- Лечится отключением лишнего дубля: остаётся один видимый хост на ноду.
Вывод. Если клиенту отдать две записи, указывающие на один ресурс, он не «выберет лучшую» — он будет метаться. Дублирование одного бэкенда под видом двух вариантов выбора создаёт недетерминированное поведение клиента. В любых списках эндпоинтов избегайте скрытых дублей одного адреса; если несколько записей ведут в одно место — это должно быть осознанной ролью (скрытое плечо балансировщика), а не случайностью.