Proxy d'entreprise et applications Windows — démêler la résolution de proxy dans WinINET, WinHTTP et .NET

« Le navigateur ouvre les sites externes, mais seule l’application métier n’atteint pas l’API externe. » « Cela marche sur la machine de développement, mais expire sur le réseau du client. » « Cela communique quand je l’exécute à la main, et échoue dès que j’en fais un service Windows. » — Lorsque vous faites tourner une application métier dans un environnement avec un proxy d’entreprise, ce type de consultation est parmi les plus fréquents.

Dans la plupart des cas, la cause n’est ni une panne du serveur proxy, ni un bogue de l’application. Windows a plusieurs familles distinctes de ce que l’on appelle « réglages de proxy », et quels réglages qui lit dépend de l’application (de la pile HTTP qu’elle utilise) et du compte d’exécution — ce décalage. Les réglages que lit le navigateur, ceux qu’un service lit, et ceux que HttpClient de .NET lit peuvent chacun être une chose différente. Une fois cette structure en tête, isoler « cela marche dans le navigateur, mais… » devient étonnamment rapide.

Cet article s’adresse au personnel informatique des PME et aux développeurs d’applications Windows. Il relie, en une seule image, les trois familles de réglages de proxy — WinINET, WinHTTP et les variables d’environnement —, l’autoconfiguration PAC et WPAD, la différence de résolution de proxy entre .NET Framework et .NET (Core et suivants), les proxys authentifiants (407), l’inspection TLS, et la procédure d’isolement pratique. Les modèles de création de HttpClient et la conception des délais d’expiration eux-mêmes sont traités dans « N’enfermez pas HttpClient dans un using », de sorte que cet article se concentre sur la résolution de proxy.

1. La conclusion d’abord

• Les réglages de proxy Windows ne sont pas une seule chose ; il y a au moins trois familles. (1) Les réglages WinINET par utilisateur (la page « Proxy » de l’application Paramètres = les anciennes Options Internet), (2) les réglages machine WinHTTP (netsh winhttp), et (3) les variables d’environnement HTTP_PROXY / HTTPS_PROXY. Celle qui est lue se décide côté application.¹²
• Le « Proxy » que vous voyez dans l’application Paramètres, ce sont les réglages par utilisateur de WinINET. Les navigateurs et les applications interactives les lisent ; les services Windows non. WinINET n’est pas pris en charge dans un service ; l’usage service est le travail de WinHTTP.¹³
• La cause la plus fréquente de « cela marche à la main mais pas en service » est une différence de compte d’exécution. LocalSystem et un compte de service ne voient pas le proxy par utilisateur qu’un administrateur a configuré sur son propre écran.³⁴
• netsh winhttp set proxy est un réglage statique ; il ne gère ni PAC, ni la détection automatique, ni l’authentification proxy. Si vous voulez configurer PAC ou WPAD par machine, il vous faut le côté netsh winhttp set advproxy.⁴²
• Les résultats PAC changent par URL. La fonction FindProxyForURL du fichier PAC prend une URL et un hôte et renvoie une liste de proxys ou une connexion directe (DIRECT). « Ce site marche, mais seule cette API ne marche pas » peut être une branche PAC.⁵⁶
• HttpClient sur .NET (Core et suivants) initialise le proxy par défaut dans l’ordre variables d’environnement → réglages de proxy utilisateur Windows. Si l’une de HTTP_PROXY, HTTPS_PROXY ou ALL_PROXY est définie, elle a priorité sur les réglages de l’OS, d’où l’accident « quelqu’un a laissé une variable d’environnement ».⁷
• Le défaut de .NET Framework, ce sont les Options Internet du compte d’exécution, et vous pouvez le remplacer par defaultProxy dans app.config. Les réglages du fichier de configuration ont priorité sur les réglages système.⁸⁹
• Le 407 est une erreur d’authentification proxy ; c’est autre chose qu’un 401 (authentification serveur). Les schémas incluent Negotiate, NTLM et Basic, et dans .NET vous passez les informations d’identification avec DefaultProxyCredentials ou WebProxy.UseDefaultCredentials. Attention au fait que sous un compte de service, le contenu des « informations d’identification par défaut » change.¹⁰¹¹¹²
• Un proxy d’inspection TLS ne tient que comme un ensemble avec le déploiement du certificat CA interne. Les machines et runtimes qui ne l’ont pas reçu ont une erreur de validation de certificat. Résolvez-la en déployant dans le magasin de certificats, pas en désactivant la validation dans l’application.¹³⁴

En une phrase : chaque fois que vous dites « j’ai vérifié les réglages de proxy », soyez toujours capable de dire laquelle des trois familles vous avez vérifiée, et depuis quel compte — tel est le sujet de cet article.

2. Windows a trois familles de « réglages de proxy »

D’abord, la carte d’ensemble. Les chemins qu’une application Windows utilise pour trouver un proxy d’entreprise tombent dans ces trois familles.

(1) est ce que les gens reconnaissent généralement comme « les réglages de proxy Windows » ; la substance est la configuration WinINET. Historiquement, ce sont les Options Internet d’Internet Explorer, et par défaut elles sont stockées par utilisateur.⁴

(2) est le défaut par machine pour des contextes comme un service où « il n’y a pas d’utilisateur connecté ». (3) est surtout la convention des outils venus du monde multiplateforme ; sur Windows, .NET (Core et suivants) et curl, entre autres, les lisent aussi.⁷

Le point important est que quelle famille est lue se décide côté application, pas côté réglages. Si l’application utilise WinINET en interne, elle lit (1) ; si WinHTTP, (2) (ou un remplacement propre à l’application) ; si .NET (Core et suivants), (3) puis (1). Ce n’est donc en général pas « les réglages de proxy sont corrects mais cela ne se connecte toujours pas » ; la réalité est « la famille que l’application lit était une famille différente de celle que vous avez vérifiée ».

flowchart TB
    accTitle: Trois familles de réglages de proxy Windows
    accDescr: WinINET, ce sont les Paramètres et Options Internet par utilisateur, WinHTTP le défaut machine via netsh, et les variables d'environnement sont à portée de processus. Quelle famille est lue se décide par l'application, pas par le côté réglages
    fam{"Quelle famille ?"}
    fam --> wininet["Réglages WinINET par utilisateur"]
    fam --> winhttp["Réglages machine WinHTTP"]
    fam --> env["HTTP_PROXY et consorts"]
    wininet -.-> r1["Navigateurs et apps de bureau"]
    winhttp -.-> r2["Services et parties de l'OS"]
    env -.-> r3[".NET Core+ et curl"]

Figure 1 : Trois familles côte à côte. L’application choisit celle qu’elle lit.

Si vous activez la stratégie de groupe « Rendre les réglages de proxy par machine (plutôt que par utilisateur) », vous pouvez basculer (1) en par machine et appliquer les mêmes réglages à chaque utilisateur. Avec MDM (Intune et similaires), vous pouvez le configurer par appareil avec le CSP NetworkProxy.⁴

3. WinINET et WinHTTP — pour les applications interactives et pour les services

3.1. La différence de rôles

WinINET et WinHTTP sont toutes deux des piles clientes HTTP livrées avec Windows, mais elles supposent des usages différents.

• WinINET : visée pour les applications de bureau interactives. Elle hérite automatiquement des Options Internet de l’utilisateur (proxy, cookies, cache d’informations d’identification) et peut même afficher une interface de saisie si besoin. L’usage dans un service ou un processus de type service n’est pas pris en charge.¹
• WinHTTP : visée pour les services et le côté serveur. Elle prend en charge l’exécution sous un compte de service, l’emprunt d’identité de thread et l’isolation de session ; en échange, elle ne partage ni les réglages du navigateur de l’utilisateur, ni les cookies, ni les informations d’identification. Elle n’affiche pas non plus d’interface.³

Le guidage de Microsoft lui-même est tout aussi net : « utilisez WinINET sauf si vous tournez à l’intérieur d’un service, ou dans un processus de type service qui a besoin d’isolation de session et d’emprunt d’identité » — autrement dit, s’il s’agit d’un service, utilisez WinHTTP.¹

flowchart TB
    accTitle: WinINET pour les apps interactives, WinHTTP pour les services
    accDescr: WinINET hérite des Options Internet de l'utilisateur connecté et n'est pas prise en charge dans un service. WinHTTP tourne sous un compte de service sans interface et ne partage pas les réglages du navigateur de l'utilisateur
    q{"Application de bureau interactive ?"}
    q -->|"Oui"| ie["WinINET"]
    q -->|"Service ou type service"| wh["WinHTTP"]
    ie -.-> ieNote["Lit les Options Internet de l'utilisateur"]
    wh -.-> whNote["Réglages machine, pas d'interface"]

Figure 2 : Les applications interactives utilisent WinINET. Un service utilise WinHTTP.

3.2. Opérations de base de netsh winhttp

Le proxy par défaut machine de WinHTTP s’opère avec netsh.²

:: Display the current WinHTTP proxy settings
netsh winhttp show proxy

:: Set a static proxy (with a bypass list)
netsh winhttp set proxy proxy-server="proxy.example.co.jp:8080" bypass-list="*.example.co.jp;<local>"

:: Import the Internet Options (WinINET) settings
netsh winhttp import proxy source=ie

:: Return to the default (DIRECT)
netsh winhttp reset proxy

Deux contraintes à garder en tête ici.

1. netsh winhttp set proxy est un réglage statique. Il ne gère ni la détection automatique de proxy, ni la spécification d’une URL PAC, ni l’authentification proxy.⁴
2. import proxy source=ie ne copie que les réglages statiques de cet instant ; il ne suit pas les changements ultérieurs côté Options Internet. Lorsque vous avez besoin d’une configuration par machine qui inclut PAC ou la détection automatique, configurez les réglages détaillés au format JSON (Proxy, ProxyBypass, AutoconfigUrl, AutoDetect) avec netsh winhttp set advproxy.²

3.3. Le piège le plus fréquent : un service ne lit pas les réglages IE de l’utilisateur

Le schéma que l’on voit le plus souvent sur le terrain, dans l’ordre du temps, ressemble à ceci.

1. Un développeur exécute l’outil sur son propre PC → ses réglages de proxy par utilisateur (1) prennent effet et cela marche
2. En production, on le laisse résident en service Windows (Comment créer et exploiter un service Windows) sous LocalSystem
3. Les réglages visibles depuis LocalSystem sont une autre chose (les réglages par utilisateur sont invisibles, et les réglages machine WinHTTP sont non configurés = DIRECT) → il tente une connexion directe à l’API externe et expire

Ce n’est pas « cela ne marche pas alors que c’est la même machine » ; même sur la même machine, un compte d’exécution différent signifie qu’un ensemble différent de réglages de proxy est visible. Pour un processus qui communique même lorsqu’aucun utilisateur n’est connecté, l’approche juste est de préparer des réglages par machine sous la forme que la pile HTTP de ce processus lit réellement. Pour une application native ou un composant Windows qui utilise WinHTTP, les réglages WinHTTP de netsh prennent effet.⁴ HttpClient sur .NET (Core et suivants), en revanche, ne lit pas les réglages machine de WinHTTP (voir le chapitre 5), donc pour un service .NET vous définissez une variable d’environnement système (HTTPS_PROXY et similaires) ou vous spécifiez HttpClientHandler.Proxy explicitement depuis les réglages de l’application.

L’accident arrive aussi dans l’autre sens. Si vous gravez un proxy statique dans un portable qui circule entre le réseau d’entreprise et l’extérieur avec netsh winhttp set proxy, ce proxy est injoignable hors de l’entreprise et la communication meurt entièrement. Traitez un réglage statique machine comme un moyen visé pour des serveurs dont la configuration réseau ne change pas.⁴

flowchart TB
    accTitle: Pourquoi un service ne voit pas les réglages IE de l'utilisateur
    accDescr: Une exécution développeur lit les réglages WinINET par utilisateur et marche. Sous LocalSystem ces réglages sont invisibles. Une app WinHTTP native suit alors les réglages machine non configurés (DIRECT). Un service .NET Core+ utilise encore les variables d'environnement ou un handler.Proxy explicite et ne bascule pas vers netsh winhttp
    dev["Exécution à la main comme l'utilisateur"] --> ok["Les réglages WinINET par utilisateur s'appliquent"]
    svc["Service Windows sous LocalSystem"] --> miss["Les réglages par utilisateur sont invisibles"]
    miss --> stack{"Quelle pile HTTP ?"}
    stack -->|"WinHTTP"| direct["WinHTTP non configuré = DIRECT"]
    stack -->|".NET Core+"| env["Variables d'env. ou handler.Proxy"]
    direct --> fail["L'API externe expire"]

Figure 3 : La même machine, un compte différent, un ensemble différent de réglages de proxy visibles.

4. PAC et WPAD — ce qu’est réellement l’« autoconfiguration »

4.1. Fichiers PAC et FindProxyForURL

Un fichier PAC (Proxy Auto-Configuration) est du JavaScript (ECMAScript) qui calcule « quel proxy utiliser pour cette URL », et il contient toujours une fonction nommée FindProxyForURL(url, host). La fonction renvoie une liste de proxys à utiliser, ou une valeur de retour spéciale (DIRECT) signifiant qu’il est correct de se connecter directement sans proxy.⁵

function FindProxyForURL(url, host) {
    // Internal domains and private addresses go direct
    if (dnsDomainIs(host, ".example.co.jp") ||
        isInNet(host, "10.0.0.0", "255.0.0.0")) {
        return "DIRECT";
    }
    // Everything else goes through a proxy. Fall back to the next if the first is unavailable
    return "PROXY proxy1.example.co.jp:8080; PROXY proxy2.example.co.jp:8080; DIRECT";
}

Deux conséquences pratiques en découlent.

• La résolution de proxy doit se faire par URL. Parce que PAC peut renvoyer un proxy différent ou une connexion directe selon l’URL (l’hôte), la fonctionnalité de proxy automatique de WinHTTP est aussi conçue pour passer l’URL de la requête et interroger à chaque fois.⁶ « Le navigateur voit un autre site » n’est pas une preuve que l’API en cause emprunte le même chemin.
• DIRECT est une instruction de « y aller sans proxy ». Si le trafic qui devrait être interne n’apparaît jamais dans le journal du proxy, suspectez d’abord que PAC a renvoyé DIRECT (ou qu’il a correspondu à une liste de contournement).

4.2. Détection automatique via WPAD

Activez « Détecter automatiquement les paramètres » et la machine cherche l’emplacement du fichier PAC avec le protocole WPAD (Web Proxy Auto-Discovery). Dans une configuration typique, DHCP distribue une URL PAC, ou DNS sert à rechercher un hôte nommé wpad et le PAC est téléchargé depuis une URL telle que http://wpad/wpad.dat.¹⁴

Autrement dit, la « détection automatique » n’est pas magique ; c’est un mécanisme qui ne fonctionne que sur un réseau qui a déjà mis en place un dispositif WPAD dans DHCP/DNS. Activer la détection automatique seule sur un réseau sans un tel dispositif n’ajoute que du temps d’attente pour un échec de détection.

flowchart TB
    accTitle: PAC résout un proxy par URL, WPAD ne trouve que le PAC
    accDescr: FindProxyForURL prend une URL et un hôte et renvoie une liste de proxys ou DIRECT. WPAD ne localise le PAC que via DHCP ou DNS. Un client qui ne peut pas évaluer PAC retombe sur un proxy statique ou des variables d'environnement
    url["URL de la requête"] --> pac["FindProxyForURL"]
    pac -->|"liste de proxys"| via["Passer par un proxy"]
    pac -->|"DIRECT"| dir["Se connecter sans proxy"]
    wpad["WPAD via DHCP ou DNS"] -.-> pac
    nopac["Client incapable d'évaluer PAC"] -.-> fb["Réglages statiques ou variables d'env."]

Figure 4 : PAC décide par URL. WPAD ne trouve que le fichier PAC.

4.3. Comment se comportent les clients qui ne peuvent pas évaluer PAC

Tous les clients ne peuvent pas évaluer PAC.

• Les réglages statiques de netsh winhttp set proxy n’évaluent pas PAC.⁴
• Les outils qui utilisent le style variable d’environnement HTTP_PROXY ne peuvent, en règle générale, qu’écrire une URL de proxy fixe (il n’y a nulle part où écrire une URL PAC).⁷
• Pour une application native qui utilise WinHTTP directement, cela dépend de la façon dont la session est ouverte. Une application ouverte avec WinHttpOpen sous Windows 8.1 et suivants en spécifiant WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY a WinHTTP qui résout automatiquement les réglages de proxy système/utilisateur (y compris WPAD/PAC) par requête.¹⁵ Si elle est ouverte avec l’ancien WINHTTP_ACCESS_TYPE_DEFAULT_PROXY (déprécié à partir de 8.1) ou similaire, le proxy automatique n’est pas intégré à la pile HTTP, et l’application doit appeler elle-même WinHttpGetProxyForUrl et appliquer le résultat à la requête. Autrement dit, sur une implémentation plus ancienne, PAC peut être présent et rester inutilisé.⁵

« Le navigateur va au bon proxy via PAC, mais l’application métier ne lit pas PAC et tente une connexion directe et échoue » — c’est un autre décalage classique. Sur un réseau opéré en PAC, il faut décider d’un repli — réglages statiques ou variables d’environnement — pour les clients qui ne peuvent pas lire PAC.

5. Résolution de proxy .NET — Framework et Core et suivants sont des choses différentes

Quels réglages de proxy une application .NET lit diffère par défaut entre .NET Framework et .NET (Core et suivants). Confondez les deux et vous enquêterez sur une application .NET 8 avec des connaissances de l’ère Framework et vous manquerez.

5.1. .NET Framework — le défaut, ce sont les Options Internet, remplacées par defaultProxy

Sous .NET Framework, HttpWebRequest et le HttpClient qui s’assoit dessus utilisent le proxy par défaut à moins que vous ne spécifiiez Proxy explicitement. Le proxy par défaut est décidé par une combinaison des réglages Internet du système (les réglages WinINET du compte d’exécution) et du fichier de configuration, et les réglages du fichier de configuration ont la priorité.⁸

Vous pouvez contrôler ce défaut avec l’élément system.net/defaultProxy dans app.config (ou machine.config).⁹

<configuration>
  <system.net>
    <!-- useDefaultCredentials: whether to send default credentials to an authenticating proxy -->
    <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>

Laissez l’élément defaultProxy vide et les réglages système (Options Internet) sont utilisés ; écrivez proxyaddress et similaires et ceux-là ont la priorité. Depuis le programme, vous pouvez remplacer le même défaut avec WebRequest.DefaultWebProxy.⁹⁸

Le piège du chapitre 3.3 s’applique ici aussi. Parce que le défaut est « les Options Internet du compte d’exécution », une application .NET Framework qui tourne sous un compte de service lit un ensemble de réglages différent (souvent vide) de ceux visibles sur le bureau de l’administrateur.

5.2. .NET (Core et suivants) — les variables d’environnement d’abord, puis les réglages utilisateur de l’OS

HttpClient sur .NET (Core et suivants) a une propriété statique HttpClient.DefaultProxy. À moins qu’un gestionnaire ne spécifie un proxy explicitement, chaque instance HttpClient l’utilise. La règle d’initialisation sous Windows est « lire les variables d’environnement, et si elles ne sont pas définies, lire les réglages de proxy utilisateur ».⁷

Les variables d’environnement utilisées sont les suivantes.⁷

Trois choses à surveiller.

• Si l’une de HTTP_PROXY, HTTPS_PROXY ou ALL_PROXY est définie, elle a priorité sur les réglages de proxy côté OS. Définir seulement NO_PROXY ne configure pas un proxy depuis les variables d’environnement, et sous Windows les réglages de proxy utilisateur de l’OS continuent d’être utilisés. Des « réglages invisibles » tels que laisser HTTPS_PROXY comme variable d’environnement système après une ancienne expérience, ou un modèle CI/CD qui l’injecte, sont un terreau d’accidents.
• NO_PROXY ne prend pas en charge les jokers (*). Pour correspondre à un sous-domaine, placez un point initial (.example.com correspond à www.example.com mais pas à example.com lui-même).⁷
• Hors Windows (conteneurs Linux et similaires), si les variables d’environnement sont indéfinies, c’est initialisé sans proxy. Le comportement par défaut de la même application qui change entre Windows et Linux est quelque chose à confirmer au moment d’une migration vers conteneur.⁷

5.3. Spécification explicite — HttpClientHandler.Proxy et UseProxy

Sur l’un ou l’autre runtime, la priorité la plus haute est une spécification explicite sur le gestionnaire. Spécifier HttpClientHandler.Proxy a priorité sur les réglages de l’OS et le fichier de configuration, et UseProxy = false n’utilise aucun proxy.¹⁴

using System.Net;

// Use a proxy read from app settings explicitly
var handler = new HttpClientHandler
{
    Proxy = new WebProxy("http://proxy.example.co.jp:8080")
    {
        BypassProxyOnLocal = true,
        BypassList = new[] { @"^intra\.example\.co\.jp$" },
        UseDefaultCredentials = true // On an authenticating proxy, respond with the running account's credentials
    },
    UseProxy = true
};
var client = new HttpClient(handler);

// A client that never uses a proxy (for direct internal APIs)
var directHandler = new HttpClientHandler { UseProxy = false };
var directClient = new HttpClient(directHandler);

Lorsqu’il n’y a pas de spécification explicite et que l’on suit les réglages de l’OS, le contournement automatique des destinations locales a des règles. Un nom plat sans point, une adresse de bouclage, une destination qui correspond au suffixe de domaine de la machine elle-même, et similaires, peuvent être traités comme « locaux ».¹⁴ Des phénomènes tels que « le comportement change si je spécifie une adresse IP » ou « cela a soudain commencé à passer par le proxy quand j’ai utilisé un FQDN » peuvent être causés par ce jugement.

L’ordre de priorité est le suivant.

flowchart TB
    accTitle: Résolution de proxy par défaut dans Framework versus Core et suivants
    accDescr: Un HttpClientHandler.Proxy explicite gagne toujours. Framework utilise ensuite app.config defaultProxy et les Options Internet du compte d'exécution. Core et suivants utilise une affectation à HttpClient.DefaultProxy, puis les variables d'environnement, puis les réglages de proxy utilisateur Windows
    expl["handler.Proxy explicite"] --> done["Ce proxy est utilisé"]
    noexpl["Pas de Proxy explicite"] --> fw{"Quel runtime ?"}
    fw -->|"Framework"| cfg["app.config defaultProxy"]
    cfg --> ie["Options Internet du compte"]
    fw -->|"Core et suivants"| dp["HttpClient.DefaultProxy"]
    dp --> ev["HTTP_PROXY et consorts"]
    ev --> user["Réglages proxy utilisateur Windows"]

Figure 5 : La spécification explicite gagne toujours. Le chemin par défaut diffère selon le runtime.

6. Proxys authentifiants — le 407 est l’erreur d’authentification du proxy

6.1. Ne confondez pas 407 et 401

Lorsque vous tentez de passer par un proxy qui exige une authentification, le proxy renvoie le code d’état 407 (Proxy Authentication Required) et un en-tête Proxy-Authenticate listant les schémas disponibles. C’est autre chose que l’exigence d’authentification du serveur de destination (401 et WWW-Authenticate) ; la partie à qui vous remettez les informations d’identification et l’endroit où vous les configurez sont tous deux différents.¹⁰

flowchart TB
    accTitle: 407 c'est le proxy, 401 c'est le serveur de destination
    accDescr: 407 et Proxy-Authenticate viennent du proxy. 401 et WWW-Authenticate viennent du serveur de destination. Les informations d'identification et l'endroit où on les configure diffèrent
    req["Requête sortante"] --> who{"Qui exige l'authentification ?"}
    who -->|"Le proxy"| e407["407 + Proxy-Authenticate"]
    who -->|"La destination"| e401["401 + WWW-Authenticate"]
    e407 -.-> cred["DefaultProxyCredentials"]

Figure 6 : 407, c’est l’authentification proxy. 401, c’est l’authentification serveur.

Les schémas incluent Basic, qui envoie le nom d’utilisateur et le mot de passe tels quels, et les schémas défi/réponse tels que Negotiate (Kerberos/NTLM). Dans un schéma défi/réponse, le mot de passe lui-même ne voyage pas sur le réseau, et l’authentification s’achève en plusieurs échanges.¹⁰ Le mécanisme du schéma vers lequel il « retombe » est traité plus en détail dans « NTLM et Kerberos expliqués en images ».

6.2. Comment passer les informations d’identification dans .NET

Lorsque vous voulez utiliser le proxy par défaut issu des réglages de l’OS et seulement faire passer l’authentification, utilisez HttpClientHandler.DefaultProxyCredentials. Ce sont les informations d’identification envoyées à ce proxy par défaut lorsque UseProxy = true et Proxy = null (= le proxy par défaut du système).¹¹

using System.Net;

var handler = new HttpClientHandler
{
    UseProxy = true,   // The default. Combined with a null Proxy, this uses the system-default proxy
    Proxy = null,
    // Respond to 407 with the credentials of the running account (signed-in user or service account)
    DefaultProxyCredentials = CredentialCache.DefaultCredentials
};
var client = new HttpClient(handler);

Lorsque vous spécifiez le proxy explicitement, placez les informations d’identification du côté WebProxy. Dans de nombreux scénarios clients, la recommandation est d’utiliser les informations d’identification par défaut de l’utilisateur connecté plutôt qu’un nom d’utilisateur et un mot de passe individuels, et WebProxy.UseDefaultCredentials = true est cela.¹²

6.3. Le problème 407 du compte de service

Le compte d’exécution compte ici aussi. « Informations d’identification par défaut » signifie les informations d’identification du compte qui exécute ce processus. Exécutez-le en utilisateur interactif et l’authentification auprès du proxy se fait en tant que cet utilisateur ; exécutez-le en service LocalSystem et c’est en tant que compte ordinateur.

• Si le proxy authentifie les utilisateurs via Active Directory, il ne peut pas authentifier un compte ordinateur ou un compte local, et le 407 continue dès que vous transformez l’application en service
• À l’inverse, certains environnements ont une exemption d’authentification côté proxy pour les services (par IP source ou par compte)

Donc une enquête 407 ne se referme pas sur « les réglages de l’application » seuls ; c’est un ensemble avec une vérification de conception côté infrastructure : le proxy peut-il authentifier le compte d’exécution. Pour une application que vous transformerez en service, vous devriez décider à la conception de l’un de : la faire tourner sous un compte de service de domaine (gMSA et similaires), poser une exemption d’authentification côté proxy, ou dresser un proxy relais interne qui n’exige pas d’authentification.

Il existe aussi un style qui embarque les informations d’identification dans une variable d’environnement, comme HTTP_PROXY=http://user:pass@proxy:8080⁷, mais un mot de passe en clair est alors exposé dans une variable d’environnement (= information de processus), ce qui n’est pas recommandé pour une exploitation permanente.

7. HTTPS et les proxys — tunnels CONNECT et inspection TLS

7.1. HTTPS passe par un proxy comme un « tunnel »

Lorsque vous utilisez un proxy pour HTTPS, le client envoie d’abord au proxy une requête CONNECT destination-host:443, et le proxy ouvre un tunnel TCP. En cas de succès, le proxy renvoie 200, et ensuite le client et le serveur de destination effectuent la poignée de main TLS à l’intérieur de ce tunnel. Si le tunnel ne s’ouvre pas, le proxy renvoie 407 (authentification requise), 502, ou similaire.¹⁶

Dans ce modèle, le proxy ne peut pas lire le contenu du tunnel (HTTPS chiffré). Ce qui reste dans le journal du proxy, c’est le nom d’hôte de destination et si la connexion a réussi ; le chemin d’URL n’est pas visible — c’est le comportement d’un proxy « pass-through ».

flowchart TB
    accTitle: HTTPS via un proxy est un tunnel CONNECT
    accDescr: Le client envoie CONNECT au proxy, le proxy ouvre un tunnel TCP et renvoie 200, puis le client et la destination font la poignée de main TLS dans le tunnel. Le journal du proxy voit l'hôte, pas le chemin d'URL
    cli["Client"] -->|"CONNECT host:443"| px["Proxy"]
    px -->|"200 et un tunnel TCP"| dest["Destination"]
    dest -->|"TLS dans le tunnel"| cli
    px -.-> log["Journal : hôte et succès seulement"]

Figure 7 : Un proxy pass-through voit l’hôte, pas le chemin chiffré.

7.2. Proxys d’inspection TLS et erreurs de certificat

Les proxys de produits de sécurité, en revanche, incluent un type d’inspection TLS (déchiffrement SSL, break and inspect) qui termine TLS, inspecte le contenu, et rechiffre avant de transférer. Dans ce schéma, le certificat serveur présenté au client n’est pas le vrai ; il est remplacé par un certificat resigné par la propre CA du proxy.¹³

La prémisse qui fait tenir cette configuration est donc « le certificat CA du proxy a été déployé dans les racines de confiance de chaque client ». Sur une machine qui ne l’a pas reçu, ou dans un runtime qui ne regarde pas le magasin de certificats Windows (outils avec leur propre magasin de confiance), vous avez une erreur de validation de certificat. Dans .NET, cela apparaît typiquement comme une HttpRequestException enveloppant une AuthenticationException (un message du genre « the remote certificate is invalid »).

Les principes de la correction sont les suivants.

• Déployez le certificat CA interne dans le magasin « Autorités de certification racines de confiance » de l’ordinateur local. La scission entre magasin utilisateur et magasin ordinateur est traitée dans « Guide pratique du magasin de certificats Windows ».
• Ne désactivez pas la validation de certificat dans le code. Un contournement qui renvoie toujours true depuis ServerCertificateCustomValidationCallback devient une application vulnérable qui ne peut pas détecter un homme du milieu dès qu’elle sort sur un réseau extérieur.
• Le trafic avec épinglage de certificat ne peut pas être inspecté pour commencer. Les connexions qui vérifient un certificat Microsoft spécifique, comme le font certains composants Windows, échouent dès que le proxy échange le certificat, et il n’y a pas d’autre contournement qu’une exclusion.⁴ Pour le trafic destiné à des SaaS tels que Microsoft 365, Microsoft lui-même recommande de l’exclure du déchiffrement et de l’inspection en couche réseau.¹³

Un symptôme du type « tous les sites internes sont visibles, mais seul un service cloud particulier produit une erreur de certificat dans l’application » devrait d’abord vous faire suspecter la combinaison de la liste d’exclusion d’inspection TLS et de l’épinglage.

flowchart TB
    accTitle: Un proxy d'inspection TLS resigne le certificat
    accDescr: Le proxy termine TLS, inspecte le contenu, et présente un certificat resigné par sa propre CA. La validation ne tient que si cette CA est dans les racines de confiance. Ne désactivez pas la validation dans le code
    real["Vrai certificat serveur"] --> px["Proxy d'inspection TLS"]
    px --> fake["Resigné par la CA du proxy"]
    fake --> client["Validation côté client"]
    client -->|"CA dans les racines"| ok["Réussite"]
    client -->|"CA absente"| err["Erreur de certificat"]
    err -.-> fix["Déployer la CA dans le magasin"]

Figure 8 : L’inspection ne fonctionne qu’en ensemble avec le déploiement de la CA interne.

8. La procédure d’isolement — cinq étapes pour identifier le coupable

Enquêtez « ne peut pas se connecter » mécaniquement dans cet ordre.

Vous pouvez collecter (2) d’un coup avec PowerShell.

# (1) Per-user (WinINET) settings — note that this reads HKCU of the running account
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
    Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

# (2) Machine (WinHTTP) settings
netsh winhttp show proxy

# (3) Environment variables
Get-ChildItem env: | Where-Object Name -match 'proxy'

Quelques conseils pratiques.

• Dans le test de reproduction de (1), soyez conscient de quelle famille de réglages l’outil lit. Le curl.exe livré avec Windows peut spécifier un proxy explicitement avec -x http://proxy:8080, et pour la validation TLS il utilise normalement le magasin de certificats de l’OS (Schannel). Invoke-WebRequest de Windows PowerShell 5.1 suit le côté .NET Framework (Options Internet par défaut) ; PowerShell 7 suit le côté .NET (variables d’environnement d’abord). « curl marche mais l’application non » est lui-même un indice de décalage entre familles de configuration.
• Si la cible de (3) est un service, revérifiez (1) et (2) sous le même compte que le service. Une vérification dans la propre session de l’administrateur n’est pas une preuve de ce que LocalSystem voit.
• Dans la classification d’erreur de (4), prenez le chapitre 6 (authentification) comme premier candidat pour 407, le chapitre 7 (inspection TLS) pour une erreur de certificat, et « cela n’atteint pas le proxy » (chemin, résolution de nom, pare-feu) pour une expiration. Le schéma où la cause est une règle entrante du Pare-feu Windows plutôt que le proxy est traité dans « Le pare-feu Windows et les applications métier ».
• Si vous allez jusqu’à (5) et qu’il n’y a toujours aucune trace dans le journal du proxy, le trafic n’a jamais atteint le proxy. Suspectez la décision DIRECT de PAC, une liste de contournement, ou une variable d’environnement oubliée, et si besoin confirmez la destination réelle avec une capture de paquets (« Capture de paquets sous Windows en pratique — choisir parmi pktmon, netsh trace et Wireshark »).

flowchart TB
    accTitle: Cinq étapes pour isoler une panne de proxy
    accDescr: Reproduire sous le même compte, collecter les trois familles de réglages, identifier le compte d'exécution, classer l'erreur, puis vérifier le journal du proxy
    s1["Reproduire avec curl"] --> s2["Collecter trois familles"]
    s2 --> s3["Identifier le compte"]
    s3 --> s4["Classer l'erreur"]
    s4 --> s5["Vérifier le journal du proxy"]
    s4 -.-> e407["407 : authentification"]
    s4 -.-> ecert["Erreur de certificat : inspection"]
    s4 -.-> eto["Expiration : jamais atteint"]

Figure 9 : Parcourez les cinq étapes dans l’ordre. La classe d’erreur choisit le chapitre suivant.

9. Une recommandation de conception — faire de l’application une que l’on peut « configurer le proxy dessus »

Retournez la procédure d’enquête et elle devient un guidage de conception côté application. Pour une application Windows que vous livrerez dans un environnement avec un proxy d’entreprise, ce qui suit est recommandé.

1. Rendez le proxy configurable depuis les réglages de l’application. Le défaut est « suivre les réglages de l’OS ». Dans la plupart des environnements, le défaut suffit ; seulement dans les environnements exceptionnels — PAC ne peut pas être lu, cela tourne en service, une configuration de proxy spéciale — vous rendez possible de spécifier une URL de proxy, une liste de contournement, et « ne pas utiliser de proxy » depuis un fichier de réglages. HttpClientHandler.Proxy / UseProxy de la section 5.3 est le point d’implémentation.¹⁴
2. Écrivez comment les destinations internes (API, bases de données, serveurs de licences, et similaires) sont traitées comme exceptions de proxy. Mettez sous une forme que vous pouvez écrire dans la procédure de déploiement si elles sont exclues par PAC DIRECT, une liste de contournement, ou NO_PROXY. Les règles de correspondance de NO_PROXY (pas de jokers, ce qu’un point initial signifie) sont largement mal comprises, donc joignez des exemples.⁷
3. Concevez les délais d’expiration et les tentatives en supposant de passer par un proxy. Si le proxy est en panne ou coincé sur l’authentification, une implémentation qui attend un long délai par défaut fige à la fois l’interface et l’exploitation. Séparez un délai de connexion plus court, et limitez les tentatives aux requêtes idempotentes (détails de conception dans « N’enfermez pas HttpClient dans un using »).
4. Journalisez « quel proxy a été utilisé ». Faites que l’application elle-même puisse répondre à la première question d’une enquête de panne.

Un journal comme en (4) est déjà efficace s’il n’enregistre que le résultat de la résolution. Le point est de dériver le chemin depuis les réglages (le gestionnaire) que vous avez réellement utilisés pour configurer le client. Si vous journalisez HttpClient.DefaultProxy directement, vous enregistrerez une valeur qui désaccorde le chemin réel lorsque le gestionnaire spécifie Proxy explicitement ou pose UseProxy = false.

using System.Net.Http;

// handler is the same instance used to create the HttpClient
// UseProxy=false is always direct. An explicit specification wins; otherwise DefaultProxy is used
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("HTTP send {Target} route {Route} account {User}",
    target, route, Environment.UserName);

Si au démarrage vous enregistrez une fois « chemin » et « compte d’exécution » pour les destinations principales, les étapes (1) à (3) du chapitre 8 se terminent rien qu’en lisant le journal. Lorsqu’on vous dit « cela marche dans le navigateur, mais… », pouvoir dire depuis le côté application « j’ai utilisé ce réglage, et ce chemin » est la condition d’une application solide contre les ennuis de proxy.

flowchart TB
    accTitle: Rendre le proxy configurable et journaliser le chemin
    accDescr: Par défaut suivre les réglages de l'OS, permettre une URL de proxy explicite ou un contournement ou l'absence de proxy depuis les réglages de l'application, et journaliser la route réellement utilisée avec le compte d'exécution
    def["Défaut : suivre les réglages de l'OS"] --> exc{"Environnement exceptionnel ?"}
    exc -->|"PAC illisible / service / spécial"| cfg["Régler URL, contournement, ou sans proxy"]
    exc -->|"Cas habituel"| os["Utiliser le défaut de l'OS"]
    cfg --> log["Journaliser route et compte"]
    os --> log

Figure 10 : Configurez lorsque vous devez. Journalisez toujours quel chemin a été utilisé.

10. Synthèse

• Les réglages de proxy Windows se séparent en trois familles — réglages WinINET par utilisateur, réglages machine WinHTTP, et variables d’environnement — et laquelle est lue se décide par l’application (sa pile HTTP) et le compte d’exécution.
• WinINET est pour les applications interactives et n’est pas pris en charge dans un service ; l’usage service est le travail de WinHTTP (netsh winhttp). Pour « cela marche à la main mais pas en service », suspectez d’abord une différence de compte d’exécution.
• netsh winhttp set proxy est un réglage statique et ne gère ni PAC, ni la détection automatique, ni l’authentification. Sur un réseau opéré en PAC, il faut décider comment les clients qui ne peuvent pas lire PAC seront traités.
• FindProxyForURL de PAC renvoie un proxy ou DIRECT par URL. WPAD ne fonctionne que sur un réseau qui a un dispositif DHCP/DNS.
• Le défaut de .NET Framework, ce sont les Options Internet du compte d’exécution (remplaçable avec defaultProxy) ; .NET (Core et suivants) ce sont les variables d’environnement puis les réglages de proxy utilisateur. Une spécification explicite (HttpClientHandler.Proxy) a toujours la priorité la plus haute.
• Le 407 est une erreur d’authentification proxy ; dans une application qui tourne sous un compte de service, la cause typique est que les « informations d’identification par défaut » deviennent une autre personne.
• Un proxy d’inspection TLS présuppose le déploiement du certificat CA interne, et la réponse juste à une erreur de certificat est le déploiement dans le magasin de certificats, pas la désactivation de la validation. Le trafic épinglé a besoin d’une exclusion.
• Isolez mécaniquement dans l’ordre « reproduire → collecter les trois familles de réglages → identifier le compte d’exécution → classer l’erreur → journal du proxy ». Côté application, une conception qui « peut configurer le proxy, et journalise le chemin qu’elle a utilisé » est la meilleure prévention.

La prochaine fois que l’on vous consulte avec « seule l’application métier ne se connecte pas », demandez d’abord ceci.

Sous le compte de qui cette application tourne-t-elle, et laquelle des trois familles de réglages de proxy lit-elle ?

Cette seule question change beaucoup l’entrée de l’enquête.

Articles connexes

• N’enfermez pas HttpClient dans un using — la communication HTTP en C# pour applications métier (modèles de création, délais d’expiration, tentatives)
• Capture de paquets sous Windows en pratique — choisir parmi pktmon, netsh trace et Wireshark
• Le pare-feu Windows et les applications métier — enregistrer les règles entrantes depuis l’installateur
• Comment créer et exploiter un service Windows ── du choix entre Planificateur de tâches et service à la transformation d’un BackgroundService en service Windows
• NTLM et Kerberos expliqués en images — Pourquoi l’authentification « retombe »-t-elle sur NTLM ?
• Guide pratique du magasin de certificats Windows — Faut-il l’installer côté utilisateur ou côté ordinateur ?

Domaines de conseil associés

KomuraSoft LLC prend en charge l’enquête des pannes de communication d’applications Windows dans des environnements de proxy d’entreprise, de proxy authentifiant et d’inspection TLS — « cela marche sur la machine de développement mais ne communique pas sur le réseau du client », « après l’avoir transformée en service elle n’atteint plus l’API externe » — et le conseil sur la conception de communication d’applications métier qui suppose un environnement proxy (éléments de réglage, délais d’expiration, conception de journaux). Il est possible de commencer par organiser les étapes de reproduction et la façon de collecter les journaux.

• Développement d’applications Windows
• Analyse des bugs et des causes
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Le navigateur se connecte, mais seule l'application métier ne passe pas le proxy d'entreprise. Pourquoi ?

Le navigateur lit les réglages de proxy par utilisateur de WinINET, mais une application métier ne lit pas forcément les mêmes. Une application qui tourne en service Windows, ou sous un autre compte, consulte les réglages visibles depuis ce compte, les réglages machine de WinHTTP, ou les variables d'environnement. Identifiez d'abord le compte d'exécution, puis vérifiez les réglages de proxy visibles depuis ce compte à la fois avec netsh winhttp show proxy et dans les réglages utilisateur. Si vous reproduisez avec curl.exe ou l'équivalent sous le même compte sur la même machine, vous pouvez traiter le cas comme un décalage entre familles de configuration plutôt qu'un problème propre à l'application.

J'ai configuré netsh winhttp set proxy, mais le trafic de l'application n'a pas changé. Pourquoi ?

Ce que netsh winhttp configure, c'est le défaut machine de WinHTTP. Cela n'affecte ni les navigateurs ni les applications interactives qui lisent WinINET, ni HttpClient de .NET (Core et suivants), qui privilégie les variables d'environnement. netsh winhttp set proxy est aussi un réglage statique ; il ne gère ni l'autoconfiguration PAC, ni la détection automatique, ni l'authentification proxy. Il faut d'abord confirmer quelle pile HTTP utilise l'application cible et depuis quelle famille de configuration elle résout le proxy.

Quels réglages de proxy une application .NET lit-elle ?

.NET Framework utilise par défaut les Options Internet (équivalent WinINET) du compte d'exécution, et vous pouvez les remplacer par l'élément system.net/defaultProxy dans app.config. HttpClient sur .NET (Core et suivants) lit d'abord les variables d'environnement HTTP_PROXY, HTTPS_PROXY et NO_PROXY, et s'il ne sont pas définies retombe sur les réglages de proxy utilisateur Windows. Dans les deux cas, un HttpClientHandler.Proxy explicite a la priorité. L'ordre de résolution par défaut diffère donc entre Framework et Core et suivants : il faut revérifier le comportement proxy à la migration.

Que faut-il vérifier lorsqu'un 407 Proxy Authentication Required est renvoyé ?

Le 407 est le signe que le proxy lui-même exige une authentification ; c'est autre chose qu'une erreur d'authentification du serveur de destination (401). Confirmez d'abord le schéma demandé par le proxy (Negotiate, NTLM, Basic) d'après l'en-tête Proxy-Authenticate, et dans .NET passez les informations d'identification avec HttpClientHandler.DefaultProxyCredentials ou WebProxy.UseDefaultCredentials. Dans une application qui tourne sous un compte de service, les « informations d'identification par défaut » deviennent celles de ce compte de service, d'où l'incident typique : cela marche pour un utilisateur interactif, puis 407 dès que vous en faites un service. Vérifiez aussi dans le journal côté proxy sous quelle identité il a authentifié.

Un proxy d'inspection TLS produit des erreurs de certificat. Puis-je désactiver la validation des certificats ?

La désactiver n'est pas recommandé. Un proxy d'inspection TLS déchiffre le trafic puis présente au client un certificat resigné par sa propre CA, de sorte que la validation échoue si ce certificat CA n'est pas dans les racines de confiance. La correction juste est de déployer le certificat CA interne dans le magasin de certificats Windows (en général Autorités de certification racines de confiance de l'ordinateur local). Désactiver la validation dans le code signifie qu'une attaque de l'homme du milieu ne pourra pas être détectée lorsque l'application est utilisée sur un réseau extérieur, et la vulnérabilité demeure.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.