PAC Request Policy para un enrutamiento coherente

Proxy Auto-Config, conocido normalmente como PAC, da al navegador una política para elegir una ruta de red. La decisión se queda en la ruta de red del navegador, de modo que la misma política puede cubrir la navegación, las redirecciones, los subrecursos y las solicitudes gestionadas por el navegador sin depender de un framework de páginas.

Esa ubicación es útil cuando un despliegue usa más de una ruta proxy aprobada. La navegación regional, las pruebas de aplicaciones internas, la validación de contenido multimedia y las cargas con varios contextos pueden necesitar familias de rutas distintas. Una política PAC mantiene esas decisiones cerca del perfil del navegador y de la configuración de arranque.

BotBrowser documenta el enrutamiento PAC estándar mediante --proxy-pac-url y, para perfiles empresariales aprobados, un callback de solicitudes adicional en el mismo script PAC. El PAC estándar sigue siendo el modelo por defecto. El callback es una capa opcional que ayuda a los equipos autorizados a mantener un tratamiento coherente de las solicitudes mientras la fuente PAC, el inventario de proxies y el perfil se revisan juntos.

TL;DR

• Mantén el enrutamiento PAC en la capa de red del navegador y conserva FindProxyForURL(url, host) para revisión.
• Registra proxy, direct o blocked y conserva policyVersion para volver atrás.
• BotBrowser aplica capacidades PAC aprobadas, pero no hace saludable un proxy ni aprueba un destino.

Contents

• Por qué el enrutamiento pertenece al navegador
• Modelo operativo y callback de solicitudes
• Usos adecuados de la política de solicitudes PAC
• Medidas de protección y validación por resultados
• Responsabilidad, despliegue y registros
• Recuperación y mantenimiento
• Practical conclusion

Por qué el enrutamiento pertenece al navegador

Conserva FindProxyForURL(url, host) y el retorno DIRECT en el registro de la política.

Un proxy estático suele bastar para una sesión sencilla. Deja de ser adecuado cuando un mismo flujo del navegador necesita varias rutas aprobadas. Mover las decisiones de ruta a manejadores del framework también puede producir comportamientos distintos entre Playwright, Puppeteer, CDP directo y el tráfico gestionado por el navegador, y la interceptación en la capa de automatización puede interrumpir la continuidad de conexiones y flujos HTTP/2 en algunos flujos de trabajo.

PAC da al navegador una única política de enrutamiento. El código de automatización maneja la página, mientras que el navegador se encarga de elegir la red. Como la política no depende de ningún framework, puede servir a distintas herramientas de automatización. Este reparto facilita la revisión del despliegue porque el perfil, el inventario de proxies y la política de enrutamiento tienen responsabilidades claras. Para ver cómo se asignan las responsabilidades de cada capa de red en despliegues grandes, consulta Límites de red del navegador empresarial: asignar responsabilidades.

El enfoque también favorece la coherencia de privacidad. Un perfil del navegador puede definir región, idioma, zona horaria y familia de dispositivo, pero esos ajustes pierden valor si el tráfico sigue una ruta de red sin relación. Mantener la política de rutas junto al perfil reduce la deriva de configuración entre los ajustes del perfil y la salida aprobada.

Cuándo basta un proxy estático

PAC no es necesario en todos los despliegues. Elige un proxy estático cuando todo el tráfico deba usar una sola ruta y no haya una política por clase de solicitud que mantener. Un contexto con una única ruta no necesita PAC, y una configuración más pequeña es más fácil de operar y deja menos piezas móviles.

Usa PAC cuando elegir la ruta sea un requisito real a nivel de navegador. No lo añadas solo para replicar una lógica del framework que ya tiene una ruta única y estable. La política debe reducir la complejidad operativa, no trasladar la misma complejidad a otro archivo.

Modelo operativo y callback de solicitudes

Un despliegue mantenible separa cuatro responsabilidades:

1. El perfil del navegador define los ajustes previstos del navegador.
2. El inventario de proxies define las rutas de red aprobadas.
3. La política PAC elige una ruta para cada clase de solicitud relevante.
4. El flujo de automatización realiza la tarea autorizada en el navegador.

Esta organización evita copiar reglas de enrutamiento en cada script. También ofrece a los equipos de soporte y privacidad un lugar estable para revisar un cambio de ruta sin leer el código de automatización de páginas. Usa nombres descriptivos y mantén cada política centrada en un único propósito de despliegue, porque un trabajo de validación regional, una prueba de aplicación interna y un flujo multimedia no deberían compartir una política grande solo porque se ejecuten en el mismo nodo. Las políticas pequeñas son más fáciles de revisar, versionar y revertir.

Los scripts PAC estándar siguen usando FindProxyForURL(url, host) para la selección ordinaria de proxy. Para perfiles ENT Tier3 aprobados, el mismo script PAC de confianza puede definir también BotBrowserFindProxyForRequest, un callback de BotBrowser que recibe la URL, el host, el método, las cabeceras y el estado del cuerpo de la solicitud. El callback no sustituye al PAC estándar. Cuando devuelve CONTINUE o ningún resultado válido, el enrutamiento vuelve a la función estándar. El callback puede hacer lo siguiente:

• Continuar la solicitud y conservar la ruta PAC estándar.
• Bloquear la solicitud.
• Escribir un breve registro de captura con etiqueta en una ruta absoluta aprobada.
• Enrutar solo la solicitud actual por otro resultado PAC estándar, como DIRECT, HTTPS o SOCKS5.
• Completar la solicitud con una respuesta sintética controlada.

Los resultados pueden combinarse con punto y coma. La captura se escribe primero. Después, una respuesta controlada completa la solicitud y tiene prioridad sobre el bloqueo y el enrutamiento; sin respuesta, el bloqueo tiene prioridad sobre una ruta. Una respuesta mal formada, demasiado grande, insegura o no admitida falla en modo cerrado y nunca se envía al destino ni al proxy.

El callback solo está disponible para perfiles aprobados y fuentes PAC explícitas: archivos PAC file:, URL PAC data:, servicios PAC HTTP(S) de loopback y servicios PAC HTTP(S) remotos que controle tu equipo. La detección automática de PAC y WPAD siguen siendo válidas para el enrutamiento PAC estándar, pero no reciben el callback. Prefiere fuentes file: o de loopback para los nodos locales y usa HTTPS cuando la fuente sea remota.

Las respuestas controladas tienen una política de fuentes más estricta que el propio callback. Se limitan a perfiles aprobados que cargan una fuente PAC file: o data:. Una fuente PAC HTTP(S) puede seguir enrutando, capturando y bloqueando solicitudes, pero no puede devolver una respuesta controlada. Los administradores deben mantener la política bajo los mismos controles de acceso que el paquete del perfil y rechazar vías de entrega sin revisar.

Las respuestas controladas son adecuadas para endpoints y fixtures que pertenecen al despliegue, como un resultado de disponibilidad, un recurso de prueba estable o una respuesta determinista usada en un flujo autorizado de control de calidad. Mantén los fixtures propios separados del tráfico real hacia destinos. Deben servir para pruebas repetibles y comprobaciones operativas, no para sustituir la navegación normal a servicios de terceros.

Usos adecuados de la política de solicitudes PAC

Coherencia regional de rutas

Una sesión respaldada por un perfil puede necesitar una ruta acorde con su región. PAC puede mantener la navegación y las solicitudes de apoyo en la familia de rutas aprobada sin duplicar la lógica de selección entre frameworks de automatización.

Rutas internas y externas de aplicaciones

Una prueba empresarial puede combinar un servicio interno con dependencias web públicas. Una política PAC pequeña puede mantener el tráfico interno en la ruta privada prevista mientras el tráfico externo usa la ruta proxy aprobada.

Nodos con varios contextos

Los nodos que crean y cierran contextos del navegador necesitan una propiedad previsible. Asociar cada configuración de contexto con su perfil y su política facilita la revisión posterior y reduce la dependencia de supuestos globales del proceso. La guía de proxy por contexto explica cómo se asignan rutas a contextos separados.

Control de calidad repetible

Los fixtures propios pueden eliminar variabilidad de red innecesaria en una ruta de prueba concreta. Con una fuente de política local aprobada, las respuestas controladas permiten ese uso acotado mientras el resto de la página sigue la red estándar del navegador.

Medidas de protección y validación por resultados

Registra proxy, direct y blocked como los tres resultados esperados para cada URL.

Trata la fuente PAC, el perfil del navegador y el inventario de proxies como una única unidad de versión revisada.

• Restringe quién puede cambiar la fuente de la política.
• Mantén explícita en la configuración del despliegue la referencia de la política aprobada.
• Usa control de versiones para los archivos de política estables.
• Revisa la propiedad de las rutas antes de cambiar credenciales o regiones del proxy.
• Inicia una sesión nueva del navegador cuando cambie la configuración del trabajo.
• Mantén los fixtures controlados bajo los mismos controles de acceso que el flujo de pruebas.
• Prefiere una lista permitida pequeña de clases de solicitud en lugar de una política general que lo abarque todo.

La entrega remota de políticas exige la misma revisión de transporte y acceso que cualquier otra configuración de producción. Que el PAC estándar admita más tipos de fuente no debe confundirse con permiso para usar respuestas controladas.

La validación debe confirmar el resultado del despliegue sin recopilar datos de página innecesarios. Empieza por el plan de rutas. Anota qué clases de solicitud deben usar cada ruta aprobada y cuáles deben quedarse con el comportamiento PAC estándar. Ejecuta el flujo autorizado habitual y compara su resultado de red observable con ese plan.

Comprueba juntos el perfil y la ruta. Región, idioma, zona horaria y salida del proxy deben describir un entorno coherente. En trabajos con varios contextos, revisa cada contexto por separado para que un contexto correcto no oculte un problema de configuración en otro.

Para un fixture controlado propio, confirma el comportamiento esperado de la aplicación con las comprobaciones habituales de la aplicación. Revisa juntos el identificador de la política efectiva, la asignación del perfil, el registro de acceso y el resultado del navegador. Estas observaciones muestran si el despliegue sigue su plan de rutas aprobado. Adjunta el resultado al mismo registro de versión que se usa para decidir el despliegue y la reversión.

Mantén breve la evidencia de validación. Versión de la política, familia de perfil, familia de ruta esperada, salida observada y resultado del flujo suelen bastar para un registro de versión.

Responsabilidad, despliegue y registros

Añade también routeClass al registro para distinguir una ruta regional de una ruta de prueba.

Guarda policyVersion, effectiveAt, owner y rollbackTarget en cada despliegue.

Una política de enrutamiento afecta al tráfico del navegador antes de que la automatización de páginas evalúe el resultado. Asigna a cada política una persona responsable que entienda las rutas de aplicación que gobierna. Esa persona debe poder explicar por qué existe cada clase de ruta, qué familias de perfil la usan y qué equipo aprueba los cambios. Las operaciones de proxy pueden seguir siendo una responsabilidad aparte, pero el límite entre elegir una ruta y disponer de ella debe quedar por escrito.

Revisa la política como un elemento de configuración de producción. Un buen registro de revisión contiene el nombre de la política, su revisión, los grupos de despliegue afectados, las familias de perfil asignadas y el resultado esperado de cada clase de ruta aprobada. También debe indicar la revisión de reversión y quién decide aplicarla. Es contexto suficiente para que un operador actúe sin copiar la política en un ticket ni exponer datos que no pertenecen a un registro operativo.

Evita compartir políticas de manera informal entre trabajos. Una política que funciona para una aplicación puede incluir supuestos sobre regiones, servicios privados o propiedad de proxies que no valen en otro lugar. Crea una política revisada distinta cuando cambie el propósito. El registro adicional cuesta menos que investigar una ruta inexplicable cuando dos despliegues han evolucionado por separado.

Las credenciales no deben incrustarse en el texto de la política que se copia en tickets ni en la automatización del navegador. Usa la vía normal de gestión de secretos del despliegue y limita el acceso a las cuentas de servicio que ejecutan el trabajo aprobado. Rota las credenciales con independencia de la lógica de enrutamiento cuando la plataforma lo permita y ejecuta después las mismas comprobaciones autorizadas de la aplicación que en una versión normal. La guía de autenticación de proxy e higiene de credenciales describe esta práctica con más detalle.

Empieza con un grupo de despliegue pequeño que represente el entorno de producción. Usa la versión prevista del navegador, la familia de perfil, el sistema operativo, el inventario de proxies y la versión de automatización. Una prueba en un portátil de desarrollo puede confirmar la sintaxis, pero no demuestra que la propiedad de rutas, las credenciales y los controles de acceso de producción sean correctos.

Compara el grupo de prueba con un grupo sin cambios durante el mismo periodo. Observaciones útiles son la finalización correcta de la aplicación, el estado de inicio y salida del navegador, la disponibilidad del proxy, el resultado por familia de ruta y el número de trabajos devueltos a la cola. Mantén comparables el conjunto de páginas y la mezcla de trabajos. Si cambian varias entradas a la vez, la comparación no mostrará si la política ayudó o si solo coincidió con otra carga.

Amplía el despliegue grupo por grupo en lugar de cambiar todos los nodos a la vez. Pausa el despliegue cuando el resultado de la aplicación, la estabilidad del navegador o el registro de propiedad de rutas dejen de coincidir con el plan de versión. Restaura la política revisada anterior antes de intentar un segundo cambio. Así la reversión es previsible y se conserva una referencia clara para la siguiente comparación.

Los nodos de larga duración deben recibir los cambios de política por el mismo ciclo de vida que las actualizaciones de perfil y navegador. Termina o detén el trabajo asignado según las reglas normales de cierre de la aplicación y después inicia una sesión nueva del navegador con la nueva unidad de versión. Mezclar una sesión antigua del navegador con una asignación de política nueva dificulta interpretar los registros de soporte.

Los registros de enrutamiento pueden revelar información operativa sensible aunque no contengan contenido de páginas. Limita la recopilación a lo que necesita una revisión de soporte o privacidad: revisión de la política, familia de perfil, familia de ruta aprobada, grupo de despliegue, ventana de tiempo y resultado de la aplicación. Evita conservar historiales completos de destinos solo para demostrar que una política estaba activa.

Aplica a estos registros el calendario de conservación habitual de la organización. Un registro de prueba de corta vida puede necesitar solo la ventana de la versión, mientras que un flujo de producción regulado puede exigir una pista de auditoría más larga. La persona responsable del despliegue debe fijar el periodo antes del lanzamiento y documentar quién puede leer o exportar el registro. No dejes que los registros del navegador se conviertan en una copia sin gestionar del historial de red. Los registros de captura que escribe el callback siguen la misma regla, así que su ruta, etiqueta y periodo de conservación deben formar parte de la política revisada.

Las revisiones de acceso deben cubrir tanto la edición como la asignación de políticas. Quien no puede cambiar el texto de una política quizá pueda asociar una política existente al grupo de despliegue equivocado. Revisa esos permisos juntos. Elimina las asignaciones que ya no tengan responsable activo y retira las revisiones de política que ya no estén disponibles para la reversión.

Recuperación y mantenimiento

Usa lastKnownGood, errorCode y retryAt para separar la recuperación de un despliegue nuevo.

Cuando un flujo autorizado produce un resultado de ruta inesperado, deja de enviar trabajo nuevo al grupo de despliegue afectado. Conserva disponibles la última revisión de política correcta y el registro de versión. Confirma que la familia de perfil asignada, la versión del navegador, el inventario de proxies y la revisión de la política coinciden con el cambio aprobado. Esta primera comparación suele revelar deriva de configuración sin necesidad de investigar a nivel de página.

Comprueba la salud de las rutas proxy aprobadas de forma independiente con la monitorización habitual de infraestructura de la organización. Una ruta puede no estar disponible aunque la política no haya cambiado. Del mismo modo, un proxy sano no demuestra que se asignó la política prevista. Trata la selección de política y la disponibilidad de la ruta como hechos distintos y compara ambos con el resultado de la aplicación. La guía de conmutación por error de proxy explica qué hacer cuando la propia ruta no está disponible.

Cambia un componente de la versión cada vez durante la recuperación. Restaurar la política anterior y cambiar a la vez el paquete de perfil, la versión del navegador y la región del proxy destruye la referencia. Vuelve primero a la última unidad revisada. Cuando pasen las comprobaciones normales de la aplicación, introduce el siguiente cambio con el proceso de despliegue gradual.

El registro del incidente debe indicar el resultado visible para el usuario, los grupos de despliegue afectados, la última revisión correcta conocida, la acción correctiva y el resultado de la validación de la versión. Resume el comportamiento observado en lugar de conservar datos de página solicitud por solicitud. Ese registro más acotado respalda la responsabilidad y respeta el límite de privacidad de la sesión de navegación.

Revisa las políticas activas con regularidad y después de cambios importantes en la aplicación, el navegador, el perfil o la red. Confirma que cada clase de ruta sigue teniendo un propósito y un responsable vigentes. Elimina las clases sin uso en lugar de dejarlas disponibles para un posible trabajo futuro. Una política más corta es más fácil de razonar durante una versión y tiene menos probabilidades de arrastrar supuestos obsoletos.

Comprueba que los enlaces de documentación apuntan a la versión actual del producto y que las plantillas de despliegue hacen referencia a una revisión de política activa. Prueba el material de reversión mientras sigue siendo válido. Una revisión que solo existe en un ticket antiguo no es una opción de recuperación fiable si su inventario de proxies o su asignación de perfil ya se han retirado.

Incluye a los responsables de privacidad y de soporte en la revisión de mantenimiento. Operaciones puede confirmar la salud de las rutas, mientras que privacidad confirma que la recopilación y la conservación siguen siendo proporcionadas. Soporte puede identificar preguntas de configuración recurrentes que deberían resolverse en las plantillas de despliegue. Esta revisión compartida mantiene útil la política sin ampliar su alcance.

Errores comunes de configuración

• Considerar equivalentes todas las fuentes de política. Los requisitos de fuente cambian según la capacidad, así que elige una fuente documentada y aprobada para el flujo previsto y revisa esa elección cuando cambie el navegador o el paquete de políticas.
• Repartir la propiedad del enrutamiento entre capas. Cuando PAC, los manejadores del framework y un servicio externo de reenvío eligen rutas, el camino final se vuelve difícil de explicar, así que elige un único responsable para cada decisión.
• Reutilizar una política para perfiles no relacionados. Una política creada para una región o familia de navegador puede no servir para otra, así que revísala cuando cambie la familia de perfil, la región del proxy o el papel del nodo.
• Usar respuestas controladas para tráfico web real. Están pensadas para fixtures propios y rutas de prueba autorizadas, y el tráfico ordinario hacia destinos debe seguir la red estándar del navegador.

Qué admite BotBrowser y dónde termina

BotBrowser soporta el enrutamiento PAC estándar mediante --proxy-pac-url y, para perfiles ENT Tier3 aprobados, un callback de solicitudes de confianza en el mismo script PAC que puede continuar, bloquear, capturar, enrutar una sola solicitud o devolver una respuesta sintética controlada desde una fuente PAC file: o data:. Así la política de rutas permanece en la ruta de red del navegador, y tu equipo revisa una política junto a cada perfil en lugar de una lógica de enrutamiento repartida entre scripts de automatización. BotBrowser no puede hacer que una ruta proxy esté disponible ni sana, no puede aprobar una política en nombre de tu organización, no permite respuestas controladas desde fuentes PAC HTTP(S) y no comprueba de quién es un destino, así que limitar las respuestas controladas a fixtures propios, y no a tráfico real de terceros, es una política de tu equipo.

Consulta la documentación del callback de solicitudes PAC para ver las fuentes admitidas, los valores de retorno y los requisitos operativos, y la guía de configuración de proxy para las opciones de proxy subyacentes. El artículo sobre configuración de proxy explica cómo encajan esas opciones.

Fuentes públicas

• MDN: archivo Proxy Auto-Configuration (PAC)
• Documentación de BotBrowser PAC-Like Request Callback

Practical conclusion

Conserva en un mismo registro la fuente PAC, el inventario de proxies aprobados, el perfil y la revisión de reversión. Valida el resultado de la ruta antes de exponer el flujo al tráfico de producción.