Отладка Cloudflare Browser Rendering: сначала Inspect, потом перезапуск

Cloudflare 18 сентября 2026 года изменила порядок разбора неудачных запусков. Теперь в завершённой записи Browser Run можно посмотреть логи консоли, сетевые запросы и итоговую структуру страницы. Это позволяет провести отладку Cloudflare Browser Rendering по уже собранным и оплаченным данным, прежде чем снова запускать браузер.

Отладка Cloudflare Browser Rendering начинается с данных завершённого запуска

Раньше после выполнения браузерной задачи оставались её результат, обработанные ошибки и воспроизведение — если Session Recording было включено заранее. Когда причина сбоя была неочевидна, обычно приходилось добавлять новые логи и повторять запуск.

Новая панель Inspect добавляет к завершённой записи три представления:

• Logs позволяет искать по сохранённому выводу консоли и фильтровать его по уровню.
• Network показывает для каждого запроса метод, статус, заголовки, данные, ответ и время выполнения. Всю активность можно экспортировать в HAR — стандартный архивный формат для истории браузерных запросов.
• DOM показывает структуру страницы в конце записи и позволяет скопировать восстановленный HTML. DOM — это дерево элементов, которое браузер построил из страницы.

Это данные для анализа после запуска, а не ещё один инструмент отладки в реальном времени. Session Recording от Cloudflare хранит структурированные события rrweb, а не видео. Запись включает изменения DOM, действия мышью и клавиатурой, а также переходы между страницами. После завершения сессии панель Inspect дополняет воспроизведение подсказками, по которым можно выполнять поиск.

Этим релиз отличается от предыдущего обновления Cloudflare Browser Run. Ограничения сессии и Live View только для чтения определяют, куда может перейти активная задача и что разрешено клиенту во время просмотра. Inspect помогает вашей команде понять, почему уже завершённая задача закончилась сбоем.

Какие сбои можно выявить по записи

Панель полезна, когда сбой оставил следы внутри браузера.

Основатель SaaS может найти отклонённый запрос

Представим, что регулярная задача извлечения данных открывает страницу, но ничего не возвращает. В Network видно, ответил ли API кодом 401, сработало ли ограничение частоты с кодом 429, отправил ли редирект браузер не туда или заняла ли одна из зависимостей большую часть времени запуска.

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

Руководитель агентской команды отличит изменение страницы от ошибки в скрипте

Клиентский сценарий может сломаться из-за изменившегося селектора, страницы входа вместо ожидаемого экрана или ошибки при загрузке ресурса. Итоговый DOM и скопированный HTML показывают, на какой странице в действительности остановился браузер. Цепочка запросов объясняет, как он туда попал.

Команда разработки получает конкретные материалы для работы. Вместо размытого «автоматизация сломалась» у неё будут итоговое дерево элементов и HAR с доступными заголовками, данными, статусами и таймингами.

Платформенный инженер сможет проследить за нужной вкладкой

В записи массивы событий привязаны к целям Chrome DevTools Protocol, например target-1; каждая такая цель обычно соответствует отдельной вкладке браузера. В записи с несколькими вкладками цели представлены раздельно, а панель Inspect в дашборде следует за выбранной вкладкой.

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

Как записать одну задачу и получить трассировку сети

Запись нужно включать явно при первом запуске браузерной сессии. Активировать её позже, при повторном подключении к уже существующей сессии, нельзя.

Для начала достаточно одной регулярной Browser Session, сбои которой сейчас приходится воспроизводить вручную.

1. 1

   Включите запись при запуске

   В примере Cloudflare для Puppeteer параметр recording: true передаётся при первом вызове запуска. Сохраните ID сессии до закрытия браузера:

   import puppeteer from "@cloudflare/puppeteer";
   
   interface Env {
   	MYBROWSER: Fetcher;
   }
   
   export default {
   	async fetch(request: Request, env: Env): Promise<Response> {
   		const browser = await puppeteer.launch(env.MYBROWSER, { recording: true });
   		const page = await browser.newPage();
   
   		await page.goto("https://example.com");
   		// ... your automation steps ...
   
   		const sessionId = browser.sessionId();
   		await browser.close();
   
   		return new Response(`Session recorded: ${sessionId}`);
   	},
   };

   В Playwright используется тот же параметр запуска. При подключении по CDP укажите recording=true в WebSocket URL.

2. 2

   Запросите завершённую запись

   После закрытия сессии запросите запись по её ID:

   curl https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID> \
     -H "Authorization: Bearer <API_TOKEN>"

   В ответе массивы событий находятся в result.events. Ключи вроде target-1 — это ID целей, которые понадобятся в запросе сетевых данных. Новая запись может некоторое время возвращать 404, пока Cloudflare завершает её обработку, поэтому повторите запрос и не считайте первый 404 признаком отсутствующей записи.

3. 3

   Получите исходные запросы выбранной цели

   Выберите цель из ответа с записью. Параметр target обязателен:

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>' \
     -H "Authorization: Bearer <API_TOKEN>"

   Ответ содержит сохранённые запросы в формате JSON, включая доступные сведения о запросах и ответах.

4. 4

   Экспортируйте HAR

   Добавьте format=har, если разработчику нужно открыть трассировку в браузерном просмотрщике сетевых запросов или другом инструменте анализа:

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>&format=har' \
     -H "Authorization: Bearer <API_TOKEN>"

   Считайте этот файл отладочным артефактом и ограничьте доступ к нему. Согласно документации, ответ может содержать доступные заголовки и данные, поэтому обращаться с ним нужно так же осторожно, как с данными самой задачи.

Распространённая ошибка — включать запись только после первого сбоя. Получить материалы для анализа задним числом уже не получится. Начните с регулярной задачи, следующий сбой которой действительно важен.

Основные затраты — не плата за работу браузера

В актуальных тарифах Browser Run Cloudflare не указывает отдельную плату за запись или её хранение. Записанная Browser Session по-прежнему учитывается в обычном счёте за браузерные часы и параллельные браузеры. Session Recording находится в бета-версии, поэтому воспринимайте это как опубликованную на сегодня цену, а не как бессрочное обещание.

Workers Free включает 10 минут работы браузера в день и три параллельных браузера. Для Workers Paid действует минимальный платёж $5 в месяц на аккаунт; в него входят 10 браузерных часов и 10 параллельных браузеров. Дополнительный браузерный час стоит $0.09, а дополнительный параллельный браузер — $2 по среднемесячному значению ежедневных пиков.

Прямая стоимость одного диагностического перезапуска невелика. Рабочее время вокруг него обходится гораздо дороже. Ниже — модель для планирования, а не бенчмарк Cloudflare:

• Аккаунт уже израсходовал включённые 10 браузерных часов.
• Одна регулярная задача выполняется 10 минут и завершается сбоем 12 раз за месяц.
• На воспроизведение и диагностику каждого сбоя у специалиста уходит 20 минут.
• Проверка существующей записи занимает 5 минут рабочего времени.
• Полная стоимость часа специалиста принята равной $75.
• Проверка позволяет избежать одного диагностического перезапуска, но позднее всё равно может понадобиться запуск для проверки исправления.

Из этой разницы лишь 18 центов приходится непосредственно на браузерное время. Остальные $225 — стоимость работы специалиста. Кроме того, Cloudflare округляет браузерное время на уровне аккаунта после подсчёта всего расчётного периода, поэтому не стоит ожидать, что 1.5 цента за 10-минутный запуск появятся в счёте отдельной строкой.

В этом и состоит влияние на бизнес. Панель Inspect не превращает браузерные вычисления в крупную статью экономии. Зато она может убрать из разбора инцидента целый цикл: добавить инструменты наблюдения, воспроизвести сбой и дождаться результата.

Чего запись не покажет

Запись сохраняет состояние документа и события, но не каждый отрисованный пиксель.

Эти ограничения показывают, где по-прежнему нужен другой способ диагностики. График в Canvas, форма оплаты во внешнем iframe, состояние видео, WebGL-сцена или значение в замаскированном поле могут работать неправильно, хотя окружающая запись выглядит нормально.

Представление DOM показывает структуру только в конце записи. По нему можно понять, на какой странице завершилась задача, но это не попиксельный скриншот каждого предыдущего состояния.

Есть и эксплуатационные ограничения. Записи доступны 30 дней, длятся от 1 секунды до 2 часов и работают с Browser Sessions через launch() или CDP. Quick Actions не умеют их создавать. Страница с большим числом изменений может сформировать объёмный поток событий, потому что каждое частое изменение DOM попадает в запись.

Кому стоит изменить процесс уже сейчас

Действуйте на этой неделе, если вы регулярно запускаете задачи в Puppeteer, Playwright или через CDP, а разбор сбоя обычно начинается с его воспроизведения. Включите запись для одной задачи, а не для всех сразу, и проверьте, отвечает ли она на первый вопрос диагностики.

Подождите, если критически важное состояние находится главным образом в Canvas, WebGL, медиаконтенте, iframe с другого домена или замаскированных полях формы. В таком сценарии сохраняйте скриншоты, логи приложения и точечные средства наблюдения: запись их не заменит.

Если вся работа выполняется через Quick Actions, изменение вас не затрагивает. Переход на Browser Sessions исключительно ради записи потребует другой реализации и добавит параллельные браузеры в модель оплаты, поэтому польза для отладки должна оправдывать такой шаг.

Что сделать в понедельник

Выберите одну регулярную Browser Session, которая уже не раз завершалась сбоем. Добавьте recording: true при первом запуске, сохраните ID сессии рядом с собственным ID задачи и дайте следующему запуску по расписанию завершиться обычным образом.

Затем получите запись, возьмите ID первой релевантной цели и запросите исходную сетевую трассировку или HAR. Замерьте, сколько времени потребуется, чтобы определить проблемный запрос или итоговое состояние страницы. Если эти данные избавляют от одного диагностического перезапуска, оставьте запись для этой задачи и включите трассировку в материалы инцидента. Если пользы нет, снова отключите запись и добавьте недостающий сигнал там, где действительно находится слепая зона.

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