À 9h14, un service de synchronisation de données en arrière-plan commence à échouer à nouveau. Il génère une erreur de connexion toutes les quelques minutes, tandis que l'utilisateur assis à la même station de travail charge les sites Web normalement et que la page proxy Windows affiche déjà le proxy d'entreprise. Le navigateur fonctionne, mais le service ne fonctionne pas.
Cette situation n'est généralement pas une contradiction. Cela signifie que le navigateur et le service peuvent utiliser des piles réseau différentes. Avant de changer de proxy, ouvrez un shell administrateur et exécutez netsh winhttp show proxy. Cette commande répond à une question étroite mais importante : que dit la configuration WinHTTP au niveau machine aux processus en arrière-plan ?
Quand un navigateur fonctionnel cache un service défaillant
La première chose que je vérifie est le contexte du processus défaillant. Un service Windows peut s'exécuter via services.exe, utiliser des identifiants SYSTEM, et hériter des paramètres de stratégie de groupe qui ne correspondent pas à la configuration de l'utilisateur interactif. Une tâche planifiée ou un agent de mise à jour peut rencontrer la même séparation. L'opérateur voit un proxy configuré dans un navigateur ou dans les paramètres Windows, mais le processus non interactif voit un accès direct.
Cette discordance est courante dans les environnements verrouillés où la stratégie de groupe ou la gestion des appareils mobiles a appliqué un paramètre utilisateur sans appliquer le paramètre correspondant au niveau machine. Le résultat est un service qui tente à plusieurs reprises une connexion directe, même si la personne testant la connexion a une session de navigateur fonctionnelle.
Règle pratique : Testez le contexte réseau qui a échoué. Un test de navigateur prouve que le navigateur peut se connecter, pas qu'un compte de service peut.
Exécutez :
netsh winhttp show proxy
Microsoft documente cette commande comme le moyen d'afficher le paramètre proxy WinHTTP actuel. Elle indique si WinHTTP utilise une connexion directe ou un proxy configuré, ainsi que le serveur proxy et la liste d'exclusion, bien que Microsoft marque désormais show proxy comme obsolète et recommande show advproxy pour les configurations plus récentes dans sa documentation de commande netsh WinHTTP.
Le reste du diagnostic dépend de la lecture correcte de ce résultat. Vous devez distinguer WinHTTP de WinINet et des paramètres du navigateur, identifier si le processus défaillant s'exécute sous un compte ou une architecture différente, et tester les modifications dans le même contexte que le service. Commencez par la commande car elle élimine les conjectures de la première couche de l'enquête.
Ce qu'est WinHTTP et pourquoi il a ses propres paramètres proxy
WinHTTP est une API HTTP au niveau système dans Windows. Elle donne aux services et autres applications non interactives un moyen de faire des requêtes HTTP et HTTPS sans dépendre de la session de navigateur d'un utilisateur connecté. Microsoft décrit les paramètres WinHTTP comme une configuration au niveau machine utilisée par les applications qui s'appuient sur l'API WinHTTP, avec des paramètres généralement appliqués lors de la création d'une session et potentiellement remplacés pour une requête individuelle dans le documentation sur la configuration du proxy WinHTTP.
Un serveur proxy est un intermédiaire qui transmet une requête client à sa destination. Une liste d'exclusion est un ensemble d'hôtes que WinHTTP doit contacter directement au lieu de passer par cet intermédiaire. L'accès direct signifie qu'aucun proxy n'est configuré au niveau WinHTTP, donc les requêtes vont directement à leurs destinations, sauf si l'application applique une autre règle.
Ces paramètres peuvent exister séparément des paramètres du navigateur. WinINet est une couche de mise en réseau client Windows associée à des applications interactives plus anciennes et aux options Internet par utilisateur. Les navigateurs modernes peuvent également maintenir leur propre comportement de mise en réseau. Changer une couche ne change pas automatiquement les autres.
Cette séparation est importante pour les charges de travail pratiques :
- Les services Windows peuvent utiliser WinHTTP tandis que l'utilisateur connecté s'appuie sur une pile de navigateur.
- Les tâches planifiées peuvent s'exécuter sous une identité de service avec des identifiants et des paramètres de profil différents.
- Windows Update et les agents de gestion peuvent dépendre de la connectivité au niveau machine.
- L'automatisation en arrière-plan peut hériter de la configuration système plutôt que du proxy sélectionné dans une fenêtre de navigateur.
Les directives de mise à jour de Windows de Microsoft utilisent explicitement netsh winhttp show proxy pour vérifier la configuration du proxy avant de scanner ou de télécharger des mises à jour. La même documentation confirme que les commandes netsh winhttp peuvent s'exécuter de manière interactive à l'invite netsh ou dans des scripts et des fichiers batch, ce qui rend la commande utile pour une administration répétable plutôt que pour des vérifications ponctuelles.
Pour un client WinHTTP, netsh winhttp show proxy est donc la lecture autorisée de cette couche spécifique. Ce n'est pas un rapport universel de chaque proxy configuré sur l'ordinateur.
Exécution de la commande et lecture de la sortie
Utilisez un shell avec des droits administratifs lorsque vous devez inspecter ou modifier des paramètres au niveau machine.
- Ouvrez Démarrer et tapez
cmd. - Cliquez avec le bouton droit sur Invite de commandes et sélectionnez Exécuter en tant qu'administrateur.
- Tapez
netsh winhttp show proxyet appuyez sur Entrée.
PowerShell fonctionne également. La syntaxe de la commande est identique car PowerShell peut invoquer directement l'utilitaire Windows netsh.
Sur les configurations Windows plus récentes prises en charge, la sortie peut inclure un avis de dépréciation recommandant show advproxy. Considérez cet avis comme une directive concernant l'interface de commande, et non comme une preuve que le paramètre affiché est invalide. Le corps de la sortie vous indique toujours ce que la couche WinHTTP actuelle rapporte.
Vous interpréterez normalement l'un de ces états :
- Accès direct (pas de serveur proxy) signifie que WinHTTP n'a pas de proxy configuré à ce niveau.
- Serveur Proxy : serveur:port signifie que WinHTTP a un point de terminaison proxy configuré.
- Liste d'exclusion identifie les hôtes qui doivent être contactés directement.
La valeur du proxy est écrite sous la forme d'un hôte et d'un port, comme proxy.corp.local:8080. Une entrée d'exclusion telle que <local> représente des destinations locales ou intranet qui devraient éviter le proxy.
La commande rapporte la configuration par machine associée à HKEY_LOCAL_MACHINE, et non la configuration par utilisateur stockée sous HKEY_CURRENT_USER. Sur Windows 64 bits, certains processus 32 bits peuvent lire la vue de registre séparée WOW6432Node. Cette distinction devient importante lorsque un service et un shell de diagnostic administrateur ne semblent pas être d'accord.
Interpréter l'accès direct vs le proxy configuré
La sortie est courte, mais chaque état pointe vers un chemin d'échec différent.
Accès direct (pas de serveur proxy) signifie que la couche WinHTTP envoie des requêtes directement à leurs destinations. Un proxy de navigateur ou un paramètre d'options Internet par utilisateur ne remplace pas ce résultat pour un client WinHTTP. Si un service en arrière-plan doit traverser un proxy d'entreprise, l'accès direct peut expliquer pourquoi il ne peut pas atteindre un point de terminaison externe, tandis que le navigateur de l'utilisateur continue de fonctionner.
Un résultat configuré ressemble plus à ce conceptuellement :
Serveur Proxy : proxy.corp.local:8080Liste d'exclusion : <local>;internal.example
L'adresse du proxy identifie l'intermédiaire. La liste d'exclusion indique à WinHTTP quelles destinations doivent le contourner. Une règle d'exclusion trop large peut envoyer le trafic directement lorsqu'il devrait être inspecté ou acheminé par le chemin d'entreprise. Une règle trop étroite peut envoyer le trafic interne à un proxy qui ne peut pas résoudre ou atteindre le nom d'hôte interne.
Ne vous arrêtez pas à la présence d'une ligne de proxy. Confirmez que l'application concernée utilise WinHTTP, que le point de terminaison n'est pas couvert par une règle de contournement, et que le processus lit la même vue de registre que celle que vous avez inspectée. Un paramètre peut également être effacé par une politique ou par un autre changement administratif, laissant la machine en mode direct après que quelqu'un ait cru qu'un proxy avait été appliqué.
| Modèle de sortie | Ce que cela signifie | Échec qu'un administrateur système peut voir |
|---|---|---|
| Accès direct, pas de serveur proxy | WinHTTP n'a pas de proxy à ce niveau | Un service tente un trafic externe directement |
| Serveur proxy avec liste de contournement | WinHTTP achemine le trafic éligible via le proxy nommé | Les noms internes échouent car ils ont été envoyés par le mauvais chemin |
| Proxy présent, exclusions inattendues | Les règles de contournement modifient le routage avant que la demande n'atteigne le proxy | Certaines destinations fonctionnent tandis que d'autres échouent systématiquement |
La commande ne teste pas l'authentification, la résolution DNS, la politique de pare-feu ou les substitutions au niveau de l'application. Elle vous indique quel itinéraire WinHTTP est proposé à l'application.
WinHTTP vs WinINet vs Paramètres de Proxy du Navigateur
Considérez la configuration du proxy comme une carte de pile, et non comme un seul paramètre Windows. WinHTTP, WinINet et la configuration au niveau du navigateur peuvent coexister sur un même appareil, et chaque application décide quel niveau elle lit.
WinHTTP est le niveau orienté machine. Il sert couramment les composants Windows en arrière-plan et les applications construites contre l'API WinHTTP. WinINet est une bibliothèque cliente de niveau supérieur historiquement associée aux applications Windows interactives et aux options Internet par utilisateur. La configuration du navigateur peut suivre les paramètres du système d'exploitation, utiliser un paramètre au niveau du profil ou appliquer ses propres règles.
| Pile | Où vivent les paramètres | Utilisé par | Équivalence netsh ou navigateur |
|---|---|---|---|
| WinHTTP | Configuration WinHTTP au niveau machine | Services, tâches planifiées, processus de mise à jour et de gestion qui utilisent WinHTTP | Lire avec netsh winhttp show proxy; les changements du navigateur ne le mettent pas à jour automatiquement |
| WinINet | Options Internet par utilisateur et contexte utilisateur associé | Applications interactives héritées et clients construits pour WinINet | Non interchangeable avec netsh winhttp |
| Proxy du navigateur | Intégration du navigateur ou du système d'exploitation, selon le navigateur | Navigation interactive et flux de travail pilotés par le navigateur | Une session de navigateur fonctionnelle ne prouve pas que WinHTTP est configuré |
C'est pourquoi copier un proxy dans un paramètre de navigateur peut résoudre un test interactif tout en laissant un scraper planifié, un travailleur QA ou un service de mise à jour inchangés. L'inverse est également vrai. Exécuter netsh winhttp set proxy peut modifier le comportement au niveau machine sans changer ce qu'un utilisateur connecté voit dans les options Internet.
Pour les équipes automatisant des recherches de marché légitimes, la vérification des annonces, la surveillance des prix ou le QA géo-dépendant, identifiez la pile client avant de sélectionner une méthode d'intégration de proxy. Une référence utile pour les concepts de configuration côté application est ce guide de configuration de proxy, mais le diagnostic Windows commence toujours par le processus qui a échoué et le niveau qu'il utilise.
Le modèle mental est simple : le succès du navigateur est un résultat du navigateur, le succès de WinINet est un résultat du contexte utilisateur, et le succès de WinHTTP est un résultat du contexte machine ou service. N'utilisez pas l'un comme substitut à l'autre.
Configuration, Importation et Réinitialisation du Proxy WinHTTP
L'inspection doit précéder la modification. Si la sortie confirme que WinHTTP est le niveau impliqué, utilisez la commande pertinente délibérément et enregistrez l'état précédent.
Une configuration explicite traditionnelle ressemble à ceci :
netsh winhttp set proxy proxy-server="proxy.corp.local:8080" bypass-list="<local>;internal.example"
La valeur proxy-server identifie le point de terminaison, tandis que bypass-list contient les destinations qui devraient se connecter directement. Microsoft considère désormais l'ancienne méthode set proxy et show proxy comme une administration héritée pour les configurations plus récentes. Pour la découverte automatique, le routage basé sur PAC, ou des paramètres d'entreprise plus avancés, utilisez les commandes advproxy à la place :
netsh winhttp show advproxynetsh winhttp set advproxy
L'importation est une autre option :
netsh winhttp import proxy source=ie
Cette commande copie la configuration WinINet actuelle par utilisateur dans le contexte WinHTTP au niveau machine. Cela peut être pratique lorsque les paramètres de l'utilisateur sont connus pour être corrects, mais cela peut également vous surprendre sur un serveur multi-utilisateurs car une configuration de contexte utilisateur devient un paramètre à l'échelle de la machine.
Pour revenir à un accès direct avec WinHTTP, utilisez :
netsh winhttp reset proxy
Microsoft avertit spécifiquement de ne pas compter sur netsh winhttp set proxy pour l'Optimisation de la Livraison car cela ne fournit pas de détection automatique, de support d'URL PAC, ou de support d'authentification de proxy. Cela rend le set proxy explicite peu adapté aux flux de travail d'entreprise qui dépendent de la découverte automatique ou des chaînes de proxy authentifiées. Pour des informations sur les concepts de découverte automatique, consultez ce guide de configuration de proxy automatique.
Exécutez l'invite de commandes en tant qu'administrateur, puis suivez cet ordre :
- Lire l'état actuel.
- Changer un paramètre.
- Exécuter à nouveau
show proxyoushow advproxy. - Tester depuis le contexte du service affecté.
- Réinitialiser si le changement aggrave l'incident.
Une mauvaise valeur au niveau machine peut affecter chaque client WinHTTP sur l'hôte, pas seulement l'application que vous étiez en train d'examiner.
Incompatibilités de Proxy Courantes Révélées par la Commande
Les échecs de proxy Windows douloureux ne sont généralement pas causés par une configuration manifestement vide. Ils proviennent d'une configuration qui semble correcte dans un contexte et incorrecte dans un autre.
| Modèle d'incompatibilité | Symptôme | Cause racine typique |
|---|---|---|
| Le navigateur a un proxy, WinHTTP signale un accès direct | La navigation interactive fonctionne, mais un service ne peut pas atteindre son point de terminaison | Le paramètre utilisateur n'a jamais été appliqué au niveau WinHTTP de la machine |
set proxy a été exécuté, mais le service le contourne toujours |
L'administrateur voit un proxy dans un test, tandis que le service continue des connexions directes | Le processus utilise une autre pile, un contexte de compte ou une vue de registre |
| Le comportement 32 bits et 64 bits diffère | Une application fonctionne tandis qu'une autre échoue sur le même hôte | Les processus lisent différentes vues de registre WOW64 et natives |
| Les destinations internes échouent après la configuration du proxy | Les demandes externes fonctionnent, mais les appels de service locaux échouent | La liste de contournement n'inclut pas les destinations internes requises |
Le premier modèle est le piège classique du navigateur contre le service. Un utilisateur configure un proxy via les options Internet ou une interface de navigateur, mais la commande WinHTTP renvoie un accès direct. Windows Update et d'autres clients au niveau machine peuvent alors suivre un chemin différent de celui du navigateur.
Le deuxième modèle apparaît souvent après un changement précipité. L'opérateur exécute set proxy, confirme que la commande est terminée, et suppose que chaque processus utilise désormais la valeur. Le service affecté peut ne pas utiliser WinHTTP du tout, ou il peut s'exécuter dans un contexte qui a des paramètres de niveau utilisateur et des substitutions d'application différents.
Le troisième modèle mérite une vérification de la vue de registre. Un processus 32 bits sous WOW64 peut lire HKLM\SOFTWARE\WOW6432Node, tandis qu'un service 64 bits lit la vue native de la machine. Les scripts qui modifient directement le registre peuvent mettre à jour une vue et laisser l'autre inchangée. Réexécutez le diagnostic après chaque changement et comparez le résultat avec le comportement du processus réel.
Dépannage des Problèmes de Proxy WinHTTP Étape par Étape
Utilisez un processus par couches. Changer les valeurs de proxy à plusieurs reprises sans identifier la pile client crée du bruit et peut perturber des services non liés.
- Identifier la pile. Confirmez si l'application en échec utilise WinHTTP, WinINet, une configuration gérée par le navigateur, ou un paramètre spécifique à l'application. Ne pas utiliser le succès du navigateur comme preuve pour un service.
- Lire l'état de la machine. Dans une invite de commande administrateur, exécutez
netsh winhttp show proxyet enregistrez si le résultat est un accès direct ou un proxy configuré. - Vérifier le chemin. Vérifiez que l'hôte et le port du proxy configuré sont accessibles depuis la machine affectée et que la cible n'est pas accidentellement couverte par une règle de contournement.
- Vérifier le contexte du processus. Confirmez si le processus est en 32 bits ou en 64 bits, puis comparez la vue du registre WinHTTP natif avec la vue
WOW6432Nodelorsque cela est applicable. - Reproduire dans l'identité du service. Si le processus s'exécute en tant que LocalSystem, ouvrez un shell de diagnostic avec
psexec -s -i cmd, exécutez la même commande et comparez le résultat.
Pour un traçage plus approfondi, utilisez netsh winhttp show tracing pour activer le traçage, reproduisez l'échec, puis désactivez le traçage afin que les journaux de diagnostic ne s'accroissent pas inutilement. Corrélez l'échec de la demande avec le Visualiseur d'événements sous Journaux des applications et des services, Microsoft, Windows, WinHttp.
Les emplacements du registre à vérifier sont HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp et son frère WOW6432Node. Si vous avez besoin d'une liste de contrôle pratique pour les échecs de connexion, ce guide sur un proxy refusant des connexions peut compléter les vérifications côté Windows.
Cas d'utilisation de l'automatisation qui dépendent de WinHTTP
Une erreur de pile proxy devient un problème opérationnel lorsqu'elle affecte un processus que personne ne surveille. Windows Update, Delivery Optimization, agents de gestion et autres composants en arrière-plan peuvent dépendre de WinHTTP. Une machine peut encore sembler saine pour son opérateur connecté tandis que la récupération de correctifs, la télémétrie, l'inscription ou les demandes réseau liées aux certificats échouent en arrière-plan.
La commande compte également pour l'automatisation native de Windows. Un travail planifié qui interroge une API, synchronise des données, vérifie des prix, vérifie des emplacements publicitaires ou exécute un flux de travail QA conforme peut hériter du réseau au niveau de la machine plutôt que du proxy du navigateur. Si le travail s'exécute sous un compte de service, testez le contexte de ce compte au lieu de supposer que la session de l'administrateur est représentative.
Un proxy qui fonctionne dans un navigateur interactif n'est pas automatiquement un proxy qui fonctionne pour l'automatisation.
Le type de proxy est une décision distincte de la sélection de la pile Windows. Les proxies de datacenter fournissent généralement des adresses hébergées par l'infrastructure et une connectivité prévisible. Les proxies résidentiels utilisent des adresses associées à des réseaux d'accès résidentiels. Les proxies mobiles utilisent des connexions de transporteur 4G ou 5G, où le NAT de niveau transporteur peut placer de nombreux abonnés derrière un espace d'adresses mobiles partagé.
Les IP mobiles peuvent être plus difficiles à classifier et à bloquer pour les services que les adresses de datacenter car elles ressemblent à un trafic ordinaire de transporteur, mais cela ne supprime pas la nécessité d'un contrôle de taux responsable, de la propriété du compte, de la conformité à la plateforme ou d'une identification précise. Choisissez HTTP ou HTTPS pour les clients qui parlent ces protocoles, et SOCKS5 lorsque l'application le prend en charge spécifiquement. Alignez ensuite la rotation, les sessions collantes, l'ASN et le ciblage géographique avec le flux de travail au lieu de traiter la rotation comme un substitut à une conception d'automatisation solide.
Référence rapide pour les sous-commandes Netsh WinHTTP
Utilisez un shell administrateur pour les modifications. Lisez la sortie après chaque modification et rappelez-vous que les processus en 32 bits et en 64 bits peuvent utiliser différentes vues du registre.
| Sous-commande | But | Quand l'utiliser |
|---|---|---|
show proxy |
Affiche l'état traditionnel du proxy WinHTTP | Vérification rapide de compatibilité lors du triage |
show advproxy |
Affiche la configuration avancée du proxy plus récente | Préféré pour les configurations modernes |
show state |
Montre l'état de configuration de WinHTTP | Inspecter le contexte de commande plus large |
set proxy proxy-server="host:port" bypass-list="hosts" |
Applique un proxy explicite traditionnel | Environnements hérités ou simples contrôlés |
set advproxy |
Applique des paramètres de proxy avancés | PAC, détection automatique ou configuration d'entreprise moderne |
import proxy source=ie |
Copie le proxy utilisateur actuel dans WinHTTP | Utilisez uniquement lorsque la configuration utilisateur est connue pour être appropriée à l'échelle de la machine |
reset proxy |
Restaure l'accès direct à WinHTTP | Supprimer une configuration de proxy traditionnel défectueuse |
show tracing |
Contrôle le traçage de diagnostic WinHTTP | Capturer un échec de demande reproductible, puis le désactiver |
La référence de commande WinHTTP de Microsoft documente l'utilisation interactive et scriptée, ce qui est utile lorsque ces vérifications font partie d'un script de déploiement ou de conformité.
Questions Fréquemment Posées sur la Commande
Pourquoi le navigateur peut-il fonctionner lorsque WinHTTP signale un accès direct
Ils peuvent utiliser des piles de proxy séparées. Un navigateur ou une configuration par utilisateur ne remplit pas automatiquement le paramètre WinHTTP au niveau de la machine.
La commande fonctionne-t-elle dans PowerShell
Oui. Ouvrez PowerShell avec des droits administratifs et exécutez netsh winhttp show proxy exactement comme vous le feriez dans l'invite de commande.
Comment les fichiers PAC s'intègrent-ils dans cela
Un fichier PAC fournit une logique de sélection automatique de proxy. Utilisez le chemin de configuration avancée WinHTTP pour PAC ou la découverte automatique plutôt que de traiter la syntaxe traditionnelle set proxy comme un remplacement complet.
Que se passe-t-il sans élévation
Vous pouvez être en mesure de lire certaines informations, mais les modifications au niveau de la machine nécessitent un shell avec des droits administratifs. Si un changement semble ne pas affecter le service, rouvrez le shell en tant qu'administrateur et vérifiez le résultat.
Pourquoi un processus 32 bits pourrait-il ne pas être d'accord avec un service 64 bits
Sous WOW64, les processus 32 bits et 64 bits peuvent lire des vues de registre séparées. Vérifiez la vue utilisée par le processus en échec au lieu de vous fier au résultat d'un shell non lié.
Choisir une couche de proxy fiable pour vos flux de travail
La commande vous indique si la machine Windows achemine le trafic WinHTTP directement ou via un intermédiaire configuré. Elle ne décide pas si l'intermédiaire convient à votre flux de travail.
Pour la gestion de plusieurs comptes sur les réseaux sociaux, la vérification des annonces, la recherche de marché, la surveillance des prix et du SEO, la protection de marque et le QA dépendant de la géographie, considérez d'abord le modèle de trafic. Les sessions collantes aident à préserver la continuité lorsque le flux de travail dépend de la même IP. La rotation est utile lorsque des tâches légitimes séparées nécessitent différentes sorties. ASN et géographie sont importants lorsque vous validez comment un service se comporte pour un réseau de transporteur ou un emplacement. Le support HTTP, HTTPS et SOCKS5 doit correspondre au client qui consommera le proxy.
Les proxies mobiles 4G peuvent s'adapter aux flux de travail où la présence du réseau de transporteur est plus importante qu'une sortie de datacenter. Utilisez-les avec une propriété de compte claire, une automatisation conservatrice et le respect des règles de chaque plateforme. Evoproxy propose un accès à des proxies mobiles pour des flux de travail conformes sur les réseaux sociaux, la vérification, la recherche et les tests, offrant aux équipes une autre couche à évaluer après avoir confirmé quelle pile Windows leur application utilise.
Si votre service, votre travail de vérification ou votre flux de travail multi-comptes nécessite un routage basé sur le transporteur, testez les proxies mobiles 4G contre le contexte WinHTTP exact qui a échoué. Visitez Evoproxy pour examiner une option de proxy mobile pour votre cas d'utilisation et valider la configuration avant de la déployer sur vos hôtes d'automatisation Windows.
