El proceso de pago según la ubicación geográfica funciona en un teléfono, pero la misma prueba falla en la laptop de la oficina. La fecha límite de la campaña no ha cambiado y alguien sugiere que omitas el proxy. Antes de cambiar una configuración, averigua si la red de la oficina bloqueó el destino, si la aplicación eligió una ruta incorrecta o si el destino rechazó la solicitud.
Identifica qué problema de proxy tienes realmente
Un problema de proxy necesita un responsable antes de necesitar una solución. Un proxy corporativo de reenvío, que envía solicitudes salientes en tu nombre, no es lo mismo que los controles de tráfico del propio sitio web. La configuración de la aplicación y la autenticación del proxy presentan otros puntos de fallo.
Usa el síntoma para asignar el ticket, en lugar de probar otra conexión al azar.
Síntomas, causas y primeros pasos para problemas de proxy
| Síntoma | Causa probable | Quién puede cambiarlo | Primer paso |
|---|---|---|---|
| Algunos sitios fallan mientras otros cargan | Host en una lista de bloqueo o filtro por categoría | Equipo de seguridad de TI | Solicita una excepción para el host exacto |
| Funciona en el navegador, pero falla en la aplicación o el script | La aplicación ignora la configuración del proxy del sistema | Tú, en la configuración de la aplicación | Configura el proxy explícitamente o añade NO_PROXY para un destino directo autorizado |
| Funciona con datos móviles, pero falla con el Wi-Fi de la oficina | Proxy de la oficina o política de inspección | TI | Pregunta si la prueba puede ejecutarse por una ruta autorizada |
| Se bloquea incluso con acceso directo | Detección de bots o proxies del propio sitio web | Política del sitio | Revisa las condiciones y detente; no cambies de IP para eludirlas |
Las solicitudes de autenticación corresponden al equipo de identidad o de TI. Las credenciales faltantes o vencidas no se solucionan añadiendo una excepción de destino.
Recopila pruebas antes de cambiar la ruta
Registra el host y puerto exactos, el protocolo, el código de error, el dispositivo y la red. Indica si la misma solicitud funciona en otra red autorizada y si el fallo ocurre antes o después de iniciar sesión.
En sistemas Windows administrados, revisar la configuración del proxy de WinHTTP ayuda a determinar qué utiliza esa pila de red. No demuestra que todos los navegadores o aplicaciones usen la misma configuración.
Cambiar la IP aparente no es una solución universal. Un estudio de 2025 descrito por Tech Xplore determinó que los patrones de tiempo de ida y vuelta entre capas permitían detectar el tráfico enviado a través de proxies en el 80% de los 5.000 sitios web con más accesos que se probaron, incluso con ofuscación.
Añadir una excepción autorizada, configurar una ruta permitida e intentar eludir la detección de un sitio son acciones distintas. Un bloqueo por políticas requiere una solicitud documentada, no una solución alternativa.
Cómo interpretar la configuración de PAC y WPAD antes de cambiarla
Un archivo PAC, abreviatura de configuración automática de proxy, es un pequeño archivo JavaScript cuya función FindProxyForURL elige una ruta para cada solicitud. Es posible que el navegador envíe una aplicación interna directamente y, en cambio, envíe los sitios web públicos a través del proxy corporativo.
WPAD, o detección automática de proxy web, encuentra esa configuración, normalmente mediante la opción 252 de DHCP o un nombre de host wpad en DNS. La detección y el enrutamiento son procesos distintos: WPAD localiza las instrucciones y el archivo PAC las contiene.
Lee la regla que realmente se aplica
- Copia la ubicación de la configuración. Busca la URL de configuración automática del proxy en la configuración del navegador o del sistema operativo. Si el campo está administrado, anótala sin intentar anular la política.
- Abre la URL de PAC en una sesión de navegador autorizada. Debería mostrarse o descargarse como texto legible, aunque puede que necesites estar en la red corporativa para acceder.
- Busca comprobaciones de host como
dnsDomainIs,shExpMatcheisInNet. Sigue el orden de ejecución de la función, porque un retorno anterior puede impedir que se ejecute una regla posterior. - Identifica la ruta devuelta. Compara el destino que falla con las condiciones reales, no solo con un dominio conocido que aparezca en alguna parte del archivo.
- Envía a TI el destino, la condición coincidente y su valor de retorno. Eso es más útil que pedirle a alguien que desactive la configuración automática.
Valores de retorno de PAC y configuración de WPAD
| Configuración o valor de retorno | Qué hace | Qué comprobar |
|---|---|---|
| DIRECT | Conecta sin proxy | Confirma que los hosts coincidentes sean nombres internos que deban omitir el proxy o excepciones externas aprobadas explícitamente |
| PROXY host:port | Envía el tráfico HTTP y HTTPS a través de ese proxy | Compara el host y el puerto con la documentación de TI |
| SOCKS5 host:port | Envía tráfico TCP a través de un proxy SOCKS5 cuando sea compatible | Úsalo solo para aplicaciones que necesiten SOCKS; los navegadores eligen según la regla |
Un valor de retorno puede incluir rutas alternativas. El orden importa, y una alternativa DIRECT debe ser intencional, no una forma accidental de eludir la inspección.
Ten en cuenta la detección y el almacenamiento en caché
La guía de configuración automática del proxy ofrece contexto para distinguir una URL de PAC configurada de la detección automática. Antes de solucionar el problema, registra qué mecanismo utiliza tu dispositivo.
Los navegadores pueden conservar el contenido de PAC o las decisiones de enrutamiento hasta que se reinicien o se actualice la caché. Que el resultado no cambie inmediatamente después de editar una configuración no demuestra que la nueva configuración haya fallado.
Regla práctica: Considera sospechosas las solicitudes inesperadas de proxy en redes Wi-Fi públicas. No introduzcas credenciales corporativas solo porque la detección automática haya encontrado un proxy.
Desactivar la detección automática también puede interrumpir servicios internos que dependen de la ruta detectada. Deja la configuración de detección administrada en manos de su responsable.
Cómo añadir excepciones de proxy paso a paso
Una excepción de proxy envía un destino seleccionado directamente en lugar de hacerlo a través del proxy configurado. Solo funciona cuando la red permite el acceso directo y no autoriza a omitir la inspección.
Empieza con un destino autorizado que aparezca en el mensaje de error. Registra el puerto por separado, porque muchos campos de exclusión aceptan patrones de host en lugar de pares de host y puerto.
Aplica la excepción donde la aplicación la lee
Registra el destino más específico. Copia el host y el puerto exactos y confirma con TI el alcance autorizado. No lo sustituyas por un dominio principal solo porque sea más fácil de escribir, ya que podría incluir servicios no relacionados.
En Windows, abre Configuración, Red e Internet y luego Proxy. En la configuración manual del proxy, edita el campo de excepciones, que a veces se llama “No usar el servidor proxy para las direcciones que comiencen con”, usando el separador que requiera la interfaz. Esto afecta a la configuración manual, pero no necesariamente a una ruta administrada por PAC ni a una aplicación con configuración independiente.
En macOS, abre Configuración del Sistema, selecciona Red, elige la conexión activa y luego Detalles y Proxies. Añade el host autorizado en la configuración de omisión para hosts y dominios; el texto puede variar según la versión. Comprueba que hayas editado la conexión que realmente transporta la prueba, y no un adaptador inactivo.
En Firefox, revisa Configuración de red y “Sin proxy para”. Chrome y Edge suelen leer la configuración del proxy del sistema operativo, a menos que una política, una extensión o las opciones de inicio la anulen. El riesgo es suponer que una excepción específica del navegador también cambia la configuración de las aplicaciones en segundo plano.
En herramientas de línea de comandos como curl y Python requests, configura NO_PROXY con la lista de destinos autorizados separada por comas en el entorno del proceso. Luego ejecuta
curl -vcon la URL autorizada y revisa el destino de la conexión; que la página se cargue correctamente no demuestra por sí solo que la ruta sea directa. Algunos clientes interpretan las exclusiones de forma distinta, así que verifica la aplicación que ejecutará el trabajo real.Mantén activada la opción «Detectar la configuración automáticamente», salvo que el departamento de TI cambie explícitamente ese requisito. Registra las entradas, el motivo empresarial, el responsable y la acción de reversión en el ticket de cambio. Si el dispositivo se administra de forma centralizada, solicita el cambio al departamento de TI en lugar de luchar contra una configuración que la política restaurará.
Comprueba el alcance antes de guardar
Los sufijos amplios, los dominios de nivel superior completos y las entradas comodín sin restricciones pueden hacer que tráfico sensible no relacionado evite la inspección. Una excepción para probar el proceso de pago no debería eludir también los controles de todos los servicios de un dominio compartido grande.
La precisión es mejor que la comodidad: añade el destino que puedas justificar, no el patrón más amplio que acepte el campo de configuración.
Guarda la configuración original antes de probar. Si el departamento de TI rechaza el cambio, restaura cualquier modificación local y usa una alternativa aprobada.
Solución de errores comunes detrás de un proxy corporativo
Para HTTPS a través de un proxy HTTP convencional, el cliente normalmente envía CONNECT con el host y el puerto de destino. El proxy abre un túnel TCP y luego reenvía los bytes de la conexión, tal como se describe en la especificación CONNECT de la IETF.
En un túnel normal, el proxy no descifra los datos de la aplicación HTTPS. Una implementación corporativa de inspección TLS es diferente: termina y vuelve a establecer las conexiones cifradas mediante certificados en los que confían los dispositivos administrados.
Distingue las respuestas del proxy de las del destino
Un 403 en la solicitud CONNECT indica que el proxy rechazó el túnel, a menudo debido a una política sobre el destino o el puerto. En cambio, un 403 recibido después de establecer el túnel puede proceder de la aplicación de destino, así que registra en qué etapa se generó.
Una respuesta 407 significa que se requiere autenticación en el proxy. Vuelve a autenticarte mediante el mecanismo aprobado y pregunta al departamento de TI si la aplicación admite el método de inicio de sesión de la organización.
No pegues credenciales en líneas de comandos, scripts compartidos ni archivos adjuntos de tickets. Esas ubicaciones pueden conservar secretos en historiales, registros y sistemas de colaboración.
Errores del proxy, causas y soluciones
| Síntoma o error | Causa probable | Solución |
|---|---|---|
| Advertencia de certificado solo en la red de la oficina | Inspección TLS sin el certificado raíz corporativo instalado | Instala el certificado raíz aprobado por el departamento de TI |
| Tiempo de espera agotado sin respuesta | Solicitud enviada a un proxy que no puede llegar al host | Si el acceso directo está aprobado, añade el host a NO_PROXY y prueba con curl -v |
| Funciona en curl, pero falla en el navegador | El navegador usa una configuración PAC o un proxy diferente | Compara la configuración del proxy del navegador y del sistema operativo |
| Comportamiento anterior tras un cambio | Archivo PAC o configuración del proxy almacenados en caché | Reinicia el navegador y vuelve a obtener el archivo PAC |
| Conexión SOCKS5 rechazada | Posible discrepancia de protocolo o puerto, servicio de escucha no disponible o conexión rechazada | Haz coincidir el protocolo con el puerto y luego comprueba que el servicio de escucha esté disponible |
Considera las etiquetas de error como pistas, no como diagnósticos
Una advertencia de certificado limitada a la red de la oficina es compatible con la inspección, pero no la demuestra. Comprueba el emisor del certificado y pide al departamento de TI que valide la cadena; nunca omitas la advertencia ni desactives la verificación del certificado para terminar una prueba.
Los tiempos de espera agotados también requieren contexto. Es posible que un proxy no tenga acceso a un destino privado, pero los fallos de DNS, los cortafuegos y una aplicación no disponible pueden provocar síntomas similares.
Para un destino interno aprobado, una ruta directa de alcance limitado puede resolver la limitación de conectividad del proxy. Para un destino externo sujeto a políticas, ese mismo tiempo de espera debe notificarse en un ticket al departamento de TI, no convertirse automáticamente en una regla de omisión.
Un rechazo de conexión SOCKS no demuestra que se haya enviado HTTP a un puerto SOCKS. El rechazo de conexión puede producirse antes de la negociación del protocolo, así que confirma el servicio de escucha y el punto de conexión antes de cambiar los protocolos de la aplicación.
Si el navegador funciona y el script falla, compara el entorno, la autenticación y el almacén de confianza del script con la configuración del navegador. La lista de comprobación para rechazos de conexiones del proxy puede ayudar a organizar esos datos.
Registra la etapa en la que se produce el fallo, la marca de tiempo y el resultado de error saneado. Así, el departamento de TI tendrá información reproducible sin exponer cookies, encabezados de autorización ni datos de clientes.
Alternativas aprobadas cuando se rechaza una excepción
| Opción | Ideal para | Aprobación necesaria | Principal contrapartida |
|---|---|---|---|
| VPN corporativa | Personal que accede a sitios internos de forma remota | Habilitación por parte del departamento de TI | El tráfico sigue sujeto a la inspección de la política |
| Navegador de pruebas o entorno aislado en la nube autorizado | QA y pruebas geográficas en un entorno aislado | Equipo de seguridad | Limitado a las ubicaciones del proveedor |
| Proxy residencial o de centro de datos aprobado | Estudios de mercado y seguimiento de precios | Compras y departamento jurídico | La reputación de la IP varía según el sitio de destino |
| Proxy móvil 4G/LTE | Verificación de anuncios autorizada, gestión de cuentas conforme a las reglas de la plataforma, QA geográfico | Responsable del equipo y revisión jurídica | Mayor coste, límites de ancho de banda y alcance que debe documentarse |
| Lista de permitidos de prueba del departamento de TI | Comprobaciones breves y definidas | Ticket de cambio de TI | Su obtención es más lenta, pero es totalmente auditable |
El rechazo de una excepción cambia el lugar donde se realiza la tarea, pero no la pone fin. El trabajo pasa a un entorno aislado o a otra política de acceso, con un alcance más limitado que el de la conectividad sin restricciones desde un portátil del personal.
Para aplicaciones internas, las recomendaciones de F1Group sobre cómo trabajar de forma remota más segura para las empresas de East Midlands ofrecen contexto para hablar con el departamento de TI sobre el acceso remoto administrado. Las pruebas en sitios públicos plantean otra cuestión: a través de qué red de salida debe ejecutarse la comprobación.
Adapta el contexto de red a la tarea
Los proxies de centros de datos salen a través de redes de alojamiento. Los proxies residenciales usan conexiones de redes de consumo y requieren verificar claramente su origen y revisar los contratos. Los proxies móviles, incluidas las conexiones 4G/LTE y 5G, salen a través de operadores móviles.
Un ASN, o número de sistema autónomo, identifica al operador de red que anuncia un rango de IP. La traducción de direcciones de red de nivel de operador, o CGNAT, permite que un operador móvil comparta una dirección pública entre sus abonados, lo que aumenta la probabilidad de que un bloqueo indiscriminado afecte a usuarios comunes.
Ese tráfico compartido hace menos concluyente la clasificación basada únicamente en la IP y más perjudicial el bloqueo generalizado. Los sistemas de detección y las reglas de aprobación se aplican a las salidas móviles igual que a cualquier otra ruta, por lo que el alcance documentado en la tabla sigue rigiendo lo que puede hacer la conexión.
La rotación de IP cambia la dirección de salida según un horario o en cada solicitud. Las sesiones persistentes intentan mantener una dirección de salida durante un período definido, lo que ayuda a conservar la continuidad en flujos de inicio de sesión aprobados, aunque los cambios subyacentes del operador todavía pueden interrumpirla.
HTTP y SOCKS5 son protocolos de acceso: definen cómo llega el tráfico al proxy, mientras que la calidad de la salida depende de la red que haya detrás. La orientación geográfica selecciona el país o la región de salida, y el destino sigue interpretando la sesión según sus propias señales.
Verifica las señales de forma independiente
Para realizar comparaciones autorizadas, mantén constantes la cuenta de prueba y el flujo de trabajo mientras comparas las ejecuciones directas y las que usan proxy. Registra por separado la dirección de origen, las propiedades TLS y HTTP, la huella del navegador, las cookies, la exposición de DNS y WebRTC, los tiempos y los resultados de los desafíos.
El estudio académico publicado en Information analiza la detección de IP ocultas y muestra por qué los resultados específicos de cada detector no sirven para hacer afirmaciones universales de éxito. La evidencia del navegador y de la sesión persiste aunque cambie la IP, por lo que el conjunto completo de señales importa más que la dirección de salida por sí sola.
Un equipo de marketing que comprueba anuncios regionales necesita condiciones de ubicación reproducibles y una autorización documentada. Las reglas del editor definen lo que puede hacer la prueba, y la elección de la red determina la ubicación geográfica.
Límites de seguridad y políticas que no debes pasar por alto
Un proxy corporativo no es simplemente una capa que mejora la velocidad. Quitarlo también puede eliminar el filtrado de URL, la inspección de malware, la visibilidad de DNS, los controles de prevención de pérdida de datos y los registros de auditoría.
El informe M-Trends de Google de 2025 recomienda supervisar el tráfico saliente a través de proxies y sistemas de detección de intrusiones, y revisar las solicitudes de DNS para identificar descargas maliciosas. Por lo tanto, una conexión directa requiere un plan de controles sustitutos, no solo una prueba de conexión exitosa.
Conserva los controles que necesita la empresa
- Limita el tráfico saliente. Restringe los permisos de salida al host y al puerto aprobados.
- Asigna responsabilidades. Nombra a un responsable y establece una fecha de vencimiento para cada excepción.
- Mantén la visibilidad. Supervisa el DNS de los endpoints y conserva registros de auditoría completos.
- Protege el tráfico cifrado. Aplica inspección TLS cuando sea legal y apropiado para el diseño aprobado.
- Reduce la exposición. Siempre que sea posible, usa credenciales de prueba y datos que no sean de producción.
Para las organizaciones que rediseñan el acceso en lugar de conceder una excepción temporal, la explicación de MR2 Solutions sobre la integración de SD-WAN con SASE ofrece contexto para mantener alineadas las políticas de redes y seguridad.
Una ruta de QA similar a la de un consumidor puede reproducir las condiciones de los clientes con mayor fidelidad, pero también expone las credenciales o los datos de prueba a una ruta de red distinta. Documenta esa contrapartida antes de realizar las pruebas.
Los proxies móviles no deben comprarse con la expectativa de evadir la detección ni de eludir los controles de acceso. Los términos de la plataforma siguen siendo aplicables; rotar direcciones para sortear una prohibición o un límite de velocidad impuesto no es un método de resolución de problemas aprobado.
Confirma la ruta con el equipo de TI antes de realizar las pruebas
La aprobación debe describir la tarea empresarial y la ruta permitida, no limitarse a autorizar a alguien a hacer desaparecer el error. Una autorización imprecisa para «desactivar el proxy» no ofrece a nadie una forma de verificarlo más adelante.
Redacta la solicitud de cambio. Limítala al formato en sí: una frase sobre la tarea, otra sobre la ruta que permitirá el equipo de TI y otra sobre cuándo termina la excepción. Adjunta las pruebas del error ya recopiladas y saneadas para que el equipo de TI pueda distinguir entre fallos de enrutamiento, autenticación y políticas de destino.
Pregunta si hay una ruta aprobada existente que sirva. Deja que la respuesta determine la configuración: dispositivo administrado, entorno aislado o conexión externa autorizada.
Verifica el cambio aprobado. Ejecuta
curl -vy prueba el navegador; después, registra la ruta de conexión real y el resultado junto con el ticket. Confirma que el flujo de trabajo empresarial funcione, no solo que se cargue una página.Elimina la excepción cuando termine el periodo de pruebas. Restaura la configuración guardada y verifica que la aplicación normal de las políticas esté activa de nuevo.
Por ejemplo, un equipo de QA necesita probar un flujo de pago en las condiciones móviles que experimenta un cliente en Francia. El equipo de TI aprueba una ruta móvil dedicada de 4G/LTE en Francia en lugar de una excepción para equipos de escritorio, limitada a cuentas de prueba y a un host de pruebas de preproducción, con controles de sesión que mantienen una misma IP durante los pasos del pago. El responsable y la fecha de vencimiento se anotan en el ticket; al finalizar, se restaura la aplicación normal de las políticas.
Evoproxy ofrece conectividad móvil 4G/LTE con opciones de enrutamiento por país y operador, controles de sesión y acceso HTTP o SOCKS5. Para una tarea aprobada que requiera condiciones de red móvil, visita Evoproxy para evaluar una configuración según la ubicación de destino, los requisitos de sesión y los registros de cumplimiento.
