Charles est fermé, mais votre Mac pointe toujours vers 127.0.0.1

Une application échoue et le VPN est blâmé, mais la requête n’atteint jamais le tunnel. Si macOS dit encore à cette application d’utiliser un proxy local, le premier saut est 127.0.0.1 et rien n’y écoute. Fermer Charles n’efface pas toujours le réglage de proxy système qu’il a installé, si bien qu’un VPN sain reste derrière une socket morte. Voici l’ordre pour le confirmer et ne réparer que la pièce fautive.

Le premier saut est ce Mac, pas le serveur

Lisez l’adresse littéralement : 127.0.0.1 est la machine devant vous, et le port est celui sur lequel l’outil de proxy était configuré pour écouter. Quand cet écouteur disparaît, la connexion échoue immédiatement par un refus de connexion plutôt que par un délai d’attente, et c’est l’indice utile.

Un VPN ne crée pas ses propres réglages de proxy et ne supprime pas ceux du système. Les deux configurations sont indépendantes, c’est pourquoi le tunnel peut être parfait et le navigateur inutilisable. Cette indépendance explique aussi pourquoi la panne survit à une reconnexion du VPN, à un redémarrage et à un profil neuf. Rien dans le chemin du VPN ne touche jamais le magasin de proxy.

Étape 1 : lisez l’état actuel du proxy

Commencez par la vue en lecture seule, car elle indique ce que le système croit avant qu’une application ne l’interprète :

scutil --proxy

Regardez HTTPEnable, HTTPProxy, HTTPPort, les équivalents HTTPS et tout ProxyAutoConfigEnable avec son URL. Un proxy activé sur un port où rien n’écoute est votre panne. Une URL PAC est l’autre forme : le réglage peut être actif sans adresse manuelle visible, parce que le fichier choisit le proxy au moment de la requête.

Confirmez ensuite les mêmes valeurs dans Réglages du système, Réseau, le service que vous utilisez réellement, Détails, Proxys. L’interface graphique et la commande lisent le même magasin, donc un désaccord signifie que vous regardez un autre service.

Étape 2 : trouvez qui possède le réglage

Trois propriétaires produisent cet état : un outil de proxy qui a installé un assistant et ne l’a pas nettoyé, un profil de configuration géré par votre organisation et un réglage manuel ajouté par quelqu’un pendant un débogage. Chacun a une correction correcte différente, et seul le premier est à vous de retirer sans hésiter.

Charles documente son intégration avec le navigateur et le proxy système, y compris l’assistant macOS, alors utilisez d’abord ses propres contrôles et son chemin d’arrêt. L’assistant privilégié existe pour modifier la configuration ; ce n’est pas une raison de donner à un logiciel sans rapport un accès étendu à la machine.

Si le réglage vient d’un profil géré, le désactiver localement échoue ou est rétabli à la prochaine vérification. Traitez cela comme une question de politique pour le propriétaire du profil, pas comme un bug local.

Étape 3 : changez la chose la plus étroite

Désactivez l’entrée involontaire précise pour le service précis. Ne basculez pas chaque service et ne videz pas tout le panneau proxy, car le service VPN et le service Wi-Fi sous-jacent gardent des réglages séparés et l’un d’eux peut être correct.

Si le proxy est requis volontairement, démarrez son écouteur approuvé au lieu de supprimer la politique. Cette distinction compte dans les organisations où le proxy est la seule route vers internet et le VPN un second chemin, plus étroit.

Réessayez une requête neuve depuis l’application affectée. Certaines applications lisent le proxy une seule fois au lancement, donc quitter et rouvrir fait partie du test et non d’une superstition.

Étape 4 : si le proxy a disparu et que cela échoue encore

Alors vous avez un autre problème, et la nouvelle erreur est la preuve utile. La résolution de noms, le routage du VPN, la confiance TLS et l’autorisation des applications sont quatre vérifications distinctes, et chacune produit une panne reconnaissable.

Gardez la confiance des certificats hors de cette réparation. Retirer une racine de confiance ou affaiblir la validation du serveur ne répare pas une socket de proxy morte et vous laisse avec deux changements et une panne d’origine. Si un proxy d’entreprise inspecte TLS, c’est une conception délibérée avec sa propre exigence de confiance, pas un effet de bord à annuler. Demandez à l’équipe qui possède le proxy avant de toucher un certificat, car sa réponse portera sur la politique et la vôtre sur une requête échouée.

Écrivez le retour arrière avant de commencer : notez les valeurs exactes de proxy que vous avez trouvées, pour que la restauration soit une copie et non un exercice de mémoire. La documentation de configuration du proxy Charles décrit l’intégration et son comportement à l’arrêt pour la version que vous utilisez.

La prochaine fois qu’une application échoue sur un VPN, vérifiez le premier saut avant le tunnel. Cela coûte une commande et écarte toute une catégorie de mauvais diagnostic.