Как работают прокси-серверы в браузерах

Жизненный цикл прокси-запроса в браузере: от сокета до рендеринга

Когда вы вводите URL-адрес в веб-браузере, настроенном на использование прокси-сервера, браузер изменяет свой стандартный цикл сетевых операций перед открытием любого исходящего сокета. В конфигурации с прямым подключением к сети браузер выполняет системный вызов getaddrinfo() для преобразования имени хоста с помощью локальных DNS-резолверов операционной системы, осуществляет трёхстороннее рукопожатие TCP с IP-адресом исходного сервера, который был найден, и напрямую завершает рукопожатие TLS. При настроенном прокси всё соединение передаётся посредническому сокету прокси-сервера.

1. Фильтр распределения сокетов и маршрутизации

   Перед отправкой запроса к системным резолверам браузер проверяет настроенные правила прокси-сервера. Если домен назначения входит в список исключений, сокет выделяется напрямую; в противном случае браузер открывает TCP-поток на IP-адрес прокси-сервера.

2. Установление соединения через HTTP CONNECT

   В случае HTTPS-адресов браузер отправляет незашифрованный HTTP-запрос CONNECT, содержащий имя целевого хоста и порт (например, CONNECT example.com:443 HTTP/1.1). Прокси-сервер выполняет разрешение DNS в своей сети и устанавливает соединение с целевым сервером.

3. Сквозной TLS-рукопожатие

   Как только прокси-сервер отвечает кодом HTTP/1.1 200 «Connection Established», он переходит в режим «слепой» ретрансляции байтов. Браузер инициирует установку соединения по протоколу TLS напрямую с целевым сервером через установленный туннель, обеспечивая полное шифрование полезных данных.

Автоматическая настройка маршрутизации: файлы PAC, WPAD и флаги среды

Предприятия и высокопроизводительные автоматизированные системы избегают ручного переключения прокси-серверов за счёт использования скриптов автоматической настройки прокси (PAC). Файл PAC содержит функцию JavaScript с именем FindProxyForURL(url, host), которая выполняется в изолированной песочнице внутри процесса сетевых служб Chromium.

function FindProxyForURL(url, host) {
    // 1. Bypass proxy for local LAN and internal intranet domains
    if (isPlainHostName(host) ||
        shExpMatch(host, "*.internal.lan") ||
        isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||
        isInNet(dnsResolve(host), "192.168.0.0", "255.255.0.0")) {
        return "DIRECT";
    }

    // 2. High-security targets route through dedicated cellular SOCKS5 proxy
    if (shExpMatch(host, "*.instagram.com") || shExpMatch(host, "*.tiktok.com")) {
        return "SOCKS5 185.220.101.5:1080; SOCKS 185.220.101.5:1080";
    }

    // 3. Fallback standard web traffic through HTTP proxy gateway
    return "PROXY 185.220.101.5:8080; DIRECT";
}

Протокол автоматического обнаружения веб-прокси (WPAD) расширяет возможности PAC, позволяя определять URL-адрес PAC с помощью опции DHCP 252 или DNS-запросов к wpad.yourdomain.local. Хотя этот протокол удобен для корпоративных сетей, он создает уязвимости в безопасности, если злоумышленники из локальной сети подделывают DNS-ответы.

Настройки для конкретных браузеров: флаги Chrome, Firefox и Chromium

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

Диагностика утечек браузера, запросов на авторизацию и ошибок 407

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

1. HTTP 407: Требуется аутентификация прокси-сервера

Browsers cannot pre-authenticate HTTP CONNECT requests before knowing what authentication scheme the proxy demands. The proxy responds with a 407 status code containing a Proxy-Authenticate header (e.g. Basic realm="Proxy"). In headless Puppeteer or Playwright instances, failure to register page.authenticate({username, password}) causes immediate request termination.

2. Утечки локальных и публичных IP-адресов в WebRTC

Даже если весь HTTP- и HTTPS-трафик проходит через выделенный мобильный прокси-сервер, реализации WebRTC в браузерах могут обойти пул сокетов прокси-сервера для установления одноранговых медиапотоков. Запросы WebRTC STUN отправляются на удаленные серверы STUN по необработанному UDP, раскрывая реальный публичный IP-адрес вашего хост-компьютера. Отключите WebRTC или настройте маршрутизацию исключительно через прокси с помощью флагов.

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

Высококачественное мобильное оборудование в местах с реальным трафиком — обход блокировок по отпечаткам браузера:

Часто задаваемые вопросы

Связанные руководства по мобильным прокси-серверам

Расширьте свои знания об архитектурах прокси-серверов, протоколах и автоматизации сетей с помощью наших серий технических руководств:

Основные принципы

Текущие запасы и инструментарий