Мы получили жалобы, что некоторые пользователи не могут получить доступ к сайту в течение дня. Каким-то образом они видят страницу обслуживания. Когда мы изучили логи haproxy, мы увидели, что все исходные IP-адреса запросов с ошибкой 503 — это ipv6. У нас нет записи AAAA dns.
Я проверил правила waf и wan брандмауэра. Также проверил логи сервера. Запросы не пересылаются на бэкенд-серверы.
пример журнала: [ <131>16 ноября 14:59:33 HaProxy haproxy[54113]: 2001:4860:7:631::e0:60332 [16/ноя/2022:14:59:33.173] HTTPS_443-Balance~ HTTP_80_443_ipv4/IIS-03 0/0/-1/-1/0 503 2695 - - SC-- 153/147/5/0/0 0/0 "GET https://example.com/path HTTP/2.0" ]
решение1
Исходный IP-адрес есть в логах, ваш haproxy получил что-то через IPv6. Так что ваш CDN-маршрутизация к вам работает.
Как уже упоминалось в комментариях, длясостояние завершения haproxy "SC"относится к сеансу TCP, неожиданно прерванному сервером. Обеспечение поддержки IPv6 на ваших бэкэндах позволит это сделать без каких-либо изменений в вашем CDN или балансировщике нагрузки. Или, по крайней мере, толерантным к адресам IPv6 в заголовках http, предполагая, что haproxy находится в режиме http.
Что касается того, кто и какой клиент вдруг стал IPv6-совместимым, исследование префикса иногда бывает познавательным. Последняя группа цифр этого IPv6-адреса слишком длинная, нопрефикс управляется Google, по-видимому, дляПрокси-сервер предварительной загрузки Google Chrome. Google и Cloudflare включают IPv6 для своих пользователей, так что да, вы получаете адреса IPv6.