Cuándo las reglas PAC basadas en el tiempo eligen un proxy
Una regla de tiempo en un PAC elige un proxy cuando se evalúa el enrutamiento. No promete mover una conexión existente a una salida nueva en un segundo exacto.
Puedes escribir una regla PAC que devuelva un proxy por la mañana y otro más tarde. Pero no puedes inferir de esa regla que todas las conexiones existentes del navegador cambien de salida al mediodía.
Funciones como timeRange() participan en una decisión de enrutamiento. No son un planificador en segundo plano que cierra túneles, migra sockets o pide a un proveedor de proxy que rote su IP pública.
Mantén tres eventos separados:
- El navegador evalúa el PAC y obtiene una ruta.
- El cliente establece o reutiliza una conexión según sus reglas de red.
- El servicio elegido escoge la dirección pública para su conexión posterior.
La condición de tiempo afecta directamente al primer evento. Una descarga ya activa o una conexión de larga duración es otro asunto. El almacenamiento en caché del cliente y la reutilización de conexiones también implican que «el script contiene una comprobación del reloj» no es prueba suficiente de un calendario de cambio preciso.
Si una tarea necesita una salida nueva por sesión, solicitud o ventana de tiempo, usa una interfaz diseñada para ese requisito y verifica su comportamiento documentado. Un PAC puede elegir entre extremos, pero no define qué hacen esos extremos con sus propias direcciones de salida.
El enrutamiento basado en el tiempo aún puede ser útil para una política de red intencionada. Descríbelo como una elección de ruta en el momento de la evaluación, no como un mecanismo garantizado de rotación de IP.