ChromeDriver - обзор - 2026

Published: 2026-08-24

Введение

ChromeDriver — это отдельный исполняемый файл (автономный сервер), который реализует стандарты W3C WebDriver и WebDriver BiDi и позволяет внешним программам управлять браузером Google Chrome: открывать страницы, переходить по ссылкам, заполнять формы, извлекать содержимое документов, делать скриншоты и многое другое. Формально ChromeDriver — это не браузер и не библиотека, а именно мост между вашим тестовым или скриптовым кодом и реальным, живым браузером Chrome.

Сегодня автоматизация браузеров стала неотъемлемой частью современной разработки: на ней держатся end-to-end тесты (e2e), регрессионное тестирование, парсинг веб-страниц, мониторинг доступности сайтов, генерация отчётов и даже роботизация повторяющихся действий в административных панелях. В этой экосистеме ChromeDriver занимает особое место: он поддерживается командой Chromium, является официальным драйвером для Google Chrome и остаётся одним из самых стабильных и предсказуемых инструментов автоматизации для своего браузера.

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

Важно понимать одно ключевое ограничение с самого начала: ChromeDriver умеет управлять только браузером Chrome (и его сборками Chromium). Он не заменяет Selenium, не является универсальным инструментом для Firefox или Safari — для каждого браузера существует собственный драйвер (geckodriver, SafariDriver и так далее). Однако именно Chrome, в силу своей доли на рынке, чаще всего становится «подопытным кроликом» автоматизации, а значит ChromeDriver — самым востребованным драйвером в индустрии.

Что такое ChromeDriver: определение и назначение

Официальная документация определяет ChromeDriver как отдельный сервер, который реализует стандарты W3C WebDriver и WebDriver BiDi. WebDriver — это открытый протокол, созданный для автоматизированного тестирования веб-приложений в разных браузерах; его интерфейс позволяет управлять пользовательскими агентами локально или удалённо с помощью так называемых capabilities (возможностей). Capabilities — это универсальный набор пар «ключ — значение», который используется для описания желаемых характеристик и поведения сессии WebDriver. Обычно они передаются как аргумент при создании экземпляра WebDriver и могут задавать параметры браузера: его имя, версию, стратегию загрузки страницы и так далее.

Простыми словами: вы пишете код на Python, Java, Ruby, C# или JavaScript, в этом коде создаётся объект драйвера, после чего все ваши команды — «открыть страницу», «найти элемент по CSS-селектору», «кликнуть», «ввести текст» — уходят в ChromeDriver по HTTP-протоколу, а ChromeDriver превращает их в команды для самого Chrome. Внутри ChromeDriver использует протокол DevTools (CDP), чтобы общаться с браузером: фактически ChromeDriver является прослойкой между JSON-протоколом WebDriver и внутренним протоколом отладки Chrome.

Именно поэтому ChromeDriver нельзя просто «положить рядом с браузером» — его нужно согласовать с версией Chrome. Долгое время это было головной болью разработчиков: несовпадение версий Chrome и ChromeDriver приводило к загадочным ошибкам. Начиная с версии Chrome 115 Google решил эту проблему радикально — появилась программа Chrome for Testing (CfT), в рамках которой бинарники Chrome и ChromeDriver выпускаются для каждого релиза синхронно и скачиваются из единого центрального репозитория.

ChromeDriver доступен для Chrome на Android и Chrome на настольных платформах: macOS, Linux, Windows и ChromeOS. Для каждой платформы собирается отдельная версия бинарника, поэтому при скачивании важно выбирать нужную архитектуру (win32, win64, mac-arm64, linux64 и так далее), иначе драйвер просто не запустится либо запустится с ошибкой о неподдерживаемом формате исполняемого файла.

Зачем нужен ChromeDriver: сценарии использования

ChromeDriver используется в целом ряде сценариев, каждый из которых заслуживает отдельного упоминания.

Первый и самый массовый сценарий — автоматизированное тестирование. Когда команда разрабатывает веб-приложение, она хочет быть уверена, что новая версия кода не сломала существующий функционал. Для этого пишутся сотни автотестов: открывается страница, вводится логин и пароль, проверяется отображение таблицы, сохраняется настройка. Все эти действия выполняет ChromeDriver под управлением Selenium. Здесь важны стабильность, скорость и предсказуемость — именно поэтому тесты часто запускают в «headless» режиме, когда окно браузера не отображается, но вся внутренняя логика работает.

Второй сценарий — веб-скрапинг. Парсинг статичных HTML-страниц обычно выполняется без браузера, но как только речь заходит о сайтах, где контент подгружается JavaScript-ом (SPA на React, Vue, Angular), простой HTTP-запрос уже не даёт результата. Здесь на помощь приходит драйвер: он открывает страницу, ждёт выполнения скриптов и даёт доступ к уже отрисованному DOM. Некоторые проекты используют ChromeDriver для парсинга в связке с Selenium Grid — распределённым пулом браузеров, что позволяет обходить ограничения на количество запросов и собирать данные параллельно.

Третий сценарий — мониторинг и регрессионные проверки. Многие компании запускают cron-задачи по ночам: скрипт с ChromeDriver открывает критичные страницы, проверяет коды ответов и наличие ключевых элементов. Если что-то сломалось — приходит уведомление в мессенджер. Это дешёвый способ поймать падение какого-нибудь лендинга раньше, чем это заметят пользователи.

Четвёртый сценарий — внутренние инструменты и CI/CD. ChromeDriver легко встраивается в конвейеры непрерывной интеграции: в GitLab CI, GitHub Actions, Jenkins. Стандартный конвейер выглядит так: собрать проект, запустить модульные тесты, затем — e2e тесты в Chrome through to Selenium Grid, затем — смоук-тесты продакшена. Во всех этих шагах ChromeDriver выполняет роль «солдата», который управляет браузером.

Наконец, пятый сценарий — обучение и эксперименты. Поскольку ChromeDriver бесплатен и открыт, его используют в учебных курсах по автоматизации, студенческих проектах и хобби-проектах. Он интуитивно понятен моделям «драйвер — браузер — элемент — действие», что делает его отличной отправной точкой для изучения браузерной автоматизации.

Исторически главный инструмент высокого уровня, работающий поверх ChromeDriver, — это Selenium WebDriver. Selenium — это набор библиотек на разных языках (Java, Python, Ruby, C#, JavaScript, Kotlin, PHP), которые переводят ваши вызовы в HTTP-запросы к драйверу. Именно поэтому почти любой пример с ChromeDriver начинается с импорта selenium. Впрочем, драйвер можно использовать и напрямую через протокол — но это вариант для самых продвинутых и почти всегда нецелесообразен: гораздо проще взять готовую библиотеку и сэкономить время.

История и эволюция ChromeDriver

История ChromeDriver — это история стандартизации браузерной автоматизации в целом. Первые версии драйвера появились задолго до принятия W3C WebDriver, и в те времена интерфейсы разных драйверов отличались настолько, что это создавало настоящие проблемы для прикладных разработчиков.

Ключевая веха — появление и развитие Selenium WebDriver, который изначально был фреймворком без строгого стандарта. Многие драйверы (включая первые сборки ChromeDriver) реализовывали «родной» протокол Selenium (так называемый JSON Wire Protocol, протокол версии 3), который был достаточно гибким, но не стандартизированным и частично реализовывался каждой командой драйверов по-своему. Из-за этого одна и та же команда в Selenium Java и Selenium Python могла работать с нюансами, а также были различия между драйверами в поведении при ошибках.

В 2018 году рабочая группа W3C приняла спецификацию WebDriver версии 1, которая стала для всех драйверов обязательным минимумом. С тех пор ChromeDriver полностью соответствует стандарту W3C WebDriver: команды, закодированные как JSON-сообщения по HTTP, описываются едиными эндпоинтами, а статусы ошибок — единым набором кодов. Это означало, что код теста, написанный в 2019 году, с минимальными правками продолжает работать в 2026-м.

Следующий важный этап — разработка стандарта WebDriver BiDi (используется аббревиатура BiDi от «bidirectional»). Если классический WebDriver построен по модели «клиент запрашивает — сервер отвечает», то BiDi добавляет полноценные двунаправленные потоки: браузер может отправлять события в реальном времени (например, срабатывание сетевого события или изменение DOM), а клиент — подписываться на них. По сути BiDi заимствует идеи из протокола DevTools (CDP) и уже привычной модели событий Puppeteer, но подаёт их в стандартизированном виде, приложимом к любому браузеру. ChromeDriver реализует и WebDriver, и WebDriver BiDi, причём реализация BiDi по сей день активно развивается и дополняется.

Отдельная глава истории — версии и нумерация репозитория ChromeDriver. Вплоть до Chrome M115 бинарники ChromeDriver публиковались отдельно на странице загрузки, и их версии почти всегда совпадали с версией Chrome (например, ChromeDriver 114.0.5735.90 для Chrome 114). Разработчикам приходилось вручную связывать версию браузера, драйвера и Selenium — это было слабое место всей экосистемы, которое часто приводило к ошибкам типа «SessionNotCreatedException: The version of ChromeDriver must match the version of Chrome». С выходом Chrome 115 (июль 2023 года) Google запустила инициативу Chrome for Testing: теперь для каждой версии Chrome публикуется автоматически собранный комплект из самого браузера и совместимого драйвера, а получить этот комплект можно через незамысловатые JSON-эндпоинты. Эта реформа, вместе с автоматическими обновлениями Selenium Manager (начиная с Selenium 4.6), существенно упростила жизнь начинающим: современная библиотека Selenium сама скачивает нужный бинарник, и ручная возня с директориями почти не нужна.

В 2026 году ChromeDriver продолжает развиваться как часть семейства Chrome for Testing, поддерживает стандарты W3C, а его исходный код открыто лежит в репозитории Chromium, в каталоге docs/chromedriver. Любой разработчик может ознакомиться с реализацией, предложить исправление или написать собственную сборку.

Архитектура ChromeDriver: как происходит сессия

Чтобы эффективно отлаживать автоматизацию, нужно понимать как устроен весь путь команды — от вашего кода до браузерных процессов. Разберём архитектуру по шагам.

На верхнем уровне находится клиент — ваш тестовый код на Java, Python или C#, использующий библиотеку Selenium или любую другую обёртку WebDriver. Клиент формирует команды в виде JSON: например, перейти по URL — это метод POST на эндпоинт /session/{sessionId}/url с телом {"url": "https://example.com"}.

Клиент отправляет эти команды по HTTP на адрес сервера ChromeDriver. По умолчанию драйвер слушает локальный порт 9515, но вы можете выбрать любой свободный порт. Когда вы создаёте объект ChromeDriver через Selenium, библиотека сначала сама запускает сервер драйвера как отдельный процесс (если вы не указали существующий), а после создания сессии команды идут уже на него.

Драйвер, в свою очередь, становится клиентом для Chrome. Он запускает бинарник Chrome с особыми флагами, среди которых ключевой — --remote-debugging-port=N. Этот флаг открывает в браузере DevTools-порт, через который ChromeDriver поддерживает связь по протоколу DevTools (CDP). Внутренние детали здесь интересны, но для практики важнее понять принцип: всё, что вы делаете через WebDriver, в конечном итоге превращается в низкоуровневые команды CDP — «создать контекст», «найти элемент», «выполнить скрипт».

Стоит различать два уровня: сессия — это долгоживущий объект, создаваемый командой POST /session; в рамках сессии у браузера есть уникальный ID, по которому далее адресуются остальные команды. Когда сессия завершается командой DELETE /session/{sessionId} (или driver.quit()), Chrome закрывается, все временные данные очищаются. Отдельно существует пара connection между драйвером и клиентом: HTTP-запросы и JSON-ответы. Когда вы видите ошибку «Session not created», это значит, что драйверу не удалось корректно установить связь с браузером.

Внутри самого Chrome взаимодействие организовано через процессы: один главный процесс браузера и множество дочерних (рендеринг вкладок, сетевые процессы и так далее). С точки зрения WebDriver все эти процессы скрыты за абстракцией «сессия», и вы работаете с ней как с единым механизмом, из чего следует, что сложный таймлайнинг, ожидания загрузки страницы и определение провала — это уже ответственность ваших тестовых библиотек.

Ключевая архитектурная деталь — именно возможность запуска Chrome в различных режимах. Драйвер передаёт браузеру аргументы командной строки, и один из них всегда присутствует: порт удалённой отладки. Поэтому если вы вручную запускаете chromedriver с аргументом --port=9517, но при этом в cli параметрах Selenium передаёте другой — сессия не создастся. Аналогично: за новую вкладку отвечает не драйвер, а сам Chrome; драйвер лишь находит появившееся окно и отдаёт его клиенту.

Протоколы: W3C WebDriver и WebDriver BiDi

Понимание двух протоколов критично, особенно в 2026 году, когда индустрия массово переходит на BiDi. Рассмотрим их по отдельности.

W3C WebDriver, классика: он описывает HTTP-эндпоинты, которые отдают команды драйверу. Клиент отправляет запрос → драйвер его выполняет → возвращает ответ. Одна команда — один ответ. Примеры команд: «вызвать newSession», «найти элемент», «получить список окон», «установить время ожидания», «выполнить скрипт». Вся семантика синхронная: вы не узнаете о фоновых сетевых событиях, пока сами их не запросите. Меньше возможностей, но зато полная совместимость: один и тот же тест можно прогнать на Chrome, Firefox и Safari через родные драйверы.

WebDriver BiDi: второй стандарт, активно расширяющийся с 2021 года. Он добавляет долгоживущие бинарные потоки (по сути, WebSocket-подобные) между клиентом и драйвером, по которым браузер передаёт события в реальном времени. Среди ключевых событий: данные трафика (network events), изменение DOM (DOM events), жизненный цикл страниц (browsingContext), свойства сессии (log events). Практические выгоды:

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

До появления BiDi эти возможности в Chrome доступны только через CDP, который официально Chrome не обещает поддерживать переходами между версиями, и поэтому все реализации наспех склеены через Selenium's execute_cdp_cmd. BiDi — это стандарт и он работает во всех браузерах.

Что означает «реализует ChromeDriver»? На текущий момент ChromeDriver поддерживает и классический WebDriver, и большую часть BiDi-модулей, причём совместимость с BiDi реализуется не самостоятельно, а через проект chromium-bidi (репозиторий GoogleChromeLabs/chromium-bidi), который является полноценным браузером-агентом поверх CDP и также может использоваться напрямую вместе с Puppeteer и другими клиентами. Официальная документация подчёркивает, что можно поучаствовать в разработке: контрибуции(https://github.com/GoogleChromeLabs/chromium-bidi#contributing) приветствуются.

Для пользователя это означает практический совет: если ваша библиотека поддержки (например, Selenium версии 4.30+) показывает опцию biDi — включайте её, если нужны события трафика или беззаботная работа с новой вкладкой. Если нет — не мучайтесь: классический протокол никуда не девается и остаётся совместимым.

Chrome for Testing: новый канал загрузки

С версии Chrome 115-й выпуск браузеров Chrome для тестирования и драйверов идёт по так называемому «Chrome for Testing» — специальному набору бинарников, собранному для автоматизации. Раньше добираться до драйвера было неудобно: страница загрузки, выбор платформы, сверка версий. Теперь же для каждого выпуска публикуется комплект.

Как это работает на практике. Бинарники публикуются в трёх видах:

Chrome (для тестирования) — сам браузер: compressed zip/zip64;
chromedriver — драйвер;
chromium-headless-shell — компактная оболочка для headless-запусков без дополнительных компонентов.

Полезные JSON-эндпоинты:

Простейший способ получить актуальный драйвер — навести любой скрипт на JSON «последних известных версий», распарсить поле «chromedriver» и скачать архив. В 2024–2026 годах практически все популярные библиотеки автоматизации интегрировали этот механизм напрямую: Selenium Manager (в составе Selenium 4.6+), а также всё большее число инструментов, ориентированных на WebDriver, автоматически скачивают драйвер при первом использовании, если он не найден в PATH. Это означает, что для большинства начинающих пользователей шаг ручной установки драйвера уже почти не требуется.

Что делать тем, кому нужна старая версия? Для более старых релизов Chrome сохранены архивы: [страница Stable Releases](https://developer.chrome.com/docs/chromedriver/downloads) и [Canary Releases](https://developer.chrome.com/docs/chromedriver/downloads/canary) всё ещё работают; там драйвер можно подобрать вручную.

Важная особенность Chrome for Testing: он не обновляется сам по себе. Ваш «обычный» Chrome обновляется в фоне и меняется версия — а драйвер, если вы его один раз скачали, останется прежним. Поэтому правило: версия ChromeDriver должна совпадать с версией браузера минимально вплоть до мажорной версии. Идеально — полное совпадение. Это правило автоматически соблюдается, если и Chrome, и драйвер брать из одного комплекта Chrome for Testing.

Установка ChromeDriver на разных платформах

Разберём установку пошагово для трёх основных платформ. Общий принцип одинаков: скачать бинарник, распаковать, добавить в PATH (или указать путь явно). Рассмотрим все три набора инструкций.

Windows

1. Откройте браузер, перейдите на [дашборд Chrome for Testing](https://googlechromelabs.github.io/chrome-for-testing/) и найдите ветку с актуальными загрузками для вашей версии Chrome. 2. Скачайте архив под названием chromedriver-win64.zip. 3. Распакуйте в удобное место, например, C:\tools\chromedriver. 4. Добавьте папку в переменную окружения PATH через Панель управления → Система → Дополнительные параметры → Переменные среды → Path → Новый. 5. Проверьте в командной строке: chromedriver --version.

Если PATH менять не хочется, можно обойтись указанием пути прямо в коде (см. ниже). На Windows это удобно сделать через системную переменную. В Python примерах можно и вовсе передавать executable_path.

macOS

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

brew install --cask chromedriver

Кстати, cask ставит последнюю версию из Chrome for Testing. Если Chrome у вас актуальный — конфликтов не будет.

Ручной путь:

DATASET=$(curl -s https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-downloads.json)
URL=$(echo "$DATASET" | jq -r '.versions[0].downloads.chromedriver[] | select(.platform=="mac-arm64") | .url')
curl -o chromedriver.zip "$URL"
unzip chromedriver.zip
sudo mv chromedriver-mac-arm64/chromedriver /usr/local/bin/
chmod +x /usr/local/bin/chromedriver

Проверка — выполнить chromedriver --version. Если вы сталкиваетесь с предупреждением Gatekeeper:

xattr -d com.apple.quarantine /usr/local/bin/chromedriver

Linux

На Debian/Ubuntu можно ставить через драйверы пакетов, но самый кросс-дистрибутивный путь — скрипт:

curl -sL https://googlechromelabs.github.io/chrome-for-testing/known-good-versions-with-downloads.json | jq -r '.versions[0].downloads.chromedriver[] | select(.platform=="linux64") | .url' | xargs wget -O chromedriver.zip
unzip chromedriver.zip
sudo mv chromedriver-linux64/chromedriver /usr/local/bin/
chmod +x /usr/local/bin/chromedriver

Проверка: chromedriver --version. На серверах часто нужен набор системных зависимостей Chrome: он совпадает с требованиями самого браузера; если Chrome запускается вручную, драйвер также запустится.

Управление жизненным циклом: драйвер и сервис

В современном Selenium класс ChromeDriver при создании сам запускает сервер драйвера, а при quit завершает его. Это удобно, но для больших наборов тестов, где драйвер создаётся на каждый тест, такой цикл может привести к лишним затратам: запуск процесса драйвера и браузера может занимать секунды, что в сотнях тестов превращается в минуты.

Решается это двумя способами.

Первый способ — ChromeDriverService. Это объект, который управляет процессом сервера отдельно от сессий: вы сами стартуете сервис, а внутри драйвер подключается к нему. Так можно переиспользовать один и тот же процесс драйвера между несколькими сессиями. Пример на Java:

import org.openqa.selenium.chrome.ChromeDriverService;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.remote.RemoteWebDriver;

ChromeDriverService service = new ChromeDriverService.Builder()
        .usingDriverExecutable(new File("/path/to/chromedriver"))
        .usingAnyFreePort()
        .build();
service.start();
WebDriver driver = new RemoteWebDriver(service.getUrl(), new ChromeOptions());

Второй способ — запустить сервер независимо. ChromeDriver можно запустить вручную на нужном порту:

./chromedriver --port=9515

После этого клиент подключается к адресу сервера как к удалённому:

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.remote.RemoteWebDriver;
import java.net.URL;

WebDriver driver = new RemoteWebDriver(
        new URL("http://127.0.0.1:9515"),
        new ChromeOptions());

Такой подход особенно полезен в контейнерных окружениях: драйвер запускается как отдельный сервис, а к нему подключаются сразу несколько конвейеров. В Selenium Grid сервер драйвера выступает в роли ноды, предоставляющей браузеры.

Быстрый старт: минимальные примеры

Теперь перейдём к практике — базовым примерам для нескольких языков.

Java

import org.openqa.selenium.*;
import org.openqa.selenium.chrome.*;
import org.junit.Test;

public class GettingStarted {
    @Test
    public void testGoogleSearch() throws InterruptedException {
        // Если драйвер не в PATH, укажите путь явно:
        // System.setProperty("webdriver.chrome.driver", "/path/to/chromedriver");
        WebDriver driver = new ChromeDriver();
        driver.get("http://www.google.com/");
        Thread.sleep(5000);
        WebElement searchBox = driver.findElement(By.name("q"));
        searchBox.sendKeys("ChromeDriver");
        searchBox.submit();
        Thread.sleep(5000);
        driver.quit();
    }
}

Python

import time
from selenium import webdriver

driver = webdriver.Chrome()  # Selenium 4.6+: драйвер найдётся сам
driver.get('https://www.google.com')
time.sleep(5)
search_box = driver.find_element('name', 'q')
search_box.send_keys('ChromeDriver')
search_box.submit()
time.sleep(5)
driver.quit()

Начиная с Selenium 4.6 вызов webdriver.Chrome() без аргументов в большинстве случаев работает из коробки: Selenium Manager найдёт или скачает совместимый ChromeDriver, сориентировавшись по версии вашего Chrome. Для старых версий библиотеки или для тотального контроля передавайте непустой путь:

from selenium import webdriver

driver = webdriver.Chrome(executable_path='/path/to/chromedriver')

Ruby

require 'selenium-webdriver'

driver = Selenium::WebDriver.for :chrome
driver.get 'http://www.google.com'
search_box = driver.find_element(name: 'q')
search_box.send_keys 'ChromeDriver'
search_box.submit
driver.quit

C# (и все языки)

Во всех языках принцип одинаков: библиотека превращает интуитивно понятные вызовы в команды WebDriver, а ChromeDriver обеспечивает их выполнение в браузере. Ошибки на этом этапе почти всегда связаны с версиями, а не с самой логикой кода.

Capabilities и ChromeOptions: настройка сессии

Этот раздел — сердце практики. Capabilities (возможности) — это пары «ключ-значение», определяющие поведение сессии. В языковых библиотеках они передаются через объект ChromeOptions (Java, Python, Ruby) или словарь goog:chromeOptions при использовании незашифрованных capabilities. Правильный способ настройки — эксперимент: почти любая настройка браузера реализуется через аргумент командной строки (args), а особые свойства профиля — через prefs.

Общий вид:

ChromeOptions options = new ChromeOptions();
options.addArguments("--start-maximized");
options.addArguments("--user-data-dir=/tmp/custom_profile");
ChromeDriver driver = new ChromeDriver(options);

В Python:

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument('--start-maximized')
options.add_argument('--disable-gpu')
driver = webdriver.Chrome(options=options)

Разберём самые используемые умения ChromeOptions.

args: аргументы командной строки

Список аргументов, передаваемых при старте Chrome. Аргументы со значениями разделяются знаком равно, например, ['--start-maximized', '--user-data-dir=/tmp/temp_profile']. Актуальный полный список Chromium-аргументов всегда лежит в справочнике [Peter Sh. список аргументов](http://peter.sh/experiments/chromium-command-line-switches/) или в исходниках Chromium. Полезные примеры:

--start-maximized — старт в развёрнутом окне;
--headless — безоконный режим (в новых версиях — --headless=new);
--disable-gpu — аппаратное ускорение отключено;
--window-size=1920,1080 — размеры окна;
--lang=ru — язык интерфейса;
--disable-notifications — отключить уведомления;
--user-data-dir=... — использование кастомного профиля;
--proxy-server=... — прокси-сервер.

binary: нестандартное расположение Chrome

По умолчанию ChromeDriver ищет браузер в типовых местах, но бинарник можно указать явно:

ChromeOptions options = new ChromeOptions();
options.setBinary("/path/to/other/chrome/binary");

На macOS пишется реальный исполняемый файл, а не .app: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome. Это частая грабля: передача пути к .app не работает.

extensions: установка расширений

Список расширений, устанавливаемых при старте сессии. Каждый пункт — это base64-закодированный запакованный CRX-файл. Пример:

ChromeOptions options = new ChromeOptions();
options.addExtensions(new File("/path/to/extension.crx"));
ChromeDriver driver = new ChromeDriver(options);

prefs: настройки профиля

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

ChromeOptions options = new ChromeOptions();
Map<String, Object> prefs = new HashMap<>();
prefs.put("download.default_directory", "/directory/path");
options.setExperimentalOption("prefs", prefs);
ChromeDriver driver = new ChromeDriver(options);

Важные подводные камни:

Chrome запрещает использовать для скачивания некоторые каталоги — например, рабочий стол; на Linux нельзя домашний каталог. Рекомендуется отдельный каталог без специального значения для системы.
ChromeDriver НЕ ждёт завершения скачивания автоматически. Если вызвать driver.quit() раньше, чем файл докачается, браузер может быть завершён, а файл — потерян.
Лучше использовать полные пути: относительные работают ненадёжно.
В Windows в качестве разделителя путей используйте \: слеш не является надёжным.

localState: локальные настройки состояния

Словарь предпочтений, соблюдаемый в файле Local State каталога данных пользователя. Менее популярен, чем prefs, но применим, когда нужно задать параметры, не привязанные к конкретному профилю браузера.

detach: отделение Chrome

Булево значение. По умолчанию false: если ChromeDriver убит, завершается и Chrome, даже если сессия не закрыта. Если true — Chrome продолжает работать, пока его не закроют по завершении сессии. Обратная сторона медали: при detach=true после завершения работы нельзя корректно очистить временный каталог данных, используемый запущенным Chrome.

debuggerAddress: подключение к существующему браузеру

Строка вида «hostname/ip:port» с адресом уже запущенного сервера отладки Chrome, например, '127.0.0.1:38947'. Так можно прицепиться к уже поднятому браузеру — полезно для повторных сессий или работы с удалённым окружением. Чтобы начать, Chrome нужно запустить с --remote-debugging-port.

excludeSwitches: отключение дефолтных аргументов

Список ключей командной строки, которые ChromeDriver по умолчанию передаёт при старте, но которые следует исключить. Например, можно блокировать всплывающие окна:

ChromeOptions options = new ChromeOptions();
options.setExperimentalOption("excludeSwitches",
        Arrays.asList("disable-popup-blocking"));

Примечание: по умолчанию ChromeDriver разрешает всплывающие окна; для возврата к обычному поведению и понадобится исключение соответствующего ключа. Важно не добавлять префикс "--" для ключей списка.

windowTypes: специальные типы окон

Список типов окон, появляющихся в списке дескрипторов окон. Полезен при тестировании встраивания webview: включите «webview» в список. По умолчанию ChromeDriver не отображает такие дескрипторы.

enableExtensionTargets

Булево (по умолчанию false), с Chrome 136 включает интроспекцию целей расширений Chrome. Это позволяет автоматам видеть и взаимодействовать с расширениями, что раньше было практически невозможно.

Полная таблица Chrome-специфичных capabilities

perfLoggingPrefs: настройки производительности

Все ключи опциональны:

Возвращаемые capabilities

При создании сессии ChromeDriver возвращает Chrome-специфичные поля, которые бывают полезны при диагностике:

Эти значения удобны для проверки правильности версии драйвера в CI-логах: здоровый запуск начинается с того, что версии совпадают. Если ожидаемая версия проскакивает в логах, значит драйвер не тот.

Профили: временные, кастомные, назначение

По умолчанию ChromeDriver создаёт новый временный профиль для каждой сессии. Это обеспечивает изолированность: cookies, кэш и localStorage чисты, а значит тесты детерминированы и не зависят от состояния предыдущих запусков. Однако иногда нужен целенаправленный профиль — например, для авторизованных сценариев или для воспроизведения конкретного ранее зафиксированного состояния.

Два пути:

внутри временного профиля можно применить предпочтения через capability prefs — они применяются уже после старта Chrome;
полностью заменить профиль — через аргумент командной строки user-data-dir:

--user-data-dir=/path/to/your/custom/profile

Правила работы с кастомным профилем:

если каталог не существует — Chrome создаст его автоматически;
посмотреть, какой профиль использует браузер, можно на странице chrome://version;
перед тем как использовать профиль в тестах, убедитесь, что он не содержит логов отлаженных сессий или «мусора»: cookie, сессии, истории — всё это будет влиять на результат;
в идеале выделите под автоматизацию отдельный профиль, который не используется для обычной работы.

Начало работы с кастомным профилем можно сделать вручную: запустите chrome с ключом user-data-dir, заполните профиль, закройте — и профиль готов к дальнейшему использованию.

Особый случай — программно запустить Chrome с user-data-dir, чтобы просто создать профиль и попутно настроить его. Это рабочая связка для подготовки окружения.

Мобильная эмуляция: тестирование без смартфона

Разработчики всегда хотят проверить, как сайт выглядит на мобильных устройствах, но держать под рукой десяток смартфонов никто не будет. Решение — эмуляция. Chrome DevTools умеют эмулировать мобильные устройства в режиме Device Mode; ChromeDriver умеет то же самое через capability mobileEmulation, задаваемую словарём.

Разберём два способа.

Способ 1: известное устройство

Для этого словарь mobileEmulation должен содержать «deviceName» — имя устройства из списка Emulated Devices DevTools. Примеры имен: Nexus 5, Pixel 7, iPhone 12 и другие.

Пример на Python:

from selenium import webdriver

mobile_emulation = {"deviceName": "Nexus 5"}
chrome_options = webdriver.ChromeOptions()
chrome_options.add_experimental_option("mobileEmulation", mobile_emulation)
driver = webdriver.Remote(
    command_executor='http://127.0.0.1:4444/wd/hub',
    desired_capabilities=chrome_options.to_capabilities())

На Java:

Map<String, String> mobileEmulation = new HashMap<>();
mobileEmulation.put("deviceName", "Nexus 5");
ChromeOptions chromeOptions = new ChromeOptions();
chromeOptions.setExperimentalOption("mobileEmulation", mobileEmulation);
WebDriver driver = new ChromeDriver(chromeOptions);

Важно: список известных устройств берётся из панели эмуляции DevTools. Если используете иное имя — получите ошибку вида «<device name> must be a valid device». Если нужное устройство не распознано — используйте второй способ.

Если список устройств вашей версии ChromeDriver и Chrome не совпадают — данные можно взять напрямую из исходного кода DevTools: [список устройств в репозитории Chromium](https://chromium.googlesource.com/chromium/src/+/167a7f5e03f8b9bd297d2663ec35affa0edd5076/third_party/WebKit/Source/devtools/front_end/emulated_devices/module.json).

Способ 2: ручные атрибуты устройства

Здесь словарь mobileEmulation содержит значения deviceMetrics, clientHints и userAgent. Более гибкий режим, когда нужного устройства в списке нет:

width — ширина экрана в пикселях (обязательно);
height — высота экрана (обязательно);
pixelRatio — соотношение пикселей (обязательно);
touch — эмулировать касания (по умолчанию true);
mobile — вести себя как мобильный пользовательский агент: оверлейные скроллбары, события поворота и другие мобильные атрибуты (по умолчанию true).

Пример (Python):

from selenium import webdriver

mobile_emulation = {
    "deviceMetrics": {"width": 360, "height": 640, "pixelRatio": 3.0},
    "userAgent": "Mozilla/5.0 (Linux; Android 4.2.1; en-us; Nexus 5 Build/JOP40D) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19",
    "clientHints": {"platform": "Android", "mobile": True},
}
chrome_options = webdriver.ChromeOptions()
chrome_options.add_experimental_option("mobileEmulation", mobile_emulation)
driver = webdriver.Chrome(chrome_options=chrome_options)

clientHints: современный способ описания устройства

Ключ clientHints стал важен в эпоху User-Agent Reduction (сокращённого User-Agent), когда браузеры постепенно урезают UA-строку. Он описывает возможности платформы каноническим образом:

Из clientHints ChromeDriver умеет выводить userAgent для платформ Android, Chrome OS, Chromium OS, Fuchsia, Linux, macOS, Windows — поэтому явно эту строку можно не указывать. Если clientHints не задан (режим наследия), ChromeDriver пытается вывести их из userAgent — но этот способ ненадёжен из-за внутренних неоднозначностей UA-формата. На практике для новых проектов рекомендую задавать clientHints явно.

Пример полного JSON-конфига:

"mobileEmulation": {
  "userAgent": "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Mobile Safari/537.36",
  "deviceMetrics": {
     "mobile": true,
     "touch": true,
     "width": 412,
     "height": 823,
     "pixelRatio": 1.75
  },
  "clientHints": {
     "brands": [{"brand": "Google Chrome", "version": "111"}],
     "fullVersionList": [{"brand": "Google Chrome", "version": "111.0.5563.64"}],
     "platform": "Android",
     "platformVersion": "11",
     "architecture": "arm",
     "model": "device model",
     "mobile": true,
     "bitness": "32",
     "wow64": false
  }
}

Мобильная эмуляция против настоящего устройства

Эмуляция — мощный, но не идеальный инструмент. Официальная документация прямо предупреждает:

устройства часто имеют другой GPU → может отличаться производительность;
интерфейс мобильных устройств не эмулируется (в частности, скрытие адресной строки влияет на высоту страницы);
отсутствуют всплывающие подсказки-уточнения (disambiguation popups), когда нужно выбрать один из нескольких элементов касания;
недоступны многие аппаратные API, например, событие orientationchange.

Поэтому правило простое: эмуляция подходит для проверки верстки и взаимодействий, но финальные решения о запуске на реальном устройстве стоит принимать только после проверки на реальном девайсе при наличии в проекте.

Логирование и отладка: verbose-лог

Приятный бонус ChromeDriver — прозрачность. По умолчанию драйвер логирует в stderr только предупреждения и ошибки. Для диагностики же включается подробный лог.

chromedriver --verbose --log-path=chromedriver.log

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

Java: System.setProperty("webdriver.chrome.logfile", "D:\\chromedriver.log"); System.setProperty("webdriver.chrome.verboseLogging", "true");
Python: webdriver.Chrome(service_args=['--verbose', '--log-path=D:\\qc1.log']);
C#: сервис с заданными service.LogPath и service.EnableVerboseLogging = true.

Особенности:

когда --log-path задан в аргументах запуска Chrome, stderr Chrome на Linux и macOS сохраняется в лог; на Windows — нет, поскольку Chrome является GUI-приложением и ОС не позволяет ему наследовать дескриптор stderr;
чтобы сохранить stderr Chrome на всех ОС, используйте переменную окружения CHROME_LOG_FILE: содержимое файла — только логи Chrome;
если в ChromeOptions указан logPath, ChromeDriver скопирует его значение в CHROME_LOG_FILE автоматически;
Android не захватывает stderr и stdout;
stdout на всех платформах выводится в консоль.

Практический сценарий: тест падает с «element click intercepted» — включаете --verbose, смотрите лог вокруг фрейма, находите, что в этот момент была перехвачена браузером рекламная панель, и добавляете исключающий аргемент.

Performance log

Отдельный бонус — получение данных о сетевой активности и производительности через perfLoggingPrefs. Ключевые настройки: enableNetwork и enablePage — собранные события из доменов Network и Page; traceCategories — категории трассировки; bufferUsageReportingInterval — частота отчётов. Производительность собирается из DevTools, поэтому доступна только для Chrome. Образец кода для включения лога производительности есть в официальной документации (см. [раздел Logging](https://developer.chrome.com/docs/chromedriver/logging)).

Безопасность: как не навредить себе и компании

ChromeDriver — это, в сути, фабрикать мощных привилегий: он открывает перед клиентом неограниченный доступ к браузеру, а значит — к cookie, страницам и действиям с ними. При использовании в производстве стоит соблюдать рекомендации.

Официальные рекомендации:

по умолчанию ChromeDriver принимает только локальные подключения; если нужны удалённые — используйте флаг --allowed-ips со списком разрешённых IP;
запускайте ChromeDriver от тестовой учётной записи, не имеющей доступа к чувствительным локальным и сетевым данным; никогда не запускайте его от привилегированного аккаунта;
запускайте в защищённой среде: Docker или виртуальная машина;
держите фаервол, чтобы никто не мог подключиться удалённо;
если работаете через Selenium Server или иные посредники — защищайте их сетевые порты;
используйте последние версии ChromeDriver и Chrome.

Настройка allowed IP выглядит так:

chromedriver --allowed-ips=10.0.0.5,192.168.1.2

Типичные ошибки безопасности в реальных компаниях:

драйвер запускается в привычном окружении разработчика, где можно прочитать файлы проекта с паролями;
flakiness-тесты CI работают от root/Administrator;
браузерный профиль доступен на томах, где лежат данные клиентов.

Вывод простой: изолируйте. Выделите для автоматизации отдельный сервер/контейнер, отдельного пользователя, отдельный профиль. Это устраняет практически все риски.

Типовые проблемы и решения

Практика показывает: 90% проблем с ChromeDriver сводится к трём категориям: версии, окружение, ожидания.

Версии. Если при вызове ChromeDriver вы получаете SessionNotCreatedException с ироничным «only supports Chrome version X» — вы запускаете тест с несовместимым набором. Решение: обновить либо браузер, либо драйвер до совпадающих версий. На практике удобно, когда и то, и другое берётся из Chrome for Testing.

Драйвер не найден. Ошибки вида «Element not found», «cannot find the binary» чаще всего говорят о том, что бинарник драйвера не в PATH. Решение: либо добавить каталог в PATH, либо явно указать путь в коде (выше есть примеры для Java и Python).

Chrome сразу падает или не стартует. Если браузер не открывается, а в логе ошибки, связанные с sandbox, on macOS — про дистрибуцию Chromium, в Linux — про нехватку --no-sandbox (но реально удалить сандбокс нужно только в киборгах/докерах, где доступ к /dev/shm проблемный), то:

на Linux в Docker — передавайте --no-sandbox и --disable-dev-shm-usage;
на macOS убедитесь, что бинарник Chrome действительно находится по указанному пути;
проверьте лог — там обычно есть прямая подсказка.

Проблемы с кликом. Результат «Element not interactable» или «click intercepted» может быть связан с перекрытием элементов (баннер, cookie-согласие, лоадер). Лечится ожиданием исчезновения перекрывающего элемента, кликом через JS или удалением элемента из DOM. Число решений велико — см. [раздел Clicking Issues](https://developer.chrome.com/docs/chromedriver/help/clicking-issues).

Headless-режим. При тестах без видимого окна работают почти все API. Но некоторые возможности недоступны: например, передвижная мышь, подделка спикер-аудио и др. В новых версиях — headless нового поколения (--headless=new) значительно расширяет возможности. Если ваши тесты используют функциональность, отсутствующую в старом headless, перезайдите на новый режим.

Нет поддержки некоторых команд при remote debugging. Если вы запустили Chrome самостоятельно с флагом удалённой отладки и подключились через debuggerAddress, некоторые операции, связанные с управлением браузером, могут быть недоступны. См. [Operation Not Supported](https://developer.chrome.com/docs/chromedriver/help/operation-not-supported-when-using-remote-debugging).

Синхронизация и ожидания. Классика джуниоров: sleep на 5 секунд, всё работает, потом падает. Вместо этого используйте явные ожидания: WebDriverWait и ExpectedConditions — ваши тесты станут быстрее и стабильнее.

Рекомендации по отладке в целом: сначала смотрите в лог драйвера (--verbose), потом проверяйте версию браузера и драйвера, потом изолируйте проблему мини-тестом на голом скрипте без фреймворка.

Сравнение с альтернативами

ChromeDriver — не единственный способ управлять Chrome. Рассмотрим конкурентов: Puppeteer и Playwright (самые популярные в 2026), а также WebDriver BiDi-клиенты.

Ключевые выводы из таблицы:

Если вы цените стандарт и зрелость — ChromeDriver + Selenium. Код пишется на привычных вам языках, архитектура очевидна, квалифицированных специалистов на рынке много.
Если нужна максимальная скорость и современный API — Playwright. Автоматические ожидания, network-перехваты и отличная поддержка CI из коробки.
Если проект только на JS и нужен именно CDP — Puppeteer. Он доступный и понятный.

ChromeDriver по-прежнему остаётся актуальным и в 2026 году — огромная доля корпоративных e2e-наборов написана именно на нём, и многие инструменты (например, Sauce Labs, BrowserStack, Selenium Grid) обслуживают его как первую граждана.

Лучшие практики применения

Подведём практику к короткому своду рекомендаций.

Всегда держите версии согласованными. Chrome и ChromeDriver — из одного релиза, предпочтительно из Chrome for Testing.
Используйте изолированный профиль. По умолчанию сессия временная — это правильно для тестирования. Кастомные профили — только когда явно нужны.
Пишите явные ожидания. WebDriverWait вместо произвольных sleep и time.sleep.
Настраивайте только через ChromeOptions. Не пишите никаких костылей вида use_legacy_mode; в современном Selenium все настройки проходят через options.
Выключайте ненужные настройки. Если вы не тестируете popup — заблокируйте их через excludeSwitches.
Изолируйте окружение. Docker, отдельный пользователь, отдельные порты, firewalls.
Не переиспользуйте драйвер без необходимости. Каждому тесту — своя сессия, а сервер можно переиспользовать через ChromeDriverService.
Используйте новые версии. С выходом Chrome 136 расширены возможности интроспекции расширений; старые версии потеряли их.
Делайте логирование обязательным. --verbose --log-path в CI — незаменимый инструмент диагностики.
Тестируйте мобильную версию там, где надо, но не заменяйте ей реальные устройства.
Храните секреты отдельно. Не в коде тестов, а в переменных окружения/секрет-менеджере — тесты с ChromeDriver часто работают в открытом CI, и утечка плохих.
Всё, что можно — на headless. Это экономит ресурсы CI и избавляет от проблем с фокусом окна.

Резюме

ChromeDriver — это сервер, реализующий стандарты W3C WebDriver и WebDriver BiDi, с помощью которого внешние приложения могут автоматизировать браузер Google Chrome на настольных платформах и Android. Он остаётся центральным элементом экосистемы браузерной автоматизации, позволяя запускать миллионы e2e-тестов, парсеров и мониторинговых процессов в 2026 году.

В статье были рассмотрены: история и стандартизация, архитектура сессии и протоколов, современная схема поставки Chrome for Testing, установка на Windows/macOS/Linux, полный набор capabilities и ChromeOptions (аргументы, бинарник, расширения, профили, prefs, detach, исключаемые ключи, наборы типов окон и возможности расширений), мобильная эмуляция вплоть до clientHints, логирование, безопасность, типовые проблемы и сравнение с альтернативами.

Главный практический вывод: пользоваться ChromeDriver в 2026 году стало проще, чем когда-либо. Благодаря Selenium Manager и Chrome for Testing ручная установка драйвера почти не требуется, а стандартизация WebDriver и BiDi сделала код надёжным и переносимым. Если вы пишете кроссбраузерные тесты на Java или Python — ChromeDriver всё ещё является безусловным выбором; если ваши требования выше стандартных возможностей — посмотрите на Playwright, но базовые концепции, изученные здесь, останутся с вами в любом случае.

Ссылки

[Официальная документация ChromeDriver](https://developer.chrome.com/docs/chromedriver)
[Быстрый старт с ChromeDriver](https://developer.chrome.com/docs/chromedriver/get-started)
[Capabilities и ChromeOptions](https://developer.chrome.com/docs/chromedriver/capabilities)
[Мобильная эмуляция](https://developer.chrome.com/docs/chromedriver/mobile-emulation)
[Логирование и performance log](https://developer.chrome.com/docs/chromedriver/logging)
[Соображения безопасности](https://developer.chrome.com/docs/chromedriver/security-considerations)
[Chrome for Testing дашборд](https://googlechromelabs.github.io/chrome-for-testing/)
[JSON с последними известными версиями](https://googlechromelabs.github.io/chrome-for-testing/last-known-good-versions-with-downloads.json)
[Спецификация W3C WebDriver](https://www.w3.org/TR/webdriver/)
[Спецификация WebDriver BiDi](https://w3c.github.io/webdriver-bidi/)
[Проект chromium-bidi](https://github.com/GoogleChromeLabs/chromium-bidi)
[Selenium WebDriver](https://www.selenium.dev/)
[Список аргументов командной строки Chromium](http://peter.sh/experiments/chromium-command-line-switches/)
[Источник списка известных устройств DevTools](https://chromium.googlesource.com/chromium/src/+/167a7f5e03f8b9bd297d2663ec35affa0edd5076/third_party/WebKit/Source/devtools/front_end/emulated_devices/module.json)
[Репозиторий исходников Chromium (ChromeDriver)](https://chromium.googlesource.com/chromium/src/+/master/docs/chromedriver_status.md)

×