Симптом: две ноды одной страны отказывают «синхронно»
Две ноды одного гео, объединённые в один балансировщик или выданные клиенту как соседние локации, периодически отказывают одновременно: у части пользователей соединение поднимается через раз или падает совсем. Каждая нода по отдельности жива и проверяется без ошибок.
Здесь два разных сценария, и они дают противоположные рекомендации по uTLS-fingerprint. Важно их не перепутать.
Сценарий 1: одиночная нода на randomized
Режим randomized заставляет uTLS периодически генерировать ClientHello, который Reality-dest иногда отвергает — рукопожатие проходит «через раз». Для одиночного хоста это скрытый дефект. Решение: fingerprint: chrome — детерминированный, стабильно принимаемый отпечаток.
Сценарий 2: ноды-близнецы с одинаковым отпечатком
Если у двух разных нод (с разными Reality-ключами) совпадают SNI + порт + fingerprint, для клиента они неотличимы. Клиент, который держит обе одновременно — например, обе являются плечами одного балансировщика, — при переиспользовании TLS-сессии или переключении бьёт сессией, установленной с одной нодой, во вторую. Ключи разные, рукопожатие падает.
Неприятный момент: именно перевод обеих нод на «стабильный» chrome и создаёт коллизию — он стирает последнее различие между близнецами. Ошибочный первичный диагноз в этом классе звучит как «randomized = killer, меняем на chrome». Для одиночной ноды это верно. Для пары близнецов chrome ломает всё разом.
Решение
- Одиночная нода →
fingerprint: chrome. - Две и более ноды одного гео, которые клиент может держать одновременно → развести так, чтобы клиентский отпечаток отличался. Лучший способ — дать каждой ноде свой Reality-dest/SNI. Более дешёвый — держать их на
randomized, чтобы отпечатки не совпадали. - Правило-инвариант: два плеча одного балансировщика не должны быть неразличимы, то есть иметь совпадающие SNI + порт + fingerprint при разных Reality-ключах.
Вывод. При диагностике «несколько серверов конфликтуют» стройте клиентский отпечаток каждого хоста — кортеж (SNI, порт, fingerprint) — и ищите пары, где отпечаток совпадает, а нода и ключ разные. Унификация клиентских параметров «для порядка» опасна, если за одинаковыми параметрами стоят разные криптографические идентичности: клиент начинает путать сессии. Разнообразие отпечатков здесь — не беспорядок, а необходимая развязка.