Невеликий набір інструментів для налагодження редиректів і HTTP-заголовків у production

Проблема з налагодженням HTTP у production

Більшість HTTP-проблем невидимі в браузері. Ланцюжок редиректів може завершитися помилкою без очевидних ознак, cache-заголовок може бути неправильним на один символ, CORS-політика може заблокувати запит без пояснення. Інструменти розробника в браузері показують результат цього обміну, але часто приховують сирий обмін, який спричинив проблему.

Це найважливіше саме в production, де ви не можете додати логування або перезапустити сервіси, щоб побачити, що змінилося. Потрібні інструменти, які показують реальний HTTP-обмін: заголовки запиту, заголовки відповіді, коди стану, цілі редиректів, таймінги. Ось п’ять інструментів, які надійно виконують цю роботу, а також браузерні прийоми, що їх доповнюють.

curl: основа

curl — перший інструмент, до якого варто звернутися, бо він показує саме те, що надіслав сервер, без проміжної інтерпретації браузером.

Щоб побачити заголовки відповіді без тіла:

curl -I https://example.com

Щоб переходити за редиректами й бачити кожен крок:

curl -L -v https://example.com

Прапорець -v (verbose) показує повний запит і відповідь, включно з усіма заголовками. Прапорець -L автоматично переходить за редиректами. Разом вони показують увесь ланцюжок редиректів — саме там живе більшість production-проблем.

Щоб побачити лише адреси редиректів:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -L https://example.com

Це корисно, коли потрібно перевірити ланцюжок редиректів без шуму повних заголовків. Прапорець -w форматує вивід так, щоб показати лише код стану та наступний URL у ланцюжку.

curl також дозволяє надсилати власні заголовки, що необхідно для тестування поведінки CDN, автентифікації або API-ендпоїнтів:

curl -H "Authorization: Bearer token" -H "Accept: application/json" https://api.example.com

httpie: curl із кращими стандартними налаштуваннями

httpie — це Python-інструмент, який робить те саме, що й curl, але має синтаксис, який легше запам’ятати, і вивід, який легше читати. Це не заміна — curl потужніший і встановлений значно ширше, — але для швидких перевірок httpie зручніший.

Щоб побачити заголовки:

http HEAD https://example.com

Щоб переходити за редиректами:

http --follow --all https://example.com

Прапорець --all показує кожну відповідь у ланцюжку редиректів, а не лише фінальну. Це еквівалент curl -L -v, але вивід має кольорове кодування й легше переглядається.

Щоб надіслати JSON:

http POST https://api.example.com name=value

httpie за замовчуванням припускає JSON, що економить набір тексту під час тестування API. Він також гарно форматує відповідь, завдяки чому легше помітити некоректні заголовки або неочікувані значення.

Browser DevTools: вкладка Network

Вкладка Network у браузері — місце, з якого варто почати, якщо проблема виникає лише в браузері. Вона показує ту саму інформацію, що й curl, але також показує інтерпретацію браузера: чи заблокував він запит, як обробив кешування, чи надіслав cookies.

Щоб побачити повні заголовки запиту й відповіді, натисніть будь-який запит на вкладці Network, а потім перегляньте розділ Headers. Подання "Raw" показує заголовки саме такими, як вони були надіслані, без форматування.

Щоб побачити ланцюжки редиректів, шукайте запити з кодами стану 3xx. Браузер групує їх під фінальним запитом, але їх можна розгорнути, щоб побачити кожен крок. Саме тут ви знайдете цикли редиректів, відсутні заголовки Location або редиректи, що вказують на неправильний домен.

Щоб побачити таймінги, відкрийте вкладку Timing для будь-якого запиту. Вона показує, скільки часу браузер витратив на DNS lookup, TCP connection, TLS handshake і очікування сервера. Якщо редирект повільний, вкладка Timing підкаже, чи проблема в мережевій затримці, чи в обробці на сервері.

Одне обмеження: браузер приховує деякі заголовки з міркувань безпеки. Заголовки Set-Cookie видимі, але фактичні значення cookies редагуються. Заголовки Authorization іноді повністю приховані. Якщо потрібно побачити їх, використовуйте curl.

mitmproxy: перехоплювальний proxy

mitmproxy — це Python-інструмент, який розміщується між вашим браузером і сервером та показує кожен запит і відповідь у реальному часі. Він складніший за curl, але це єдиний інструмент, який показує, що браузер насправді надсилає, включно із заголовками, які браузер додає автоматично.

Щоб запустити його:

mitmproxy

Потім налаштуйте браузер на використання localhost:8080 як HTTP proxy. mitmproxy показуватиме кожен запит у термінальному інтерфейсі. Ви можете переглядати заголовки, редагувати запити перед надсиланням або повторювати запити з іншими параметрами.

Це корисно для налагодження проблем, які виникають лише в браузері: CORS preflight-запитів, обробки cookies або запитів, що падають за наявності певних заголовків. Це також корисно для тестування того, як ваш сайт поводиться за корпоративним proxy або VPN, адже mitmproxy може імітувати такі середовища.

Мінус — складність налаштування. Потрібно встановити кореневий сертифікат, щоб mitmproxy міг перехоплювати HTTPS-трафік, і налаштувати браузер на використання proxy. Для швидких перевірок curl швидший. Для глибокого налагодження mitmproxy вартий часу на налаштування.

webpagetest: production-погляд

WebPageTest — це безкоштовний сервіс, який завантажує вашу сторінку в реальних браузерах із різних локацій і показує повний HTTP-обмін. Він повільніший за curl, але показує те, що відчувають реальні користувачі, включно з поведінкою CDN, DNS resolution і TLS negotiation.

Подання "Request Headers" і "Response Headers" показують саме те, що браузер надіслав і отримав. Подання "Waterfall" показує таймінги кожного запиту, включно з редиректами. Саме тут можна знайти проблеми, які виникають лише в певних регіонах або в певних мережах.

WebPageTest також показує ланцюжок редиректів для основного документа — саме там зазвичай живе більшість проблем із редиректами. Якщо ваш сайт редиректить з http:// на https://, потім з www. на non-www., а потім з / на /en/, WebPageTest покаже всі три кроки й скільки часу зайняв кожен.

Для інструментів, які допомагають перевіряти й оптимізувати ці HTTP-основи, Wux Webtools пропонує кілька утиліт, що працюють повністю у вашому браузері, включно з аналізаторами заголовків і перевірками редиректів, які поважають вашу приватність, обробляючи все на стороні клієнта.

Коли заголовки брешуть

Найскладніші HTTP-проблеми — це ті, у яких сервер надсилає суперечливі заголовки. Заголовок Cache-Control каже no-cache, але заголовок Expires каже, що ресурс дійсний протягом року. Заголовок Location вказує на відносний URL, але заголовок Content-Location вказує кудись іще. Браузер має здогадатися, якому з них довіряти, і різні браузери здогадуються по-різному.

Коли це трапляється, потрібно бачити сирі заголовки в тому порядку, у якому їх надіслав сервер. curl -v це робить. Так само й mitmproxy. DevTools браузера іноді перевпорядковують заголовки для зручності читання, що приховує проблему.

Ще одна поширена ситуація: заголовки додає CDN або балансувальник навантаження, а не ваш застосунок. Якщо ви налагоджуєте проблему кешування, потрібно знати, чи заголовок Cache-Control прийшов із вашого застосунку, чи з CDN. curl показує фінальний результат, але не каже, звідки взявся кожен заголовок. Для цього потрібно обійти CDN (звернувшись безпосередньо до origin-сервера) і порівняти заголовки.

Проблема циклу редиректів

Цикли редиректів — найпоширеніша HTTP-проблема в production. Вони виникають, коли два сервери не погоджуються, куди має вказувати URL: CDN редиректить на origin, а origin редиректить назад на CDN. Або балансувальник навантаження редиректить HTTP на HTTPS, але застосунок редиректить HTTPS назад на HTTP, бо не бачить заголовка X-Forwarded-Proto.

Щоб це налагодити, потрібно бачити повний ланцюжок редиректів, включно із заголовком Location на кожному кроці. curl -L -v це робить, але зупиняється після 50 редиректів, щоб запобігти нескінченним циклам. Якщо ви досягаєте цього ліміту, у вас цикл редиректів.

Виправлення зазвичай полягає в зміні конфігурації: сказати застосунку довіряти заголовку X-Forwarded-Proto або сказати CDN припинити редиректити запити, які вже є HTTPS. Але це неможливо виправити, доки ви не побачите цикл, а браузер не покаже більше ніж кілька редиректів, перш ніж здасться.

Що перевірити спочатку

Коли щось ламається в production, перевіряйте це в такому порядку:

1. Код стану: Він такий, як ви очікували? 301 — постійний, 302 — тимчасовий, 307 зберігає HTTP-метод. Якщо ви бачите неправильний код, проблема у конфігурації редиректів.

1. Заголовок Location: Він вказує на правильне місце? Це абсолютний URL чи відносний? Відносні URL розв’язуються відносно поточного URL, що може давати неочікувані результати, якщо базовий URL не такий, як ви думаєте.

1. Cache-заголовки: Чи кешує браузер редирект? Редирект 301 кешується за замовчуванням, а це означає, що неправильно налаштований редирект може ламати ваш сайт годинами навіть після виправлення. Перевірте заголовки Cache-Control і Expires, щоб побачити, як довго браузер пам’ятатиме редирект.

1. CORS-заголовки: Якщо запит cross-origin, чи надсилає сервер правильний заголовок Access-Control-Allow-Origin? Якщо ні, браузер заблокує запит, і ви побачите CORS-помилку в консолі. Заголовки відповіді сервера — єдине місце, де це можна виправити; обійти це в браузері неможливо.

1. Таймінги: Скільки часу зайняв запит? Якщо він повільний, це мережева затримка чи обробка на сервері? DevTools браузера й WebPageTest показують деталізовані таймінги, які пояснюють, куди пішов час.

Щоб глибше подивитися, як поведінка браузерів змінилася навколо приватності й заголовків, дивіться що змінилося для cookies у 2026 році та що з цим робити, де розглянуто наслідки останніх оновлень браузерів для заголовків і згоди.

Ключові висновки

• curl -L -v показує повний ланцюжок редиректів і всі заголовки без інтерпретації браузером
• Вкладка Network у браузері показує, що браузер зробив із відповіддю, включно з рішеннями щодо кешування та CORS
• mitmproxy показує, що браузер надіслав, включно із заголовками, які браузер додає автоматично
• WebPageTest показує досвід реальних користувачів, включно з поведінкою CDN і регіональними відмінностями
• Цикли редиректів і суперечливі заголовки — найпоширеніші production-проблеми, і вони невидимі без перевірки сирого HTTP

FAQ

Q: Чому curl показує інші заголовки, ніж браузер?

A: Тому що браузер автоматично додає заголовки (User-Agent, Accept, Cookie) і дотримується власних правил кешування та CORS. curl надсилає лише те, що ви наказали йому надіслати. Щоб побачити, що браузер насправді надсилає, використовуйте mitmproxy або DevTools браузера.

Q: Як налагодити редирект, який відбувається лише для деяких користувачів?

A: Перевірте, чи залежить редирект від заголовків, які надсилає користувач: User-Agent, Accept-Language, Cookie або IP-адреси (через X-Forwarded-For). Використайте curl, щоб надіслати ті самі заголовки, які надіслав користувач, або WebPageTest, щоб завантажити сторінку з локації користувача.

Q: У чому різниця між редиректами 301 і 302?

A: 301 — постійний і каже браузеру кешувати редирект (іноді назавжди). 302 — тимчасовий і каже браузеру не кешувати його. Якщо не впевнені, що використовувати, використовуйте 302 — ви завжди можете змінити його на 301 пізніше.

Q: Чому мій редирект працює в curl, але не в браузері?

A: Найімовірніше, браузер кешує старий редирект або блокує редирект через правила CORS чи mixed content. Перевірте консоль DevTools браузера на помилки та заголовки Cache-Control, щоб побачити, чи браузер використовує кешовану відповідь.

Q: Як побачити заголовки, які додає CDN?

A: Використайте curl, щоб звернутися до CDN URL, а потім ще раз використайте curl, щоб звернутися безпосередньо до origin-сервера (в обхід CDN). Порівняйте заголовки. Ті, що з’являються лише в першій відповіді, прийшли з CDN.

<!-- tool-cta:start -->

💡 Спробуйте це: Під час пошуку проблем із перенаправленнями Redirect Checker відстежує весь ланцюжок і показує коди стану та заголовки на кожному переході.

<!-- tool-cta:end -->

Джерела

• curl documentation — Офіційний довідник щодо параметрів командного рядка curl і його поведінки
• HTTPie documentation — Посібник із синтаксису та можливостей httpie
• MDN Web Docs: HTTP redirections — Вичерпне пояснення кодів стану HTTP-редиректів і їхньої поведінки
• WebPageTest documentation — Як інтерпретувати результати й заголовки WebPageTest