URL de proxy automática: archivos PAC y configuración de WPAD

Una URL de proxy automático apunta a un archivo PAC, un pequeño script que suele llamarse proxy.pac y que decide para cada solicitud si se conecta directamente o a través de un proxy. Este enfoque surgió del diseño de navegador de Netscape de 1996, creado para seleccionar automáticamente el comportamiento de enrutamiento.

Probablemente ya hayas visto cómo falla. Alguien de tu equipo pega una configuración en un navegador, consulta una página para verificar la IP, ve el país esperado y da el trabajo por terminado. Horas después, un flujo de control de calidad muestra precios locales, una comprobación de anuncios devuelve la creatividad equivocada o una llamada a la API en segundo plano revela la red de la oficina. La configuración parecía correcta, pero no todo el tráfico la siguió. Ahí empieza la mayor parte de la confusión, porque una URL de proxy automático no es realmente una dirección para el tráfico. Es una dirección para tomar una decisión.

A qué apunta realmente una URL de proxy automático

La persona responsable de verificar anuncios abre un navegador de prueba en Lyon y ve una campaña exactamente como debería verla un usuario móvil francés. Un colega hace la misma comprobación desde otro portátil y obtiene la página global predeterminada. Ambos juran que usaron «el proxy». En la práctica, un dispositivo obtuvo el script de enrutamiento y lo aplicó, mientras que el otro conservó una configuración manual o nunca descargó el script.

Esa es la distinción fundamental. Una configuración de proxy normal apunta a un servidor, como un host y un puerto. Una URL de proxy automático apunta a un archivo de configuración automática de proxy, normalmente llamado proxy.pac, que el navegador o el sistema operativo descarga y ejecuta. Piensa en un proxy fijo como una carretera que siempre tomas. Un archivo PAC se parece más a una aplicación de navegación que recalcula la ruta para cada viaje según el destino.

Por qué importa centralizar la decisión

El sistema se basa en el método de configuración automática de proxy diseñado originalmente por Netscape en 1996 para Netscape Navigator 2.0, y un archivo PAC contiene una función de JavaScript llamada FindProxyForURL(url, host) que decide si cada solicitud se conecta directamente o a través de uno o varios proxies, como se describe en la guía de Mozilla sobre archivos PAC. Más adelante, el Grupo de Trabajo de Ingeniería de Internet documentó PAC en el RFC 3040 en enero de 2001.

Ese antecedente no es un dato anecdótico. El RFC 3040 señaló que PAC simplificaba la administración al centralizar las políticas de proxy en un solo script, de modo que los administradores pudieran actualizarlo en lugar de reconfigurar manualmente cada agente de usuario. También advirtió que la interoperabilidad no era perfecta, porque los navegadores podían interpretar el mismo script de maneras distintas.

Una URL de proxy automático válida demuestra que un dispositivo puede obtener instrucciones de enrutamiento. No demuestra que todas las aplicaciones de ese dispositivo vayan a seguirlas.

Cuando pegas esa URL en una pantalla de configuración, no estás eligiendo un único servidor de salida. Estás eligiendo quién decide la salida para cada solicitud y con qué rapidez puedes cambiar esa decisión para todos, sin tener que modificar manualmente cada portátil, teléfono o perfil del navegador.

Cómo decide un archivo PAC adónde va cada solicitud

Sigamos una solicitud. Tu navegador quiere abrir la página de un producto. Antes de abrir una conexión, le pasa la URL y el host a FindProxyForURL(url, host). La función evalúa reglas sencillas y devuelve una instrucción como DIRECT o un proxy con nombre, a veces con proxies alternativos que el navegador puede probar si el primero falla.

Un ejemplo sencillo ayuda a entenderlo. Las herramientas internas pueden devolver DIRECT porque ya están en tu red. Los destinos de investigación públicos pueden devolver un proxy con la ubicación que necesitas. Un segundo proxy en la lista devuelta sirve de respaldo, no como un segundo salto para la misma solicitud.

El límite de la caché por nombre de host

No des por sentado que puedes enrutar cada ruta de forma distinta. Las recomendaciones actuales señalan que los resultados de proxy automáticos se almacenan en caché por nombre de host, lo que limita la capacidad de seleccionar proxies distintos según la ruta de la URL u otros componentes de la URL. En la práctica, dos páginas del mismo host suelen reutilizar el mismo resultado de enrutamiento, aunque esperases que una ruta de pago se comportara de forma distinta a la página de inicio.

Qué cambia con HTTPS

Una URL de proxy automático no cambia la semántica de los túneles HTTP. Para destinos HTTPS, un cliente que cumpla con las especificaciones se conecta al proxy configurado y emite CONNECT destination-host:port; tras una respuesta satisfactoria, el proxy reenvía los bytes cifrados sin inspeccionarlos, mientras que TLS se mantiene de extremo a extremo entre el cliente y el destino, tal como se establece en la semántica de HTTP en el RFC 9110.

Esta distinción ahorra tiempo al solucionar problemas:

• 400 Bad Request: El puerto explícito en CONNECT es obligatorio, y una solicitud con un puerto no válido o vacío debe rechazarse de esta manera.
• 407 Proxy Authentication Required: El proxy necesita credenciales y devuelve un desafío Proxy-Authenticate.
• CONNECT se completa, pero TLS falla: El túnel se abrió; por tanto, revisa el protocolo de enlace con el destino en lugar de culpar al ancho de banda del proxy.
• CONNECT falla repetidamente: Comprueba primero la autenticación, las listas de permitidos, los puertos o las políticas del destino.

Una URL de proxy que empieza con ` puede seguir transportando tráfico HTTPS mediante CONNECT. Eso no significa que el proxy pueda inspeccionar el contenido cifrado de la página. Mide por separado el tiempo de resolución de DNS, el tiempo de conexión TCP, la tasa de éxito de CONNECT, la latencia del protocolo de enlace TLS y el rendimiento sostenido; de lo contrario, solucionarás el problema en la capa equivocada.

Alojar un archivo PAC y permitir que los clientes lo encuentren

Tu script puede ser lógicamente perfecto y aun así no servir de nada si los dispositivos no pueden descargarlo. Alojarlo es una tarea de infraestructura poco vistosa, pero es donde los equipos consiguen actualizaciones sencillas o crean un único punto de fallo silencioso.

Coloca proxy.pac en un servidor web al que todos los dispositivos de destino puedan acceder sin necesitar previamente el proxy que intentas configurar. Es una trampa habitual para el personal remoto. Si un portátil necesita el proxy para acceder al archivo PAC y necesita el archivo PAC para conocer el proxy, no podrá arrancar.

Dos formas de descubrir el script

La ruta explícita es la más sencilla de entender. Un administrador o un usuario introduce directamente la URL de proxy automático en la configuración del sistema o del navegador. Sabes exactamente qué script debería descargar el dispositivo y puedes probar esa misma URL desde un dispositivo limpio en la misma red.

La ruta automática es WPAD, abreviatura de detección automática de proxy web. Los clientes buscan una ubicación wpad.dat mediante DNS o DHCP y, luego, descargan la configuración desde ahí. WPAD reduce la configuración manual en las redes de oficina administradas, pero aumenta la importancia de controlar los nombres. Si el host equivocado responde al nombre WPAD, los dispositivos pueden recibir instrucciones de enrutamiento que no publicaste.

Regla práctica: Prefiere una URL de proxy automático explícita cuando no puedas controlar por completo DNS y DHCP en todas las redes a las que se conectan tus dispositivos.

Los cambios tampoco se propagan al instante. Los clientes aplican una versión nueva solo cuando vuelven a descargar el archivo, lo que puede depender de la caché, de que se vuelvan a conectar o de que se reinicie la aplicación. No edites las reglas de producción minutos antes de comprobar una campaña dando por hecho que todos los puestos ya tienen el nuevo comportamiento.

Breve lista de comprobación para el alojamiento

• Guarda el archivo en un sistema de control de versiones: Revisa los cambios de enrutamiento como si fueran código, porque una sola regla incorrecta puede enviar el tráfico directo a través de un proxy o el tráfico del proxy directamente.
• Limita quién puede publicar: Cualquiera que pueda reemplazar el archivo PAC puede influir en adónde va el tráfico del navegador.
• Usa una URL estable: Cambiar la ubicación implica reconfigurar los clientes, lo que contradice el propósito de las actualizaciones centralizadas.
• Mantén una URL de prueba: Ábrela desde un dispositivo limpio, fuera de la red de administración, y confirma que se carga el script esperado.
• Mantén las reglas legibles: Resolver problemas más adelante será más difícil si nadie recuerda por qué se forzó la conexión directa para un host hace meses.

Configurar la URL de proxy automático en plataformas comunes

Empieza con una decisión antes de tocar ningún menú. ¿Este enrutamiento debe aplicarse a todo el dispositivo o solo a un perfil del navegador usado para una tarea concreta? Un administrador de redes sociales que consulta contenido regional quizá quiera un perfil aislado. Un dispositivo de QA que prueba un recorrido completo de usuario suele necesitar un comportamiento a nivel del sistema, con la salvedad de que no todas las aplicaciones lo respetan.

Las etiquetas de los menús cambian entre versiones, así que consulta la documentación oficial y actual de la plataforma en lugar de confiar en rutas de clic memorizadas. Los conceptos siguientes siguen siendo los mismos aunque cambien las opciones.

Ordenadores de escritorio y navegadores

En Windows y macOS, busca la configuración de red o proxy del sistema que ofrezca un script de configuración automática o una opción de configuración automática del proxy. Actívala, pega la URL de Auto Proxy, guarda los cambios y reinicia por completo el navegador que estás probando. Algunos navegadores reflejan la configuración del sistema operativo, mientras que otros permiten elegirla por separado, así que comprueba qué nivel tiene el control.

Si trabajas desde el navegador, consulta los pasos para cambiar la configuración del proxy en Chrome antes de dar por sentado que el navegador y el sistema operativo coinciden. Un proxy manual obsoleto en un perfil puede anular el nuevo script. Esa discrepancia explica muchos casos en los que las capturas de pantalla de una persona no coinciden con los resultados de otra.

Para implementaciones en equipo, documenta tres aspectos en tu manual de procedimientos:

• Ámbito: Todo el sistema, un navegador o un perfil administrado.
• Salida esperada: País, tipo de red y cualquier comportamiento de sesión que requiera la tarea.
• Reversión: Cómo desactivar el script y volver a DIRECT si el host PAC falla.

Dispositivos móviles

En dispositivos móviles, configura el proxy para la red Wi-Fi específica cuando esa opción esté disponible, elige la configuración automática e introduce la URL PAC. Las directrices de implementación actuales indican que iOS puede gestionar PAC a nivel del sistema, mientras que los clientes personalizados de Android, como OkHttp, pueden requerir el análisis explícito de PAC y la ejecución de JavaScript. Esta distinción se explica en esta guía de integración de proxy corporativo en aplicaciones móviles.

Esa consideración debería cambiar la forma en que validas la configuración. Una comprobación correcta en el navegador de un teléfono no demuestra que la aplicación, su WebView integrado o su SDK de analítica hayan usado la misma ruta.

Ejecuta una rutina breve de verificación en cada plataforma. Carga una página de prueba conocida, confirma la IP de salida mediante una página de comprobación fiable y luego repite el flujo de trabajo exacto en un segundo dispositivo. Haz la prueba en la red que la gente realmente usará, no solo en la red Wi-Fi de la oficina, junto a la persona que escribió el script.

Tipos de proxy, sesiones persistentes e IP móviles

Un archivo PAC elige una ruta, pero las características de esa ruta dependen del proxy que la recibe. Primero importan tres términos. La rotación de IP cambia la dirección de salida con el tiempo o cuando se solicita. Las sesiones persistentes mantienen una dirección durante un periodo determinado para que un inicio de sesión o un proceso de compra no pierda la coherencia. Un ASN, o número de sistema autónomo, identifica al operador de red que anuncia un bloque de direcciones, y la segmentación geográfica permite seleccionar un país o una región.

Por lo general, a un destino le resulta más fácil reconocer las direcciones de centros de datos como tráfico no doméstico porque su ASN pertenece a una red de alojamiento. Las direcciones residenciales se parecen más a las conexiones domésticas habituales. Las direcciones móviles proceden de redes de operadores y es ahí donde el uso compartido de direcciones cambia el cálculo del bloqueo.

Por qué es importante la NAT de nivel de operador

La NAT de nivel de operador, o CGNAT, permite que un operador traduzca las conexiones de muchos dispositivos de sus abonados mediante un grupo más reducido de direcciones IPv4 públicas. RFC 6598 reserva el bloque 100.64.0.0/10, que contiene 1,048,576 direcciones, para el espacio de direcciones compartido que utilizan los dispositivos CGN de los proveedores de servicios. Ese bloque no es enrutado globalmente, tal como se define en RFC 6598 sobre el espacio de direcciones compartido.

Como muchos clientes reales pueden compartir una misma IP móvil pública, un destino que bloquee esa dirección de forma agresiva puede afectar a muchas personas sin relación entre sí. Por eso es más difícil identificar las IP móviles como pertenecientes a un único actor y más arriesgado bloquearlas sin más. También por eso una IP es una señal de identidad imperfecta.

Para diseñar las sesiones, lee cómo la persistencia de sesión mantiene estable una dirección de proxy y decide dónde conviene mantener la coherencia. Usa un comportamiento persistente para la gestión legítima de cuentas, el QA de varios pasos y los flujos de anuncios que fallan si cambia la salida durante el proceso. Usa la rotación para investigaciones públicas amplias sin estado. En cualquier caso, registra las marcas de tiempo, el destino, el estado de la respuesta y el contexto de la sesión, porque una salida compartida de un operador no corresponde de forma unívoca a un usuario.

Los proxies HTTP gestionan solicitudes web y túneles CONNECT, mientras que SOCKS5 es un protocolo de proxy más general que puede transportar una gama más amplia de tráfico TCP. El valor de retorno de PAC, la compatibilidad del cliente y la tarea deben coincidir en esa elección.

Pruebas de cobertura y seguridad antes de usar en producción

Un resultado satisfactorio en una página de comprobación de IP es la prueba más débil que puedes hacer. Demuestra que una solicitud del navegador usó la salida esperada en un momento concreto. No dice nada sobre redirecciones, cargas, llamadas en segundo plano ni sobre si el proxy seleccionado seguirá siendo fiable mañana.

PAC es un mecanismo de enrutamiento del navegador o del sistema operativo. Es posible que las aplicaciones móviles personalizadas y los clientes HTTP no ejecuten la lógica PAC automáticamente. Una prueba en el navegador puede usar el proxy previsto mientras un WebView integrado, un SDK, una solicitud en segundo plano o un cliente de API se conecta directamente. En el QA con dependencia geográfica, ese punto ciego puede invalidar todo el resultado.

Diseña las comprobaciones en torno a flujos de trabajo reales, con una configuración estructurada del entorno de pruebas de proxy en lugar de comprobaciones puntuales improvisadas:

• Resolución DNS: Confirma que las consultas no revelen una ubicación no deseada ni fallen cuando la ruta del proxy esté activa.
• Redirecciones y HTTPS: Sigue toda la cadena y verifica que CONNECT funcione para cada host de destino.
• WebSockets y cargas: Prueba conexiones de larga duración y envíos de archivos, no solo la visualización de páginas.
• Llamadas en segundo plano: Activa solicitudes de analítica, API y SDK, e inspecciona por dónde salen.
• Comportamiento alternativo: Desactiva el primer proxy en una copia de prueba del script y confirma que los clientes usen la alternativa prevista o fallen de forma clara.

Por qué hay que examinar la procedencia de los proxies

La automatización no convierte un endpoint en seguro. En un estudio de más de 107,000 proxies abiertos publicados, aproximadamente el 92% no estaba disponible o no permitía el tráfico de proxy, según las mediciones a gran escala de proxies abiertos publicados. El mismo conjunto de hallazgos verificados indica que cinco países concentraban casi el 60% de los proxies abiertos funcionales y que solo 10 sistemas autónomos alojaban el 41%.

Un análisis independiente de nueve meses incluido en esos hallazgos identificó más de 436,000 proxies y 104,000 ejemplos con respuesta; el 7.17% de los proxies con respuesta modificaba el contenido de las páginas web y el 76.42% de esos proxies modificadores realizaba acciones maliciosas. No hace falta memorizar esas cifras. Sí debes recordar la lección que transmiten.

No enrutes investigaciones de producción, protección de marca ni tareas de cuentas a través de endpoints seleccionados automáticamente que no hayas comprobado y cuyo acceso no hayas controlado.

Antes de usarlo en producción, realiza comprobaciones continuas de disponibilidad, mantén la lógica de respaldo en el archivo PAC, supervisa la integridad del contenido en páginas de prueba conocidas y exige autenticación cuando tu configuración lo permita. Registra qué proxy gestionó una tarea, cuándo lo hizo y qué estado devolvió. Cuando los resultados parezcan incorrectos, esos registros te permitirán distinguir un fallo de enrutamiento de un endpoint defectuoso.

Cómo elegir la configuración adecuada para tu equipo

Elige según el flujo de trabajo, no por costumbre. Una conexión directa es adecuada para sistemas internos y comprobaciones públicas en las que tu ubicación real sea el objetivo de la prueba. Configurar un proxy manualmente sirve para que una persona realice una tarea breve y estable, pero se vuelve frágil cuando diez personas necesitan las mismas reglas y estas cambian cada semana.

Una configuración basada en PAC justifica su complejidad cuando el enrutamiento varía según el destino. Por ejemplo, las herramientas internas pueden conectarse directamente, la supervisión pública de precios puede usar una salida residencial en el mercado objetivo y un proxy de respaldo puede cubrir una interrupción. Una actualización del script modifica la política sin tener que recorrer todas las estaciones de trabajo.

Las fuentes móviles 4G tienen sentido cuando la experiencia en el destino depende de las redes de los operadores. Los especialistas en verificación de anuncios pueden necesitar ver una campaña tal como la ve un suscriptor móvil. Los equipos de control de calidad pueden necesitar una salida de un operador francés para un flujo de registro localizado. Los gestores de redes sociales que manejan cuentas legítimas de clientes pueden necesitar sesiones persistentes y coherentes con la ubicación, que no cambien de red a mitad de una tarea. Los equipos de protección de marca y supervisión SEO pueden necesitar la misma segmentación geográfica sin vincular cada comprobación a una única conexión de oficina.

Compara estos criterios antes de decidirte:

• Cobertura necesaria: Solo el navegador, todo el dispositivo o una aplicación con su propio cliente HTTP.
• Comportamiento de la sesión: Rotativa para investigaciones sin estado, persistente para flujos de trabajo legítimos de varios pasos.
• Identidad de red: Velocidad de centro de datos, contexto residencial o salida del operador a través de IP móviles.
• Control operativo: Acceso autenticado, comprobaciones de estado, reglas de respaldo y registros útiles.
• Límites de cumplimiento: Normas de la plataforma, legislación aplicable, autorización del cliente y un propósito empresarial documentado.

Dentro de este modelo, Evoproxy es un proveedor de proxies móviles con sede en el sur de Francia y acceso a más de 1,500,000 direcciones IP móviles. Sus planes personales funcionan en hardware móvil dedicado, con 250 GB de tráfico mensual y rotación de uno a cinco minutos, mientras que los puertos compartidos ofrecen 50 GB con rotación programada para pruebas breves.

No compres basándote solo en el tamaño del grupo. Ejecuta un flujo de trabajo real con la configuración, aplica las comprobaciones de cobertura y seguridad anteriores y verifica que todos los componentes hayan seguido la ruta. Mantén las reglas PAC legibles, documenta las sesiones y limita todo uso a las normas de la plataforma y la legislación aplicable. Así, una URL de proxy automático se convierte en una política de enrutamiento fiable, en lugar de una cadena misteriosa que alguien pegó en la configuración hace meses.

Si tu próxima prueba necesita una salida auténtica de la red de un operador en lugar de una aproximación limitada al navegador, prueba la configuración móvil 4G de Evoproxy con un flujo de trabajo real de verificación de anuncios, control de calidad o investigación de mercado. Configura el comportamiento de sesión que necesites, verifica la cobertura más allá de la comprobación de IP visible y amplía la escala solo cuando tus propios registros demuestren que el enrutamiento funciona de extremo a extremo.