Cloudflare Browser Rendering и Browser Run: сессии, лимиты и архитектура автоматизации

Cloudflare Browser Run предоставляет доступ к управляемому браузеру Chrome без необходимости настраивать собственный сервер. Его используют для отображения страниц с JavaScript, создания снимков экрана и PDF, тестирования интерфейсов и запуска браузерных сценариев с помощью AI-агентов.

По запросу Cloudflare Browser Rendering все еще можно найти информацию об этом продукте, но в 2026 году его актуальное название Browser Run. Он хорошо подходит для разового отображения страниц и разрешенного сбора данных, однако длительные авторизованные сессии требуют отдельного подхода к сохранению состояния. Если главная сложность связана с антибот-проверками, сначала разберитесь, как работает Cloudflare для веб-скрапинга, и только потом выбирайте среду запуска браузера.

На практике выбор сводится к трем архитектурным подходам:

• Browser Run как облачный рендерер для страниц, которые можно законно обрабатывать без постоянного пользовательского профиля
• локальный или серверный Playwright, Puppeteer либо Selenium, когда нужен полный контроль над средой
• профильная инфраструктура, где файлы cookie, localStorage, прокси, цифровой отпечаток и настройки аккаунта сохраняются в согласованной среде

Для процессов без написания кода могут быть полезны визуальные сценарии автоматизации.

Как соотносятся названия Browser Rendering и Browser Run

Cloudflare Browser Rendering является прежним названием продукта, а Browser Run актуальным. В документации Cloudflare прямо указано, что раньше Browser Run назывался Browser Rendering, поэтому в поиске и статьях оба варианта могут встречаться одновременно.

На практике ориентируйтесь на Browser Run. Именно так называются текущие страницы о Quick Actions, Playwright, Puppeteer, CDP, лимитах и тарифах. Если в старой статье или примере кода еще встречается browser-rendering, это не обязательно означает, что API устарел. Маршрут, SDK и дату документации нужно проверять отдельно.

Если команда планирует управлять браузерными задачами через AI-агентов, отдельно оцените Afina MCP для AI-агентов. Так выбор облачной среды выполнения не смешается с выбором инструмента оркестрации.

Для SEO и технического поиска учитывайте оба названия:

• cloudflare browser rendering как старый высокочастотный запрос
• cloudflare browser run как актуальное название продукта
• browser run limits как запрос о квотах и ошибках 429
• browser run sessions как запрос о повторном использовании браузера
• cloudflare headless chrome как запрос о механике запуска

Такое разделение экономит время при отладке. Если команда ищет ошибку Browser time limit exceeded, ей нужна страница лимитов Browser Run. При чтении старого обзора Browser Rendering следует проверить, не изменились ли значения лимитов после переименования.

Какие способы запуска и управления браузером доступны сейчас

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

Quick Actions работают как готовые HTTP-операции. С их помощью можно получить HTML, сделать снимок экрана, создать PDF, получить Markdown, собрать ссылки или запустить обход страниц. Это удобно для задач, в которых не требуется сложный сценарий на Playwright. Например, сервис мониторинга может раз в час снимать собственную страницу после развертывания обновления или проверять работу SSR на странице с большим количеством JavaScript.

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

Для проверки подключения можно использовать минимальный пример с Playwright. В нем BROWSER_CDP_URL означает адрес CDP-подключения, полученный для браузерной сессии. Конкретный способ получения адреса зависит от выбранного варианта запуска Browser Run.

import { chromium } from 'playwright';

const browser = await chromium.connectOverCDP(process.env.BROWSER_CDP_URL);
try {
  const context = browser.contexts()[0] ?? await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com', { waitUntil: 'domcontentloaded' });
  console.log(await page.title());
} finally {
  await browser.close();
}

Это пример управления уже доступной CDP-сессией, а не полная инструкция по ее созданию в Cloudflare. Для рабочей среды добавьте обработку ошибок и контроль времени выполнения.

Browser Run не заменяет весь набор браузерных инструментов. Это облачная среда выполнения для определенного класса задач. Если задача длится около минуты и не требует постоянного пользовательского профиля, Browser Run выглядит логичным выбором. Если нужно возвращаться на сайт в том же профиле, потребуется сохраненный профиль, а не очередной чистый Chrome в безголовом режиме.

Не каждый рабочий процесс относится только к одному из этих вариантов. Часто в одном продукте короткие задачи по обработке и отображению страниц для технических проверок соседствуют с отдельной профильной инфраструктурой для операторской работы.

Как проверять лимиты сессий, запусков и параллельных браузеров

Лимиты Browser Run зависят от плана Cloudflare Workers и типа использования. План Free включает 10 минут browser time в день, 3 одновременные Browser Sessions, 1 новый браузер каждые 20 секунд, 60 секунд idle timeout и 1 запрос Quick Actions каждые 10 секунд.

В Workers Paid действует другая модель. На странице лимитов Cloudflare указаны отсутствие дневного ограничения browser hours, 200 одновременных Browser Sessions по умолчанию, 3 новых браузера в секунду, 60 секунд idle timeout и 30 запросов Quick Actions в секунду. В тарифах при этом указаны 10 browser hours в месяц в составе плана, $0.09 за каждый дополнительный browser hour, 10 concurrent browsers в стоимости плана для Browser Sessions и $2.00 за дополнительный concurrent browser по среднемесячному расчету.

Не смешивайте два разных показателя. Лимит 200 concurrent browsers в документации означает техническую границу по умолчанию для Paid. Число 10 concurrent browsers на странице тарифов означает включенный объем, после которого появляется плата за среднемесячную пиковую параллельность. Поэтому команда технически может запустить больше браузеров, чем входит в базовый тариф.

Начните проверку с короткого сценария, а не с рабочей нагрузки:

1. зафиксируйте план Cloudflare Workers и дату проверки
2. запустите одну Quick Action и сохраните X-Browser-Ms-Used
3. запустите одну Browser Session и закройте ее через browser.close()
4. повторите запуск серией и отслеживайте появление HTTP 429
5. проверьте idle timeout без команд в течение 60 секунд
6. повторите тест с keep_alive, если в сценарии есть паузы между действиями
7. сверьте итог с панелью Browser Run

При такой проверке причиной проблемы нередко оказывается ошибка в коде, а не ограничение Cloudflare. Например, браузер не закрывается в блоке finally, сессия остается активной до истечения времени ожидания, а учет браузерного времени продолжается. Такая ошибка может привести к непредвиденным расходам.

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

Как оценить расходы для типового рабочего сценария

Стоимость Browser Run рассчитывается не по количеству страниц, а по browser time и, для Browser Sessions, по среднемесячной параллельности. Поэтому два сценария с одинаковыми 100 000 URL могут стоить по-разному. Легкие страницы с Quick Actions потребуют мало времени, а сложные одностраничные приложения со скриптами, медиафайлами и долгим ожиданием networkidle2 израсходуют больше.

Отдельного внимания требуют неудачные запросы и превышение времени ожидания. Cloudflare указывает, что Quick Actions с waitForTimeout не добавляют billable browser hours, но это не повод разрешать неограниченное количество повторов. Повторные попытки быстрее расходуют лимиты запросов, увеличивают очередь и усложняют анализ журналов.

Сначала уменьшите вес страницы и отключите загрузку ненужных ресурсов, если сценарий это допускает. Точно задайте waitForSelector и не ждите полного прекращения сетевой активности там, где страница постоянно поддерживает аналитику или websocket-соединение.

Рассмотрим упрощенный расчет для Workers Paid, если команда использует 50 browser hours в месяц. Первые 10 часов входят в план, остальные 40 умножаются на $0.09. Browser time в таком примере добавляет $3.60 сверх базового плана. Если Browser Sessions в среднем за месяц используют одновременно 15 браузеров, 10 входят в тариф, а оставшиеся 5 умножаются на $2.00. Это еще $10.00 за параллельность. Общие дополнительные расходы составят $13.60 без учета стоимости самого плана Workers Paid.

Для собственного сценария используйте простую формулу:

1. измерьте средний browser time на одну страницу
2. умножьте его на месячное количество страниц
3. переведите секунды в часы
4. вычтите 10 часов, включенных в Workers Paid
5. умножьте остаток на $0.09
6. отдельно рассчитайте среднемесячный daily peak concurrent browsers
7. добавьте плату за concurrent browsers сверх включенного объема

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

Browser Run обычно проще запустить, а собственная инфраструктура предоставляет больше гибкости. Решение зависит от того, что обходится вашей команде дороже: инфраструктура или ограничения управляемой среды.

Расходы на Quick Actions обычно проще оценить, если сценарий состоит из коротких независимых действий. Если нужны сессия, вкладки и CDP, счет зависит от того, закрывается ли браузер сразу после выполнения задачи. Для собственной автоматизации вне Cloudflare сравните эту модель с расходами на сервер, очередь задач, обновление браузеров, мониторинг и поддержку Playwright-стека. В зависимости от нагрузки и требований к инфраструктуре Cloudflare может оказаться как более экономичным, так и более дорогим решением.

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

Управляемый облачный браузер стоит выбирать для задач, где браузер служит одноразовым исполнителем, а не постоянным пользовательским профилем. Это снимки экрана, PDF, QA-проверки, краулинг собственных страниц, создание превью и рендеринг контента для системы, которая имеет право получать эти страницы.

Отдельные профили нужны там, где важно сохранять состояние между запусками. Авторизованный аккаунт, файлы cookie, локальное хранилище, история сессии, стабильный прокси, часовой пояс, язык, WebGL, Canvas и User-Agent должны быть согласованы. Если каждый запуск начинается с чистой среды, сайт может воспринимать его как новое браузерное окружение. Для задач, связанных с цифровыми отпечатками и признаками безголового браузера, отдельно прочитайте об обнаружении headless-браузеров. Проблема часто заключается не в коде, а в том, как среда выглядит со стороны сайта.

Сравнение ниже помогает быстро исключить неподходящую архитектуру:

Для разовых задач по отображению страниц сначала рассмотрите Browser Run. Если нужен полный контроль над кодом и средой, лучше подойдет собственный Playwright. Для длительной работы с авторизованными аккаунтами и сохранения их состояния удобнее изолированные браузерные профили.

Практическая ценность Afina здесь выходит за рамки простого снимка экрана. Отдельные браузерные профили, локальная автоматизация, API, прокси и контроль среды объединены для задач, где состояние должно сохраняться между запусками. Если сценариями нужно управлять программно, изучите отдельный материал об API Afina. Это не заменяет Browser Run для быстрого отображения страниц, а решает другой класс задач.

Материал предоставлен исключительно в ознакомительных и образовательных целях. Для скрапинга и автоматизации проверяйте правила платформы, robots.txt, условия доступа к данным и юридические ограничения в своей юрисдикции. Browser Run лучше оставить для разрешенных, коротких и хорошо измеримых браузерных действий. Профили и Afina уместны там, где рабочий процесс зависит от стабильного состояния, изоляции аккаунтов и управляемой автоматизации, а не от разового запуска headless Chrome.