ERR_TOO_MANY_REDIRECTS за CDN: два налаштування, що зациклюються разом.
CDN, який забирає origin через звичайний HTTP, і origin, який примусово переводить HTTP на HTTPS, кожен окремо в порядку, а разом зациклюються. Як упізнати пару, відтворити її одним запитом і закрити обидва кінці.
У цій статті 4 розділів
- Пара, яку треба шукати, коли сайт за CDN повертає ERR_TOO_MANY_REDIRECTS: режим SSL CDN, який забирає origin через звичайний HTTP, і origin, який примусово перенаправляє HTTP на HTTPS, не перевіряючи, що proxy вже зробив.
- Дві хиби, кожна нешкідлива сама по собі. Багато origin віддають HTTP за CDN, який термінує TLS, і багато origin примусово переводять на HTTPS. Зациклюються лише дві разом.
- Цикл може не лишити жодного запису в access log, бо рівень, який відповідає перенаправленням, може не логувати рутинні запити. Тиша виглядає як відсутність трафіку і спрямовує пошук не туди.
- Відтворіть його одним запитом до origin, тим шляхом, яким ідуть відвідувачі, потім виправте обидва кінці, щоб цикл не міг утворитися, хоч би як сайт був виставлений уперед.
Увімкнути proxy CDN перед origin, який примусово переводить на HTTPS, досить, щоб запустити цикл. Обидва налаштування розумні, і жодне саме по собі нічого не ламає. Перемкнути одне налаштування і протестувати шляхом, який обходить CDN, виглядає як виправлення, тоді як кожен справжній відвідувач досі зациклюється.
Механізм: два кінці, один цикл
Режим SSL CDN був встановлений на «Flexible»: браузер говорить з CDN через HTTPS, але CDN говорить з origin через звичайний HTTP. Цілком захисне налаштування саме по собі. Багато origin віддають HTTP за CDN, який термінує TLS.
Тим часом edge origin примусово перенаправляв кожен запит HTTP на HTTPS, не знаючи про proxy: він видавав перенаправлення, не перевіряючи заголовок, який каже, що цей запит уже був HTTPS на вході. Тож CDN забирає через HTTP, origin відповідає «йди на HTTPS», наступний запит браузера прибуває на CDN як HTTPS, CDN знову забирає origin через HTTP, і origin знову перенаправляє. Нескінченно, за побудовою. Flexible сам по собі в порядку. Примусове перенаправлення саме по собі в порядку. Зациклюються лише двоє разом.
Помилка, яка нічого не залогувала
Якщо рівень, який відповідає перенаправленням, не логує рутинні запити, цикл не лишає нічого в access log. Тиша виглядає так, ніби трафік не прийшов, і розслідування йде всюди, крім правильного місця. Правило: коли помилка не лишає логів, перестаньте полювати на тишу і відтворіть механізм.
Відтворіть механізм
$ curl -I -H 'X-Forwarded-Proto: https' http://origin.example/
HTTP/1.1 301 Moved Permanently
Location: https://origin.example/
# told the origin the request was already HTTPS. it redirects anyway.Один запит відтворює цикл, тим шляхом, яким ідуть відвідувачі. Тест будь-яким іншим шляхом проходить і нічого не доводить.
Виправте обидва кінці
| КІНЕЦЬ | ВИПРАВЛЕННЯ |
|---|---|
| Бік CDN | Режим SSL переведено на «Full (Strict)»: CDN говорить справжнім, перевіреним HTTPS з origin. |
| БУДЬ-ЯКЕ ВИПРАВЛЕННЯ РОЗРИВАЄ ЦИКЛ. ОБИДВА РОБЛЯТЬ ЙОГО НЕМОЖЛИВИМ.Бік origin | Перенаправлення зроблено свідомим щодо proxy: воно перевіряє заголовок forwarded-protocol і ніколи не відбиває запит, який уже був HTTPS на вході. |
Виправлення одного кінця двосторонньої несумісності лишає заряджену конфігурацію, яка чекає на наступну зміну. Закрийте обидва кінці, і не лишиться жодної комбінації, яка кружляє: призупиніть CDN, поміняйте CDN, змініть origin, і циклу більше немає де утворитися.
“Жоден кінець не був зламаний. Зламані були двоє разом.”
Прямі відповіді
Як виправити ERR_TOO_MANY_REDIRECTS за CDN?+
Перевіряйте пару, а не одне налаштування. Якщо CDN забирає ваш origin через звичайний HTTP (режим SSL на кшталт «Flexible»), а ваш origin примусово перенаправляє HTTP на HTTPS, вони зациклюються. Переведіть CDN на повний, строгий HTTPS до origin і зробіть перенаправлення origin свідомим щодо proxy.
Чому мій цикл перенаправлень не показує нічого в access log?+
Рівень, який зациклюється, може не логувати рутинні запити, тож цикл невидимий. Не полюйте на тишу. Відтворіть механізм одним запитом до origin і прочитайте, що він робить.
Що робить X-Forwarded-Proto?+
Proxy встановлює його, щоб сказати origin, який протокол насправді використав відвідувач. Origin, який перенаправляє HTTP на HTTPS, має його перевіряти, інакше він відбиває запити, які вже були HTTPS на proxy, і саме так починаються цикли.
Режим Flexible SSL поганий?+
Це обмін з гострим краєм: трафік між CDN і origin не зашифрований, а в поєднанні з примусовим перенаправленням на origin він зациклюється. Повний, строгий режим, зі справжнім сертифікатом на origin, прибирає обидві проблеми.
Чому це працювало, коли я тестував?+
Тест, який не проходить через CDN, іде іншим шляхом, ніж ваші відвідувачі. Відтворюйте саме тим шляхом, який не працює, із заголовками включно. У цій різниці й ховається цей клас помилок.
Боретеся з помилкою, яка нічого не логує?
Тиша теж є симптомом. Ми відтворюємо відмову, читаємо першоджерела і виправляємо обидва кінці.
Поговоріть з інженеромВи дійшли до кінця.
Застосуйте прочитане на практиці
Що ви запускаєте?
Розкажіть нам про навантаження, трафік і вимоги до відновлення. Почніть з конструктора сервера або обговоріть деталі з інженером.
Написано інженерами, які будують і експлуатують інфраструктуру, про яку йдеться.Поговоріть з інженером