En la red de mi instituto, Chrome se volvió lentísimo desde que comenzó el curso 2024-2025: cada inicio de un PC, abrir Chrome y hacer una búsqueda en una pestaña se demoraba 20 segundos o más! Lo extraño: Firefox funcionaba al instante. Ningún reinicio, limpieza de caché o ajuste de DNS resolvía el misterio. El patrón era claro:

  • Chrome sufría solo en equipos Windows de la red.

La Raíz del Problema: Windows y WPAD

Tras investigar (y con ayuda de ChatGPT), descubrí que el fallo venía de cómo Windows gestiona la detección de proxy:

  1. WPAD (Web Proxy Auto-Discovery Protocol): Windows usa DHCP o DNS para buscar un archivo wpad.dat que define reglas de proxy 214.
  2. Chrome vs. Firefox:
    • Chrome depende totalmente de la configuración de proxy del sistema (WinHTTP).
    • Firefox usa su propio gestor y puede ignorar WPAD si está mal configurado.
  3. El error: Si Windows no encuentra wpad.dat o trama en resolverlo, agota el tiempo de espera (~20 segundos) antes de permitir tráfico directo. ¡Chrome heredaba este retraso! 

La Solución: Un WPAD Minimalista y DHCP

ChatGPT sugirió crear un archivo wpad.dat que deshabilitara explícitamente el proxy. Así nació este script de 3 líneas:

function FindProxyForURL(url, host) {
return "DIRECT"; // ¡Sin proxy, tráfico directo!
}

Pasos para implementarlo:

  1. Hostear el archivo. Subí wpad.dat a un servidor HTTP interno (ej: http://192.168.1.1/wpad.dat).
  2. Configurar DHCP. Asigné la Opción 252 de DHCP con la URL del archivo:
    /ip dhcp-server option add name="wpad" code=252 value="'http://192.168.1.1/wpad.dat'"
    /ip dhcp-server network set [find] dhcp-option=wpad
  3. Reiniciar clientes: ¡Chrome pasó de 20 segundos a respuesta inmediata!

Análisis Técnico

  • Ventajas:
    • Simplicidad: Elimina la latencia de WPAD al evitar búsquedas DNS/DHCP fallidas 14.
    • Compatibilidad: Funciona en redes donde solo Windows/Chrome tienen problemas (sin afectar otros dispositivos).
    • Mantenimiento cero: No requiere actualizar reglas de proxy.
  • Desventajas:
    • En redes complejas, usar DIRECT siempre es inseguro: expone IPs internas y omite filtros. Lo ideal sería un wpad.dat con reglas reales (ej: return "PROXY mi-proxy:8080";) .
    • Si un atacante modifica wpad.dat, podría redirigir tráfico.
  • Alternativas mejores:
    • Usar GPOs de Windows para configurar proxy estático (más seguro).
    • Habilitar WPAD via DNS (creando un registro wpad.empresa.com) si la infraestructura lo permite.