PAC Request Policy: функции запросов на уровне браузера

Введение

Файлы Proxy Auto-Config давно являются частью сетевой модели браузеров. PAC-файл позволяет браузеру решать для каждого запроса, использовать ли прокси или подключаться напрямую. Решение принимается внутри сетевого слоя браузера до выхода запроса из браузера, поэтому PAC отличается от скриптов страницы, framework hooks и обработчиков запросов на уровне приложения.

Эта старая возможность все еще полезна, потому что современные browser workflow стали сложнее. Команды уже не запускают один браузер на одной машине с одним прокси. Они используют profile-backed sessions на Windows, macOS и Linux, headless servers, proxy pools, региональные маршруты, длинные цепочки навигации, страницы с активными media и разные automation frameworks. Решения о маршрутизации должны оставаться согласованными с идентичностью браузера, а не расходиться по вспомогательным скриптам.

Поддержка PAC Request Policy в BotBrowser расширяет эту модель для одобренных enterprise workflow. Она держит request-aware policy рядом с управляемым сетевым стеком браузера и сохраняет обычное PAC routing behavior. В результате команды получают более чистый способ выражать request policy без переноса каждого решения о маршруте в page code или framework-specific request handlers.

Эта статья описывает PAC function model, поддерживаемые request actions, deployment sources и случаи, где browser-level request policy яснее, чем framework interception. Для короткой справки используйте PAC Request Policy и CLI flags reference.

Почему PAC все еще важен

PAC выглядит просто: браузер спрашивает политику, какой маршрут использовать для URL. Эта простота и есть ценность. Routing должен находиться рядом с сетевым стеком браузера, а не добавляться после того, как page framework уже начал обрабатывать запросы.

Решение о прокси часто зависит не только от hostname. Некоторые запросы должны идти через residential или mobile route. Некоторые должны использовать региональный прокси. Некоторые внутренние сервисы должны оставаться на локальном маршруте. Некоторые static assets могут использовать путь, отличный от authenticated navigation. Некоторые enterprise workflow должны держать небольшое число request classes под более строгой политикой, оставляя остальную страницу с обычным поведением браузера.

Размещать эти решения в application code можно для небольших скриптов, но с ростом workflow это становится трудно поддерживать. Playwright route handler, Puppeteer request handling, side proxy, Node service и PAC-файл превращаются в отдельные места, где может измениться поведение запроса. Когда появляется support case, первый вопрос становится таким: какой слой фактически принял решение о маршруте?

PAC уменьшает эту неопределенность. Браузер владеет вопросом routing. Правило следует за launch configuration браузера. Одна и та же политика естественнее применяется к navigation requests, subresources, redirects и browser-managed requests.

Для privacy-focused browser work это важно, потому что идентичность не ограничивается JavaScript. Network path, route selection, profile locale, timezone, browser-family behavior и runtime signals должны совпадать. Профиль может выглядеть согласованным внутри страницы, но ослабляться из-за несогласованного routing. PAC делает сетевую сторону модели явной.

Проблема логики запросов вне браузера

Automation frameworks дают полезные request controls. Они удобны для тестов, mock-сценариев и простых задач. Но они не всегда являются лучшим местом для enterprise routing policy.

Page-level request handlers обычно ограничены страницей или контекстом. Они могут требовать framework-specific setup step. Часто они зависят от включения request handling mode до начала навигации. С service workers, redirects, preloads, popups и browser-managed requests такая модель становится сложнее для анализа.

Side proxy services имеют другой компромисс. Они централизуют network logic вне браузера, но отделяют policy от profile, который определяет browser identity. Proxy service видит network traffic, но может не знать, какой profile, context или browser-family identity должен быть активен. Команды могут передавать дополнительные metadata, но тогда операционная модель становится больше, чем сама browser session.

Жесткие launch flags тоже ограничены. Один --proxy-server чист и понятен, когда достаточно одного маршрута. Он становится слишком грубым, когда браузеру нужен route selection по request class, domain group, environment или workflow stage.

PAC заполняет промежуток между этими крайностями. Он native для браузера, request-aware и может поставляться как небольшой policy file. Он остается рядом с browser launch, путешествует вместе с session configuration и остается понятным во время support review.

Подход BotBrowser

BotBrowser поддерживает доверенную PAC request policy для enterprise workflow, которым нужно держать routing decisions внутри browser network model. Стандартный PAC routing остается доступен. Команды могут продолжать использовать PAC для direct routes, HTTP proxies, HTTPS proxies, SOCKS routes и других обычных PAC outcomes, поддерживаемых браузером.

Дополнительная ценность заключается в operational consistency. Доверенная PAC policy может жить рядом с profile и launch configuration. Это держит routing policy, browser identity, proxy configuration и automation entrypoint в одном reviewable bundle. Это также не распыляет request decisions по page scripts и framework code, когда browser network layer является более естественным владельцем.

Конфигурация использует стандартную форму --proxy-pac-url:

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --proxy-pac-url="file:///absolute/path/to/policy.pac"

Контролируемый loopback PAC service также часто используется, когда policy генерируется внутренним control plane:

chromium-browser \
  --bot-profile="profiles/profile.enc" \
  --proxy-pac-url="http://127.0.0.1:8080/policy.pac"

Источник должен быть явным. Локальный файл легко аудировать и версионировать вместе с job definition. Loopback service полезен, когда internal tool выбирает policy для конкретного worker. В обоих случаях policy следует считать частью browser environment, а не случайным helper script.

PAC Request Policy предназначен для approved enterprise use. Его нужно сочетать с profile-backed browser identity, clear route ownership и обычной privacy validation. Он не заменяет responsible use controls или customer-side authorization checks.

Модель функций

BotBrowser PAC Request Policy сначала сохраняет обычный PAC entrypoint:

function FindProxyForURL(url, host) {
  if (dnsDomainIs(host, "example.internal")) {
    return "DIRECT";
  }
  return "SOCKS5 proxy.example.com:1080";
}

FindProxyForURL(url, host) остается правильной функцией для обычного proxy selection. Она получает URL и host, затем возвращает стандартный PAC result: DIRECT, PROXY, HTTPS, SOCKS, SOCKS4 или SOCKS5.

Approved ENT Tier3 profiles могут добавить callback BotBrowser в тот же trusted PAC source:

function BotBrowserFindProxyForRequest(url, host, method, headersB64, bodyB64, bodyState) {
  if (method === "POST" && dnsDomainIs(host, "api.example.test")) {
    return "CAPTURE; CAPTURE_FILE /var/botbrowser/captures/api.jsonl; CAPTURE_TAG api-post; CONTINUE";
  }
  if (shExpMatch(url, "https://media.example.test/*")) {
    return "SOCKS5 media-proxy.example.net:1080";
  }
  if (dnsDomainIs(host, "static.example.test")) {
    return "HTTPS static-proxy.example.net:8443";
  }
  return "CONTINUE";
}

BotBrowserFindProxyForRequest выполняется как browser request policy callback. Он не отменяет standard PAC. Когда callback возвращает CONTINUE, или когда он не возвращает valid route, запрос продолжает идти через обычный PAC routing. Когда он возвращает standard PAC route, эта route применяется к текущему запросу.

Callback получает шесть значений:

Параметр	Значение
url	Полный request URL.
host	Hostname запроса.
method	HTTP method, например GET или POST.
headersB64	Base64-encoded request headers record.
bodyB64	Base64-encoded request body, когда body bytes доступны.
bodyState	Состояние доступности body: none, bytes, file, stream, too_large или unsupported.

Это дает PAC policy больше контекста, чем стандартный FindProxyForURL, но сохраняет решение внутри browser network path.

Действия запроса

Callback BotBrowser может возвращать routing actions, control actions и capture actions. Actions можно комбинировать через точку с запятой.

Return value	Поведение
CONTINUE	Продолжить request handling и использовать standard PAC routing, если callback не вернул route.
BLOCK	Остановить запрос.
CAPTURE	Включить capture для этого запроса, когда action используется вместе с CAPTURE_FILE <path>.
CAPTURE_TAG <tag>	Добавить короткий tag к capture record.
CAPTURE_FILE <path>	Записать capture records в approved absolute path, когда используется вместе с CAPTURE.
DIRECT	Подключиться напрямую для текущего запроса.
PROXY host:port	Направить текущий запрос через HTTP proxy.
HTTPS host:port	Направить текущий запрос через HTTPS proxy.
SOCKS host:port	Направить текущий запрос через SOCKS proxy.
SOCKS4 host:port	Направить текущий запрос через SOCKS4 proxy.
SOCKS5 host:port	Направить текущий запрос через SOCKS5 proxy.

Capture является явным действием. Один CAPTURE_FILE <path> не записывает record. CAPTURE и CAPTURE_FILE <path> должны присутствовать вместе. CAPTURE; CAPTURE_FILE <path>; BLOCK записывает approved capture record и затем останавливает запрос. CAPTURE; CAPTURE_FILE <path>; CAPTURE_TAG <tag>; CONTINUE записывает запрос и сохраняет обычный route.

Return string также может объединять policy и route selection. Media request может вернуть SOCKS5 route, internal host может вернуть DIRECT, а обычная navigation может вернуть CONTINUE, чтобы default FindProxyForURL decision остался активным.

Доверенные PAC sources

Request callback доступен только из explicit PAC sources, контролируемых deployment:

• file:// PAC files.
• data: PAC URLs.
• Loopback HTTP(S) PAC services.
• Explicit remote HTTP(S) PAC services, контролируемые оператором.

PAC auto-detect и WPAD остаются полезными для standard PAC routing, но они не являются правильным source для BotBrowser request callbacks. Enterprise request policy должна приходить из known file, controlled loopback service или controlled remote service over HTTPS.

Эта trust model важна в production. PAC-файл может route traffic, останавливать selected requests или записывать approved capture records. Считайте его частью browser launch package и ревьюйте с той же дисциплиной, что profiles, proxy inventory и worker configuration.

Где он подходит

PAC Request Policy наиболее полезен, когда workflow имеет больше одного request class, но все еще нуждается в coherent browser identity.

Search или monitoring workflow может требовать, чтобы navigation requests шли по regional route, а static assets использовали другой route. QA workflow может требовать, чтобы internal test hosts оставались local, а external pages следовали выбранному profile route. Multi-region validation job может требовать выбора маршрута через небольшую policy table, а не через отдельные code paths в каждом automation script.

Он также помогает, когда команда хочет запускать один и тот же browser workflow под Playwright, Puppeteer, raw CDP или worker service без переписывания route logic для каждого framework. Policy остается в PAC. Automation framework запускает браузер и управляет страницей. Браузер владеет network route decision.

Разделение обязанностей остается ясным:

• Profile определяет browser identity.
• Proxy configuration определяет доступные network paths.
• PAC policy выбирает path для каждого request class.
• Automation framework выполняет workflow.
• Validation process проверяет, что результат остается consistent.

Это разделение дает support, QA и platform teams меньше мест для проверки, когда поведение меняется.

Связь с per-context workflow

Per-context browser operation повышает потребность в чистых границах policy. Один browser instance может размещать несколько independent contexts, каждый со своим profile, proxy route, storage и runtime behavior. Если request logic разбросана по page handlers, становится сложнее понять, какое правило относится к какому context.

PAC Request Policy дает способ держать network policy рядом с launch configuration контекста. Context может нести нужный profile и routing policy без зависимости от global process assumptions. Это особенно важно, когда workers переиспользуются, contexts создаются и уничтожаются во времени, или fleet запускает много profile families на одном host.

Тот же принцип относится к browser-family consistency. Profile-backed browser identity не должен отделяться от network behavior. Если workflow валидирует browser family, region и route, request policy должна быть частью validation package.

Заметки по развертыванию

Относитесь к PAC policy как к production configuration. Храните ее с job definition, ревьюйте как code и держите достаточно малой, чтобы operator понимал intended routing behavior.

Предпочитайте explicit policy sources. Local file хорошо работает для стабильных deployment. Loopback service хорош, когда worker agent должен предоставить policy для текущего job. Избегайте зависимости от ambient machine state, который трудно воспроизвести позже.

Имена policy должны быть простыми и описательными. Файл policy.pac в директории job проще ревьюить, чем generated path с неясным назначением. Если policies генерируются, выдавайте manifest вместе с job, чтобы launch можно было воспроизвести.

Route ownership должен быть понятным. Если меняется page route, PAC-файл должен быть первым местом проверки. Если меняется proxy credential, сначала проверяйте proxy inventory. Если меняется profile, первым местом проверки должен быть profile package. Смешивание всех этих вопросов в одном helper script замедляет support.

Для sensitive workflows избегайте logging request contents из general-purpose automation code. Operational logs должны фокусироваться на route decision, policy version, profile family и high-level outcome. Detailed evidence следует хранить только в controlled support packages, когда это требуется для authorized review.

Валидация

Validation должна подтверждать, что policy behavior соответствует deployment plan, не превращая документацию в low-level request inspection recipe.

Начните с простой route matrix. Перечислите request classes, важные для workflow, ожидаемую route family для каждого класса и profile family, которая будет запускать session. Держите эту matrix рядом с deployment configuration.

Запускайте workflow с тем же profile и route setup, которые используются в production. Рассматривайте page behavior, route behavior и browser signal consistency вместе. Policy, которая работает только в synthetic test, но меняет поведение во время реальной navigation chain, недостаточна.

Повторяйте ту же validation до и после browser updates, profile updates или proxy inventory changes. PAC policy наиболее полезна, когда становится частью release process, а не одноразовым launch option.

Для scale валидируйте representative sample of workers, а не только одну локальную машину. Routing behavior может зависеть от host networking, proxy availability, file paths и service startup order. Policy, стабильная в реальном fleet, полезнее policy, работающей только в developer shell.

Распространенные ошибки

Первая ошибка - считать PAC второстепенной настройкой. Если network path браузера важен для privacy и consistency, PAC-файл является частью product environment. Его нужно version, review и хранить с launch configuration.

Вторая ошибка - делить одно правило между слишком многими слоями. Если route decision живет частично в PAC, частично в Playwright, частично в side proxy и частично в job code, support превращается в догадки. Выберите владельца для каждого решения и держите решение там.

Третья ошибка - использовать PAC для компенсации profile mismatch. PAC может выбирать routes. Он не может сделать inconsistent profile согласованным. Browser identity, locale, timezone, proxy region и route policy должны планироваться вместе.

Четвертая ошибка - делать policy слишком сложной. Небольшая policy, покрывающая routes, которые workflow действительно использует, легче валидируется, чем большая policy с редко используемыми branches. Начните с minimum routing map и расширяйте только при операционной необходимости.

Пятая ошибка - забывать headless и server deployment. Local desktop testing недостаточен, если production работает в Linux containers или headless servers. Валидируйте PAC loading, file access, loopback service startup и route behavior в той же deployment shape.

Когда использовать

Используйте PAC Request Policy, когда браузеру нужен request-aware routing и policy должна оставаться связанной с browser environment.

Он подходит для enterprise browser automation, regional validation, long-running workflows, per-context routing и production QA, где route behavior должен быть repeatable. Он также полезен, когда командам нужен один policy model, работающий под несколькими automation frameworks.

Он не нужен для простых deployment, где каждый request использует один и тот же proxy. В таком случае --proxy-server остается более чистым вариантом. Он также не заменяет profile planning, proxy inventory management или responsible use controls.

Практическое правило простое: если route decisions являются частью browser identity и support process, держите их в browser network model. Если workflow нужен только один route, сохраняйте конфигурацию простой.

Есть и team-process signal. Если route changes требуют координации между browser engineers, infrastructure engineers, QA и support, PAC часто является правильным местом для централизации policy. Browser launch показывает, какая policy активна, policy показывает, какая route family применяется, а validation подтверждает результат по тому же файлу.

Операционная модель для команд

PAC Request Policy особенно полезна там, где браузер обслуживает не один скрипт, а постоянную операционную систему. В такой системе есть люди, которые готовят profiles, люди, которые поддерживают proxies, люди, которые запускают workers, и люди, которые разбирают support cases. Если маршрут определяется неявно, каждая такая команда вынуждена искать ответ в своем слое. Один инженер проверяет framework handler, другой смотрит proxy service, третий сравнивает launch flags, четвертый читает worker logs. Это быстро становится дорогим процессом.

PAC делает маршрутную политику отдельным артефактом. Его можно положить рядом с job definition, использовать в release review и ссылаться на него в support notes. Когда команда меняет маршрут для класса запросов, изменение видно в одном месте. Когда workflow переносится с локального запуска на Linux worker, тот же policy artifact можно проверить в новой среде. Когда профиль обновляется, route matrix остается доступной для сравнения.

Такой подход также помогает разделять ответственность. Browser team отвечает за то, что PAC загружается и применяется в рамках браузерной модели. Infrastructure team отвечает за доступность proxy routes. Automation team отвечает за workflow steps. QA отвечает за validation matrix. Support получает воспроизводимый набор: profile, PAC policy, proxy family и job launch. Чем меньше скрытых route rules остается в коде, тем проще повторить проблему.

Для долгоживущих workers это особенно важно. Worker может выполнять разные tasks в течение дня, создавать новые contexts, закрывать старые contexts и обновлять runtime state. Если request policy привязана к явному PAC source, оператор может проверить, какая политика активна для конкретного запуска. Если policy скрыта в helper function, это сложнее. Видимый PAC source уменьшает риск того, что старое правило останется активным после смены workflow.

Есть и release benefit. Перед обновлением браузера команда может запустить один и тот же workflow с той же PAC policy и сравнить high-level route behavior. После обновления тот же набор повторяется. Если поведение изменилось, команда смотрит browser update, profile package, proxy inventory и PAC file по порядку. Такой порядок не гарантирует мгновенный ответ, но он делает расследование дисциплинированным.

PAC не должен превращаться в универсальный механизм для всех задач. Он лучше всего работает как небольшая policy boundary. Чем проще policy, тем легче ее ревьюить, валидировать и объяснять другим командам. Если правило нужно только одному тесту, оно может оставаться в тесте. Если правило определяет сетевую идентичность браузерной сессии, ему место рядом с PAC и launch configuration.

Для change management полезно добавить короткий человеческий процесс. Каждое изменение PAC должно иметь владельца, описание affected workflow, ожидаемую route family и план проверки. Это не обязательно тяжелая бюрократия. Даже небольшой review checklist помогает понять, почему маршрут изменился и кто подтвердил результат. В enterprise automation такие детали становятся важными через несколько недель, когда команда расследует regression, повторяет customer environment или переносит workload на новый runner. Хорошая PAC policy не только работает сегодня, но и оставляет след для будущей команды.

FAQ

Это то же самое, что обычный PAC-файл?

Модель начинается с обычного PAC. Standard PAC routing остается доступен. BotBrowser добавляет enterprise operating model вокруг trusted PAC sources, чтобы route policy оставалась рядом с profile-backed browser sessions.

Это заменяет --proxy-server?

Нет. Используйте --proxy-server, когда достаточно одного proxy route. Используйте PAC, когда браузеру нужен request-aware routing под reviewable policy.

Можно ли запускать из локального PAC-файла?

Да. Local PAC file хорошо подходит, когда policy стабильна и должна версионироваться с job. Controlled loopback PAC service полезен, когда internal tooling должен динамически предоставить policy для worker.

Работает ли это с automation frameworks?

Да. Framework запускает и управляет браузером, а PAC остается владельцем route selection. Это делает routing policy менее зависимой от request handling API конкретного framework.

Должен ли каждый workflow использовать PAC?

Нет. PAC приносит ценность, когда routing decisions отличаются по request class или context. Простые single-route workflows должны оставаться простыми.

Итог

PAC Request Policy дает enterprise teams браузерный способ удерживать request routing, profile identity и automation workflows согласованными. Он сохраняет преимущества standard PAC и подходит к тому, как работают современные BotBrowser deployments: profile-backed sessions, per-context operation, headless workers, proxy-aware routing и repeatable validation.

Используйте его, когда routing policy является частью browser environment. Держите policy explicit, reviewable и рядом с profile и launch configuration. Валидируйте ее на реальном workflow, а не только на минимальной test page. Для команд, которые воспринимают браузер как infrastructure, это удерживает request-aware policy в той же operating model, что и остальная часть BotBrowser privacy protection stack.

Для деталей конфигурации смотрите PAC Request Policy, Proxy Configuration и Per-Context Proxy.