Proxy por perfil del navegador: DNS, autenticación y modos de fallo

Esta guía utiliza como referencia el comportamiento de red documentado de Chromium. Otros navegadores y productos pueden tomar decisiones diferentes, y un gestor del navegador puede añadir un intermediario local de red alrededor de Chromium. Verifica el comportamiento de la compilación exacta que utilizas.

Empieza con cuatro preguntas independientes

Un registro de proxy suele contener un esquema, un endpoint, un puerto y, en ocasiones, una referencia de autenticación. Ese registro deja cuatro preguntas independientes sobre las políticas:

1. Cobertura: ¿Qué solicitudes y protocolos del navegador se asignan a este proxy?
2. Resolución de nombres: ¿Resuelve el nombre de host de destino el dispositivo o el proxy?
3. Autenticación: ¿Qué esquemas de cliente y proxy funcionan juntos y dónde se guardan las credenciales?
4. Fallo: ¿Un error de conexión detiene la solicitud, prueba otro proxy o recurre a una ruta directa?

Tratar estas preguntas como un solo interruptor de «proxy activado» causa la mayoría de las sorpresas. Chromium documenta la selección de proxies como resolución a nivel de URL: una URL genera una lista ordenada de opciones de proxy antes de que el destino tenga que resolverse. Las reglas de omisión y las vías alternativas forman parte de esa decisión.

Qué cubre un proxy por perfil

La política ProxySettings de Google se aplica en el nivel del perfil de Chrome. Puede seleccionar los modos directo, del sistema, detección automática, servidor fijo o script PAC, con campos explícitos de omisión y PAC obligatorio.

Ese límite es más estrecho que una VPN o un espacio de nombres de red del sistema operativo. Gobierna las solicitudes que gestiona el contexto de red del navegador. No gobierna automáticamente:

• las llamadas de API del propio gestor de escritorio;
• una aplicación o actualizador del navegador ejecutado en otro proceso;
• las comprobaciones de DNS y conectividad del sistema operativo;
• otra aplicación iniciada desde un archivo descargado;
• una herramienta auxiliar nativa independiente de una extensión;
• servicios locales a los que se llega mediante omisiones implícitas de loopback; ni
• tráfico que utilice un protocolo que la ruta de proxy elegida no pueda transportar.

Algunos de esos componentes pueden admitir sus propios proxies. Ese soporte debe especificarse y probarse por separado. Una afirmación como «el tráfico del perfil utiliza este proxy» debe identificar los procesos y protocolos incluidos, en vez de insinuar un enrutamiento para todo el dispositivo.

Sigue una solicitud HTTPS

Una navegación HTTPS corriente tiene varios pasos.

1. Elegir la ruta

El navegador evalúa reglas fijas, un script de configuración automática del proxy o los ajustes del sistema. Una coincidencia con una omisión puede elegir una conexión directa. Una lista puede elegir un proxy principal seguido de alternativas, incluida DIRECT cuando se permite una vía directa.

Chromium también aplica omisiones implícitas para localhost y destinos locales de enlace. Esto protege los orígenes locales frente a ajustes de proxy controlados desde el exterior, pero implica que debe matizarse una descripción amplia de «todo el tráfico».

2. Resolver y alcanzar el proxy

Si el endpoint del proxy es un nombre de host, el dispositivo sigue necesitando resolverlo y conectarse a él. Que el DNS del destino sea remoto no elimina esta consulta inicial. Un fallo en este punto difiere de que el proxy sea accesible pero no pueda resolver el destino.

3. Autenticarse en el proxy

Un proxy HTTP que exige credenciales suele devolver 407 Proxy Authentication Required con un desafío. RFC 9110 define ese intercambio y los campos Proxy-Authenticate y Proxy-Authorization.

Chromium no utiliza un nombre de usuario y una contraseña incluidos en la configuración manual del proxy. Su documentación sobre proxies señala que la autenticación sigue el flujo normal de credenciales del navegador. Por tanto, un gestor de perfiles necesita una integración explícita para el desafío compatible, no la promesa de que funcionará cualquier cadena usuario:contraseña@host.

4. Establecer la conexión con el destino

Con un proxy HTTP, Chromium delega en el proxy la resolución del nombre de destino. Para un destino HTTPS, el navegador pide al proxy que cree un túnel CONNECT y después establece TLS de extremo a extremo con el destino a través de él.

El proxy sigue conociendo el nombre de host de destino y los metadatos de la conexión. Cuando el tramo entre cliente y proxy utiliza HTTP sin cifrar, la solicitud CONNECT y su nombre de host no están protegidos en ese tramo. Un proxy HTTPS añade TLS entre navegador y proxy y protege esos metadatos frente a observadores situados entre ambos. No impide que el propio proxy vea el destino solicitado.

Normalmente, el proxy no puede leer el contenido de la página HTTPS transportado dentro del túnel. La interceptación TLS es otro modelo de confianza, en el que un cliente confía en una autoridad de certificación que permite al intermediario terminar y volver a crear TLS. Nunca debe confundirse silenciosamente con el reenvío corriente.

La responsabilidad de DNS cambia con el esquema del proxy

El comportamiento documentado de Chromium varía según el tipo de proxy:

Ruta elegida	Resolución del nombre de destino en Chromium	Límite importante
Directa u omitida	Resolutor del dispositivo o navegador	El tráfico de destino sale sin el proxy del perfil
Proxy HTTP	En el proxy	El transporte HTTP sin cifrar entre cliente y proxy expone las solicitudes HTTP; HTTPS utiliza CONNECT
Proxy HTTPS	En el proxy	El cliente debe validar el certificado TLS del proxy
Proxy SOCKS4	En el cliente	Solo destinos IPv4; Chromium no implementa la vía alternativa SOCKS4a
Proxy SOCKS5	En el proxy	Chromium lo utiliza para solicitudes URL por TCP y documenta que no admite autenticación SOCKS5

RFC 1928 permite que una solicitud SOCKS5 incluya un nombre de dominio y define varios identificadores de métodos de autenticación. La capacidad del protocolo no garantiza que el cliente la implemente. Actualmente, Chromium envía los nombres de destino a un proxy SOCKS5, pero indica que su cliente SOCKS5 integrado no admite métodos de autenticación de proxy. Un proveedor con acceso SOCKS5 mediante usuario y contraseña puede necesitar un intermediario compatible u otro esquema de proxy. Confirma la implementación del navegador antes de aceptar el registro.

DNS sobre HTTPS añade otra capa. La política DnsOverHttpsMode de Chrome distingue automatic, que puede recurrir a DNS no seguro, de secure, que hace fallar la resolución si falla el DNS seguro. La misma política está documentada a nivel del navegador, mientras que ProxySettings lo está a nivel del perfil. Esta diferencia sirve de advertencia: que un ajuste contenga la palabra «perfil» no implica que todos los controles de DNS tengan el mismo alcance.

Un producto que ejecute cada perfil en un proceso independiente del navegador puede crear un límite efectivo más estrecho, pero es una elección de implementación. Pruébala. Las pruebas deben diferenciar:

• la resolución del endpoint del proxy;
• la resolución del destino solicitado;
• el DNS utilizado por solicitudes directas u omitidas;
• el arranque y la vía alternativa de DNS seguro; y
• el DNS realizado por componentes externos al contexto de red del perfil.

La autenticación es un problema de compatibilidad y tratamiento de secretos

Chromium documenta Basic, Digest, Negotiate y NTLM para proxies HTTP. Los proxies HTTPS añaden un canal protegido entre cliente y proxy, y también pueden admitir certificados de cliente. El cliente integrado de Chromium no implementa la autenticación de SOCKS4 ni SOCKS5, aunque la especificación SOCKS5 incluya métodos de autenticación.

Incluso un esquema compatible puede ser inseguro con el transporte equivocado. RFC 7617 explica que las credenciales Basic solo se codifican en Base64 y necesitan un canal protegido como TLS. Usar autenticación Basic con un proxy HTTP sin cifrar expone la contraseña del proxy a cualquiera que pueda observar ese tramo.

Un gestor de perfiles debe mantener separados estos datos:

• metadatos no secretos del endpoint, como el esquema, el host, el puerto y la etiqueta del proveedor;
• una referencia al secreto que utiliza el servicio de ciclo de vida o red;
• el valor de la credencial en un almacenamiento protegido;
• un estado de conexión oculto para la interfaz y el registro de auditoría; y
• detalles de diagnóstico disponibles únicamente mediante un flujo controlado de asistencia.

Las pantallas, los registros, las API, las exportaciones y las salidas de automatización normales no necesitan la contraseña del proxy. Un operador suele necesitar saber que falló la autenticación, qué esquema se solicitó, qué endpoint intervino y si se utilizó alguna vía alternativa.

Modos de fallo y sus síntomas

Fallo	Síntoma probable	Límite que debe verificarse
Esquema de proxy equivocado	Falla el protocolo de enlace TLS o del protocolo	¿Se declaró como HTTP un endpoint HTTPS, o al contrario?
No se puede resolver el host del proxy	La conexión falla antes de alcanzar el proxy	¿Qué resolutor realizó la consulta inicial?
El puerto del proxy no es accesible	Tiempo de espera o conexión rechazada	¿Hay otro proxy o DIRECT a continuación en la lista?
Desafío de autenticación no compatible	Mensajes repetidos 407 o aviso de inicio de sesión	¿Implementa el navegador el esquema solicitado?
Credencial equivocada o caducada	407 después de enviar la credencial	¿Se resolvió la referencia al secreto y se ocultó en las salidas?
Falla el certificado del proxy HTTPS	Se rechaza la conexión segura al proxy	¿Sigue intacta la validación del certificado?
El proxy no puede resolver el destino	Fallo de host o túnel específico del proxy	¿Evitó el cliente volver a probar directamente el destino?
Se rechaza CONNECT	Falla la navegación HTTPS hacia ese destino	¿Se trata el rechazo como una política y no como permiso para omitir el proxy?
El archivo PAC no está disponible	La resolución del proxy se detiene o cambia de ruta	¿Es obligatorio el PAC o puede Chromium utilizar DIRECT de forma silenciosa?
El patrón de omisión es demasiado amplio	Algunos sitios se conectan directamente	¿Se comprenden las reglas exactas, de host, subdominio, puerto e implícitas?
WebRTC utiliza otra interfaz	La ruta multimedia difiere de la del tráfico de la página	¿Está desactivado el UDP sin proxy para el perfil?
Una conexión existente sobrevive a un cambio	La ruta antigua permanece activa temporalmente	¿Se vacían las conexiones o se reinicia el perfil?
La captura de diagnóstico contiene demasiados detalles	URL, nombres de host o secretos llegan a un archivo de asistencia	¿Qué modo de ocultación y regla de conservación se aplican?

La vía alternativa de Chromium tiene estado. Un proxy con un fallo de conexión puede marcarse como defectuoso y colocarse detrás de otras entradas durante un tiempo. Si DIRECT figura en la lista, las solicitudes posteriores pueden salir sin proxy. Un rechazo de CONNECT se gestiona de otra forma porque puede representar una política deliberada sobre el destino, no la indisponibilidad del proxy.

Los fallos de PAC exigen especial atención. Chromium documenta que, si el archivo PAC no está disponible, puede recurrir silenciosamente a una resolución directa salvo que el PAC se marque como obligatorio. La política ProxySettings de Chrome expone ProxyPacMandatory específicamente para impedir esa vía directa.

WebRTC y UDP necesitan su propia decisión

Una página puede utilizar rutas WebRTC que no equivalen a las solicitudes URL HTTP y HTTPS corrientes. La política WebRtcIPHandling predeterminada de Chrome puede utilizar todas las interfaces disponibles. Su modo disable_non_proxied_udp restringe WebRTC a TCP en la interfaz pública salvo que un proxy configurado admita UDP.

Esa política está documentada a nivel del perfil y, por tanto, es pertinente para un proxy de perfil, pero sigue siendo otro control. Puede reducir el rendimiento multimedia o romper un flujo que necesite UDP directo. Elige y prueba expresamente la contrapartida. No afirmes que todo el tráfico queda contenido por el proxy basándote únicamente en la carga correcta de una página.

Decide si el fallo debe cerrar el acceso o mantener la disponibilidad

Una vía directa puede ser legítima para un perfil de navegación general que valore la disponibilidad. Es insegura para un flujo cuya autorización, privacidad o validez de las pruebas regionales dependa de una ruta de salida concreta.

Una buena política de perfiles identifica el comportamiento previsto:

• Proxy obligatorio: detener las solicitudes de red afectadas cuando no pueda utilizarse la ruta elegida.
• Conjunto de proxies aprobados: probar solo alternativas identificadas con una política equivalente.
• Vía directa permitida: mostrar que la ruta cambió y registrar el suceso sin valores secretos.
• Omisión explícita: documentar la clase de destino y por qué necesita acceso directo.

La interfaz debe mostrar el estado de la ruta antes del inicio y después de un fallo. Cambiar silenciosamente de proxy a conexión directa convierte un error de red en uno de integridad: el flujo puede parecer correcto mientras utiliza la ruta equivocada.

Una matriz de validación segura

Prueba con endpoints y zonas DNS de tu propiedad o que estés autorizado a inspeccionar. Registra los resultados esperados antes de ejecutar la prueba.

1. Verifica el esquema de proxy declarado frente al transporte real del endpoint.
2. Confirma el comportamiento correcto de HTTP, HTTPS, WebSocket y el WebRTC necesario.
3. Observa la dirección de salida en un destino controlado.
4. Observa qué resolutor recibe la consulta del destino y cuál inicia la resolución del host del proxy.
5. Haz caducar una credencial de prueba y confirma que ningún valor sin procesar aparece en la interfaz, los registros ni las salidas de automatización.
6. Haz inaccesible el proxy de prueba y confirma el cierre seguro o la vía alternativa configurados.
7. Deniega un destino CONNECT controlado y confirma que una denegación de política no se convierte en acceso directo.
8. Haz que un PAC de prueba deje de estar disponible y confirma el comportamiento obligatorio.
9. Ejercita los casos de omisión exactos, de subdominio, locales, locales de enlace, IPv4 e IPv6 que necesite el flujo.
10. Cambia el proxy mientras haya conexiones activas y verifica cuándo entra en vigor la ruta nueva.
11. Captura solo los detalles de diagnóstico necesarios para la prueba y verifica después su conservación y eliminación.

Las indicaciones de NetLog de Chromium tratan el registro de red como un riesgo para la privacidad y la seguridad. Los modos ocultos pueden omitir campos sensibles, mientras que otros más detallados pueden incluir cookies o encabezados de autenticación. Un archivo de asistencia debe tratarse según su modo real de captura, no según su nombre.