El mensaje de estado dice «Resolving host in proxy script», pero cambiar de servidor proxy apenas cambia nada. Es una pista útil: puede que el navegador siga decidiendo adónde enviar la solicitud.

Un archivo PAC puede realizar comprobaciones que dependen del DNS. Si esas comprobaciones esperan a un resolutor inaccesible o hacen preguntas innecesarias una y otra vez, la carga de la página puede detenerse antes de que el proxy seleccionado reciba algo.

1. Localice la pausa

Para una URL afectada, determine si el retraso se produce al obtener el archivo PAC, al evaluarlo o al conectar con el proxy devuelto. Un registro de acceso del proxy vacío es coherente con las dos primeras etapas; no demuestra que el navegador haya usado una ruta directa.

Después revise qué reglas necesitan DNS. Las pautas de rendimiento de PAC de Microsoft recomiendan evitar el trabajo innecesario que depende del DNS. Una comprobación de igualdad de nombre de host no necesita la misma información que resolver ese nombre y comprobar una subred.

2. Elimine el trabajo de DNS innecesario

Las excepciones de nombre de host conocidas suelen poder decidirse antes de las comprobaciones amplias basadas en direcciones. Resuelva un nombre solo cuando la política restante necesite realmente su dirección. Guarde el resultado en una variable local si varias condiciones posteriores necesitan el mismo valor.

No «arregle» un script lento añadiendo un retorno DIRECT incondicional al principio. Eso elimina la decisión de enrutamiento junto con el retraso.

Las soluciones de DNS específicas de cada máquina necesitan pruebas. Habilitar el uso compartido de archivos o reescribir el archivo hosts de cada portátil es una mala primera reacción ante un script de enrutamiento lento. Compruebe el comportamiento del resolutor y del nombre de host en la red afectada, sobre todo tras un cambio de red, y cambie el PAC solo donde su ruta de decisión real lo exija.

Artículos relacionados