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 communique quand je l’exécute à la main, et échoue dès que j’en fais un service Windows. » Dans un environnement avec un proxy d’entreprise, ce type de décalage est fréquent.

Le point de départ de l’enquête est quels réglages de proxy cette application lit, et sous le compte de qui. Windows n’a pas un seul réglage de proxy. Le navigateur, un service et HttpClient de .NET peuvent chacun consulter des réglages différents.

Dans la plupart des cas, la cause n’est ni une panne du serveur proxy, ni un bogue de l’application, mais ce décalage entre familles de configuration et comptes d’exécution. Cet article s’adresse au personnel informatique des PME et aux développeurs d’applications Windows. Il parcourt d’abord le tableau d’ensemble des réglages, puis PAC, l’authentification et les certificats, et enfin la procédure d’isolement.

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 ». Le centre de cet article est depuis quels réglages le proxy est résolu, et où la communication s’arrête ensuite.

1. D’abord la conclusion

Il y a trois points à fixer d’abord.

• Avant de regarder les réglages, identifiez l’application et son compte d’exécution. Laquelle des trois familles — paramètres par utilisateur de WinINET, paramètres machine de WinHTTP, variables d’environnement — est lue se décide côté application. Les réglages qu’un administrateur voit sur son écran ne sont pas forcément visibles depuis un service.¹²³
• Enquêtez avec l’URL qui échoue, pas avec une qui marche. PAC renvoie un proxy ou DIRECT par URL. Dans .NET aussi, l’itinéraire change selon le runtime, les variables d’environnement et un réglage explicite du handler.⁴⁵⁶
• Enquêtez séparément l’itinéraire, l’authentification et les certificats. Le 407 est l’authentification du proxy, distincte d’un 401 de la destination. Une erreur de certificat due à l’inspection TLS se traite en déployant la CA interne et en configurant les exclusions nécessaires, pas en désactivant la validation.⁷⁸³

flowchart TB
    accTitle: Informations à aligner pour une enquête proxy
    accDescr: Identifier la pile HTTP et le compte d'exécution de l'application, aligner les réglages visibles depuis ce compte et l'URL qui échoue, puis enquêter sur l'itinéraire, l'authentification et les certificats
    app["Pile HTTP et compte"] --> settings["Vérifier les réglages de ce compte"]
    settings --> url["Vérifier l'itinéraire avec l'URL qui échoue"]
    url --> error["Enquêter aussi séparément l'authentification et les certificats"]

Figure 1 : Alignez « quels réglages », « vus depuis le compte de qui » et « quelle URL » avant d’enquêter sur le lieu de l’échec.

En une phrase : quand vous dites « j’ai vérifié les réglages de proxy », soyez en mesure de dire laquelle des trois familles vous avez vérifiée, et depuis quel compte.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (19 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

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

Les chemins par lesquels une application sous Windows trouve le proxy d’entreprise se répartissent en trois grandes familles.

« Les réglages de proxy Windows » désignent d’ordinaire (1)

Le « Proxy » visible dans l’application Paramètres, c’est historiquement les Options Internet d’Internet Explorer, c’est-à-dire la configuration de WinINET. Par défaut, elle est enregistrée par utilisateur.³

(2) est le défaut par machine pour les contextes sans utilisateur connecté, comme les services. (3) est surtout la convention d’outils d’origine multiplateforme ; sous Windows, .NET (Core et suivants), curl et leurs équivalents la lisent.⁵

C’est l’application, pas la personne qui a configuré, qui décide ce qui est lu

La source est fixée par l’application : (1) pour une application qui utilise WinINET, (2) ou un réglage propre à l’application pour WinHTTP, et (3) puis (1) pour .NET (Core et suivants).

Donc, lorsque « les réglages sont justes mais cela ne se connecte toujours pas », confirmez d’abord si les réglages que vous avez vérifiés et ceux que l’application a lus appartiennent à la même famille. Avant de parcourir les trois familles pour leur donner la même valeur, il importe d’identifier le point d’entrée de l’application cible.

Certaines configurations sont par appareil plutôt que par utilisateur

En activant la stratégie de groupe « Définir les paramètres de proxy par ordinateur (et non par utilisateur) », on bascule (1) à la portée machine et on applique les mêmes réglages à tous les utilisateurs. Avec une MDM (Intune et équivalents), le CSP NetworkProxy configure par appareil.³

flowchart TB
    accTitle: Changer la portée des réglages par utilisateur
    accDescr: Les réglages WinINET sont par utilisateur par défaut, mais la stratégie de groupe peut les basculer en réglages par ordinateur, et la MDM peut les configurer par appareil via le CSP NetworkProxy
    user["Les réglages WinINET sont par utilisateur par défaut"] --> gp["La GPO les bascule par ordinateur"]
    gp --> all["Les mêmes réglages s'appliquent à tous les utilisateurs"]
    mdm["CSP NetworkProxy de la MDM"] --> device["Configuré par appareil"]

Figure 2 : Parce que certaines configurations changent la portée de (1) en par appareil, lisez « par utilisateur » comme l’état par défaut.

3. WinINET et WinHTTP — l’un pour les applications interactives, l’autre pour les services

3.1. Des rôles différents

WinINET et WinHTTP sont tous deux des piles clientes HTTP standard de Windows. Ils diffèrent toutefois par le modèle d’exécution qu’ils supposent.

WinINET est destiné aux applications de bureau interactives. Il hérite automatiquement des Options Internet de l’utilisateur, du proxy, des cookies et du cache d’informations d’identification, et peut afficher une interface de saisie des informations d’identification si besoin. En revanche, l’usage dans un service ou un processus de type service n’est pas pris en charge.¹

WinHTTP est destiné aux services et au côté serveur. Il prend en charge l’exécution sous un compte de service, l’emprunt d’identité de thread et l’isolation de session. En échange, il ne partage ni les réglages, ni les cookies, ni les informations d’identification du navigateur, et n’affiche aucune interface.²

Le guide de choix de Microsoft est de même WinINET, sauf si vous êtes dans un service ou un processus de type service qui a besoin d’isolation de session ou d’emprunt d’identité, et WinHTTP pour les services.¹ Cela ne signifie pas, toutefois, que toute application qui tourne en service lit les réglages machine de WinHTTP. Les services écrits en .NET sont traités à part à la section 3.3.

3.2. Opérations de base de netsh winhttp

Le proxy par défaut machine de WinHTTP se gère avec netsh.⁹

:: Afficher les réglages de proxy WinHTTP actuels
netsh winhttp show proxy

:: Définir un proxy statique (avec une liste de contournement)
netsh winhttp set proxy proxy-server="proxy.example.co.jp:8080" bypass-list="*.example.co.jp;<local>"

:: Importer les réglages des Options Internet (WinINET)
netsh winhttp import proxy source=ie

:: Revenir au défaut (DIRECT)
netsh winhttp reset proxy

Ne pas confondre réglage statique, import et autoconfiguration

set proxy est un réglage statique. Il ne gère ni la détection automatique, ni une URL PAC, ni l’authentification proxy.³

import proxy source=ie copie les réglages statiques tels qu’ils sont au moment de l’exécution. Si les Options Internet changent ensuite, le côté WinHTTP ne suit pas.

flowchart TB
    accTitle: L'import des réglages de proxy est une copie unique
    accDescr: import proxy source=ie ne copie dans WinHTTP que les réglages statiques de cet instant, et les changements ultérieurs des Options Internet ne sont pas suivis automatiquement
    source["Réglages statiques au moment de l'exécution"] --> copy["import proxy source=ie"]
    copy --> dest["Copiés dans WinHTTP"]
    source -.-> later["Les changements ultérieurs ne sont pas suivis automatiquement"]

Figure 3 : import n’est pas un réglage de synchronisation, mais une opération qui reprend les réglages statiques de cet instant.

Pour configurer la machine en y incluant PAC et la détection automatique WPAD, utilisez netsh winhttp set advproxy. Les réglages avancés au format JSON comprennent Proxy, ProxyBypass, AutoconfigUrl et AutoDetect.⁹

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

Le cas typique est celui d’un développeur qui déplace un outil qui tournait sur son PC vers un service Windows exécuté en LocalSystem.

Même s’il communiquait pendant le développement via les réglages par utilisateur du développeur (1), les réglages visibles depuis LocalSystem sont autre chose. Si les réglages machine de WinHTTP ne sont pas configurés (DIRECT), l’outil tente de joindre l’API externe en direct et expire. La procédure pour en faire un service est traitée dans « Comment créer et exploiter un service Windows ».

flowchart TB
    accTitle: Le décalage lorsqu'un outil lancé à la main devient un service
    accDescr: Quand un outil qui tournait sous les réglages par utilisateur du développeur devient un service LocalSystem, les réglages visibles changent, et si le défaut WinHTTP est DIRECT il tente une connexion directe et échoue
    dev["Exécution manuelle en tant que développeur"] --> works["Communique avec vos propres réglages"]
    works --> service["Passage en service LocalSystem"]
    service --> changed["Les réglages visibles changent"]
    changed --> direct["Connexion directe si WinHTTP n'est pas configuré"]
    direct --> failure["Expiration sur l'API externe"]

Figure 4 : Même sur la même machine, changer le compte d’exécution change les réglages que l’on peut voir.

Fournir les réglages sous la forme que lit la pile HTTP

Pour un processus qui communique même lorsqu’aucun utilisateur n’est connecté, fournissez des réglages de portée machine. La façon de les configurer, toutefois, doit correspondre à la pile HTTP.

HttpClient de .NET (Core et suivants) ne lit pas les réglages machine de WinHTTP. Ne concluez pas que « c’est un service, donc configurer netsh suffit ». L’ordre de priorité détaillé est au chapitre 5.

Un réglage statique sur un portable qui sort du bureau casse dans l’autre sens

Si vous figez le proxy statique de l’entreprise sur un portable, le proxy est injoignable hors du bureau et la communication échoue. Traitez les réglages machine statiques comme un outil pour des serveurs dont la configuration réseau ne change pas.³

4. PAC et WPAD — de quoi se compose l’« autoconfiguration »

PAC calcule l’itinéraire, et WPAD trouve où se trouve le PAC. Découper l’« autoconfiguration » en ces deux parties montre où regarder.

4.1. Le fichier PAC et FindProxyForURL

PAC (Proxy Auto-Configuration) est un fichier écrit en JavaScript (ECMAScript). Sa fonction obligatoire FindProxyForURL(url, host) renvoie, pour l’URL et l’hôte donnés, soit la liste des proxys à utiliser, soit DIRECT, c’est-à-dire une connexion directe.¹⁰

function FindProxyForURL(url, host) {
    // Le domaine interne et les adresses privées se connectent en direct
    if (dnsDomainIs(host, ".example.co.jp") ||
        isInNet(host, "10.0.0.0", "255.0.0.0")) {
        return "DIRECT";
    }
    // Tout le reste passe par le proxy. En cas d'indisponibilité du premier, basculer sur le suivant
    return "PROXY proxy1.example.co.jp:8080; PROXY proxy2.example.co.jp:8080; DIRECT";
}

Dans cet exemple, le domaine interne et les adresses privées indiquées se connectent en direct, et tout le reste passe par le proxy. Dans ce second cas, si le premier proxy est indisponible on passe au suivant, et on retombe enfin sur DIRECT.

flowchart TB
    accTitle: PAC change l'itinéraire selon la destination
    accDescr: L'exemple de PAC montré évalue l'URL et l'hôte, renvoie DIRECT pour le domaine interne et les adresses privées indiquées, et sinon une liste ordonnée de proxys
    target["Passer l'URL et l'hôte"] --> check{"Correspond aux conditions internes de l'exemple ?"}
    check -->|"Oui"| direct["Renvoyer DIRECT"]
    check -->|"Non"| proxies["Proxy 1, proxy 2, puis DIRECT"]

Figure 5 : Parce que la réponse du PAC change par URL, le succès d’un autre site ne confirme pas l’itinéraire de l’API qui échoue.

Deux précautions d’enquête en découlent.

Vérifiez en passant l’URL qui échoue. PAC peut renvoyer une réponse différente pour chaque URL. La fonction de proxy automatique de WinHTTP est aussi conçue pour être interrogée à chaque fois avec l’URL de la requête. « D’autres sites sont visibles dans le navigateur » n’est pas la preuve que l’API qui échoue emprunte le même itinéraire.⁴

Pour un trafic absent du journal du proxy, suspectez aussi DIRECT et les contournements. DIRECT est une instruction « allez sans le proxy ». Si le trafic interne n’apparaît pas dans le journal, vérifiez un résultat DIRECT du PAC ou une correspondance dans la liste de contournement.

4.2. Détection automatique via WPAD

Activer « Détecter automatiquement les paramètres » utilise WPAD (Web Proxy Auto-Discovery) pour trouver où se trouve le fichier PAC. En général, l’URL PAC est distribuée par DHCP, ou un hôte nommé wpad est résolu via DNS et le fichier est récupéré à une URL telle que http://wpad/wpad.dat.¹¹

flowchart TB
    accTitle: De la détection automatique jusqu'à la récupération du PAC
    accDescr: Dans WPAD, l'emplacement du fichier PAC est trouvé via DHCP ou DNS, et le PAC est récupéré à cet emplacement puis utilisé pour calculer les itinéraires
    auto["Activer la détection automatique"] --> find["Trouver l'emplacement via DHCP ou DNS"]
    find --> pac["Récupérer le fichier PAC"]
    pac --> route["Calculer l'itinéraire par destination"]
    find -.-> missing["La détection échoue si rien n'est mis en place"]

Figure 6 : La détection automatique a besoin de la mise en place DHCP/DNS côté réseau.

Activer la seule détection automatique sur un réseau sans cette mise en place ne fait rien, et ajoute l’attente jusqu’à l’échec de la détection. Choisir « automatique » ne résout pas partout.

4.3. Comportement des clients qui ne peuvent pas lire un PAC

Même si vous distribuez un PAC, tous les clients ne l’évaluent pas. netsh winhttp set proxy est un réglage statique, et les outils qui suivent la convention de variable d’environnement HTTP_PROXY n’ont en général nulle part où mettre une URL PAC non plus. Ils prennent une URL de proxy fixe.³⁵

Pour une application native qui utilise WinHTTP directement, vérifiez comment la session est ouverte.

flowchart TB
    accTitle: Vérifier si WinHTTP utilise le PAC
    accDescr: Si la session WinHTTP est ouverte avec AUTOMATIC_PROXY le proxy est résolu automatiquement, mais avec l'ouverture traditionnelle l'application doit appeler l'API AutoProxy et appliquer le résultat
    open["Vérifier les paramètres de WinHttpOpen"] --> mode{"AUTOMATIC_PROXY ?"}
    mode -->|"Oui"| automatic["WinHTTP résout automatiquement"]
    mode -->|"Ouverture traditionnelle"| api["L'application appelle l'API AutoProxy"]
    api --> apply["Appliquer le résultat à la requête"]

Figure 7 : Savoir seulement qu’une application utilise WinHTTP ne dit pas que le PAC est utilisé automatiquement aussi.

Dans les implémentations plus anciennes, un PAC peut exister et n’être pourtant pas utilisé. Sur un réseau exploité avec PAC, décidez aussi quoi donner, via des réglages statiques ou des variables d’environnement, aux clients qui ne peuvent pas lire le PAC.

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

.NET Framework et .NET (Core et suivants) déterminent le proxy par défaut différemment. Enquêter sur une application .NET 8 avec des connaissances de l’ère Framework peut vous faire vérifier les mauvais réglages.

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

HttpWebRequest de .NET Framework, et le HttpClient construit dessus, utilisent le proxy par défaut sauf si Proxy est défini explicitement. Ce défaut se détermine en combinant les réglages Internet du compte d’exécution (l’équivalent WinINET) et le fichier de configuration, et les réglages du fichier de configuration ont la priorité.⁶

On le pilote via system.net/defaultProxy dans app.config ou machine.config.¹³

<configuration>
  <system.net>
    <!-- useDefaultCredentials : envoyer ou non les informations d'identification par défaut à un proxy authentifiant -->
    <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 vide, les réglages des Options Internet sont utilisés ; si proxyaddress et équivalents sont spécifiés, ceux-ci ont la priorité. Depuis le code, WebRequest.DefaultWebProxy replace le même défaut.¹³⁶

flowchart TB
    accTitle: Le proxy par défaut de .NET Framework
    accDescr: .NET Framework part des réglages Internet du compte d'exécution et donne la priorité aux valeurs spécifiées dans le fichier de configuration pour déterminer le proxy par défaut
    account["Réglages du compte d'exécution"] --> config["Le fichier de configuration a la priorité"]
    config --> default["Proxy par défaut de Framework"]
    replace["Remplacé via DefaultWebProxy"] -.-> default

Figure 8 : Le défaut Framework, ce sont les réglages du « compte d’exécution », qui ne sont pas forcément ceux visibles à l’écran de l’administrateur.

Lors de l’exécution sous un compte de service, la même prudence qu’à la section 3.3 s’applique. Ce qu’il lit par défaut, ce sont les Options Internet de ce compte, distinctes de ce qui est visible sur le bureau de l’administrateur, et en général vides.

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

.NET (Core et suivants) a la propriété statique HttpClient.DefaultProxy. C’est le défaut utilisé lorsque le handler ne spécifie pas de proxy explicitement, et sous Windows il est initialisé en lisant les variables d’environnement puis, si elles ne sont pas définies, les réglages de proxy de l’utilisateur, dans cet ordre.⁵

Séparer les trois variables qui spécifient un proxy de NO_PROXY

Si l’une de HTTP_PROXY, HTTPS_PROXY ou ALL_PROXY est définie, elle a la priorité sur les réglages de l’OS. Un HTTPS_PROXY laissé par un test, ou injecté par un modèle CI/CD, envoie le trafic sur un itinéraire différent des réglages que vous avez vus à l’écran.

En revanche, définir seulement NO_PROXY ne configure pas de proxy depuis les variables d’environnement. Sous Windows, les réglages de proxy utilisateur de l’OS continuent d’être utilisés.

flowchart TB
    accTitle: Initialisation du proxy par défaut dans .NET sous Windows
    accDescr: Si l'une de HTTP_PROXY, HTTPS_PROXY et ALL_PROXY est définie les variables d'environnement ont la priorité, et si aucune n'est définie les réglages utilisateur Windows sont utilisés. NO_PROXY seul ne configure pas de proxy depuis les variables d'environnement
    init["Initialiser le proxy par défaut"] --> env{"L'une des 3 variables de proxy est-elle définie ?"}
    env -->|"Oui"| useenv["Les variables d'environnement ont la priorité"]
    env -->|"Non"| user["Réglages utilisateur Windows"]
    init -.-> no["NO_PROXY seul ne configure rien"]

Figure 9 : Vérifiez d’abord si un proxy est spécifié par des variables d’environnement, et distinguez cela d’un état avec seulement NO_PROXY.

Le « point en tête » de NO_PROXY et la différence sous Linux

NO_PROXY ne prend pas en charge les jokers (*). .example.com avec un point en tête correspond à www.example.com mais pas à example.com lui-même.⁵

Dans les conteneurs Linux et équivalents, le défaut est l’absence de proxy si les variables d’environnement ne sont pas définies. Parce que le comportement par défaut diffère entre Windows et Linux, vérifiez-le aussi lors d’un passage en conteneur.⁵

5.3. Configuration explicite — HttpClientHandler.Proxy et UseProxy

Sur les deux runtimes, un HttpClientHandler.Proxy explicite a la plus haute priorité. Il prime sur les réglages de l’OS et le fichier de configuration. Avec UseProxy = false, aucun proxy n’est utilisé.¹¹

using System.Net;

// Utiliser explicitement un proxy lu depuis la configuration de l'application
var handler = new HttpClientHandler
{
    Proxy = new WebProxy("http://proxy.example.co.jp:8080")
    {
        BypassProxyOnLocal = true,
        BypassList = new[] { @"^intra\.example\.co\.jp$" },
        UseDefaultCredentials = true // Pour un proxy authentifiant, répondre avec les informations d'identification du compte d'exécution
    },
    UseProxy = true
};
var client = new HttpClient(handler);

// Un client qui n'utilise jamais de proxy (pour les connexions directes aux API internes)
var directHandler = new HttpClientHandler { UseProxy = false };
var directClient = new HttpClient(directHandler);

flowchart TB
    accTitle: Déterminer le proxy effectif à partir du handler
    accDescr: Si UseProxy est false la connexion est directe, si true le Proxy explicite du handler est utilisé, et s'il n'y a pas de réglage explicite le proxy par défaut est utilisé
    use{"UseProxy est-il true ?"} -->|"Non"| direct["Connexion directe"]
    use -->|"Oui"| explicit{"Proxy défini explicitement ?"}
    explicit -->|"Oui"| proxy["Utiliser le proxy spécifié"]
    explicit -->|"Non"| default["Utiliser le proxy par défaut"]

Figure 10 : Avant d’enquêter sur le proxy par défaut, vérifiez le réglage explicite du handler et UseProxy.

Attention aussi au contournement automatique des destinations locales

Lorsqu’il n’y a pas de réglage explicite et que l’on suit les réglages de l’OS, les noms plats sans point, les adresses de bouclage et les destinations correspondant au suffixe de domaine de la machine peuvent être traités comme « locaux » et contournés.¹¹

Lorsque « le comportement diffère entre une adresse IP directe et un nom » ou « cela a commencé à passer par le proxy une fois le FQDN utilisé », vérifiez cette détermination.

L’ordre de priorité jusqu’ici se résume ainsi.

6. Proxys authentifiants — le 407 est une erreur d’authentification « du proxy »

6.1. Ne pas confondre 407 et 401

Même après avoir atteint le proxy, on n’avance pas sans passer l’authentification. Distinguez qui exige l’authentification d’après le code d’état et l’en-tête.⁷

Sur un 407, vérifiez d’abord les schémas listés dans Proxy-Authenticate. Basic envoie un nom d’utilisateur et un mot de passe, alors que Negotiate (Kerberos/NTLM) et équivalents sont des schémas défi/réponse. Dans ces derniers, le mot de passe lui-même ne circule pas, et l’authentification se termine en plusieurs allers-retours.⁷

sequenceDiagram
    accTitle: Flux de réponse à un proxy authentifiant
    accDescr: Le client reçoit 407 et une indication du schéma d'authentification de la part du proxy, et répond avec les informations d'identification de ce schéma. Les schémas défi-réponse nécessitent plusieurs allers-retours
    participant C as Client
    participant P as Proxy
    C->>P: Demander la communication
    P-->>C: 407 avec Proxy-Authenticate
    C->>P: Répondre à l'authentification selon le schéma
    Note over C,P: Plusieurs allers-retours selon le schéma

Figure 11 : Sur un 407, vérifiez les informations d’authentification envoyées au proxy, pas au serveur de destination.

Le schéma d’authentification vers lequel les choses « retombent » est détaillé dans « NTLM et Kerberos expliqués en images ».

6.2. Passer les informations d’identification dans .NET

L’endroit où configurer diffère selon que l’on suit le proxy par défaut ou que l’on spécifie un proxy explicitement.

Pour utiliser le proxy par défaut et passer des informations d’identification, utilisez HttpClientHandler.DefaultProxyCredentials. Ce sont les informations d’identification envoyées au proxy par défaut lorsque UseProxy = true et Proxy = null.¹⁴

using System.Net;

var handler = new HttpClientHandler
{
    UseProxy = true,   // Le défaut. Combiné à un Proxy null, le proxy par défaut du système est utilisé
    Proxy = null,
    // Répondre au 407 avec les informations d'identification du compte d'exécution (utilisateur connecté ou compte de service)
    DefaultProxyCredentials = CredentialCache.DefaultCredentials
};
var client = new HttpClient(handler);

Lorsque vous spécifiez le proxy explicitement, donnez les informations d’identification au WebProxy. Dans la plupart des 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, ce que fait WebProxy.UseDefaultCredentials = true.¹⁵

6.3. Le problème 407 du compte de service

Les « informations d’identification par défaut » sont celles du compte qui exécute le processus. Pour un utilisateur interactif, l’authentification se fait en tant que cet utilisateur ; pour un service LocalSystem, en tant que compte ordinateur.

flowchart TB
    accTitle: Devenir un service change qui est authentifié
    accDescr: Avec les informations d'identification par défaut, une exécution interactive authentifie en tant que cet utilisateur et un service LocalSystem en tant que compte ordinateur, donc vérifiez si le proxy peut authentifier ce principal
    run{"Compte d'exécution ?"} -->|"Utilisateur interactif"| user["Informations d'identification de cet utilisateur"]
    run -->|"LocalSystem"| machine["Compte ordinateur"]
    user --> check["Vérifier si le proxy peut l'authentifier"]
    machine --> check

Figure 12 : Même en laissant « par défaut » dans le code, le principal que le proxy authentifie change lorsque l’application devient un service.

Un proxy qui authentifie les utilisateurs via l’intégration AD peut être incapable d’authentifier un compte ordinateur ou un compte local, et les 407 continuent. Inversement, certains environnements prévoient des exemptions d’authentification pour les services, par IP source ou par compte.

Pour une application destinée à devenir un service, décidez donc dès la conception s’il faut utiliser un compte de service de domaine (gMSA et équivalents), mettre en place une exemption d’authentification sur le proxy, ou fournir un proxy relais interne qui n’a pas besoin d’authentification. Enquêter sur un 407 exige à la fois la configuration de l’application et « si le proxy peut authentifier ce compte d’exécution ».

Il existe aussi la méthode consistant à embarquer les informations d’identification dans une variable d’environnement, du type HTTP_PROXY=http://user:pass@proxy:8080.⁵ Parce que le mot de passe en clair est exposé dans les variables d’environnement, c’est-à-dire dans les informations du processus, ce n’est pas recommandé pour une exploitation permanente.

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

7.1. HTTPS traverse le proxy en « tunnel »

Pour utiliser un proxy en HTTPS, le client envoie d’abord CONNECT hôte-de-destination:443 pour ouvrir un tunnel TCP. En cas de succès, le proxy renvoie 200, après quoi le client et le serveur de destination effectuent la poignée de main TLS à l’intérieur du tunnel. Si le tunnel ne s’ouvre pas, un 407, un 502 ou équivalent revient.¹⁶

flowchart TB
    accTitle: Jusqu'à l'ouverture du tunnel HTTPS
    accDescr: En HTTPS, une requête CONNECT ouvre un tunnel TCP, et après le 200 la poignée de main TLS a lieu à l'intérieur du tunnel. Si le tunnel ne s'ouvre pas, un 407 ou un 502 ou équivalent est renvoyé
    connect["Indiquer la destination avec CONNECT"] --> result{"Tunnel ouvert ?"}
    result -->|"Succès, 200"| tls["Connexion TLS à l'intérieur du tunnel"]
    result -->|"Échec"| error["407, 502, etc."]

Figure 13 : Lisez un échec au stade de l’ouverture du tunnel séparément d’un échec de la connexion TLS qui suit.

Dans ce modèle « en transit », le proxy ne peut pas lire le contenu HTTPS chiffré. Ce qui apparaît dans le journal, c’est seulement le nom d’hôte de destination et si la connexion a réussi ; le chemin d’URL n’est pas visible.

7.2. Proxys d’inspection TLS et erreurs de certificat

Dans le modèle d’inspection TLS (décryptage SSL, break and inspect), le proxy termine TLS, déchiffre et inspecte le trafic, puis le rechiffre. Le certificat présenté au client est aussi remplacé par un certificat re-signé par la propre CA du proxy.⁸

flowchart TB
    accTitle: L'inspection TLS change le certificat
    accDescr: Dans l'inspection TLS, le proxy termine TLS pour inspecter le contenu et présente au client un certificat re-signé par sa propre CA, donc la confiance dans cette CA est requise
    proxy["Le proxy termine TLS"] --> inspect["Déchiffrer, inspecter, rechiffrer"]
    proxy --> cert["Certificat re-signé par la CA interne"]
    cert --> trust["Confiance dans la CA nécessaire côté client"]

Figure 14 : Dans le modèle d’inspection, la question n’est pas seulement le certificat de la destination, mais si l’on peut faire confiance à la CA interne.

D’abord, vérifier quel magasin de confiance sert à la validation

Cette configuration exige que le certificat CA du proxy soit déployé dans les racines de confiance de chaque client. Les erreurs de validation de certificat surviennent non seulement sur les machines qui ne l’ont pas reçu, mais aussi dans les runtimes qui utilisent leur propre magasin de confiance et ne regardent pas le magasin de certificats Windows.

Dans .NET, cela se manifeste typiquement par une HttpRequestException avec une AuthenticationException interne. Cherchez un message du type « the remote certificate is invalid ».

La correction, c’est de déployer la CA, pas de désactiver la validation

Le certificat CA interne est normalement déployé dans « Autorités de certification racines de confiance » de l’ordinateur local. Pour savoir quand utiliser plutôt le magasin utilisateur, voir « Guide pratique du magasin de certificats Windows ».

Ne contournez pas en renvoyant toujours true depuis ServerCertificateCustomValidationCallback. Cela reste une vulnérabilité dans laquelle une attaque de l’homme du milieu ne peut pas être détectée lorsque l’application est utilisée sur un réseau extérieur.

Exclure le trafic épinglé de l’inspection

Le trafic qui pratique l’épinglage de certificat (certificate pinning) échoue dès que le proxy remplace le certificat. Pour les composants Windows qui valident des certificats Microsoft spécifiques et équivalents, il n’y a pas de contournement, et une exclusion est requise.³

flowchart TB
    accTitle: Séparer le déploiement de la CA de l'exclusion du trafic épinglé
    accDescr: Pour une erreur de certificat sous inspection TLS, vérifiez la confiance dans la CA, mais pour le trafic qui épingle les certificats le remplacement lui-même est la cause de l'échec, donc excluez-le de l'inspection
    failure["Erreur de validation de certificat"] --> pinned{"Certificat épinglé ?"}
    pinned -->|"Oui"| exclude["Exclure de l'inspection"]
    pinned -->|"Non"| store["Vérifier le magasin de confiance utilisé"]
    store --> ca["Vérifier le déploiement de la CA interne"]

Figure 15 : Déployer la CA interne et éviter le remplacement du certificat lui-même sont des corrections distinctes.

Microsoft recommande aussi d’exclure le trafic vers des SaaS tels que Microsoft 365 du déchiffrement et de l’inspection à la couche réseau.⁸ Si des erreurs de certificat ne surviennent qu’avec certains services cloud, suspectez la combinaison de la liste d’exclusion d’inspection et de l’épinglage.

8. Procédure d’isolement — identifier le responsable en cinq étapes

Dans une enquête réelle, vérifiez les mécanismes vus jusqu’ici dans l’ordre suivant.

(1) Reproduire : même URL, mais alignez aussi la famille de réglages de l’outil

Accédez à l’URL qui échoue, si possible depuis la même machine et le même compte. Surveillez aussi les différences entre outils.

« curl passe mais l’application non » est un indice que les familles de réglages diffèrent. Ne concluez pas, du seul succès d’un autre outil, que l’application a emprunté le même itinéraire.

(2) Collecter les réglages : enregistrer les trois familles ensemble

En PowerShell, on peut les collecter comme suit. Le HKCU des réglages par utilisateur appartient au compte qui a exécuté cette commande.

# (1) Réglages par utilisateur (WinINET) -- notez que cela lit le HKCU du compte d'exécution
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
    Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

# (2) Réglages machine (WinHTTP)
netsh winhttp show proxy

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

(3) Identifier le compte : pour un service, revérifier sous le même compte

Identifiez si la cible tourne en service, depuis le Planificateur de tâches, ou en tant qu’un autre utilisateur. Pour un service, refaites la reproduction de (1) et la collecte de (2) sous le même compte. Un succès dans votre propre session d’administrateur n’est pas une preuve de ce que voit LocalSystem.

flowchart TB
    accTitle: Reproduire sous le même compte d'exécution
    accDescr: Parce qu'une collecte dans la session de l'administrateur n'est pas une preuve des réglages visibles depuis le service, identifiez le compte d'exécution de la cible puis revérifiez la reproduction et la collecte des réglages sous ce compte
    admin["Vérifié dans la session de l'administrateur"] --> identify["Identifier le compte d'exécution de la cible"]
    identify --> same["Reproduire et collecter sous le même compte"]
    same --> compare["Comparer réglages et informations d'identification"]

Figure 16 : Confirmez que les informations rassemblées en (1) et (2) sont celles que voit le compte cible identifié en (3).

(4) Classer l’erreur : décomposer « impossible de se connecter »

Pour un 407, vérifiez l’authentification proxy au chapitre 6 ; pour une erreur de certificat, l’inspection TLS au chapitre 7. Pour une expiration, traitez l’impossibilité d’atteindre le proxy comme premier candidat et enquêtez sur l’itinéraire, la résolution de noms et les pare-feu. Un refus de stratégie 403 se tient aussi à part de l’authentification et des expirations.

flowchart TB
    accTitle: Décider où enquêter d'après l'erreur
    accDescr: Répartir les échecs de communication en 407, 403, expiration ou échec de résolution de noms, et erreur de certificat, et enquêter respectivement sur l'authentification, le refus de stratégie, l'itinéraire et l'inspection TLS
    error["Échec de communication"] --> auth["407 signifie authentification proxy"]
    error --> deny["403 signifie refus de stratégie"]
    error --> route["Expiration ou résolution de noms signifie l'itinéraire"]
    error --> tls["Erreur de certificat signifie TLS"]

Figure 17 : Découper par code d’état et exception restreint les réglages et journaux à vérifier.

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 ».

(5) Journal du proxy : confirmer l’arrivée et le compte authentifié

Dans le journal d’accès à l’heure concernée, confirmez si le proxy a été atteint et sous quelle identité il a authentifié. S’il n’y a aucune trace, traitez le trafic comme n’ayant jamais atteint le proxy, et enquêtez sur un résultat DIRECT du PAC, la liste de contournement, et des variables d’environnement laissées en place.

Si besoin, confirmez la destination réelle avec une capture de paquets. Pour la façon de la collecter, voir « Capture de paquets sous Windows en pratique — choisir entre pktmon, netsh trace et Wireshark ».

9. Recommandations de conception — rendre le proxy « configurable » dans l’application

La facilité d’une enquête dépend des réglages et des journaux de l’application. Pour une application livrée dans un environnement avec un proxy d’entreprise, fournissez les quatre éléments suivants.

Autoriser un proxy explicite et une connexion directe, pas seulement le suivi du défaut

Faites de « suivre les réglages de l’OS » le défaut, et pour les cas où le PAC ne peut pas être lu, où l’application tourne en service, ou où la configuration est inhabituelle, permettez de spécifier l’URL du proxy, la liste de contournement et « n’utiliser aucun proxy » depuis un fichier de configuration. Les points d’implémentation sont HttpClientHandler.Proxy et UseProxy de la section 5.3.¹¹

Le défaut de .NET (Core et suivants) inclut aussi la priorité des variables d’environnement expliquée à la section 5.2. Même en s’en remettant au défaut, lisez quels réglages sont utilisés selon ces règles.

Mettre les exceptions internes sous une forme qui tient dans le guide de déploiement

Documentez lequel, d’un résultat DIRECT du PAC, de la liste de contournement et de NO_PROXY, exclut le trafic interne vers les API, les bases de données, les serveurs de licences et équivalents. Montrez, avec des exemples, que NO_PROXY ne prend pas en charge les jokers et ce que signifie le point en tête.⁵

Concevoir les délais d’expiration et les tentatives en supposant aussi l’itinéraire proxy

Attendre la fin d’un long délai d’expiration par défaut lorsque le proxy est en panne ou que l’authentification est en attente fige à la fois l’interface et les opérations. Séparez un délai de connexion plus court, et limitez les tentatives aux requêtes idempotentes. Les détails sont dans « N’enfermez pas HttpClient dans un using ».

Journaliser l’itinéraire à partir du handler effectivement configuré

Journaliser seulement HttpClient.DefaultProxy manque le réglage explicite du handler et UseProxy = false, et enregistre un itinéraire qui ne correspond pas. Il importe de sélectionner les réglages effectifs à partir du handler utilisé pour créer le HttpClient, et d’appliquer aussi la détermination de contournement de la destination.

using System.Net.Http;

// handler est la même instance que celle utilisée pour créer le HttpClient
// UseProxy=false signifie toujours le direct. Un réglage explicite est utilisé s'il est présent, sinon 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("HTTP send {Target} route {Route} running account {User}",
    target, route, Environment.UserName);

flowchart TB
    accTitle: Journaliser l'itinéraire à partir de la configuration du client
    accDescr: Sélectionner le proxy effectif à partir du handler utilisé pour créer le HttpClient, effectuer la détermination de contournement et la résolution de proxy de la destination, et journaliser l'itinéraire et le compte d'exécution
    handler["Même handler qu'à la création"] --> effective["Appliquer UseProxy et le réglage explicite"]
    effective --> target["Détermination de contournement et résolution pour la destination"]
    target --> log["Journaliser l'itinéraire et le compte"]

Figure 18 : Journalisez l’itinéraire à partir de la configuration du client lui-même, pas seulement à partir du proxy par défaut.

Journaliser au démarrage les itinéraires vers les destinations principales et le compte d’exécution facilite le suivi des étapes (1) à (3) du chapitre 8. Quand quelqu’un dit « mais cela marche dans le navigateur », une conception qui tient face à l’enquête est celle dans laquelle l’application peut expliquer ses propres réglages et son itinéraire.

10. Synthèse

Dans une enquête proxy Windows, alignez d’abord la famille de réglages, le compte d’exécution et l’URL cible.

Les réglages par utilisateur de WinINET, les réglages machine de WinHTTP et les variables d’environnement sont des familles distinctes. Devenir un service change les réglages visibles et les informations d’identification, et l’ordre par défaut diffère aussi entre .NET Framework et .NET (Core et suivants). netsh winhttp set proxy à lui seul ne peut pas gérer PAC, la détection automatique ni l’authentification.

PAC renvoie un proxy ou DIRECT par URL, et WPAD a besoin de la mise en place côté réseau. Même une fois l’itinéraire déterminé, l’authentification proxy avec le 407 et la validation de certificat sous inspection TLS se vérifient séparément. Ne désactivez pas la validation de certificat ; déployez la CA et excluez le trafic épinglé.

L’isolement procède dans l’ordre reproduire, collecter les trois familles de réglages, identifier le compte d’exécution, classer l’erreur, puis le journal du proxy. Côté application, fournissez un proxy explicite et une connexion directe, des réglages d’exception, des délais d’expiration et une journalisation d’itinéraire.

La prochaine fois que l’on vous parle de « seule l’application métier ne se connecte pas », commencez par confirmer 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 est le point d’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 entre 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 problèmes de communication d’applications Windows dans des environnements avec proxy d’entreprise, proxy authentifiant et inspection TLS, tels que « cela marche sur la machine de développement mais ne communique pas sur le réseau du client » et « cela a cessé d’atteindre l’API externe une fois devenu un service », ainsi que le conseil sur la conception de communication des applications métier qui supposent un environnement proxy (réglages, délais d’expiration et conception des journaux). Commencer par mettre au clair les étapes de reproduction et la façon de collecter les journaux convient tout à fait.

• Développement d’applications Windows
• Investigation de bugs et analyse des causes
• Conseil technique et revue de conception
• Nous contacter

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 si elles 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 re-signé 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.