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

Проблема отладки HTTP в production

Большинство HTTP-проблем в браузере невидимы. Цепочка перенаправлений тихо ломается, в заголовке кэша ошибочен один символ, политика 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: перехватывающий прокси

mitmproxy — Python-инструмент, который находится между браузером и сервером и показывает каждый запрос и ответ в реальном времени. Он сложнее, чем curl, но это единственный инструмент, который показывает, что браузер действительно отправляет, включая заголовки, которые браузер добавляет автоматически.

Чтобы запустить его:

mitmproxy

Затем настройте браузер на использование localhost:8080 в качестве HTTP-прокси. mitmproxy покажет каждый запрос в терминальном интерфейсе. Можно просматривать заголовки, редактировать запросы перед отправкой или повторять запросы с другими параметрами.

Это полезно для отладки проблем, которые возникают только в браузере: CORS preflight requests, обработка cookies или запросы, которые ломаются при наличии определенных заголовков. Это также полезно для проверки поведения сайта за корпоративным прокси или VPN, потому что mitmproxy может имитировать такие окружения.

Недостаток — сложность настройки. Нужно установить корневой сертификат, чтобы mitmproxy мог перехватывать HTTPS-трафик, и настроить браузер на использование прокси. Для быстрых проверок curl быстрее. Для глубокой отладки mitmproxy стоит времени, потраченного на настройку.

webpagetest: взгляд из production

WebPageTest — бесплатный сервис, который загружает вашу страницу в реальных браузерах из разных локаций и показывает полный HTTP-диалог. Он медленнее, чем curl, но показывает, что испытывают реальные пользователи, включая поведение CDN, разрешение DNS и 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 тоже. Browser DevTools иногда переупорядочивают заголовки для читаемости, и это скрывает проблему.

Другая распространенная проблема: заголовки, которые добавляет CDN или балансировщик нагрузки, а не ваше приложение. Если вы отлаживаете проблему кэширования, нужно знать, пришел ли заголовок Cache-Control из приложения или из CDN. curl показывает финальный результат, но не говорит, откуда пришел каждый заголовок. Для этого нужно обойти CDN (обратившись напрямую к origin server) и сравнить заголовки.

Проблема циклов перенаправления

Циклы перенаправления — самая распространенная 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. Заголовки кэша: Кэширует ли браузер перенаправление? Перенаправление 301 кэшируется по умолчанию, а значит неверно настроенное перенаправление может ломать сайт часами даже после исправления. Проверьте заголовки Cache-Control и Expires, чтобы понять, как долго браузер будет помнить перенаправление.

1. Заголовки CORS: Если запрос кросс-доменный, отправляет ли сервер правильный заголовок Access-Control-Allow-Origin? Если нет, браузер заблокирует запрос, и в консоли вы увидите ошибку CORS. Заголовки ответа сервера — единственное место, где это можно исправить; обойти это в браузере нельзя.

1. Тайминги: Сколько занял запрос? Если он медленный, это сетевая задержка или обработка на сервере? Browser 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 или Browser 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. Проверьте консоль Browser DevTools на ошибки и проверьте заголовки Cache-Control, чтобы понять, использует ли браузер кэшированный ответ.

Q: Как увидеть заголовки, которые добавляет CDN?

A: Используйте curl, чтобы обратиться к CDN URL, затем снова используйте curl, чтобы обратиться напрямую к origin server (в обход 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