Le VPN fonctionne, mais une appli n’a pas Internet ? Vérifiez son proxy

Votre tunnel est monté, la page d’état affiche un handshake sain, et une application ne charge toujours rien. Cette application envoie probablement encore ses requêtes à un intermédiaire plus ancien : un proxy système, une extension, un fichier de configuration poussé par la gestion des appareils ou une variable de proxy que seul son propre processus lit. Changer de serveur VPN ne touchera pas à ce réglage, et cela explique le schéma où les autres applications fonctionnent depuis la même machine. Travaillez depuis l’application en panne vers l’extérieur, et laissez le tunnel tranquille jusqu’à ce que la question du proxy soit réglée.

Quelle couche possède le réglage du proxy

Quatre endroits peuvent revendiquer l’autorité sur les requêtes d’une application, et le plus étroit gagne généralement. Le système d’exploitation détient un proxy global et une URL de configuration automatique facultative ; un navigateur peut la suivre, la remplacer ou confier le contrôle à une extension ; un outil en ligne de commande lit son propre environnement ; et une stratégie gérée peut épingler tout cela après une modification. Décidez quelle couche est responsable avant de modifier quoi que ce soit, car effacer la mauvaise couche ressemble à une correction réussie qui revient à la prochaine connexion.

Comparez deux applications sur le même site ordinaire plutôt que sur une page de test réservée au VPN. Si le navigateur échoue alors qu’un téléchargement en terminal réussit, le système d’exploitation n’est pas le problème, et la différence se situe dans le profil du navigateur ou ses extensions. Si les deux échouent mais qu’un second compte utilisateur sur la même machine réussit, le réglage est propre à l’utilisateur. Cette comparaison coûte une minute et élimine l’essentiel des suppositions.

Lisez la valeur que chaque outil utilise réellement

Imprimez la configuration avant de la modifier, et copiez la chaîne de proxy exacte quelque part où vous pouvez la restaurer. Les variables du shell sont le contrôle le plus rapide pour les outils en ligne de commande, car un client VPN les laisse normalement intactes.

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

N’exécutez que la ligne qui correspond à la plateforme devant vous, puis lisez la sortie pour l’hôte, le port et les identifiants. Une valeur comme http://proxy.corp.example:8080 signifie que l’outil interroge cet hôte pour chaque requête, tandis qu’un résultat vide signifie qu’il passe en direct et que la vraie panne se trouve ailleurs. Masquez la partie utilisateur et mot de passe avant de coller la sortie dans un ticket, car ces chaînes sont bien plus souvent des identifiants actifs qu’on ne le suppose.

Les outils dotés de leur propre moteur de proxy ont besoin de leurs propres preuves. Curl indique la décision qu’il a prise quand vous augmentez la verbosité, ce qui vaut mieux que de deviner à partir de l’environnement, et le même indicateur montre si la résolution de nom a eu lieu localement ou au niveau du proxy.

Effacez la dérogation et retestez la même requête

Modifiez une couche, puis répétez exactement la requête qui a échoué, car une autre URL ne prouve rien. Effacez d’abord les variables d’environnement dans le shell courant, puisque cette modification est réversible et ne peut pas casser le tunnel :

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

Si la sortie verbeuse annonce encore un proxy, l’environnement n’était pas l’autorité. Montez d’un niveau au lieu d’empiler d’autres dérogations.

Sur macOS, vérifiez qu’un fichier de configuration automatique ne fournit pas la valeur, puis désactivez le proxy du service et confirmez la modification. Sous Windows, rappelez-vous que le réglage WinHTTP et le réglage du navigateur par utilisateur sont des objets différents, si bien qu’un outil en ligne de commande propre peut coexister avec un navigateur qui pointe encore vers un ancien serveur. Les extensions méritent la même méfiance : une extension de proxy peut réécrire les requêtes pour un seul profil, ce qui correspond exactement à une panne qui touche un navigateur et rien d’autre.

Vérifiez que la correction survit à un redémarrage

Un réglage qui ne fonctionne que dans le terminal que vous avez modifié n’est pas corrigé. Rouvrez l’application depuis le lanceur du bureau, déconnectez-vous puis reconnectez-vous, et regardez si l’ancien proxy revient.

Deux contrôles séparent une vraie correction d’une temporaire, et les deux devraient signaler une connexion directe ou la valeur voulue. L’exécution en environnement propre montre si un processus épuré reprend encore un réglage système.

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

Si l’ancienne valeur revient après un redémarrage, la source est une stratégie gérée ou un profil qui la réapplique, et le propriétaire de cette stratégie doit retirer l’exception. Laissez la vérification des certificats activée tout du long, car un proxy qui intercepte le trafic semblera sinon résolu dès que vous désactivez les contrôles. Terminez en notant la valeur retirée et la date dans vos notes, afin que la personne suivante puisse distinguer un proxy intentionnel d’un proxy oublié.