PAC Request Policy: funciones de solicitud a nivel de navegador

Introducción

Los archivos Proxy Auto-Config forman parte del networking de los navegadores desde hace mucho tiempo. Un archivo PAC permite que el navegador decida, para cada solicitud, si debe usar un proxy o conectar directamente. La decisión ocurre dentro de la capa de red del navegador antes de que la solicitud salga del proceso, lo que diferencia PAC de scripts de página, hooks de frameworks o manejadores de solicitudes a nivel de aplicación.

Esa función sigue siendo útil porque los flujos de navegador modernos son más complejos. Los equipos ya no ejecutan un solo navegador en una máquina con un solo proxy. Ejecutan sesiones con perfiles, hosts Windows, macOS y Linux, servidores headless, pools de proxy, rutas regionales, cadenas largas de navegación, páginas con medios activos y varios frameworks de automatización. Las decisiones de routing tienen que mantenerse alineadas con la identidad del navegador, no dispersas en scripts auxiliares.

El soporte de PAC Request Policy de BotBrowser extiende ese modelo para flujos enterprise aprobados. Mantiene la política sensible a solicitudes cerca del stack de red gestionado por el navegador, preservando al mismo tiempo el comportamiento normal de PAC. El resultado es una forma más limpia de expresar política de solicitudes sin mover cada decisión de routing a código de página o a manejadores específicos de un framework.

Este artículo cubre el modelo público de funciones PAC, las acciones de solicitud soportadas, las fuentes de despliegue y los casos donde una política de solicitud en el navegador es más clara que la interceptación en el framework. Para la referencia corta, consulta PAC Request Policy y la referencia de flags CLI.

Por qué PAC todavía importa

PAC parece simple: el navegador pregunta a una política qué ruta debe usar para una URL. Esa simplicidad es la ventaja. El routing pertenece cerca del stack de red del navegador, no después de que un framework de página ya haya empezado a manejar solicitudes.

Una decisión de proxy suele depender de más que el hostname. Algunas solicitudes pertenecen a una ruta residencial o móvil. Algunas deben usar un proxy regional. Algunos servicios internos deben permanecer en una ruta local. Algunos assets estáticos pueden usar una ruta distinta a la navegación autenticada. Algunos flujos enterprise necesitan mantener una pequeña cantidad de clases de solicitud bajo una política más estricta mientras el resto de la página conserva comportamiento normal de navegador.

Poner esas decisiones en código de aplicación puede funcionar para scripts pequeños, pero se vuelve difícil de mantener al crecer el flujo. Un route handler de Playwright, un manejador de Puppeteer, un proxy lateral, un servicio Node y un archivo PAC se convierten en lugares separados donde el comportamiento de solicitud puede cambiar. Cuando aparece un caso de soporte, la primera pregunta es: qué capa tomó realmente la decisión de routing.

PAC reduce esa ambigüedad. El navegador posee la pregunta de routing. La regla acompaña a la configuración de lanzamiento del navegador. La misma política se aplica de forma más natural a navegaciones, subrecursos, redirecciones y solicitudes gestionadas por el navegador.

Para trabajo de navegador orientado a privacidad, esto importa porque la identidad no es solo JavaScript. Ruta de red, selección de proxy, locale del perfil, zona horaria, comportamiento de familia de navegador y señales de runtime tienen que coincidir. Un perfil puede parecer coherente dentro de la página y aun así debilitarse por un routing inconsistente. PAC hace explícito el lado de red de ese modelo.

El problema de la lógica de solicitudes fuera del navegador

Los frameworks de automatización ofrecen controles de solicitud útiles. Son convenientes para tests, mocks y tareas simples. No siempre son el mejor lugar para poseer política enterprise de routing.

Los manejadores de solicitud a nivel de página suelen estar acotados a una página o contexto. Pueden requerir un paso de configuración específico del framework. A menudo dependen de activar un modo de manejo antes de la navegación. Pueden ser más difíciles de razonar cuando entran service workers, redirecciones, preloads, popups o solicitudes gestionadas por el navegador.

Los servicios proxy laterales tienen otra compensación. Centralizan la lógica de red fuera del navegador, pero separan la política del perfil que define la identidad del navegador. El servicio proxy ve tráfico de red, pero puede no saber qué perfil, contexto o identidad de familia de navegador debe estar activa. Los equipos pueden pasar metadatos adicionales, pero entonces el modelo operativo se vuelve más grande que la sesión del navegador.

Los flags de lanzamiento fijos también son limitados. Un solo valor de --proxy-server es limpio cuando una ruta es suficiente. Se vuelve demasiado rígido cuando el navegador necesita selección de ruta por clase de solicitud, grupo de dominios, entorno o etapa del flujo.

PAC llena el espacio entre esos extremos. Es nativo del navegador, sensible a solicitudes y desplegable como un archivo pequeño de política. Puede permanecer cerca del lanzamiento del navegador, viajar con la configuración de sesión y seguir siendo comprensible durante una revisión de soporte.

El enfoque de BotBrowser

BotBrowser soporta política PAC confiable para flujos enterprise que necesitan mantener decisiones de routing dentro del modelo de red del navegador. El routing PAC estándar sigue disponible. Los equipos pueden seguir usando PAC para elegir rutas directas, proxies HTTP, proxies HTTPS, rutas SOCKS u otros resultados normales soportados por el navegador.

El valor adicional es la consistencia operativa. Una política PAC confiable puede vivir junto al perfil y la configuración de lanzamiento. Esto mantiene política de routing, identidad del navegador, configuración de proxy y punto de entrada de automatización dentro de un paquete revisable. También evita dispersar decisiones de solicitud en scripts de página y código de framework cuando la capa de red del navegador es el dueño más natural.

La configuración usa la forma estándar de --proxy-pac-url:

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

Un servicio PAC controlado en loopback también es común cuando la política la genera una herramienta interna:

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

Mantén explícita la fuente. Un archivo local es fácil de auditar y versionar con la definición del trabajo. Un servicio loopback es útil cuando una herramienta interna elige política por worker. En ambos casos, la política debe tratarse como parte del entorno del navegador, no como un script auxiliar incidental.

PAC Request Policy está pensada para uso enterprise aprobado. Debe combinarse con identidad de navegador basada en perfiles, propiedad clara de rutas y validación normal de privacidad. No reemplaza controles de uso responsable ni comprobaciones de autorización del lado del cliente.

Modelo público de funciones

BotBrowser PAC Request Policy conserva primero el entrypoint PAC normal:

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

FindProxyForURL(url, host) sigue siendo la función correcta para selección ordinaria de proxy. Recibe la URL y el host, y devuelve un resultado PAC estándar como DIRECT, PROXY, HTTPS, SOCKS, SOCKS4 o SOCKS5.

Los profiles ENT Tier3 aprobados pueden añadir el callback de BotBrowser en la misma fuente PAC confiable:

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 se evalúa como callback de política de solicitud del navegador. No elimina PAC estándar. Cuando el callback devuelve CONTINUE, o cuando no devuelve una ruta válida, la solicitud continúa por el routing PAC normal. Cuando devuelve una ruta PAC estándar, esa ruta se aplica a la solicitud actual.

El callback recibe seis valores:

Parámetro	Significado
url	URL completa de la solicitud.
host	Hostname de la solicitud.
method	Método HTTP, por ejemplo GET o POST.
headersB64	Registro de headers de solicitud codificado en Base64.
bodyB64	Body de solicitud codificado en Base64 cuando los bytes están disponibles.
bodyState	Estado de disponibilidad del body: none, bytes, file, stream, too_large o unsupported.

Esto da a la policy PAC más contexto que FindProxyForURL, sin sacar la decisión del camino de red del navegador.

Acciones de solicitud

El callback de BotBrowser puede devolver acciones de routing, acciones de control y acciones de captura. Las acciones pueden combinarse con punto y coma.

Valor devuelto	Comportamiento
CONTINUE	Continúa el manejo de la solicitud y usa PAC estándar si el callback no ofrece una ruta.
BLOCK	Detiene la solicitud.
CAPTURE	Activa captura para esta solicitud cuando se combina con CAPTURE_FILE <path>.
CAPTURE_TAG <tag>	Añade un tag corto al registro de captura.
CAPTURE_FILE <path>	Escribe registros de captura en una ruta absoluta aprobada cuando se combina con CAPTURE.
DIRECT	Conecta directamente para la solicitud actual.
PROXY host:port	Enruta la solicitud actual por un proxy HTTP.
HTTPS host:port	Enruta la solicitud actual por un proxy HTTPS.
SOCKS host:port	Enruta la solicitud actual por un proxy SOCKS.
SOCKS4 host:port	Enruta la solicitud actual por un proxy SOCKS4.
SOCKS5 host:port	Enruta la solicitud actual por un proxy SOCKS5.

La captura es explícita. CAPTURE_FILE <path> por sí solo no escribe un registro. CAPTURE y CAPTURE_FILE <path> deben aparecer juntos. CAPTURE; CAPTURE_FILE <path>; BLOCK escribe el registro aprobado y luego detiene la solicitud. CAPTURE; CAPTURE_FILE <path>; CAPTURE_TAG <tag>; CONTINUE registra la solicitud y mantiene la ruta normal.

La cadena de retorno también puede mezclar policy y selección de ruta. Una solicitud de media puede devolver una ruta SOCKS5, un host interno puede devolver DIRECT, y una navegación ordinaria puede devolver CONTINUE para que siga activa la decisión predeterminada de FindProxyForURL.

Fuentes PAC confiables

El callback de solicitud solo está disponible desde fuentes PAC explícitas controladas por el despliegue:

• Archivos PAC file://.
• URLs PAC data:.
• Servicios PAC HTTP(S) en loopback.
• Servicios PAC HTTP(S) remotos explícitos controlados por el operador.

PAC auto-detect y WPAD siguen siendo útiles para routing PAC estándar, pero no son la fuente adecuada para callbacks de solicitud de BotBrowser. Una request policy empresarial debe venir de un archivo conocido, un servicio loopback controlado o un servicio remoto controlado sobre HTTPS.

Este modelo de confianza importa en producción. El archivo PAC puede enrutar tráfico, detener solicitudes seleccionadas o escribir registros de captura aprobados. Trátalo como parte del paquete de lanzamiento del navegador, con la misma revisión que profiles, inventario de proxies y configuración de workers.

Dónde encaja

PAC Request Policy es más útil cuando un flujo tiene más de una clase de solicitud pero todavía necesita una identidad de navegador coherente.

Un flujo de búsqueda o monitorización puede necesitar que las navegaciones sigan una ruta regional mientras los assets estáticos usan otra. Un flujo de QA puede necesitar que hosts internos permanezcan locales mientras las páginas externas siguen la ruta del perfil. Un trabajo de validación multi-región puede necesitar que la selección de ruta esté definida por una pequeña tabla de política, no por caminos de código separados en cada script de automatización.

También ayuda cuando el equipo quiere que el mismo flujo se ejecute bajo Playwright, Puppeteer, CDP directo o un servicio worker sin reescribir la lógica de ruta para cada framework. La política permanece en PAC. El framework lanza el navegador y conduce la página. El navegador posee la decisión de ruta de red.

La separación mantiene responsabilidades claras:

• El perfil define la identidad del navegador.
• La configuración de proxy define las rutas disponibles.
• La política PAC selecciona la ruta para cada clase de solicitud.
• El framework de automatización ejecuta el flujo.
• El proceso de validación comprueba que el resultado permanezca consistente.

Esa división reduce la cantidad de lugares que soporte, QA y plataforma tienen que revisar cuando cambia el comportamiento.

Relación con flujos per-context

La operación per-context aumenta la necesidad de límites claros. Una sola instancia de navegador puede alojar múltiples contextos independientes, cada uno con su propio perfil, ruta proxy, almacenamiento y comportamiento de runtime. Si la lógica de solicitudes está dispersa en manejadores de página, se vuelve más difícil saber qué regla pertenece a qué contexto.

PAC Request Policy permite mantener la política de red cerca de la configuración de lanzamiento del contexto. Un contexto puede llevar el perfil y la política de routing que necesita sin depender de supuestos globales del proceso. Esto importa cuando se reutilizan workers, se crean y destruyen contextos durante horas, o un fleet ejecuta varias familias de perfiles en el mismo host.

El mismo principio aplica a la consistencia de familia de navegador. Una identidad basada en perfil no debería separarse del comportamiento de red. Si un flujo valida familia de navegador, región y ruta, la política de solicitud debe formar parte del paquete de validación.

Notas de despliegue

Trata la política PAC como configuración de producción. Guárdala con la definición del trabajo, revísala como código y mantenla lo bastante pequeña para que un operador entienda el routing esperado.

Prefiere fuentes explícitas. Un archivo local funciona bien para despliegues estables. Un servicio loopback funciona cuando un agente worker necesita proporcionar una política para el trabajo actual. Evita depender de estado ambiental de la máquina que sea difícil de reproducir.

Usa nombres descriptivos. Un archivo llamado policy.pac dentro de un directorio de trabajo es más fácil de revisar que una ruta generada sin propósito claro. Si se generan políticas, emite un manifiesto con el trabajo para que el lanzamiento pueda reproducirse.

Mantén clara la propiedad de rutas. Si cambia una ruta de página, el archivo PAC debe ser el primer lugar a revisar. Si cambia una credencial de proxy, revisa primero el inventario de proxies. Si cambia un perfil, revisa primero el paquete del perfil. Mezclar todo en un helper hace más lento el soporte.

En flujos sensibles, evita registrar contenido de solicitudes desde código de automatización general. Los logs operativos deben centrarse en decisión de ruta, versión de política, familia de perfil y resultado de alto nivel. Guarda evidencia detallada solo en paquetes de soporte controlados cuando una revisión autorizada lo requiera.

Validación

La validación debe confirmar que el comportamiento de política coincide con el plan de despliegue sin convertir la documentación en una receta de inspección de bajo nivel.

Empieza con una matriz simple de rutas. Lista las clases de solicitud que importan al flujo, la familia de ruta esperada para cada una y la familia de perfil que ejecutará la sesión. Mantén esta matriz cerca de la configuración.

Ejecuta el flujo con el mismo perfil y setup de rutas usado en producción. Revisa comportamiento de página, comportamiento de ruta y consistencia de señales del navegador juntos. Una política que solo funciona en una página sintética, pero cambia durante una cadena real de navegación, no es suficiente.

Repite la misma validación antes y después de actualizaciones del navegador, de perfiles o de inventario de proxy. PAC es más valioso cuando forma parte del proceso de release y no solo de una opción de lanzamiento única.

A escala, valida una muestra representativa de workers, no solo una máquina local. El comportamiento de routing puede depender de red del host, disponibilidad de proxy, rutas de archivo y orden de arranque de servicios. Una política estable en el fleet real es más útil que una política que solo funciona en una shell de desarrollo.

Errores comunes

El primer error es tratar PAC como un detalle secundario. Si la ruta de red del navegador importa para privacidad y consistencia, el archivo PAC forma parte del entorno del producto. Debe versionarse, revisarse y mantenerse con la configuración de lanzamiento.

El segundo error es dividir la misma regla en demasiadas capas. Si una decisión vive en parte en PAC, en parte en Playwright, en parte en un proxy lateral y en parte en código de trabajo, el soporte se vuelve adivinanza. Elige dueño para cada decisión y mantenla ahí.

El tercer error es usar PAC para compensar un perfil incoherente. PAC puede seleccionar rutas. No puede hacer coherente un perfil inconsistente. Identidad del navegador, locale, zona horaria, región proxy y política de ruta todavía deben planificarse juntos.

El cuarto error es hacer la política demasiado inteligente. Una política pequeña que cubre las rutas necesarias es más fácil de validar que una grande con ramas poco usadas. Empieza con el mapa mínimo y crece solo cuando operaciones lo requieran.

El quinto error es olvidar headless y servidores. Si producción corre en contenedores Linux o servidores headless, probar solo en escritorio local no basta. Valida carga de PAC, acceso a archivos, arranque de servicio loopback y comportamiento de rutas bajo la misma forma de despliegue.

Cuándo usarlo

Usa PAC Request Policy cuando el navegador necesita routing sensible a solicitudes y la política debe permanecer ligada al entorno del navegador.

Encaja bien con automatización enterprise, validación regional, flujos largos, routing per-context y QA de producción donde el comportamiento de ruta debe ser repetible. También sirve cuando los equipos quieren un único modelo de política que pueda ejecutarse bajo varios frameworks.

No es necesario para despliegues simples donde todas las solicitudes usan el mismo proxy. En ese caso, --proxy-server sigue siendo la opción más limpia. Tampoco reemplaza planificación de perfiles, gestión de inventario proxy ni controles de uso responsable.

La regla práctica es simple: si las decisiones de ruta forman parte de la identidad del navegador y del proceso de soporte, mantenlas en el modelo de red del navegador. Si el flujo solo necesita una ruta, mantén la configuración simple.

También hay una señal de proceso de equipo. Si cambios de ruta requieren coordinación entre ingeniería de navegador, infraestructura, QA y soporte, PAC suele ser el lugar correcto para centralizar la política. Da a cada equipo un artefacto que revisar. El lanzamiento dice qué política está activa, la política dice qué familia de ruta aplica y la validación confirma el resultado contra el mismo archivo.

FAQ

¿Es igual que un archivo PAC normal?

Parte del modelo PAC normal. El routing PAC estándar sigue disponible. BotBrowser añade un modelo operativo enterprise alrededor de fuentes PAC confiables para que la política permanezca cerca de sesiones basadas en perfiles.

¿Reemplaza --proxy-server?

No. Usa --proxy-server cuando una ruta proxy es suficiente. Usa PAC cuando el navegador necesita routing sensible a solicitudes bajo una política revisable.

¿Puede ejecutarse desde un archivo PAC local?

Sí. Un archivo PAC local es una buena opción cuando la política es estable y debe versionarse con el trabajo. Un servicio loopback controlado es útil cuando una herramienta interna necesita proporcionar política dinámica para un worker.

¿Funciona con frameworks de automatización?

Sí. El framework lanza y conduce el navegador, mientras PAC mantiene la propiedad de la selección de ruta. Esto hace que la política dependa menos de una API de manejo de solicitudes de un framework concreto.

¿Todos los flujos deberían usar PAC?

No. PAC aporta valor cuando las decisiones de routing difieren por clase de solicitud o contexto. Los flujos simples de una sola ruta deben permanecer simples.

Resumen

PAC Request Policy ofrece a los equipos enterprise una forma a nivel de navegador de mantener routing de solicitudes, identidad de perfil y flujos de automatización alineados. Preserva las ventajas de PAC estándar y encaja con la forma en que se despliega BotBrowser: sesiones con perfil, operación per-context, workers headless, rutas con proxy y validación repetible.

Úsalo cuando la política de routing forme parte del entorno del navegador. Mantén la política explícita, revisable y cerca del perfil y la configuración de lanzamiento. Valídala con el flujo real, no solo con una página mínima. Para equipos que tratan el navegador como infraestructura, esto mantiene la política sensible a solicitudes dentro del mismo modelo operativo que el resto del stack de protección de privacidad de BotBrowser.

Para detalles de configuración, consulta PAC Request Policy, Proxy Configuration y Per-Context Proxy.