Proxy interno de la empresa y aplicaciones de Windows — Cómo se resuelve el proxy en WinINET, WinHTTP y .NET

«En el navegador puedo abrir sitios externos, pero solo la aplicación de negocio no llega a la API externa». «Si lo ejecuto a mano funciona, pero en cuanto lo convierto en servicio de Windows falla». En entornos con proxy interno, este tipo de discrepancia es habitual.

El punto de partida de la investigación es con qué cuenta y qué configuración de proxy lee esa aplicación. La configuración de proxy de Windows no es una sola. El navegador, un servicio y el HttpClient de .NET pueden estar consultando configuraciones distintas.

En la mayoría de los casos la causa no es un fallo del servidor proxy ni un error de la aplicación, sino esta discrepancia entre sistemas de configuración y cuenta de ejecución. Este artículo se dirige al personal de sistemas de pequeñas y medianas empresas y a desarrolladores de aplicaciones Windows, y ordena el panorama de la configuración, luego PAC, autenticación y certificados, y por último el procedimiento de aislamiento.

Los patrones de creación de HttpClient y el diseño de tiempos de espera en sí se tratan en «No hay que envolver HttpClient en un using». El centro de este artículo es desde qué configuración se resuelve el proxy y dónde se detiene después la comunicación.

1. Primero la conclusión

Lo que conviene fijar primero son estos tres puntos.

• Antes de mirar la configuración, identifique la aplicación y la cuenta de ejecución. Cuál de la configuración por usuario de WinINET, la configuración de máquina de WinHTTP y las variables de entorno se lee lo decide el lado de la aplicación. La configuración que el administrador ve en su propia pantalla no tiene por qué ser visible desde un servicio.¹²³
• Investigue con la URL que falla, no con una que funciona. El PAC devuelve un proxy o DIRECT según la URL. En .NET también cambia la ruta con el runtime, las variables de entorno y una especificación explícita en el controlador.⁴⁵⁶
• Investigue por separado la ruta, la autenticación y los certificados. El 407 es autenticación de proxy y es distinto de un 401 del destino. Un error de certificado por inspección TLS se trata distribuyendo la CA interna y configurando las exclusiones necesarias, no desactivando la validación.⁷⁸³

flowchart TB
    accTitle: Información que hay que alinear en una investigación de proxy
    accDescr: Identificar la pila HTTP y la cuenta de ejecución de la aplicación, alinear la configuración visible desde esa cuenta y la URL que falla, y luego investigar la ruta, la autenticación y los certificados
    app["Pila HTTP y cuenta"] --> settings["Comprobar la configuración de esa cuenta"]
    settings --> url["Comprobar la ruta con la URL que falla"]
    url --> error["Investigar también autenticación y certificados por separado"]

Figura 1: Alinee «qué configuración», «vista desde qué cuenta» y «qué URL» antes de investigar el punto de fallo.

En una frase: cuando diga «he comprobado la configuración de proxy», debe poder indicar siempre cuál de los tres sistemas comprobó y desde qué cuenta.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (19 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Windows tiene tres sistemas de «configuración de proxy»

Las rutas por las que una aplicación en Windows encuentra el proxy interno se dividen a grandes rasgos en estos tres sistemas.

«La configuración de proxy de Windows» suele referirse a (1)

El «Proxy» que se ve en la aplicación Configuración es, históricamente, las Opciones de Internet de Internet Explorer, es decir, la configuración de WinINET. De forma predeterminada se guarda por usuario.³

(2) es el valor predeterminado a nivel de máquina para contextos como los servicios, donde «no hay un usuario con sesión iniciada». (3) procede sobre todo de la convención de herramientas de origen multiplataforma, y en Windows también la leen .NET (Core en adelante), curl y similares.⁵

Quién decide qué se lee no es quien configuró, sino la aplicación

El origen queda fijado por la aplicación: (1) si usa WinINET, (2) o una especificación propia si usa WinHTTP, y (3)→(1) si es .NET (Core en adelante).

Por tanto, cuando «la configuración es correcta pero no conecta», primero compruebe si la configuración que revisó y la que leyó la aplicación pertenecen al mismo sistema. Antes de recorrer los tres sistemas para ponerlos al mismo valor, es importante identificar el punto de entrada de la aplicación de destino.

También hay configuraciones por dispositivo, no por usuario

Si se habilita la Directiva de grupo «Hacer que la configuración del proxy sea por equipo (en lugar de por usuario)», (1) pasa a ámbito de máquina y se aplica la misma configuración a todos los usuarios. Con MDM (Intune y similares) se puede configurar por dispositivo con NetworkProxy CSP.³

flowchart TB
    accTitle: Cambiar el ámbito de aplicación de la configuración por usuario
    accDescr: La configuración de WinINET es por usuario de forma predeterminada, pero la Directiva de grupo puede cambiarla a configuración por equipo, y MDM puede configurarla por dispositivo con NetworkProxy CSP
    user["WinINET es por usuario de forma predeterminada"] --> gp["GPO la pasa a ámbito de equipo"]
    gp --> all["Se aplica la misma configuración a todos los usuarios"]
    mdm["NetworkProxy CSP de MDM"] --> device["Se configura por dispositivo"]

Figura 2: Como también hay configuraciones que cambian el ámbito de (1) a por dispositivo, lea «por usuario» como el estado predeterminado.

3. WinINET y WinHTTP — Una para aplicaciones interactivas, otra para servicios

3.1. Diferencia de funciones

WinINET y WinHTTP son ambas pilas de cliente HTTP estándar de Windows. Sin embargo, el modelo de ejecución que presuponen es distinto.

WinINET está pensada para aplicaciones de escritorio interactivas. Hereda de forma automática las Opciones de Internet del usuario, el proxy, las cookies y la caché de credenciales, y puede mostrar una interfaz de entrada de credenciales si hace falta. En cambio, no se admite su uso en servicios ni en procesos de tipo servicio.¹

WinHTTP está pensada para servicios y para el lado del servidor. Admite la ejecución con una cuenta de servicio, la suplantación de subprocesos (impersonation) y la separación de sesiones. A cambio, no comparte la configuración, las cookies ni las credenciales del navegador, y no muestra interfaz.²

La orientación de Microsoft para elegir entre ellas es igualmente WinINET salvo que se trate de un servicio o de un proceso de tipo servicio que necesite separación de sesiones o suplantación, y WinHTTP si es un servicio.¹ Esto no significa, sin embargo, que toda aplicación que se ejecute como servicio lea la configuración de máquina de WinHTTP. El trato de los servicios escritos en .NET se separa en el apartado 3.3.

3.2. Operaciones básicas de netsh winhttp

El proxy predeterminado de máquina de WinHTTP se gestiona con netsh.⁹

:: Mostrar la configuración de proxy de WinHTTP actual
netsh winhttp show proxy

:: Configurar un proxy estático (con lista de omisión)
netsh winhttp set proxy proxy-server="proxy.example.co.jp:8080" bypass-list="*.example.co.jp;<local>"

:: Incorporar la configuración de Opciones de Internet (WinINET)
netsh winhttp import proxy source=ie

:: Volver al valor predeterminado (DIRECT)
netsh winhttp reset proxy

No confunda configuración estática, incorporación y configuración automática

set proxy es una configuración estática. No trata la detección automática, la especificación de una URL PAC ni la autenticación de proxy.³

import proxy source=ie copia la configuración estática tal como está en el momento de ejecutarlo. Si después se cambian las Opciones de Internet, el lado de WinHTTP no las sigue.

flowchart TB
    accTitle: La incorporación de la configuración de proxy es una copia de una sola vez
    accDescr: import proxy source=ie solo copia en WinHTTP la configuración estática de ese momento, y los cambios posteriores de Opciones de Internet no se siguen de forma automática
    source["Configuración estática en el momento de la ejecución"] --> copy["import proxy source=ie"]
    copy --> dest["Copia en WinHTTP"]
    source -.-> later["Los cambios posteriores no se siguen de forma automática"]

Figura 3: import no es una configuración de sincronización, sino una operación que incorpora la configuración estática de ese momento.

Para configurar a nivel de máquina incluyendo PAC y la detección automática de WPAD, use netsh winhttp set advproxy. La configuración detallada en formato JSON incluye Proxy, ProxyBypass, AutoconfigUrl y AutoDetect.⁹

3.3. El escollo más frecuente: el servicio no lee la configuración de IE del usuario

El caso típico es el de un desarrollador que pasa a un servicio de Windows con LocalSystem una herramienta que ejecutaba en su propio PC.

Aunque durante el desarrollo comunicara con su propia configuración por usuario (1), la configuración visible desde LocalSystem es otra. Si la configuración de máquina de WinHTTP está sin configurar (DIRECT), intenta conectar en directo a la API externa y se agota el tiempo de espera. El procedimiento de convertir algo en servicio se trata en «Cómo crear y operar servicios de Windows».

flowchart TB
    accTitle: La discrepancia al convertir en servicio una herramienta ejecutada a mano
    accDescr: Si una herramienta que funcionaba con la configuración por usuario del desarrollador se convierte en un servicio LocalSystem, la configuración visible cambia, y si el valor predeterminado de WinHTTP es DIRECT intenta una conexión directa y falla
    dev["Ejecución manual como desarrollador"] --> works["Comunica con la propia configuración"]
    works --> service["Cambio a servicio LocalSystem"]
    service --> changed["Cambia la configuración visible"]
    changed --> direct["Conexión directa si WinHTTP no está configurado"]
    direct --> failure["Tiempo de espera agotado en la API externa"]

Figura 4: Aunque la máquina sea la misma, al cambiar la cuenta de ejecución cambia la configuración que se puede consultar.

Prepare la configuración en la forma que lee esa pila HTTP

Para un proceso que comunica aunque no haya un usuario con sesión iniciada, prepare configuración a nivel de máquina. El modo de configurarla, sin embargo, debe coincidir con la pila HTTP.

El HttpClient de .NET (Core en adelante) no lee la configuración de máquina de WinHTTP. No concluya que «como es un servicio, basta con configurar netsh». El orden de prioridad detallado se confirma en el capítulo 5.

Una configuración estática en un portátil que sale de la oficina también provoca el accidente inverso

Si fija el proxy estático interno en un portátil, fuera de la oficina ese proxy no es alcanzable y la comunicación deja de funcionar. Considere la configuración estática de máquina como un medio para servidores cuya configuración de red no cambia.³

4. PAC y WPAD — En qué consiste la «configuración automática»

PAC calcula la ruta; WPAD busca dónde está el PAC. Si se divide la «configuración automática» en estas dos, se ve qué hay que comprobar.

4.1. El archivo PAC y FindProxyForURL

PAC (Proxy Auto-Configuration) es un archivo escrito en JavaScript (ECMAScript). La función obligatoria FindProxyForURL(url, host) devuelve, para la URL y el host indicados, la lista de proxies que usar o DIRECT, que indica conexión directa.¹⁰

function FindProxyForURL(url, host) {
    // El dominio interno y las direcciones privadas conectan en directo
    if (dnsDomainIs(host, ".example.co.jp") ||
        isInNet(host, "10.0.0.0", "255.0.0.0")) {
        return "DIRECT";
    }
    // El resto pasa por el proxy. Si el primero no está disponible, se pasa al siguiente
    return "PROXY proxy1.example.co.jp:8080; PROXY proxy2.example.co.jp:8080; DIRECT";
}

En este ejemplo, el dominio interno y las direcciones privadas indicadas conectan en directo, y el resto pasa por el proxy. En este último caso, si el primer proxy no está disponible se pasa al siguiente y, al final, se recurre a DIRECT.

flowchart TB
    accTitle: PAC cambia la ruta según el destino
    accDescr: En el ejemplo de PAC descrito se evalúan la URL y el host, se devuelve DIRECT para el dominio interno y las direcciones privadas indicadas, y en caso contrario se devuelve una lista ordenada de proxies
    target["Pasar la URL y el host"] --> check{"¿Coincide con las condiciones internas del ejemplo?"}
    check -->|"Sí"| direct["Devolver DIRECT"]
    check -->|"No"| proxies["Proxy 1, proxy 2 y luego DIRECT"]

Figura 5: Como la respuesta del PAC cambia por URL, el éxito en otro sitio no confirma la ruta de la API que falla.

De aquí salen dos precauciones para la investigación.

Compruebe pasando la URL que falla. El PAC puede devolver una respuesta distinta por cada URL. La función de proxy automático de WinHTTP también está diseñada para consultar cada vez con la URL de la solicitud. «En el navegador se ven otros sitios» no es prueba de que la API que falla tome la misma ruta.⁴

Si la comunicación no está en el registro del proxy, sospeche también DIRECT y las omisiones. DIRECT es la instrucción de «ir sin usar el proxy». Si la comunicación dirigida al interior no aparece en el registro, compruebe un resultado DIRECT del PAC o una coincidencia con la lista de omisión.

4.2. Detección automática con WPAD

Si se activa «Detectar la configuración automáticamente», WPAD (Web Proxy Auto-Discovery) busca el lugar del archivo PAC. En general se reparte la URL PAC por DHCP, o se resuelve por DNS un host llamado wpad y se obtiene el archivo de una URL como http://wpad/wpad.dat.¹¹

flowchart TB
    accTitle: De la detección automática a la obtención del PAC
    accDescr: En WPAD se busca el lugar del archivo PAC mediante DHCP o DNS, se obtiene el PAC de ese lugar y se usa para calcular las rutas
    auto["Activar la detección automática"] --> find["Buscar el lugar con DHCP o DNS"]
    find --> pac["Obtener el archivo PAC"]
    pac --> route["Calcular la ruta por destino"]
    find -.-> missing["Si no hay mecanismo, la detección falla"]

Figura 6: La detección automática necesita el mecanismo de DHCP/DNS en el lado de la red.

Activar solo la detección automática en una red sin ese mecanismo no funciona, y aumenta el tiempo de espera hasta que la detección falla. Elegir «automático» no resuelve las cosas en todas partes.

4.3. Comportamiento de los clientes que no pueden leer un PAC

Aunque se distribuya un PAC, no todos los clientes lo evalúan. netsh winhttp set proxy es una configuración estática, y las herramientas del estilo de la variable de entorno HTTP_PROXY tampoco tienen, por lo general, un lugar donde escribir una URL PAC. Se especifica una URL de proxy fija.³⁵

En una aplicación nativa que usa WinHTTP de forma directa, compruebe cómo se abre la sesión.

flowchart TB
    accTitle: Comprobar si WinHTTP usa el PAC
    accDescr: Si la sesión de WinHTTP se abre con AUTOMATIC_PROXY se resuelve de forma automática, pero con la forma tradicional de abrirla la aplicación debe llamar a la API AutoProxy y aplicar el resultado
    open["Comprobar los parámetros de WinHttpOpen"] --> mode{"¿AUTOMATIC_PROXY?"}
    mode -->|"Sí"| automatic["WinHTTP resuelve de forma automática"]
    mode -->|"Forma tradicional de abrir"| api["La aplicación llama a la API AutoProxy"]
    api --> apply["Aplicar el resultado a la solicitud"]

Figura 7: Saber solo que una aplicación usa WinHTTP no permite concluir que el PAC también se use de forma automática.

En implementaciones antiguas, puede haber un PAC y aun así no usarse. En una red operada con PAC, decida también qué entregar, con configuración estática o variables de entorno, a los clientes que no pueden leer el PAC.

5. Resolución de proxy en .NET — Framework y Core en adelante son cosas distintas

.NET Framework y .NET (Core en adelante) determinan el proxy predeterminado de forma distinta. Investigar una aplicación .NET 8 con conocimientos de la era Framework puede llevar a comprobar la configuración equivocada.

5.1. .NET Framework — De forma predeterminada Opciones de Internet, sobrescrito con defaultProxy

HttpWebRequest de .NET Framework, y el HttpClient que se apoya en él, usan el proxy predeterminado salvo que se especifique Proxy de forma explícita. Ese valor predeterminado se determina combinando la configuración de Internet de la cuenta en ejecución (equivalente a WinINET) con el archivo de configuración, y la configuración del archivo de configuración tiene prioridad.⁶

Se controla con system.net/defaultProxy de app.config o machine.config.¹³

<configuration>
  <system.net>
    <!-- useDefaultCredentials: si se envían las credenciales predeterminadas al proxy con autenticación -->
    <defaultProxy enabled="true" useDefaultCredentials="true">
      <proxy usesystemdefault="true"
             proxyaddress="http://proxy.example.co.jp:8080"
             bypassonlocal="true" />
      <bypasslist>
        <add address="[a-z]+\.example\.co\.jp$" />
      </bypasslist>
    </defaultProxy>
  </system.net>
</configuration>

Si defaultProxy está vacío se usan las Opciones de Internet; si se escriben proxyaddress y similares, esa especificación tiene prioridad. Desde el programa se puede sustituir el mismo valor predeterminado con WebRequest.DefaultWebProxy.¹³⁶

flowchart TB
    accTitle: El proxy predeterminado de .NET Framework
    accDescr: En .NET Framework se parte de la configuración de Internet de la cuenta en ejecución y se da prioridad a los valores especificados en el archivo de configuración para determinar el proxy predeterminado
    account["Configuración de la cuenta de ejecución"] --> config["Prioridad a lo especificado en el archivo de configuración"]
    config --> default["Proxy predeterminado de Framework"]
    replace["Sustitución con DefaultWebProxy"] -.-> default

Figura 8: El valor predeterminado de Framework es la configuración de la «cuenta en ejecución», que no tiene por qué ser la visible en la pantalla del administrador.

Al ejecutarlo con una cuenta de servicio hace falta la misma precaución que en el apartado 3.3. Lo que lee de forma predeterminada son las Opciones de Internet de esa cuenta, distintas de lo que se ve en el escritorio del administrador y, por lo general, vacías.

5.2. .NET (Core en adelante) — Primero las variables de entorno, después la configuración de usuario del SO

.NET (Core en adelante) tiene la propiedad estática HttpClient.DefaultProxy. Es el valor predeterminado que se usa cuando el controlador no especifica un proxy de forma explícita, y en Windows se inicializa leyendo las variables de entorno y, si no están definidas, la configuración de proxy del usuario, en ese orden.⁵

Separe las tres variables que especifican el proxy de NO_PROXY

Si está definida cualquiera de HTTP_PROXY, HTTPS_PROXY o ALL_PROXY, tiene prioridad sobre la configuración del SO. Un HTTPS_PROXY de prueba que quedó atrás, o uno inyectado por una plantilla de CI/CD, envía el tráfico por una ruta distinta de la configuración que se vio en pantalla.

En cambio, definir solo NO_PROXY no configura un proxy a partir de las variables de entorno. En Windows se sigue usando la configuración de proxy de usuario del SO.

flowchart TB
    accTitle: Inicialización del proxy predeterminado de .NET en Windows
    accDescr: Si está definida cualquiera de HTTP_PROXY, HTTPS_PROXY y ALL_PROXY se priorizan las variables de entorno, y si no está definida ninguna se usa la configuración de usuario de Windows. Solo NO_PROXY no configura un proxy por variables de entorno
    init["Inicialización del proxy predeterminado"] --> env{"¿Hay alguna de las 3 variables de proxy?"}
    env -->|"Sí"| useenv["Prioridad a las variables de entorno"]
    env -->|"No"| user["Configuración de usuario de Windows"]
    init -.-> no["Solo NO_PROXY no configura nada"]

Figura 9: Compruebe primero si hay una especificación de proxy por variables de entorno, y distíngala del estado con solo NO_PROXY.

El «punto inicial» de NO_PROXY y la diferencia en Linux

NO_PROXY no admite comodines (*). .example.com con un punto al inicio coincide con www.example.com, pero no con example.com en sí.⁵

En contenedores Linux y similares, si las variables de entorno no están definidas se inicializa sin proxy. Como el comportamiento predeterminado cambia entre Windows y Linux, compruébelo también al pasar a un contenedor.⁵

5.3. Especificación explícita — HttpClientHandler.Proxy y UseProxy

En ambos runtimes, la especificación explícita de HttpClientHandler.Proxy tiene la máxima prioridad. Tiene prioridad sobre la configuración del SO y el archivo de configuración. Con UseProxy = false no se usa proxy en absoluto.¹¹

using System.Net;

// Usar de forma explícita un proxy leído de la configuración de la aplicación
var handler = new HttpClientHandler
{
    Proxy = new WebProxy("http://proxy.example.co.jp:8080")
    {
        BypassProxyOnLocal = true,
        BypassList = new[] { @"^intra\.example\.co\.jp$" },
        UseDefaultCredentials = true // Si hay proxy con autenticación, responder con las credenciales de la cuenta de ejecución
    },
    UseProxy = true
};
var client = new HttpClient(handler);

// Un cliente que no usa proxy en absoluto (para conexión directa a API internas)
var directHandler = new HttpClientHandler { UseProxy = false };
var directClient = new HttpClient(directHandler);

flowchart TB
    accTitle: Determinar el proxy efectivo a partir del controlador
    accDescr: Si UseProxy es false la conexión es directa, si es true se usa la especificación explícita de Proxy en el controlador, y si no hay especificación explícita se usa el proxy predeterminado
    use{"¿UseProxy es true?"} -->|"No"| direct["Conexión directa"]
    use -->|"Sí"| explicit{"¿Proxy especificado de forma explícita?"}
    explicit -->|"Sí"| proxy["Usar el proxy indicado"]
    explicit -->|"No"| default["Usar el proxy predeterminado"]

Figura 10: Antes de investigar el proxy predeterminado, compruebe la especificación explícita del controlador y UseProxy.

Atención también a la omisión automática de destinos locales

Cuando no hay especificación explícita y se sigue la configuración del SO, los nombres planos sin punto, las direcciones de bucle invertido y los destinos que coinciden con el sufijo de dominio de la propia máquina pueden tratarse como «locales» y omitirse.¹¹

Cuando «el comportamiento difiere entre una dirección IP directa y un nombre» o «al usar el FQDN empezó a pasar por el proxy», compruebe esta determinación.

El orden de prioridad hasta aquí se resume así.

6. Proxies con autenticación — El 407 es un error de autenticación «del proxy»

6.1. No confunda 407 con 401

Aunque se llegue al proxy, sin pasar la autenticación no se avanza. Separe quién exige la autenticación por el código de estado y la cabecera.⁷

En un 407, primero compruebe los métodos enumerados en Proxy-Authenticate. Basic es un método que envía nombre de usuario y contraseña; Negotiate (Kerberos/NTLM) y similares son métodos de desafío/respuesta. En estos últimos la contraseña en sí no circula, y la autenticación se completa en varios intercambios.⁷

sequenceDiagram
    accTitle: Flujo de respuesta a un proxy con autenticación
    accDescr: El cliente recibe del proxy un 407 y la notificación del método de autenticación, y responde con las credenciales de ese método. En un método de desafío-respuesta hacen falta varios intercambios
    participant C as Cliente
    participant P as Proxy
    C->>P: Solicitar la comunicación
    P-->>C: 407 y Proxy-Authenticate
    C->>P: Responder a la autenticación según el método
    Note over C,P: Según el método, varios intercambios

Figura 11: En un 407, compruebe la información de autenticación que se envía al proxy, no al servidor de destino.

A qué método de autenticación se «cae» se trata con detalle en «NTLM y Kerberos explicados con diagramas».

6.2. Cómo pasar las credenciales en .NET

El lugar de configuración difiere entre seguir el proxy predeterminado y especificar el proxy de forma explícita.

Para usar el proxy predeterminado y pasar credenciales, use HttpClientHandler.DefaultProxyCredentials. Son las credenciales que se envían a ese proxy predeterminado cuando UseProxy = true y Proxy = null.¹⁴

using System.Net;

var handler = new HttpClientHandler
{
    UseProxy = true,   // Valor predeterminado. Combinado con Proxy nulo, se usa el proxy predeterminado del sistema
    Proxy = null,
    // Responder al 407 con las credenciales de la cuenta de ejecución (usuario con sesión o cuenta de servicio)
    DefaultProxyCredentials = CredentialCache.DefaultCredentials
};
var client = new HttpClient(handler);

Cuando se especifica el proxy de forma explícita, las credenciales se ponen en el lado de WebProxy. En la mayoría de los escenarios de cliente se recomienda usar las credenciales predeterminadas del usuario con sesión, no un nombre de usuario y una contraseña individuales, y eso es lo que hace WebProxy.UseDefaultCredentials = true.¹⁵

6.3. El problema del 407 con cuenta de servicio

Las «credenciales predeterminadas» son las credenciales de la cuenta que ejecuta ese proceso. Con un usuario interactivo se autentica como ese usuario; con un servicio LocalSystem, como cuenta de equipo.

flowchart TB
    accTitle: Al convertirse en servicio cambia el sujeto que se autentica
    accDescr: Si se usan las credenciales predeterminadas, en una ejecución interactiva se autentica como ese usuario y en un servicio LocalSystem como cuenta de equipo, así que hay que comprobar si el proxy puede autenticar a ese sujeto
    run{"¿Cuenta de ejecución?"} -->|"Usuario interactivo"| user["Credenciales de ese usuario"]
    run -->|"LocalSystem"| machine["Cuenta de equipo"]
    user --> check["Comprobar si el proxy puede autenticarlo"]
    machine --> check

Figura 12: Aunque en el código se deje elegido «predeterminado», al convertirse en servicio cambia el sujeto que el proxy autentica.

Un proxy que autentica usuarios mediante integración con AD puede no poder autenticar una cuenta de equipo o una cuenta local, y los 407 continúan. A la inversa, hay entornos que establecen una exclusión de autenticación para servicios por IP de origen o por cuenta.

Por eso, en una aplicación que se va a convertir en servicio, decida en la fase de diseño si usar una cuenta de servicio de dominio (gMSA y similares), establecer una exclusión de autenticación en el proxy, o preparar un proxy de retransmisión interno que no requiera autenticación. La investigación de un 407 necesita tanto la configuración de la aplicación como «si el proxy puede autenticar esa cuenta de ejecución».

También existe el método de incrustar las credenciales en una variable de entorno, como en HTTP_PROXY=http://user:pass@proxy:8080.⁵ Como la contraseña en texto claro queda expuesta en las variables de entorno, es decir, en la información del proceso, no se recomienda para una operación permanente.

7. HTTPS y el proxy — Túnel CONNECT e inspección TLS

7.1. HTTPS atraviesa el proxy en un «túnel»

Cuando se usa un proxy con HTTPS, el cliente primero envía CONNECT host-de-destino:443 y abre un túnel TCP. Si tiene éxito, el proxy devuelve 200 y, a continuación, el cliente y el servidor de destino realizan el protocolo de enlace TLS dentro del túnel. Si el túnel no se abre, se devuelve 407, 502 u otro similar.¹⁶

flowchart TB
    accTitle: Hasta que se abre el túnel HTTPS
    accDescr: En HTTPS se abre un túnel TCP con una solicitud CONNECT y, tras devolver 200, se realiza el protocolo de enlace TLS dentro del túnel. Si el túnel no se abre, se devuelve 407, 502 u otro similar
    connect["Indicar el destino con CONNECT"] --> result{"¿Se abrió el túnel?"}
    result -->|"Éxito, 200"| tls["Conexión TLS dentro del túnel"]
    result -->|"Fallo"| error["407, 502, etc."]

Figura 13: Lea por separado el fallo en la etapa de abrir el túnel y el fallo de la conexión TLS posterior.

En este modelo «de paso transparente», el proxy no puede leer el contenido cifrado de HTTPS. Lo que se ve en el registro es solo el nombre de host de destino y si la conexión tuvo éxito; la ruta de la URL no se ve.

7.2. Proxies de inspección TLS y errores de certificado

En el modelo de inspección TLS (descifrado SSL, break and inspect), el proxy termina TLS, descifra e inspecciona, y después vuelve a cifrar. El certificado que se presenta al cliente también se sustituye por uno re-firmado por la propia CA del proxy.⁸

flowchart TB
    accTitle: La inspección TLS cambia el certificado
    accDescr: En la inspección TLS el proxy termina TLS para inspeccionar el contenido y presenta al cliente un certificado re-firmado por su propia CA, así que hace falta confianza en esa CA
    proxy["El proxy termina TLS"] --> inspect["Descifrar, inspeccionar y volver a cifrar"]
    proxy --> cert["Certificado re-firmado por la CA interna"]
    cert --> trust["Hace falta confianza en la CA en el lado del cliente"]

Figura 14: En el modelo de inspección, el problema no es solo el certificado del destino, sino si se puede confiar en la CA interna.

Primero, compruebe en qué almacén de confianza se valida

Esta configuración requiere que el certificado de CA del proxy esté distribuido a las raíces de confianza de todos los clientes. El error de validación de certificado se produce no solo en las máquinas a las que no se ha distribuido, sino también en runtimes que usan su propio almacén de confianza y no miran el almacén de certificados de Windows.

En .NET suele aparecer como un HttpRequestException con un AuthenticationException interno. Confirme un mensaje del tipo «el certificado remoto no es válido».

El remedio es distribuir la CA, no desactivar la validación

El certificado de la CA interna se distribuye, por lo general, a «Entidades de certificación raíz de confianza» del equipo local. Para cuándo usar el almacén de usuario, consulte «Guía práctica del almacén de certificados de Windows».

No recurra a devolver siempre true en ServerCertificateCustomValidationCallback. Sigue quedando como una vulnerabilidad que impide detectar un ataque de intermediario cuando la aplicación se usa en una red externa.

Excluya de la inspección el tráfico con anclaje de certificados

La comunicación que hace anclaje de certificados (certificate pinning) falla en el momento en que el proxy sustituye el certificado. En componentes de Windows que validan certificados concretos de Microsoft y similares no hay esta vía de escape, y hace falta una configuración de exclusión.³

flowchart TB
    accTitle: Separar la distribución de la CA y la exclusión del tráfico con anclaje
    accDescr: En un error de certificado por inspección TLS se comprueba la confianza en la CA, pero en el tráfico con anclaje de certificados la propia sustitución es la causa del fallo, así que se excluye de la inspección
    failure["Error de validación de certificado"] --> pinned{"¿Certificado anclado?"}
    pinned -->|"Sí"| exclude["Excluir de la inspección"]
    pinned -->|"No"| store["Comprobar el almacén de confianza que se consulta"]
    store --> ca["Comprobar la distribución de la CA interna"]

Figura 15: Distribuir la CA interna y evitar la propia sustitución del certificado son remedios distintos.

Microsoft también recomienda excluir el tráfico hacia SaaS como Microsoft 365 del descifrado e inspección en la capa de red.⁸ Si los errores de certificado aparecen solo con servicios en la nube concretos, sospeche la combinación de la lista de exclusión de la inspección y el anclaje.

8. Procedimiento de aislamiento — Identificar al culpable en 5 pasos

En una investigación real, compruebe los mecanismos vistos hasta aquí en este orden.

(1) Reproducir: aunque la URL sea la misma, alinee también el sistema de configuración de la herramienta

Acceda a la URL que falla, si es posible desde la misma máquina y la misma cuenta. Preste atención también a las diferencias entre herramientas.

«curl pasa y la aplicación no» es una pista de que los sistemas de configuración no coinciden. El éxito con otra herramienta no basta para concluir que la aplicación tomó la misma ruta.

(2) Recoger la configuración: registrar los tres sistemas juntos

En PowerShell se pueden recoger así. El HKCU de la configuración por usuario es el de la cuenta que ejecutó este comando.

# (1) Configuración por usuario (WinINET) — atención a que lee el HKCU de la cuenta de ejecución
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
    Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

# (2) Configuración de máquina (WinHTTP)
netsh winhttp show proxy

# (3) Variables de entorno
Get-ChildItem env: | Where-Object Name -match 'proxy'

(3) Identificar la cuenta: si es un servicio, vuelva a comprobarlo con la misma cuenta

Identifique si el destino se ejecuta como servicio, desde el Programador de tareas o como otro usuario. Si es un servicio, repita la reproducción de (1) y la recogida de (2) con la misma cuenta. El éxito en la propia sesión de administrador no demuestra lo que ve LocalSystem.

flowchart TB
    accTitle: Reproducir alineando la cuenta de ejecución
    accDescr: Como la recogida en la sesión del administrador no demuestra la configuración visible desde el servicio, tras identificar la cuenta de ejecución de destino se vuelven a comprobar la reproducción y la recogida de configuración con esa cuenta
    admin["Comprobado en la sesión del administrador"] --> identify["Identificar la cuenta de ejecución de destino"]
    identify --> same["Reproducir y recoger con la misma cuenta"]
    same --> compare["Confrontar configuración y credenciales"]

Figura 16: Confirme que la información recogida en (1) y (2) es la vista desde la cuenta de destino identificada en (3).

(4) Clasificar el error: descomponer «no conecta»

Si es 407, compruebe la autenticación de proxy del capítulo 6; si es un error de certificado, la inspección TLS del capítulo 7. Si se agota el tiempo de espera, tome como primer candidato que no se está llegando al proxy, e investigue la ruta, la resolución de nombres y el firewall. Una denegación por directiva 403 también se separa de la autenticación y del tiempo de espera.

flowchart TB
    accTitle: Separar el destino de la investigación a partir del error
    accDescr: Dividir el fallo de comunicación en 407, 403, tiempo de espera o fallo de resolución de nombres, y error de certificado, e investigar respectivamente autenticación, denegación por directiva, ruta e inspección TLS
    error["Fallo de comunicación"] --> auth["Si es 407, autenticación de proxy"]
    error --> deny["Si es 403, denegación por directiva"]
    error --> route["Si es tiempo de espera o resolución de nombres, la ruta"]
    error --> tls["Si es error de certificado, TLS"]

Figura 17: Al separar por código de estado y excepción, se acotan la configuración y los registros que hay que comprobar.

El patrón en el que la causa es una regla de entrada del Firewall de Windows, y no el proxy, se trata en «El Firewall de Windows y las aplicaciones de negocio».

(5) Registro del proxy: confirmar la llegada y la cuenta autenticada

En el registro de acceso de la hora correspondiente, confirme si se llegó al proxy y como quién se autenticó. Si no hay rastro, trate la comunicación como que no llegó al proxy, e investigue un DIRECT del PAC, la lista de omisión y variables de entorno que quedaron olvidadas.

Si hace falta, confirme el destino real con una captura de paquetes. El método de captura está en «Captura de paquetes en Windows en la práctica — Cómo elegir entre pktmon, netsh trace y Wireshark».

9. Recomendaciones de diseño — Hacer del proxy una «aplicación configurable»

La facilidad de investigación cambia con los elementos de configuración y los registros de la aplicación. En una aplicación que se entrega a un entorno con proxy interno, prepare estos cuatro puntos.

No solo seguir el valor predeterminado: poder elegir también especificación explícita y conexión directa

Deje como valor predeterminado «seguir la configuración del SO» y, para los casos en que no se puede leer el PAC, se ejecuta como servicio o la configuración es especial, permita especificar desde un archivo de configuración la URL del proxy, la lista de omisión y «no usar proxy». Los puntos de implementación son HttpClientHandler.Proxy y UseProxy del apartado 5.3.¹¹

El valor predeterminado de .NET (Core en adelante) también incluye la prioridad de las variables de entorno explicada en el apartado 5.2. Aunque se deje al valor predeterminado, lea qué configuración se usa según esas reglas.

Deje las excepciones internas en una forma que quepa en la guía de implantación

Deje por escrito con cuál de DIRECT del PAC, la lista de omisión y NO_PROXY se excluye la comunicación interna hacia API, bases de datos, servidores de licencias y similares. Muestre, con ejemplos, que NO_PROXY no admite comodines y el significado del punto inicial.⁵

Diseñe también los tiempos de espera y los reintentos presuponiendo el paso por el proxy

Si se espera un tiempo de espera predeterminado largo ante una parada del proxy o una espera de autenticación, se congelan tanto la interfaz como la operación. Separe un tiempo de espera de conexión más corto y limite los reintentos a solicitudes idempotentes. Los detalles se tratan en «No hay que envolver HttpClient en un using».

Deje en el registro la ruta a partir del controlador realmente configurado

Si solo se registra HttpClient.DefaultProxy, se pasan por alto la especificación explícita del controlador y UseProxy = false, y se registra una ruta que no coincide. Es importante elegir la configuración efectiva a partir del controlador usado para crear el HttpClient, y reflejar también la determinación de omisión del destino.

using System.Net.Http;

// handler es la misma instancia usada para crear el HttpClient
// UseProxy=false siempre es conexión directa. Si hay especificación explícita se usa esa; si no, DefaultProxy
var effectiveProxy = handler.UseProxy
    ? handler.Proxy ?? HttpClient.DefaultProxy
    : null;
var target = new Uri("https://api.example.com/v1/orders");
var route = effectiveProxy is null || effectiveProxy.IsBypassed(target)
    ? "DIRECT"
    : effectiveProxy.GetProxy(target)?.ToString() ?? "DIRECT";
logger.LogInformation("Envío HTTP {Target} ruta {Route} cuenta de ejecución {User}",
    target, route, Environment.UserName);

flowchart TB
    accTitle: Registrar la ruta a partir de la configuración del cliente de comunicación
    accDescr: Elegir el proxy efectivo a partir del controlador usado para crear el HttpClient, realizar la determinación de omisión del destino y la resolución del proxy, y registrar la ruta y la cuenta de ejecución
    handler["El mismo controlador que en la creación"] --> effective["Reflejar UseProxy y la especificación explícita"]
    effective --> target["Determinación de omisión y resolución del destino"]
    target --> log["Registrar la ruta y la cuenta"]

Figura 18: Registre la ruta a partir de la configuración del propio cliente, no solo del proxy predeterminado.

Si al iniciar se registran la ruta hacia los destinos principales y la cuenta de ejecución, resulta más fácil seguir los pasos (1) a (3) del capítulo 8. Cuando le digan «pero en el navegador sí conecta», un diseño resistente a la investigación es aquel en el que la aplicación puede explicar su propia configuración y su ruta.

10. Resumen

En una investigación de proxy de Windows, primero alinee el sistema de configuración, la cuenta de ejecución y la URL de destino.

La configuración por usuario de WinINET, la configuración de máquina de WinHTTP y las variables de entorno son sistemas distintos. Al convertirse en servicio cambian la configuración visible y las credenciales, y el orden predeterminado también difiere entre .NET Framework y .NET (Core en adelante). netsh winhttp set proxy por sí solo no trata PAC, detección automática ni autenticación.

El PAC devuelve un proxy o DIRECT por URL, y WPAD necesita el mecanismo en el lado de la red. Aunque la ruta ya esté decidida, la autenticación de proxy del 407 y la validación de certificados por inspección TLS se comprueban por separado. No desactive la validación de certificados; distribuya la CA y excluya el tráfico con anclaje.

El aislamiento sigue el orden reproducir → recoger los tres sistemas de configuración → identificar la cuenta de ejecución → clasificar el error → registro del proxy. En el lado de la aplicación, prepare especificación explícita del proxy y conexión directa, configuración de excepciones, tiempos de espera y registro de la ruta.

La próxima vez que le consulten «solo la aplicación de negocio no conecta», empiece por confirmar esto.

Esa aplicación, ¿con la cuenta de quién se ejecuta y cuál de los tres sistemas de configuración de proxy lee?

Esa sola pregunta es la entrada a la investigación.

Artículos relacionados

• No hay que envolver HttpClient en un using — Comunicación HTTP práctica en aplicaciones de negocio en C# (patrones de creación, tiempos de espera, reintentos)
• Captura de paquetes en Windows en la práctica — Cómo elegir entre pktmon, netsh trace y Wireshark
• El Firewall de Windows y las aplicaciones de negocio — Registrar las reglas de entrada desde el instalador
• Cómo crear y operar servicios de Windows — De la diferencia con el Programador de tareas a convertir un BackgroundService en servicio
• NTLM y Kerberos explicados con diagramas — Por qué la autenticación «cae» a NTLM
• Guía práctica del almacén de certificados de Windows — Usuario o equipo, ¿dónde hay que ponerlo?

Ámbitos de consulta relacionados

En KomuraSoft LLC tratamos la investigación de fallos de comunicación de aplicaciones Windows en entornos con proxy interno, proxy con autenticación e inspección TLS, como «en el equipo de desarrollo funciona, pero en la red del cliente no comunica» o «al convertirlo en servicio dejó de alcanzar la API externa», y también la consulta sobre el diseño de comunicación de aplicaciones de negocio que presuponen un entorno de proxy (elementos de configuración, tiempos de espera y diseño de registros). Basta con empezar por ordenar el procedimiento de reproducción y el método de recogida de registros.

• Desarrollo de aplicaciones Windows
• Investigación de fallos y análisis de causas
• Consulta técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

El navegador conecta, pero solo la aplicación de negocio no puede atravesar el proxy interno. ¿Por qué?

El navegador lee la configuración de proxy por usuario de WinINET, pero la aplicación de negocio no necesariamente lee la misma configuración. Una aplicación que se ejecuta como servicio de Windows o con otra cuenta consulta la configuración visible desde esa cuenta, la configuración de máquina de WinHTTP o las variables de entorno. Primero identifique la cuenta de ejecución y compruebe la configuración de proxy visible desde esa cuenta tanto con netsh winhttp show proxy como en la configuración de usuario. Si puede reproducir el problema con curl.exe u otra herramienta usando la misma cuenta y la misma máquina, se trata de una discrepancia entre sistemas de configuración y no de un problema propio de la aplicación.

Configuré netsh winhttp set proxy, pero la comunicación de la aplicación no cambia. ¿Por qué?

netsh winhttp configura el valor predeterminado de máquina de WinHTTP, y no afecta a los navegadores ni a las aplicaciones interactivas que leen WinINET, ni al HttpClient de .NET (Core en adelante), que prioriza las variables de entorno. Además, netsh winhttp set proxy es una configuración estática que no trata la configuración automática mediante PAC, la detección automática ni la autenticación de proxy. Primero hay que confirmar con qué pila HTTP trabaja la aplicación en cuestión y de qué sistema de configuración resuelve el proxy.

¿Qué configuración de proxy leen las aplicaciones .NET?

.NET Framework usa de forma predeterminada la configuración de Opciones de Internet (equivalente a WinINET) de la cuenta en ejecución, y se puede sobrescribir con el elemento system.net/defaultProxy de app.config. El HttpClient de .NET (Core en adelante) lee primero variables de entorno como HTTP_PROXY, HTTPS_PROXY y NO_PROXY, y si no están definidas recurre a la configuración de proxy de usuario de Windows. En ambos casos, si se especifica de forma explícita con HttpClientHandler.Proxy, esa especificación tiene la máxima prioridad. Es decir, el orden de resolución predeterminado difiere entre Framework y Core en adelante, por lo que al migrar conviene volver a comprobar el comportamiento del proxy.

¿Qué se debe comprobar cuando aparece 407 Proxy Authentication Required?

El 407 es una señal de que el propio proxy exige autenticación, algo distinto de un error de autenticación del servidor de destino (401). Primero confirme, mediante la cabecera Proxy-Authenticate, qué método de autenticación exige el proxy (Negotiate, NTLM, Basic), y en .NET pase las credenciales con HttpClientHandler.DefaultProxyCredentials o WebProxy.UseDefaultCredentials. En aplicaciones que se ejecutan con una cuenta de servicio, las «credenciales predeterminadas» pasan a ser las de esa cuenta de servicio, por lo que es típico que algo funcione con un usuario interactivo pero devuelva 407 en cuanto se convierte en servicio. Compruebe también, en los registros del propio proxy, con qué identidad se autenticó.

Con un proxy de inspección TLS obtengo errores de certificado. ¿Puedo desactivar la validación de certificados?

No se recomienda desactivarla. Un proxy de inspección TLS descifra la comunicación y presenta al cliente un certificado re-firmado por su propia CA, de modo que si esa CA no está en las entidades de confianza, se produce un error de validación. La solución correcta es distribuir el certificado de la CA interna al almacén de certificados de Windows (normalmente Entidades de certificación raíz de confianza del equipo local). Desactivar la validación en el código impide detectar ataques de intermediario cuando la aplicación se usa fuera de la red de la empresa, y deja una vulnerabilidad permanente.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.