(порт закрыт, RST, или полный timeout на SYN) — современные браузеры (Chrome, Firefox, Edge, Safari) действительно перебирают адреса из списка A/AAAA записей автоматически. Это заложено в самой логике Happy Eyeballs (RFC 8305/6555), изначально созданной для выбора между IPv4/IPv6, но она же используется и для перебора нескольких адресов одной семьи. Если попытка подключения к первому IP не удаётся за разумное время, браузер пробует следующий из списка, полученного от резолвера — без ошибки для пользователя, просто с небольшой задержкой.
Но есть нюансы, где это не спасает:
1. TCP-соединение установилось, а сервис "подвис" на уровне приложения (например, процесс жив, порт слушает, но HTTP-ответ не приходит) — тут Happy Eyeballs не поможет, браузер будет ждать таймаута именно на этом соединении и не переключится на другой IP автоматически, пока не истечёт таймаут запроса. Пользователь увидит зависание/ошибку.
2. DNS-резолвер и OS-кэш — сам браузер получает список IP от системного резолвера (или собственного, как в Chrome с DoH). Если резолвер вернул не все A-записи (некоторые кэширующие резолверы иногда отдают по одной), либо TTL старый, перебор будет ограничен тем, что реально пришло.
3. TLS/SNI-специфика — если у разных IP разные сертификаты или конфигурация, второй IP может успешно принять TCP, но упасть на TLS handshake — тоже может увести в ошибку, если приложение не умеет ретраить.
4. Не все браузеры/платформы реализуют это одинаково агрессивно — мобильные и некоторые встроенные HTTP-клиенты (curl без спец. флагов, многие backend-библиотеки) вообще не перебирают A-записи по умолчанию и падают в ошибку на первом неудачном IP.
Так что для настоящего failover через несколько A-записей — это работает как "best effort" в браузерах при явных сетевых отказах, но не является надёжным HA-механизмом. Для серьёзного failover обычно используют health-check + DNS с коротким TTL и активным удалением мёртвых записей, GSLB/anycast, либо балансировщик перед серверами, а не просто надежду на клиентский перебор.