HAR-файл: что это, как записать в браузере и как не отдать свою сессию

Коротко. HAR (HTTP Archive) — это JSON-файл, куда браузер выгружает всё, что вкладка запросила по сети: адреса, заголовки, коды ответов, размеры и тайминги. Его просит техподдержка, чтобы увидеть проблему вашими глазами. Записывается за минуту через панель разработчика. Главное: сырой HAR содержит cookie вашей сессии и токены — перед отправкой его нужно вычистить.

Что такое HAR-файл и зачем его просят

HAR расшифровывается как HTTP Archive. Это обычный текстовый файл в формате JSON, куда панель разработчика браузера выгружает журнал сетевой активности одной вкладки: каждый запрос, который страница отправила, и каждый ответ, который она получила. Расширение .har, внутри — читаемый глазами JSON, который можно открыть любым текстовым редактором.

Формат родился в проекте Firebug, дорос до версии 1.2 и так и остался черновиком спецификации — но его умеют экспортировать все основные браузеры и читать десятки анализаторов. Именно поэтому поддержка любого сервиса просит «пришлите HAR»: это универсальный способ передать сетевую картину без доступа к вашему компьютеру.

Внутри файла — объект log с четырьмя основными частями:

• log.version и log.creator — версия формата и какой браузер её записал;
• log.pages — список загруженных страниц с отметками времени onContentLoad и onLoad;
• log.entries — главное: массив записей, по одной на каждый сетевой запрос;
• внутри каждой записи — request (метод, URL, заголовки, cookie, тело POST), response (код, заголовки, cookie, размер, иногда тело), timings (разбивка времени по фазам), serverIPAddress и time — общая длительность в миллисекундах.

Кто читает HAR на практике: поддержка хостинга и CDN, инженеры платёжного шлюза, разработчики фронтенда и бэкенда, SRE при разборе инцидента. Все они смотрят в одно и то же — какой запрос не дошёл, какой вернул не тот код и где именно ушло время.

HAR — это не скриншот и не лог сервера. Это то, что видел именно ваш браузер: с вашими cookie, вашими заголовками и вашим маршрутом до сайта. Отсюда и его ценность для диагностики, и его опасность при пересылке.

Как записать HAR-файл: пошагово по браузерам

Алгоритм одинаковый во всех браузерах, отличаются только названия пунктов меню. Шесть шагов:

1. Откройте вкладку с проблемной страницей.
2. Откройте панель разработчика — обычно F12 или Ctrl+Shift+I (на macOS Cmd+Option+I).
3. Перейдите на вкладку «Сеть» / Network.
4. Поставьте галку «сохранять журнал» (Preserve log). Без неё редирект или перезагрузка очистят список.
5. Воспроизведите проблему: перезагрузите страницу, нажмите кнопку, отправьте форму — ровно то действие, которое ломается.
6. Экспортируйте результат в HAR и сохраните файл.

Chrome

Панель: F12, либо меню «три точки» → «Дополнительные инструменты» → «Инструменты разработчика». Вкладка Network / «Сеть». Галка Preserve log («Сохранять журнал») — в верхней панели рядом с «Отключить кеш» (Disable cache); её тоже полезно включить, чтобы увидеть реальную загрузку, а не кеш.

Экспорт: иконка со стрелкой вниз в панели инструментов вкладки «Сеть», либо правый клик по списку запросов → пункт вида «Сохранить всё как HAR». В свежих версиях Chrome экспорт разделён на два пункта: обычный (санитизированный — из него вырезаны cookie и заголовки авторизации) и отдельный, который сохраняет чувствительные данные и тела ответов. Названия пунктов в разных версиях отличаются — ориентируйтесь на упоминание «sanitized» / «sensitive data» / «with content».

Яндекс.Браузер

Яндекс.Браузер построен на Chromium, поэтому панель разработчика внутри такая же, как в Chrome, но путь до неё называется иначе.

• Быстро: F12 или Ctrl+Shift+I.
• Через меню: кнопка меню (три полоски) в правом верхнем углу → «Дополнительно» → «Дополнительные инструменты» → «Инструменты разработчика».
• Дальше — вкладка «Сеть», галка «Сохранять журнал», воспроизвели проблему, правый клик по списку запросов → сохранить всё как HAR (либо иконка экспорта в панели вкладки «Сеть»).

Если в вашей сборке пункты подписаны по-английски (Network, Preserve log, Export HAR) — это нормально: локализация панели разработчика в Яндекс.Браузере зависит от версии и языка интерфейса. Логика и расположение элементов при этом ровно как в Chrome.

Firefox

Панель: F12 или меню → «Другие инструменты» → «Инструменты веб-разработки». Вкладка «Сеть» / Network. Галка называется «Сохранять логи» (Persist Logs) и живёт в панели фильтров над списком запросов.

Экспорт: правый клик по любому запросу в списке → «Сохранить всё как HAR» (Save All As HAR). Рядом обычно есть «Копировать всё как HAR» — удобно, если файл нужно вставить в тикет, а не прикреплять.

Edge

Edge тоже на Chromium: F12, вкладка «Сеть», галка Preserve log, экспорт через иконку со стрелкой вниз либо правым кликом по списку запросов. Отличие от Chrome — только в оформлении панели.

Safari

Сначала включите меню разработчика: Safari → «Настройки» → вкладка «Дополнения» (Advanced) → включить показ инструментов для веб-разработчиков. После этого в строке меню появится пункт «Разработка».

Панель: Cmd+Option+I или «Разработка» → «Показать веб-инспектор». Вкладка «Сеть». Экспорт: кнопка со стрелкой вниз в правой части панели инструментов вкладки «Сеть» — она сохраняет весь журнал в .har.

Опция «сохранять журнал при переходах» в Safari есть не во всех версиях и лежит в настройках самой вкладки «Сеть». Если вы её не нашли — просто не перезагружайте страницу лишний раз: начните запись, воспроизведите проблему и сразу экспортируйте.

Браузер	Как открыть панель	Галка «сохранять журнал»	Экспорт
Chrome	F12 → вкладка Network / «Сеть»	Preserve log / «Сохранять журнал»	Иконка экспорта в панели «Сеть» или правый клик → сохранить всё как HAR
Яндекс.Браузер	F12, либо меню → «Дополнительно» → «Дополнительные инструменты» → «Инструменты разработчика»	«Сохранять журнал» / Preserve log	Правый клик по списку запросов → сохранить всё как HAR
Firefox	F12 → вкладка «Сеть»	«Сохранять логи» / Persist Logs	Правый клик → «Сохранить всё как HAR»
Edge	F12 → вкладка «Сеть»	Preserve log	Иконка экспорта в панели «Сеть»
Safari	Cmd+Option+I после включения меню «Разработка»	Есть не во всех версиях, в настройках вкладки «Сеть»	Кнопка со стрелкой вниз в панели вкладки «Сеть»

Самая частая причина «прислал пустой HAR» — не включена галка «сохранять журнал». Без неё редирект, переход по ссылке или обычная перезагрузка очищают список запросов, и вы экспортируете пустоту. Включайте её до того, как воспроизводите проблему.

Что попадает в HAR-файл: cookie, токены, пароли

Это тот раздел, который обычно пропускают в инструкциях. HAR — не обезличенная телеметрия. Он записывает содержимое обмена, а не только его факт. В сыром файле лежит:

• Cookie сессии — в массиве request.cookies и в заголовке Cookie. Этого достаточно, чтобы зайти в ваш аккаунт без пароля, пока сессия жива.
• Заголовок Authorization — Bearer-токены, JWT, ключи API, Basic-авторизация в base64 (то есть логин и пароль в один шаг от расшифровки).
• Заголовки Set-Cookie из ответов — свежевыданные сессионные идентификаторы.
• Тела POST-запросов в request.postData — всё, что вы ввели в форму: адрес, телефон, номер заказа, а на странице входа — логин и пароль открытым текстом.
• Параметры в URL — токены сброса пароля, одноразовые ссылки, ключи API, если они передаются через query-строку.
• Тела ответов (если экспорт делался «с содержимым») — HTML и JSON с персональными данными: ФИО, e-mail, суммы, документы.
• Ваш IP-путь — serverIPAddress по каждому хосту, плюс полный список сторонних доменов, к которым ходила страница.

Отправить необработанный HAR в поддержку — это отдать доступ к своей сессии. Файл уходит в тикет-систему, оседает в почте, пересылается между сотрудниками и живёт там годами. Считайте сырой HAR-файл эквивалентом пароля.

Как записать HAR без чувствительных данных

• Не логиньтесь внутри этой же записи. Войдите в аккаунт заранее, затем откройте панель, включите запись и воспроизводите только сам сбой. Тогда в файле не будет POST на страницу входа с логином и паролем.
• Записывайте минимум. Одно действие — один HAR. Чем короче запись, тем меньше в ней лишнего и тем проще её потом читать поддержке.
• Если проблема воспроизводится без авторизации — снимайте HAR в приватном окне на неавторизованной сессии. Это самый чистый вариант: cookie почти нет, токенов нет.
• Не сохраняйте тела ответов, если вас об этом не просили. Тела ответов (response.content.text) — это отдельная от заголовков сущность. Экспорт «с содержимым» вкладывает в файл HTML и JSON целиком, в base64: файл распухает в разы и начинает содержать данные с экрана. Для диагностики скорости тела не нужны совсем — тайминги и размеры лежат в других полях.
• Не полагайтесь на «санитизированный» экспорт браузера. В свежем Chrome обычный экспорт действительно вырезает cookie и Authorization, но это поведение появилось не во всех версиях и не во всех браузерах. Всегда проверяйте файл сами — команда для проверки ниже.

Как вычистить HAR перед отправкой в поддержку

HAR — это JSON, поэтому его можно отредактировать программно. Самый удобный инструмент — jq. Команда ниже обнуляет cookie в запросах и ответах, выбрасывает авторизационные заголовки и Set-Cookie, стирает тела POST-запросов и тела ответов:

# Вычистить HAR: cookie, авторизационные заголовки, тела запросов и ответов
jq --arg drop "cookie,authorization,proxy-authorization,x-api-key,x-auth-token,x-csrf-token" '
  ($drop | split(",")) as $d
  | .log.entries |= map(
        .request.cookies  = []
      | .response.cookies = []
      | .request.headers  |= map(select((.name | ascii_downcase) as $n | $d | index($n) | not))
      | .response.headers |= map(select((.name | ascii_downcase) != "set-cookie"))
      | (if .request.postData    then .request.postData.text = "[removed]"
                                      | .request.postData.params = [] else . end)
      | (if .response.content    then .response.content |= del(.text) else . end)
    )' raw.har > clean.har

Дальше — обязательная проверка. Первая команда должна вывести пустоту, вторая — ноль:

# 1. Не осталось ли заголовков cookie/authorization
jq -r '.log.entries[].request.headers[]?.name' clean.har   | tr 'A-Z' 'a-z' | grep -E '^(cookie|authorization)$' | sort -u

# 2. Не осталось ли тел ответов
jq '[.log.entries[].response.content.text // empty] | length' clean.har

# 3. Глазами: поиск подозрительных строк по всему файлу
grep -o -i -E '(bearer [a-z0-9._-]{10,}|sessionid|phpsessid|password)' clean.har | sort -u

Отдельно проверьте query-строки: если сайт передаёт токен через URL (?token=…, ?key=…), он останется в поле request.url, и никакая чистка заголовков его не уберёт. Такие URL проще заменить руками в текстовом редакторе.

Если вы уже отправили HAR с боевой сессией — считайте её скомпрометированной. Выйдите из аккаунта на всех устройствах (в нормальном сервисе есть кнопка «завершить все сеансы»), отзовите ключи API, которые светились в заголовках, и смените пароль, если в записи был вход в аккаунт.

Важное следствие для диагностики: вычищенный HAR анализируется ровно так же информативно, как и сырой. Тайминги (timings), коды ответов, размеры (bodySize, headersSize), заголовки кеширования и сжатия, порядок запросов — всё это остаётся на месте. Секреты лежат в других полях. Поэтому «мне нужен HAR с содержимым» — требование, которое стоит уточнять: для разбора скорости оно почти никогда не обязательно.

Как открыть и прочитать HAR-файл

Три рабочих способа:

• Обратно в панель разработчика. Откройте вкладку «Сеть» и перетащите .har прямо в список запросов — браузер отрисует привычный waterfall со всеми таймингами. Это самый быстрый способ «посмотреть глазами».
• Онлайн-анализатор. Наш анализатор HAR разбирает файл и сразу показывает узкие места: самые долгие запросы, цепочки редиректов, тяжёлые несжатые ресурсы.
• Текстовый редактор или jq. Когда нужно ответить на конкретный вопрос («какой запрос вернул 502?»), быстрее написать одну команду, чем листать интерфейс.

Что смотреть в первую очередь:

• Waterfall — визуальная лента запросов. Ищите длинные полосы и «ступеньки», где следующий запрос начинается только после завершения предыдущего.
• Коды ответов — всё, что не 2xx: 3xx (лишние редиректы), 4xx (битые ссылки, отвалившаяся авторизация), 5xx (ошибка на сервере).
• Тайминги — разбивка времени по фазам (таблица ниже).
• Размеры и сжатие — bodySize в сотни килобайт при отсутствии заголовка Content-Encoding означает, что ресурс отдаётся без gzip или brotli.

Поле в timings	Что означает	О чём говорит большое значение
blocked	Ожидание в очереди браузера до начала запроса	Упёрлись в лимит одновременных соединений к одному хосту, либо тормозит прокси или расширение браузера
dns	Резолвинг доменного имени	Медленный или далёкий DNS-резолвер, холодный кеш, много разных сторонних доменов
connect	Установка TCP-соединения	Сервер географически далеко, потери пакетов, нет keep-alive
ssl	TLS-рукопожатие (входит в connect)	Длинная цепочка сертификатов, нет возобновления сессии, слабое железо на сервере
send	Отправка запроса на сервер	Большое тело POST или узкий исходящий канал у клиента
wait	Ожидание первого байта ответа — это и есть TTFB на уровне запроса	Медленный бэкенд: тяжёлые запросы к БД, отсутствие кеша, внешние API внутри обработчика
receive	Скачивание тела ответа	Ресурс большой или не сжат, узкий канал, отдача без CDN

Значение -1 в любом из полей означает «неприменимо» — например, dns и connect равны -1, если соединение переиспользовано. Сумма всех фаз даёт entry.time.

Чем HAR не является

HAR описывает сеть, и только сеть. Он не покажет:

• Работу JavaScript. Долгие вычисления, блокирующий main thread, лишние ререндеры — это профилировщик Performance, а не HAR.
• Рендеринг и раскладку. Сдвиги макета, время до отрисовки крупного элемента, отзывчивость на клик — это Core Web Vitals, их HAR не измеряет.
• Оценку «на сколько баллов». HAR — сырые данные, а не отчёт. Синтетический аудит с рекомендациями даёт инструмент проверки скорости.
• Что происходит на сервере. Длинный wait говорит, что бэкенд думал долго, но не говорит почему — за этим в логи приложения.

Как по HAR найти причину медленной загрузки

Начните с двух команд: одна показывает, кто дольше всех думал, вторая — кто больше всех весит.

# Топ-20 запросов по времени ожидания ответа сервера (wait ~ TTFB)
jq -r '.log.entries[] | [(.timings.wait | floor), .response.status, .request.url] | @tsv' page.har   | sort -rn | head -20

# Самые тяжёлые ответы и их сжатие
jq -r '.log.entries | sort_by(-(.response.bodySize)) | .[:15][]
       | [ .response.bodySize,
           (.response.content.mimeType // "-"),
           (first(.response.headers[] | select(.name | ascii_downcase == "content-encoding") | .value) // "none"),
           .request.url ] | @tsv' page.har

# Цепочки редиректов
jq -r '.log.entries[] | select(.response.status >= 300 and .response.status < 400)
       | [.response.status, .request.url, (.response.redirectURL // "-")] | @tsv' page.har

# Запросы, которые повторяются больше одного раза
jq -r '.log.entries[].request.url' page.har | sort | uniq -c | sort -rn | awk '$1 > 1'

Что видно в HAR	Вероятная причина	Что делать и чем проверить
Длинный wait (сотни мс — секунды) у самого HTML-документа	Медленный бэкенд: тяжёлые запросы к БД, нет кеша страницы, внешний вызов внутри обработчика	Кеширование на стороне сервера, профилирование бэкенда. Замерить снаружи — проверка скорости
Десятки запросов с длинным blocked	Упёрлись в лимит одновременных соединений к одному хосту (характерно для HTTP/1.1)	Перейти на HTTP/2 или HTTP/3, объединить мелкие файлы. Проверить протокол и заголовки — анализ HTTP-заголовков
Цепочка 301 → 302 → 200 в начале записи	Лишние редиректы: http → https → www → слеш в конце	Свести к одному переходу. Проверить цепочку — проверка URL и редиректов
Ресурсы в сотни килобайт без Content-Encoding	Не включено сжатие gzip или brotli на сервере	Включить сжатие для текстовых типов. Проверить — анализ HTTP-заголовков
В начале waterfall много сторонних доменов	Блокирующие сторонние скрипты: аналитика, чаты, виджеты, шрифты	Загружать их с async/defer, после основного контента
Один и тот же URL повторяется десятки раз	Нет кеширования, кривой повтор запроса или цикл в клиентском коде	Заголовки Cache-Control и ETag, ограничение ретраев
Длинный dns у многих доменов	Медленный резолвер или холодный кеш	Сократить число сторонних доменов. Проверить — DNS-проверка и проверка пинга
Длинный connect и ssl	Сервер далеко, потери пакетов, тяжёлое рукопожатие	CDN, keep-alive, проверить маршрут — трассировка

HAR-файл: ошибки при записи и как их починить

Файл пустой или в нём две записи

Почти всегда — не включена галка «сохранять журнал», и перезагрузка стёрла список. Либо панель разработчика открыли уже после загрузки страницы: браузер записывает только то, что произошло при открытой панели. Порядок правильный: открыть панель → включить «сохранять журнал» → и только потом перезагружать.

Запись оборвалась на редиректе

Та же причина. Каждый переход по адресу — это новая навигация, и без «сохранять журнал» список очищается. Особенно заметно на страницах входа и оплаты, где переходов несколько подряд.

Файл слишком большой

HAR на 50–200 МБ обычно означает экспорт «с содержимым» на тяжёлой странице: тела ответов лежат внутри в base64 и раздувают файл примерно на треть от исходного объёма. Что делать:

# Сколько записей и какой объём
jq '.log.entries | length' page.har
du -h page.har

# Оставить только запросы к своему домену — файл станет в разы легче
jq '.log.entries |= map(select(.request.url | test("^https://example\.com/")))' page.har > small.har

# Или выбросить тела ответов, сохранив всю диагностику
jq '.log.entries |= map(if .response.content then .response.content |= del(.text) else . end)'    page.har > light.har

Файл не открывается, анализатор ругается на JSON

Обычно файл обрезан: браузер или вкладка упали во время экспорта, либо запись была слишком длинной. Признак — файл не заканчивается на }. Проверить целостность: jq empty page.har — если JSON битый, команда покажет позицию ошибки. Лечится только повторной записью, желательно более короткой. Ещё одна частая причина — файл переслали через мессенджер, который переименовал его или упаковал в архив: попробуйте открыть исходник.

В записи нет нужного запроса

Проверьте три вещи. Во-первых, фильтры в панели «Сеть»: если включён фильтр по типу (например, только XHR), экспорт всё равно обычно кладёт все запросы, но в интерфейсе вы их не увидите — ищите в файле, а не на экране. Во-вторых, запрос мог уйти из другой вкладки, из iframe или из расширения — HAR записывает только текущую вкладку. В-третьих, ответ мог прийти из кеша: включите «Отключить кеш» (Disable cache) и повторите.

Как проанализировать HAR на enterno.io

Загрузите файл в анализатор HAR: он разберёт log.entries, посчитает распределение времени по фазам, найдёт самые долгие запросы, цепочки редиректов, ответы с ошибочными кодами и тяжёлые несжатые ресурсы. Вычищенный от cookie и токенов файл анализируется так же полно — тайминги и размеры чистка не трогает.

Чем дополнить картину:

• Проверка скорости — синтетический замер снаружи, чтобы понять, проблема у всех или только у вас;
• Проверка URL — коды ответов и цепочка редиректов для конкретного адреса;
• Анализ HTTP-заголовков — кеширование, сжатие, протокол. Подробнее в статье о HTTP-заголовках;
• Пинг и трассировка — если в HAR долгие connect и dns. Как читать результаты — в статье о проверке пинга.

Частые вопросы

HAR-файл — это опасно?

Сырой — да. В нём лежат cookie вашей сессии, заголовок Authorization и тела форм. Этого достаточно, чтобы войти в ваш аккаунт без пароля, пока сессия не истекла. Вычищенный HAR безопасен и при этом полностью пригоден для диагностики скорости.

Как открыть HAR-файл без интернета?

Перетащите его во вкладку «Сеть» панели разработчика любого браузера — он отрисуется как обычный waterfall. Это работает офлайн, файл никуда не отправляется.

Чем HAR отличается от скриншота панели «Сеть»?

Скриншот показывает картинку, HAR — данные. По HAR можно отсортировать запросы, посчитать суммы, найти конкретный заголовок и загрузить файл в анализатор. Поддержке почти всегда нужен именно файл.

Почему в HAR нет тела ответа?

Потому что экспорт был обычный, а не «с содержимым». Для диагностики скорости это нормально и даже правильно: тайминги, коды и размеры на месте, а персональных данных в файле нет.

Можно ли записать HAR на телефоне?

Напрямую в мобильном браузере — нет. Стандартный путь: подключить телефон к компьютеру и снять запись через удалённую отладку (для Android-браузеров на Chromium — из десктопного Chrome, для Safari на iOS — из Safari на macOS). Панель «Сеть» при этом работает как обычно.

Сколько записей нормально для одной страницы?

Типовая страница делает от нескольких десятков до пары сотен запросов. Тысяча и больше — уже повод посмотреть, нет ли цикла в клиентском коде или лавины сторонних скриптов.

Поддержка просит «HAR с содержимым» — соглашаться?

Уточните, какой именно запрос им нужен. Часто достаточно тела одного конкретного ответа, а не всей страницы. Если тела действительно нужны — снимайте запись на тестовом аккаунте или на данных, которые не жалко показать.

Чеклист перед тем, как отправить HAR

• Панель разработчика открыта до перезагрузки, галка «сохранять журнал» включена.
• В записи только воспроизведение проблемы — без входа в аккаунт и посторонних действий.
• Экспорт сделан без тел ответов, если их прямо не просили.
• Файл прогнан через jq: cookie обнулены, Authorization и Set-Cookie удалены, тела POST стёрты.
• Проверка выполнена: поиск по cookie, authorization, bearer, password ничего не находит.
• Токены в query-строках заменены вручную.
• Размер файла разумный — лишние домены отфильтрованы.
• jq empty file.har отрабатывает без ошибок — JSON целый.
• Файл открывается обратно в панели «Сеть» и содержит нужный запрос.
• Если в записи была боевая сессия — она завершена, ключи API отозваны.