PAC Request Policy para un enrutamiento coherente

Proxy Auto-Config, normalmente abreviado como PAC, proporciona al navegador una política para seleccionar una ruta de red. La decisión permanece en la capa de red del navegador, de modo que la misma política puede cubrir navegación, redirecciones, subrecursos y solicitudes gestionadas por el navegador sin depender de un entorno de automatización de página.

Esta ubicación resulta útil cuando un despliegue utiliza más de una ruta proxy aprobada. La navegación regional, las pruebas de aplicaciones internas, la validación multimedia y las cargas con varios contextos pueden requerir familias de rutas diferentes. Una política PAC mantiene estas decisiones cerca del perfil y de la configuración de inicio.

BotBrowser 150.0.7871.46 añade respuestas controladas al flujo enterprise PAC Request Policy. El enrutamiento PAC estándar sigue disponible. La capa adicional ayuda a los equipos autorizados a mantener un tratamiento coherente con requisitos explícitos de fuente y perfil.

Por qué el enrutamiento pertenece al navegador

Un proxy estático suele ser suficiente para una sesión sencilla. Resulta menos adecuado cuando un mismo flujo necesita varios caminos aprobados. Trasladar las decisiones a los manejadores de un entorno de automatización también puede generar diferencias entre Playwright, Puppeteer, CDP directo y el tráfico gestionado por el propio navegador.

PAC ofrece al navegador una política única. El código de automatización controla la página y el navegador selecciona la red. Esta separación facilita la revisión porque el perfil, el inventario de proxies y la política de enrutamiento tienen responsabilidades claras.

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

Cambios en BotBrowser 150.0.7871.46

BotBrowser 150.0.7871.46 amplía el flujo PAC enterprise aprobado con dos capacidades operativas:

• El enrutamiento por proxy autenticado puede permanecer en la capa de red gestionada por el navegador.
• Las respuestas controladas pueden servir recursos propios y recorridos de calidad repetibles bajo una política de fuentes más estricta.

La selección PAC estándar continúa atendiendo el tráfico normal. Los despliegues no tienen que trasladar cada solicitud a la capa adicional. El nuevo comportamiento está pensado para categorías seleccionadas que requieren más control que la elección de una ruta.

Estas capacidades permanecen vinculadas a perfiles enterprise aprobados. Una fuente PAC debe tratarse como configuración de producción porque puede afectar al destino del tráfico y a la entrega local de un recurso propio.

Un modelo operativo claro

Un despliegue mantenible separa cuatro responsabilidades:

1. El perfil define la identidad prevista del navegador.
2. El inventario de proxies define las rutas de red aprobadas.
3. La política PAC selecciona una ruta para cada categoría relevante.
4. El flujo de automatización ejecuta la tarea autorizada.

Esta organización evita copiar reglas 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 la página.

Use nombres descriptivos y mantenga cada política centrada en un solo propósito. Una validación regional, una prueba interna y un flujo multimedia no deberían compartir una política grande solo porque utilizan el mismo proceso de trabajo. Las políticas pequeñas son más fáciles de revisar, versionar y restaurar.

Respuestas controladas y límites de la política

Las respuestas controladas son adecuadas para puntos de conexión y recursos que pertenecen al despliegue. Entre los usos razonables están un resultado de disponibilidad, un recurso estable de prueba o una respuesta determinista dentro de un control de calidad autorizado.

Esta capacidad aplica una política de confianza más limitada que el enrutamiento PAC normal. Los administradores deben elegir una fuente compatible según la documentación vigente, proteger la política con los mismos controles de acceso que el perfil y rechazar cualquier vía de entrega no revisada. La distinción operativa es si la fuente está aprobada para la capacidad seleccionada, no la etiqueta de transporte visible para una aplicación.

Mantenga los recursos propios separados del tráfico real hacia destinos. Las respuestas controladas sirven para pruebas repetibles y controles operativos, no para sustituir la navegación normal hacia servicios de terceros.

Usos adecuados de PAC Request Policy

Coherencia regional

Una sesión con perfil puede necesitar una ruta que coincida con la región elegida. PAC mantiene la navegación y las solicitudes relacionadas en la familia aprobada sin duplicar la lógica en varios entornos de automatización.

Rutas internas y externas

Una prueba enterprise puede combinar un servicio interno con dependencias públicas. Una política pequeña mantiene el tráfico interno en el camino privado previsto y envía el externo por el proxy aprobado.

Procesos de trabajo con varios contextos

Los procesos que crean y cierran contextos necesitan una propiedad clara de la configuración. Asociar cada contexto con su perfil y su política facilita la revisión posterior y reduce las suposiciones a nivel de proceso.

Control de calidad repetible

Los recursos propios pueden reducir la variabilidad de red en un recorrido seleccionado. Con una fuente de política aprobada, las respuestas controladas atienden ese uso limitado mientras el resto de la página conserva la red estándar.

Cuándo es mejor un proxy estático

PAC no es necesario en todos los despliegues. Prefiera un proxy estático cuando todo el tráfico deba utilizar una sola ruta y no exista una política por categorías. Una configuración menor es más sencilla de operar.

Use PAC cuando la selección en el navegador sea un requisito real. No lo añada para duplicar una lógica de entorno de automatización que ya tiene una ruta estable. La política debe reducir la complejidad operativa.

Medidas de protección del despliegue

Trate la fuente PAC, el perfil y el inventario de proxies como una única unidad revisada.

• Limite quién puede cambiar la fuente.
• Mantenga la referencia de política aprobada explícita en la configuración del despliegue.
• Use control de versiones para políticas estables.
• Revise la propiedad de las rutas antes de cambiar regiones o credenciales.
• Inicie una nueva sesión cuando cambie la configuración del trabajo.
• Aplique a los recursos controlados los mismos controles de acceso que al flujo de prueba.
• Prefiera unas pocas categorías permitidas a una política general.

La distribución remota requiere la misma revisión de transporte y acceso que cualquier configuración de producción. La disponibilidad de más tipos de fuente para PAC estándar no autoriza respuestas controladas en esas fuentes.

Validación basada en resultados

La validación debe confirmar el resultado del despliegue sin recopilar datos de página innecesarios.

Comience con el plan de rutas. Registre qué categorías deben utilizar cada ruta aprobada y cuáles deben conservar el comportamiento PAC estándar. Ejecute el flujo autorizado normal y compare el resultado de red observable con el plan.

Revise juntos el perfil y la ruta. Región, idioma, zona horaria y salida proxy deben describir el mismo entorno. En trabajos con varios contextos, revise cada uno por separado para evitar que un éxito oculte un problema en otro.

Para un recurso controlado propio, confirme el comportamiento esperado mediante las comprobaciones normales de la aplicación. Revise en conjunto el identificador efectivo de la política, la asignación del perfil, el registro de acceso y el resultado del navegador. Estas observaciones muestran si el despliegue sigue el plan de rutas aprobado.

Un registro conciso suele bastar: versión de la política, familia del perfil, familia de ruta esperada, salida observada y resultado del flujo.

Incluye también la revisión del navegador, el grupo de despliegue y la decisión del responsable. Si el recorrido no coincide con el plan, conserva la primera evidencia, restaura la última unidad aprobada y repite el mismo caso antes de cambiar la red o la aplicación. Así, la revisión puede separar un problema de asignación de una indisponibilidad temporal de la ruta.

Responsabilidad y revisión

Asigne a cada política un responsable que conozca las rutas de aplicación que gobierna. La operación de los proxies puede pertenecer a otro equipo, pero el límite entre selección de ruta y disponibilidad debe quedar escrito. El registro de revisión debe incluir el nombre y la revisión de la política, los grupos de despliegue afectados, las familias de perfil asignadas, el resultado esperado y la revisión de retorno.

No comparta una política de manera informal entre trabajos. Una configuración válida para una aplicación puede depender de regiones, servicios privados o responsables que no existen en otra. Cree una política revisada cuando cambie el propósito. Mantenga las credenciales fuera del texto de la política y del código de automatización; use el sistema habitual de secretos y limite el acceso a las cuentas del trabajo autorizado.

Despliegue gradual

Empiece con un grupo pequeño que represente la producción. Use la versión prevista del navegador, el perfil, el sistema operativo, el inventario de proxies y la versión de automatización. Compare el grupo con otro sin cambios durante el mismo periodo, usando páginas y trabajos equivalentes. Observe el resultado de la aplicación, el inicio y cierre del navegador, la disponibilidad del proxy y la familia de ruta obtenida.

Amplíe por grupos de despliegue. Si el resultado deja de coincidir con el plan, pause la expansión y restaure la última política revisada antes de probar otro cambio. Las tareas de larga duración deben recibir la nueva unidad de versión en una sesión de navegador nueva, siguiendo el ciclo normal de cierre de la aplicación.

Registros y respuesta operativa

Los registros de rutas pueden revelar información operativa sensible. Conserve solo la revisión de la política, la familia de perfil, la familia de ruta aprobada, el grupo, el intervalo y el resultado de la aplicación. Aplique la política normal de retención y controle tanto quién edita una política como quién puede asignarla a un grupo.

Ante un resultado inesperado, detenga la entrega de nuevos trabajos al grupo afectado. Compare el navegador, el perfil, el inventario de proxies y la revisión asignada con el último cambio aprobado. Compruebe la disponibilidad de las rutas mediante la supervisión normal de infraestructura, como un hecho separado de la selección de política. Restaure primero la última unidad revisada y cambie un solo componente en cada nueva prueba.

Revise las políticas activas después de cambios importantes y de forma periódica. Retire categorías sin propietario o propósito actual. Incluya a operaciones, privacidad y soporte para confirmar que las rutas siguen disponibles, que la retención es proporcional y que las plantillas apuntan a una revisión vigente.

Errores comunes

Considerar equivalentes todas las fuentes de política

Los requisitos cambian según la capacidad y la versión. Seleccione una fuente documentada y aprobada para el flujo previsto, y revise esa elección cuando cambie el navegador o el paquete de políticas.

Repartir la propiedad del enrutamiento

Cuando PAC, los manejadores del entorno de automatización y un servicio externo eligen rutas, el camino final es difícil de explicar. Asigne un responsable a cada decisión y documente los límites.

Reutilizar una política para perfiles no relacionados

Una política creada para una región o familia puede no servir para otra. Revísela cuando cambien el perfil, la región del proxy o la función del proceso.

Usar respuestas controladas para tráfico web real

Están destinadas a recursos propios y recorridos de prueba autorizados. El tráfico normal debe continuar por la red estándar del navegador.

Preguntas frecuentes

¿PAC Request Policy sustituye a PAC estándar?

No. PAC estándar sigue siendo el modelo normal de selección. El flujo enterprise añade un tratamiento seleccionado para despliegues aprobados.

¿Cómo se elige una fuente para respuestas controladas?

Use una fuente compatible con la documentación vigente y aprobada por el responsable del despliegue. Registre sus controles de acceso, su revisión y su asignación de perfil en el mismo cambio.

¿Todos los BrowserContext necesitan PAC?

No. Use PAC solo cuando el contexto necesite selección de rutas en el navegador. Un proxy estático es más claro para una sola ruta.

¿Funciona la misma política con varios entornos de automatización?

Sí. La política pertenece a la capa de red del navegador, por lo que el entorno de automatización no tiene que reproducir las reglas.

¿Dónde están los detalles de configuración?

Consulte la documentación de PAC Request Policy para fuentes y requisitos operativos. La guía de configuración de proxies cubre las opciones de proxy.

PAC Request Policy aporta más valor cuando hace que el enrutamiento sea fácil de entender. Mantenga la política pequeña, alinéela con el perfil y reserve las respuestas controladas para fuentes aprobadas en flujos propios.