Le serveur proxy ne répond pas : diagnostic étape par étape des timeouts, ports et pare-feu

Introduction : ce que vous allez apprendre dans ce guide

La situation est familière à tous ceux qui travaillent avec des proxys : hier tout filait, aujourd'hui le navigateur tourne dans le vide, votre script de scraping se bloque dès la première requête, et votre navigateur antidetect indique que le serveur proxy ne répond pas. Aucun message clair, juste de l'attente et du silence. On a envie d'écrire au support ou de changer de fournisseur, mais dans la plupart des cas, la cause est de votre côté et se règle en dix minutes.

Ce guide pratique vous aidera à passer de « rien ne fonctionne » à « connexion stable » sans tâtonner. Nous allons examiner les trois coupables réseau les plus fréquents : les timeouts, les ports fermés ou incorrects et le pare-feu. Vous apprendrez à identifier où exactement la chaîne se rompt entre votre ordinateur et le proxy, et vous obtiendrez une série de commandes qui révèlent la source du problème en une minute.

Périmètre important : nous ne parlons ici que des causes réseau, lorsque la connexion ne s'établit pas du tout ou reste bloquée. Les cas où le proxy répond mais renvoie un code d'erreur comme 407 ou 502 sont un autre sujet et ne sont pas traités ici. Si vous voyez un code HTTP spécifique dans la réponse, cela signifie que le proxy est vivant et que votre cas ne concerne pas cet article.

À qui s'adresse ce guide

• Aux marketeurs et spécialistes SMM qui gèrent plusieurs comptes via des proxys mobiles et dont le navigateur ne se connecte plus.
• Aux arbitrageurs dont les setups ont soudainement cessé de fonctionner et dont les comptes publicitaires ne s'ouvrent plus via le proxy.
• Aux développeurs dont les scripts Python, Node.js ou Go reçoivent un timeout au lieu d'une réponse.
• Aux dirigeants qui ont configuré un proxy pour leurs employés et veulent comprendre pourquoi cela fonctionne pour l'un mais pas pour l'autre.

Ce qu'il faut savoir au préalable

Pratiquement rien de spécial. Il suffit de savoir ouvrir une invite de commandes ou un terminal, copier des commandes et lire ce qu'elles affichent. Tous les termes seront expliqués au fur et à mesure. Si vous n'avez jamais ouvert un terminal, pas d'inquiétude : chaque action est décrite au niveau « appuyez sur cette touche, tapez ce texte ».

Combien de temps cela prendra

Le diagnostic complet de toutes les étapes prend entre 30 et 60 minutes. Le plus souvent, le problème est détecté à la première ou deuxième étape, et vous vous en sortirez en 10-15 minutes. La section avancée à la fin peut être étudiée séparément, une fois la connexion de base rétablie.

Préparation : outils et données

Avant de commencer, rassemblez tout le nécessaire au même endroit. Cela vous fera gagner du temps et évitera de courir entre les onglets au mauvais moment.

Les données de votre proxy

Ouvrez l'espace client de votre fournisseur et notez dans un fichier texte les paramètres suivants. Ils seront nécessaires à presque chaque étape.

1. Adresse du serveur (host). Soit un nom de domaine comme proxy.example.net, soit une adresse IP comme 185.10.20.30.
2. Port pour la connexion HTTP. Pour les proxys mobiles, c'est souvent un nombre à cinq chiffres, par exemple 30001 ou 51234.
3. Port SOCKS5, si le fournisseur le fournit séparément. Il diffère parfois du port HTTP d'une unité ou de plusieurs milliers.
4. Identifiant et mot de passe pour l'authentification, si vous utilisez l'authentification par identifiants.
5. Liste des IP autorisées, si l'authentification par IP est activée. Vérifiez quelle adresse y figure.
6. Lien de changement d'IP et informations sur le mode de rotation : planifiée, par lien ou à chaque requête.

Conseil : conservez ces données non seulement dans votre gestionnaire de mots de passe, mais aussi dans un simple fichier texte pendant le diagnostic. Vous les collerez dans des commandes des dizaines de fois, et passer constamment d'une fenêtre à l'autre est fatigant.

Les outils déjà présents sur votre système

Bonne nouvelle : presque tout ce dont vous avez besoin est intégré au système d'exploitation. Rien à acheter.

• Windows 10 et 11 : PowerShell (recherchez-le dans le menu Démarrer) et l'invite de commandes cmd. PowerShell dispose de la commande Test-NetConnection qui remplace des utilitaires séparés.
• macOS : l'application Terminal (Applications, dossier Utilitaires). Les utilitaires nc et curl sont déjà installés.
• Linux (Ubuntu, Debian, Fedora) : n'importe quel terminal. Il faudra peut-être installer les paquets curl, netcat et mtr via le gestionnaire de paquets de votre système.

Ce qu'il est conseillé d'installer en plus

1. curl pour Windows. Dans Windows 10 version 1803 et ultérieure, ainsi que Windows 11, curl est déjà présent. Vérifiez : ouvrez cmd et tapez curl --version. Si vous voyez un numéro de version, tout va bien.
2. Un second appareil pour comparer : un smartphone, un second ordinateur portable ou une machine virtuelle. Ce n'est pas un logiciel, mais un outil très utile dont nous parlerons à la première étape.
3. L'accès aux paramètres du routeur : l'adresse du panneau (le plus souvent 192.168.0.1 ou 192.168.1.1) et le mot de passe administrateur. Nécessaire à la cinquième étape.

Sauvegardes avant de commencer

Nous allons modifier les paramètres du pare-feu et, éventuellement, du routeur. Avant cela, faites deux choses pour pouvoir toujours revenir à l'état initial.

1. Sous Windows, créez un point de restauration : ouvrez la recherche, tapez « Créer un point de restauration », cliquez sur Créer et donnez-lui un nom clair, par exemple « Avant configuration proxy ».
2. Exportez les règles actuelles du pare-feu Windows. Ouvrez PowerShell en tant qu'administrateur et exécutez la commande netsh advfirewall export "C:/firewall-backup.wfw". Le fichier apparaîtra à la racine du disque C.
3. Dans le panneau du routeur, trouvez une section comme « Système », « Maintenance » ou « Sauvegarde » et enregistrez le fichier de configuration sur votre ordinateur.

Attention : ne désactivez pas complètement le pare-feu « au cas où » et ne le laissez pas désactivé. Pendant le diagnostic, nous désactiverons la protection deux minutes maximum pour tester une hypothèse, puis nous remettrons tout en place et créerons une règle ciblée.

Notions de base : ce qui se passe quand le proxy ne répond pas

Pour que le diagnostic ait du sens et ne soit pas une recherche chaotique, il est important de comprendre comment la chaîne de connexion est structurée. Ainsi, chaque étape du guide vérifiera un segment précis de cette chaîne.

Le parcours d'une requête de vous jusqu'au site

Lorsque vous travaillez via un proxy mobile, la requête suit ce chemin. D'abord, votre application (navigateur, script, antidetect) envoie les données au système d'exploitation. Le système les fait passer par son pare-feu et les transmet au routeur. Le routeur transmet le trafic à votre fournisseur d'accès Internet. Le fournisseur achemine les paquets jusqu'au serveur proxy. Le serveur proxy redirige la requête via un modem mobile avec carte SIM vers le réseau de l'opérateur cellulaire. Et seulement ensuite, la requête part vers le site cible. La réponse suit le même chemin en sens inverse.

Une coupure peut survenir à n'importe quel maillon de cette chaîne. La phrase « le serveur proxy ne répond pas » signifie en réalité une seule chose : la réponse n'est pas parvenue à votre application dans le délai imparti. Où exactement elle s'est perdue, c'est ce qu'il faut déterminer.

Le port : la porte d'entrée du serveur

Un serveur a une seule adresse IP, mais de nombreux ports, numérotés de 1 à 65535. Imaginez un immeuble avec une seule adresse et des milliers d'appartements. Le service proxy « habite » dans un appartement précis, c'est-à-dire écoute un port précis. Si vous frappez à un autre port, personne n'ouvrira, et vous attendrez jusqu'à expiration du timeout. Et le serveur, lui, est parfaitement fonctionnel.

Les ports peuvent être ouverts, fermés ou filtrés. Un port ouvert répond à la tentative de connexion par un accord. Un port fermé répond immédiatement par un refus, et vous obtenez une erreur instantanée comme « connection refused ». Un port filtré reste silencieux : vos paquets sont jetés en route et vous ne recevez rien. C'est précisément le filtrage qui donne l'image classique d'un blocage sans réponse, et le coupable est presque toujours un pare-feu quelque part.

Timeout : combien de temps attendre avant d'abandonner

Un timeout est la limite d'attente après laquelle l'application arrête sa tentative et signale une erreur. Il existe plusieurs types de timeouts, et il ne faut pas les confondre.

• Timeout de connexion (connect timeout). Combien de temps attendre que le serveur accepte d'établir la liaison. S'il expire, cela signifie que vous n'avez pas du tout atteint le port proxy.
• Timeout de lecture (read timeout). Combien de temps attendre les données après que la connexion est établie. S'il expire, cela signifie que le proxy vous a accepté, mais que le site cible ou le réseau mobile répondait trop lentement.
• Timeout global de la requête. La limite supérieure pour l'ensemble.

Les proxys mobiles fonctionnent via le réseau cellulaire, où les latences sont naturellement plus élevées que pour les datacenters. Si votre logiciel est configuré avec un timeout de 5 secondes, il peut se déconnecter d'un proxy mobile parfaitement fonctionnel simplement parce que la réponse est arrivée à la sixième seconde.

Pare-feu : le filtre qui décide de ce qu'il faut laisser passer

Un pare-feu (firewall) est un programme ou un dispositif qui examine les paquets réseau et décide de les laisser passer ou de les rejeter. Dans votre chaîne, il peut y avoir trois ou quatre pare-feu : celui intégré à Windows ou macOS, celui de votre antivirus, celui du routeur et celui d'un administrateur d'entreprise. N'importe lequel peut silencieusement rejeter les paquets sur un port non standard, et vous ne verrez qu'un blocage.

Authentification par IP : le pare-feu invisible côté proxy

De nombreux fournisseurs de proxys mobiles proposent un mode où, au lieu d'un identifiant et d'un mot de passe, une liste blanche d'adresses IP est utilisée. Le serveur n'accepte les connexions que des adresses de la liste et peut simplement ignorer les autres tentatives. Si votre IP domestique a changé (cela arrive lors du redémarrage du routeur chez la plupart des fournisseurs), le proxy ne vous reconnaîtra plus. Extérieurement, cela ressemble exactement à un port bloqué.

Maintenant que le tableau est clair, passons à la pratique. Chaque étape suivante vérifie un segment de la chaîne et soit écarte un suspect, soit trouve le coupable.

Étape 1 : déterminer où la connexion se rompt

Objectif : comprendre en cinq minutes si le problème vient de votre côté, du côté du réseau ou du côté du proxy. C'est l'étape la plus importante, car elle élimine d'emblée la moitié des causes possibles.

Vérifier Internet sans proxy

1. Ouvrez votre navigateur et désactivez temporairement le proxy dans ses paramètres. Dans Chrome, c'est Paramètres, section Système, « Ouvrir les paramètres de proxy de l'ordinateur ». Dans un navigateur antidetect, créez un profil sans proxy ou choisissez le mode « Sans proxy » dans les paramètres du profil.
2. Ouvrez n'importe quel grand site, par exemple une page de moteur de recherche. Elle doit se charger en une ou deux secondes.
3. Si le site ne s'ouvre pas non plus sans proxy, le problème ne vient pas du proxy. Redémarrez le routeur, vérifiez le câble ou le Wi-Fi et revenez à ce guide plus tard.

Vérifier le proxy depuis un autre appareil

1. Prenez un smartphone et désactivez le Wi-Fi pour qu'il fonctionne via Internet mobile. Vous serez ainsi dans un réseau complètement différent, sans passer par votre routeur ni votre fournisseur.
2. Installez sur le téléphone un navigateur compatible proxy ou utilisez les paramètres système : sur Android, dans les propriétés du point d'accès, cela se fait via APN, mais il est plus simple d'installer une application de navigateur avec saisie manuelle du proxy.
3. Saisissez l'adresse, le port, l'identifiant et le mot de passe de votre proxy, puis ouvrez n'importe quel site affichant votre adresse IP.
4. Si le proxy fonctionne depuis le téléphone, cela signifie que le proxy lui-même est vivant et que le problème se situe entre votre ordinateur et Internet : pare-feu, routeur ou paramètres du logiciel. Passez aux étapes 2, 3, 4 et 5.
5. Si cela ne fonctionne pas non plus depuis le téléphone, le problème vient soit du proxy lui-même, soit de ses paramètres d'authentification. Passez à l'étape 6, puis contactez le support.

Conseil : si vous n'avez pas de second appareil, essayez de connecter votre ordinateur au point d'accès mobile de votre téléphone. Le changement de réseau produira le même effet qu'une vérification depuis un autre appareil.

Vérifier le statut du proxy dans l'espace client

1. Connectez-vous à l'espace client de votre fournisseur de proxys mobiles.
2. Trouvez la fiche de votre proxy et regardez l'indicateur d'état. Chez la plupart des services, il indique si le modem est en ligne et quand a eu lieu la dernière activité.
3. Si l'indicateur montre que le proxy est déconnecté ou que le modem n'est pas en ligne, inutile de continuer le diagnostic : la cause est du côté de l'équipement et c'est le support qui la résoudra.

Vérification : à la fin de cette étape, vous devez avoir une réponse à une question : le proxy fonctionne-t-il au moins depuis quelque part, ou ne fonctionne-t-il de nulle part. Notez cette conclusion. Elle détermine quelles étapes seront les plus importantes par la suite.

Problèmes possibles à cette étape

Parfois, le proxy fonctionne depuis le téléphone puis cesse de fonctionner une minute plus tard. Cela peut être dû à la rotation d'IP sur le proxy ou à un réseau cellulaire instable au niveau du modem. Répétez la vérification deux ou trois fois à une minute d'intervalle pour ne pas tirer de fausses conclusions d'une seule tentative.

Étape 2 : vérifier l'adresse et le port du proxy

Objectif : s'assurer que le port du proxy est ouvert et accessible précisément depuis votre ordinateur. C'est la vérification clé : si le port ne répond pas, tout le reste est inutile.

Pourquoi ping ne convient pas

La première idée de beaucoup : pinguer le serveur. Mais ping ne vérifie que la disponibilité de l'adresse IP via le protocole ICMP, pas l'ouverture d'un port précis. De nombreux serveurs proxy ne répondent pas du tout au ping pour des raisons de sécurité. Donc un ping réussi ne garantit rien, et un ping échoué ne signifie rien. Nous avons besoin de vérifier précisément le port TCP.

Vérification du port sous Windows

1. Appuyez sur la touche Windows, tapez PowerShell et ouvrez-le.
2. Saisissez la commande en remplaçant par vos adresse et port :

   Test-NetConnection -ComputerName proxy.example.net -Port 30001

3. Appuyez sur Entrée et attendez. La commande peut mettre jusqu'à 20 secondes.
4. Cherchez dans la sortie la ligne TcpTestSucceeded. La valeur True signifie que le port est ouvert et accepte les connexions. La valeur False signifie que le port n'est pas joignable.
5. Notez la ligne PingSucceeded. Si elle est False et que TcpTestSucceeded est True, tout va bien : le serveur ne répond simplement pas au ping.

Vérification du port sous macOS et Linux

1. Ouvrez le Terminal.
2. Saisissez la commande :

   nc -zv proxy.example.net 30001

3. L'option -z indique à l'utilitaire de ne pas envoyer de données, mais seulement de vérifier la connexion. L'option -v active la sortie détaillée.
4. Une réponse du type succeeded ou Connection to ... port 30001 succeeded! signifie un succès. La réponse Connection refused signifie que le port est fermé et que le serveur a immédiatement refusé. Si la commande reste sans réponse puis affiche timed out, le port est filtré quelque part en chemin.

Vérification via curl sur n'importe quel système

curl peut non seulement vérifier le port, mais aussi effectuer immédiatement une requête via le proxy. C'est le niveau de vérification suivant.

1. Saisissez la commande en remplaçant par vos données :

   curl -x http://login:password@proxy.example.net:30001 --connect-timeout 15 -v https://api.ipify.org

2. L'option -x définit le proxy. L'option -v affiche toutes les étapes de la connexion. L'option --connect-timeout limite l'attente d'établissement de la liaison à 15 secondes.
3. Lisez la sortie de haut en bas. La ligne Connected to proxy.example.net signifie que le port est ouvert. La ligne CONNECT api.ipify.org:443 montre que curl a demandé au proxy d'établir un tunnel. Si une réponse 200 est arrivée ensuite et qu'à la fin vous voyez l'adresse IP, le proxy fonctionne parfaitement.
4. Si la sortie s'est arrêtée sur la ligne Trying 185.10.20.30:30001... et qu'après 15 secondes est apparu Connection timed out, le port n'est pas accessible depuis votre ordinateur.

Conseil : si le mot de passe contient des caractères spéciaux comme @ ou #, curl peut mal interpréter l'adresse. Utilisez l'option -U pour les identifiants : curl -x http://proxy.example.net:30001 -U login:password ... Ainsi, le mot de passe ne se mélangera pas à l'adresse.

Vérifier le protocole et le port SOCKS5

Erreur fréquente : indiquer le port HTTP là où le logiciel attend SOCKS5, ou inversement. La connexion s'établira, mais les données ne passeront pas, et l'application pourra générer un timeout.

1. Vérifiez dans l'espace client du fournisseur quels ports sont attribués pour HTTP et pour SOCKS5.
2. Effectuez la vérification via curl avec le protocole SOCKS5 :

   curl -x socks5://login:password@proxy.example.net:30002 --connect-timeout 15 https://api.ipify.org

3. Assurez-vous que dans votre application, le protocole sélectionné correspond à celui de la commande curl réussie.

Vérification : après cette étape, vous savez précisément l'une des trois choses suivantes : le port est ouvert et le proxy répond via curl (alors le problème vient des paramètres de votre application, passez à l'étape 3) ; le port est ouvert mais la requête via le proxy reste bloquée (problème d'authentification ou côté proxy, étape 6) ; le port ne répond pas (problème de pare-feu ou de réseau, étapes 4 et 5).

Problèmes possibles à cette étape

Si Test-NetConnection renvoie une erreur de résolution de nom, cela signifie que l'ordinateur ne peut pas convertir le nom de domaine en adresse IP. Essayez de remplacer le nom par l'adresse IP de votre espace client. Si cela fonctionne avec l'IP mais pas avec le nom, vous avez un problème de DNS : changez le serveur DNS dans les paramètres de votre carte réseau pour un serveur public et réessayez.

Étape 3 : comprendre les timeouts dans votre logiciel

Objectif : s'assurer que l'application laisse suffisamment de temps au proxy mobile pour répondre, et apprendre à distinguer un timeout de connexion d'un timeout de lecture.

Mesurer le temps de réponse réel

1. Exécutez la commande curl avec affichage du timing :

   curl -x http://login:password@proxy.example.net:30001 -o /dev/null -s -w "connect: %{time_connect}s total: %{time_total}s" https://api.ipify.org

   Sous Windows, remplacez /dev/null par NUL.
2. La valeur connect indique en combien de temps la connexion TCP avec le proxy a été établie. Norme pour les proxys mobiles : de 0,05 à 0,5 seconde.
3. La valeur total indique le temps de toute la requête. Pour les proxys mobiles, il est normal de voir 1 à 4 secondes, et aux heures de pointe du réseau cellulaire jusqu'à 6-8 secondes.
4. Répétez la commande cinq fois et notez la dispersion. Si connect reste constamment bas et que total saute parfois à 10 secondes, votre logiciel doit être prêt à de tels délais.

Configurer les timeouts dans les outils populaires

Python et la bibliothèque requests

Le paramètre timeout accepte un tuple de deux valeurs : timeout de connexion et timeout de lecture. Valeurs recommandées pour les proxys mobiles : 10 secondes pour la connexion et 30 secondes pour la lecture.

proxies = {"http": "http://login:password@proxy.example.net:30001", "https": "http://login:password@proxy.example.net:30001"}
response = requests.get("https://api.ipify.org", proxies=proxies, timeout=(10, 30))

Si vous indiquez un seul nombre, par exemple timeout=5, il s'applique aux deux timeouts, et c'est une cause fréquente de faux messages indiquant que le serveur proxy ne répond pas.

Node.js et axios

Dans axios, le paramètre timeout est unique et global. Réglez-le à au moins 30000 millisecondes. Pour le proxy, utilisez un agent, par exemple du paquet https-proxy-agent, et passez-le dans le paramètre httpsAgent.

Navigateurs antidetect

1. Ouvrez les paramètres du profil, section proxy.
2. Trouvez le bouton de vérification de connexion. Il existe dans pratiquement tous les antidetect modernes.
3. Notez en combien de temps le résultat arrive. Si la vérification dure plus de 10 secondes et se termine par un échec, alors que curl fonctionne, regardez dans les paramètres généraux du navigateur le paramètre de timeout proxy et augmentez-le.
4. Assurez-vous que le champ protocole indique bien HTTP ou SOCKS5 en fonction du port qui a passé la vérification à l'étape 2.

Outils de scraping et d'automatisation

Dans Scrapy, c'est le paramètre DOWNLOAD_TIMEOUT, par défaut 180 secondes, et il est rarement problématique. Dans Puppeteer et Playwright, le timeout de navigation par défaut est de 30 secondes, mais en travaillant via un réseau cellulaire lent, les pages lourdes peuvent ne pas tenir : augmentez à 60 secondes via le paramètre timeout de la méthode goto.

Conseil : ne réglez pas des timeouts trop élevés. 30-60 secondes pour la lecture est une limite raisonnable. Si vous mettez 300 secondes, votre script restera des heures sur des connexions mortes au lieu de répéter rapidement la requête.

Distinguer le timeout de connexion du timeout de lecture

C'est important, car ils se traitent différemment.

• Timeout de connexion : dans curl, il ressemble à « Connection timed out after 15001 milliseconds » juste après la ligne Trying. Dans Python requests, c'est l'exception ConnectTimeout. Traitement : étapes 4, 5 et 6, car vous n'avez pas atteint le port.
• Timeout de lecture : dans curl, il ressemble à « Operation timed out after 30000 milliseconds with 0 bytes received » après la ligne Connected. Dans Python, c'est ReadTimeout. Traitement : augmenter le timeout de lecture, vérifier si une rotation d'IP n'est pas en cours sur le proxy et s'assurer que le site cible est accessible.

Vérification : après cette étape, le temps de réponse du proxy via curl s'inscrit dans les timeouts de votre application avec au moins un facteur deux de marge. Si curl répond en 3 secondes, le logiciel doit avoir au moins 10 secondes pour la lecture.

Étape 4 : vérifier le pare-feu et l'antivirus sur votre appareil

Objectif : s'assurer que le logiciel de protection sur l'ordinateur ne bloque pas les connexions sortantes vers le port proxy, et si nécessaire créer une règle d'autorisation ciblée.

Test rapide : désactivation temporaire

Avant de fouiller dans les règles, testons l'hypothèse de la manière la plus simple. Nous désactivons la protection une minute, répétons la vérification du port, puis la réactivons.

1. Sous Windows, ouvrez la recherche, tapez « Pare-feu Windows Defender » et ouvrez-le.
2. À gauche, cliquez sur « Activer ou désactiver le Pare-feu Windows Defender ».
3. Pour le profil réseau actif (généralement Privé ou Public), choisissez « Désactiver » et cliquez sur OK.
4. Exécutez immédiatement Test-NetConnection de l'étape 2.
5. Remettez aussitôt l'interrupteur sur « Activer » et cliquez sur OK.

Attention : ne travaillez pas avec le pare-feu désactivé plus longtemps que nécessaire pour une vérification. Une commande prend quelques secondes, et un système ouvert sur le réseau est un vrai risque. Si vous avez oublié de le réactiver, Windows vous le rappellera par une notification, mais mieux vaut ne pas compter dessus.

Si avec le pare-feu désactivé le port devient accessible, le coupable est trouvé. Sinon, vérifions l'antivirus de la même manière : la plupart des produits ont une option « Suspendre la protection pendant 5 minutes » dans le menu contextuel de l'icône dans la barre des tâches. Répétez la vérification du port et réactivez la protection.

Créer une règle d'autorisation dans le pare-feu Windows

On ne peut pas désactiver le pare-feu définitivement. À la place, créons une règle qui autorise précisément à votre application les connexions sortantes.

1. Ouvrez « Pare-feu Windows Defender » et cliquez à gauche sur « Paramètres avancés ». Une fenêtre avec les paramètres avancés s'ouvrira.
2. Dans la colonne de gauche, sélectionnez « Règles de trafic sortant ».
3. Dans la colonne de droite, cliquez sur « Nouvelle règle ».
4. Choisissez le type « Programme » et cliquez sur Suivant.
5. Choisissez « Chemin du programme » et via le bouton Parcourir indiquez le fichier exécutable de votre application : navigateur, antidetect ou interpréteur Python. Cliquez sur Suivant.
6. Choisissez « Autoriser la connexion » et cliquez sur Suivant.
7. Cochez les trois profils : Domaine, Privé, Public. Cliquez sur Suivant.
8. Donnez à la règle un nom clair, par exemple « Autoriser proxy pour navigateur antidetect », et cliquez sur Terminer.

Variante alternative, si les applications sont nombreuses : créer une règle de type « Pour un port », choisir le protocole TCP, indiquer le port distant précis du proxy et l'autoriser pour tous les programmes. Pour cela, au quatrième point, choisissez « Personnalisé », dans la section « Protocole et ports » indiquez TCP et dans le champ « Port distant » saisissez le numéro du port proxy.

Vérifier s'il n'y a pas de règle de blocage

Parfois, le problème n'est pas l'absence d'autorisation, mais la présence d'une interdiction créée par l'antivirus ou une politique d'entreprise.

1. Dans la même fenêtre des paramètres avancés, ouvrez « Règles de trafic sortant ».
2. Cliquez sur l'en-tête de la colonne « Action » pour trier la liste. Les règles avec l'action « Bloquer » se retrouveront côte à côte.
3. Parcourez-les. Si vous voyez une règle bloquant votre application ou une plage de ports dans laquelle tombe le port proxy, faites un clic droit dessus et choisissez « Désactiver la règle ».
4. Répétez la vérification du port.

Pare-feu sous macOS

1. Ouvrez les Réglages Système, section Réseau, puis Pare-feu.
2. Si le pare-feu est activé, cliquez sur Options.
3. Assurez-vous que votre application dans la liste a le statut « Autoriser les connexions entrantes ». Bien que ce soient les connexions sortantes qui nous intéressent, certaines applications ouvrent un port local pour fonctionner avec le proxy.
4. Décochez « Bloquer toutes les connexions entrantes » si elle est cochée, et répétez la vérification.

Vérifiez séparément les utilitaires tiers comme Little Snitch ou LuLu : ils contrôlent précisément le trafic sortant et ont pu mémoriser votre refus passé à une demande d'autorisation. Trouvez votre application dans leur liste de règles et autorisez les connexions vers l'adresse du proxy.

Pare-feu sous Linux

1. Vérifiez le statut d'ufw avec la commande sudo ufw status verbose. Notez la ligne Default : si pour outgoing il est indiqué deny, les connexions sortantes sont bloquées par défaut.
2. Autorisez la connexion sortante vers le port proxy :

   sudo ufw allow out to 185.10.20.30 port 30001 proto tcp

3. Si vous utilisez iptables directement, consultez les règles avec la commande sudo iptables -L OUTPUT -n -v et cherchez les lignes avec DROP ou REJECT sous lesquelles tombe votre trafic.
4. Sur les serveurs avec Docker, rappelez-vous que les conteneurs utilisent un sous-système réseau séparé. Vérifiez l'accessibilité du port depuis l'intérieur du conteneur, et pas seulement depuis l'hôte.

Conseil : notez l'heure exacte à laquelle vous avez modifié les règles du pare-feu. Si quelque chose casse dans une semaine, vous vous souviendrez rapidement quelle modification a pu en être la cause et vous la revertirez via le fichier exporté lors de la préparation.

Vérification : après cette étape, Test-NetConnection ou nc montre une connexion réussie avec le pare-feu activé et l'antivirus actif. Si le port est encore inaccessible alors qu'avec la protection désactivée il ne s'ouvrait pas non plus, le problème est plus haut, au niveau du routeur ou du réseau. Passez à l'étape 5.

Étape 5 : vérifier le routeur, le réseau d'entreprise et le fournisseur d'accès

Objectif : déterminer si l'équipement entre votre ordinateur et le serveur proxy ne rejette pas votre trafic, et si nécessaire corriger les paramètres du routeur ou changer de réseau.

Voir où exactement les paquets se perdent

L'utilitaire de traçage montre la liste des nœuds par lesquels passent les paquets jusqu'au serveur. Si les paquets atteignent un nœud puis disparaissent, vous voyez à qui appartient ce nœud : votre routeur, le fournisseur d'accès ou quelque chose de plus loin.

1. Sous Windows, ouvrez cmd et exécutez tracert 185.10.20.30 en remplaçant par l'IP du proxy.
2. Sous macOS, exécutez traceroute 185.10.20.30. Sous Linux, mieux vaut utiliser mtr -n 185.10.20.30 : il affiche des statistiques en temps réel et les pertes à chaque nœud.
3. La première ligne est votre routeur. La deuxième et la troisième sont généralement l'équipement du fournisseur d'accès. Ensuite viennent les nœuds de dorsale et enfin le serveur proxy.
4. Si une réponse arrive de tous les nœuds sauf le dernier, c'est normal : les serveurs proxy ne répondent souvent pas à ce type de requêtes. Regardez les pertes au milieu du chemin.
5. Si les astérisques commencent juste après le premier nœud, votre routeur ou votre fournisseur d'accès ne laisse pas passer le trafic vers cette adresse.

Rappelez-vous : le traçage utilise ICMP ou UDP, et non TCP sur le port voulu, il montre donc la disponibilité générale de la route, et non l'ouverture du port. C'est un outil complémentaire, pas un remplacement de la vérification de l'étape 2.

Vérifier le routeur

1. Ouvrez un navigateur et saisissez dans la barre d'adresse l'adresse du routeur, généralement 192.168.0.1 ou 192.168.1.1. L'identifiant et le mot de passe sont imprimés sur l'étiquette sous l'appareil, si vous ne les avez pas changés.
2. Trouvez une section du type « Sécurité », « Pare-feu », « Filtrage » ou « Contrôle parental ».
3. Vérifiez s'il y a un filtrage activé par ports ou par URL. Certains routeurs ont des profils prédéfinis comme « Niveau de protection élevé » qui bloquent tout sauf les ports 80 et 443. Passez au niveau standard.
4. Vérifiez la section « Contrôle d'accès » ou « Planification » : il peut y avoir une règle limitant l'accès Internet pour votre appareil à certaines heures.
5. Trouvez le réglage SPI Firewall ou « Protection contre les attaques DoS ». Parfois, une protection trop agressive perçoit de nombreuses connexions parallèles vers une même adresse comme une attaque et commence à les couper. Si vous avez des dizaines de threads de scraping, essayez de désactiver temporairement cette protection et répétez la vérification.
6. Enregistrez les modifications et, si nécessaire, redémarrez le routeur.

Attention : ne modifiez pas les paramètres du routeur dont la fonction vous est inconnue, surtout dans les sections WAN et DHCP. Une erreur là-bas privera tout le foyer ou le bureau d'Internet. En cas de doute, faites une sauvegarde de la configuration, comme décrit dans la préparation, et ne modifiez qu'un seul paramètre à la fois.

Vérifier le MTU

Le MTU est la taille maximale d'un paquet de données. S'il est mal réglé, les petites requêtes passent mais les réponses volumineuses se perdent. Le symptôme est caractéristique : la connexion au proxy s'établit, les petites pages s'ouvrent, mais les grandes se bloquent.

1. Sous Windows, exécutez dans cmd : ping -f -l 1472 8.8.8.8. Si les paquets passent, le MTU 1500 est correct. Si le message « fragmentation nécessaire » apparaît, diminuez le nombre par pas de 10 jusqu'à ce que cela passe.
2. Trouvez dans le routeur le réglage MTU (généralement dans la section WAN ou Internet) et réglez la valeur trouvée plus 28.
3. Valeurs typiques : 1500 pour une connexion câble classique, 1492 pour PPPoE, 1400-1450 pour certains canaux mobiles et satellites.

Réseau d'entreprise et Wi-Fi public

Si vous travaillez au bureau, dans un espace de coworking ou à l'hôtel, entre vous et Internet se trouve presque certainement une passerelle d'entreprise avec son propre pare-feu. Ces passerelles autorisent très souvent uniquement les ports 80 et 443 et coupent tout le reste. Le port à cinq chiffres du proxy mobile ne passera alors tout simplement pas.

1. Connectez-vous au point d'accès mobile de votre téléphone et répétez la vérification du port. Si cela fonctionne, la passerelle d'entreprise est en cause.
2. Contactez l'administrateur système avec une demande précise : autoriser les connexions TCP sortantes vers telle IP et tel port. Plus la demande est précise, plus vite elle sera traitée.
3. Demandez au fournisseur de proxy s'il est possible d'obtenir un port dans la plage standard, par exemple 443 ou 8080. Chez de nombreux services, cela se configure.

Fournisseur d'accès domestique

Les fournisseurs domestiques bloquent rarement les ports sortants, mais certains coupent des plages connues liées aux torrents ou aux serveurs mail. Si après toutes les vérifications le port ne répond pas depuis le réseau domestique mais répond via Internet mobile, appelez le support de votre fournisseur et demandez directement s'ils filtrent les connexions sortantes vers le port indiqué.

Conseil : conservez la sortie du traçage et la vérification du port depuis votre réseau et depuis le réseau mobile dans un seul fichier. Lorsque vous écrirez au fournisseur ou à l'administrateur, joignez les deux résultats. Cela réduira le dialogue d'une semaine à une journée.

Vérification : le port proxy est accessible depuis votre réseau avec la commande de l'étape 2, le traçage ne montre pas de pertes aux nœuds du fournisseur, et le ping avec l'option -f passe à une taille de 1472. Si ces trois conditions sont remplies et que le proxy ne répond toujours pas, cela vient de ses propres paramètres. Passons à l'étape 6.

Étape 6 : vérifier les paramètres côté proxy

Objectif : s'assurer que le serveur proxy accepte précisément vous : votre IP est dans la liste blanche, le modem est en ligne, la rotation ne coïncide pas avec vos requêtes et la limite de connexions n'est pas dépassée.

Vérifier l'authentification par IP

C'est la cause la plus fréquente lorsque le proxy fonctionne depuis le téléphone mais pas depuis l'ordinateur, ou fonctionnait hier mais pas aujourd'hui.

1. Déterminez votre adresse IP externe actuelle. Ouvrez sans proxy n'importe quel site affichant l'IP, ou exécutez curl https://api.ipify.org dans le terminal.
2. Ouvrez l'espace client du fournisseur de proxy, section paramètres d'authentification.
3. Comparez l'adresse de la liste blanche avec votre adresse actuelle. Si elles diffèrent, voilà la cause : votre fournisseur a attribué une nouvelle adresse après un redémarrage du routeur ou selon un planning.
4. Mettez à jour l'adresse dans la liste blanche ou passez à l'authentification par identifiant et mot de passe. La seconde option est plus fiable si votre IP externe change.
5. Attendez une à deux minutes : les paramètres sur le serveur proxy ne s'appliquent pas instantanément.
6. Répétez la vérification via curl de l'étape 2.

Conseil : si vous travaillez depuis chez vous avec une IP dynamique, l'authentification par identifiant et mot de passe vous débarrassera de ce problème pour toujours. La liste blanche est pratique pour les serveurs à adresse statique, pas pour les ordinateurs domestiques.

Vérifier l'état du modem et la rotation

1. Dans l'espace client, trouvez les informations sur l'IP actuelle du proxy et l'heure du dernier changement.
2. Si une rotation automatique est configurée toutes les quelques minutes, notez ceci : au moment du changement d'IP, le modem se reconnecte au réseau cellulaire et pendant 5 à 20 secondes le proxy ne répond effectivement pas. C'est un comportement normal, pas une panne.
3. Si vos requêtes attrapent régulièrement un timeout précisément au moment de la rotation, augmentez l'intervalle de rotation ou passez au changement d'IP par lien pour contrôler vous-même le moment de la reconnexion.
4. Essayez de forcer un changement d'IP via le lien de l'espace client. Si après le changement le proxy s'est mis à fonctionner, le problème venait d'une IP spécifique ou d'une connexion bloquée du modem.

Vérifier la limite de connexions simultanées

Les proxys mobiles ont une limite sur le nombre de connexions parallèles depuis un même port. Si votre scraper a ouvert cent threads et que la limite est de cinquante, les connexions en trop resteront en file d'attente et tomberont en timeout.

1. Vérifiez la limite dans la description du forfait ou dans l'espace client.
2. Fermez toutes les applications utilisant le proxy et exécutez une requête unique via curl. Si la requête unique passe mais que sous charge les timeouts commencent, vous butez sur la limite.
3. Réduisez le nombre de threads dans les paramètres du scraper ou de l'antidetect à une valeur inférieure à la limite. Pour les proxys mobiles, un démarrage raisonnable : 5 à 10 connexions parallèles par port.

Vérifier les fuseaux horaires et le réseau cellulaire

Le modem du proxy se trouve physiquement dans une ville précise et est connecté à un opérateur précis. Aux heures de pointe du soir, lorsque les réseaux cellulaires sont surchargés, les latences augmentent fortement. Si les timeouts apparaissent seulement entre 19h et 23h selon le fuseau de la région du proxy, c'est le réseau cellulaire, pas votre configuration. Solution : augmenter les timeouts à ces heures ou répartir la charge sur d'autres créneaux.

Vérification : votre IP actuelle correspond à la liste blanche ou l'authentification par mot de passe est utilisée, le modem dans l'espace client affiche le statut « en ligne », une requête unique via curl passe, et le nombre de threads dans le logiciel ne dépasse pas la limite. Si tout cela est rempli et que le serveur proxy ne répond toujours pas, il est temps d'écrire au support du fournisseur en joignant les résultats des six étapes.

Vérification du résultat : checklist d'une connexion stable

Vous avez parcouru toutes les étapes. Maintenant, assurons-nous que le résultat est atteint non pas par hasard et pas pour une minute. Parcourez la checklist et cochez chaque point.

Checklist

• Test-NetConnection ou nc montre une connexion TCP réussie au port proxy avec le pare-feu et l'antivirus activés.
• curl via le proxy renvoie l'adresse IP de l'opérateur mobile en 5 secondes maximum sur cinq tentatives consécutives.
• Le timeout de connexion dans votre logiciel est d'au moins 10 secondes, le timeout de lecture d'au moins 30 secondes.
• Le protocole dans l'application (HTTP ou SOCKS5) correspond au port qui a passé la vérification via curl.
• Dans le pare-feu, une règle d'autorisation ciblée a été créée, et non la protection désactivée entièrement.
• Votre IP externe correspond à la liste blanche ou l'authentification par mot de passe est utilisée.
• Le nombre de connexions parallèles dans l'application est inférieur à la limite du forfait.
• Les sauvegardes des paramètres du pare-feu et du routeur sont conservées pour un éventuel retour en arrière.

Test de charge

Une requête unique, c'est une chose, mais le vrai travail, ce sont des dizaines de requêtes d'affilée. Faisons un court test.

1. Exécutez dans le terminal une boucle de 20 requêtes. Sous macOS et Linux :

   for i in $(seq 1 20); do curl -x http://login:password@proxy.example.net:30001 -s -o /dev/null -w "%{http_code} %{time_total}\n" https://api.ipify.org; done

   Sous PowerShell, utilisez la boucle 1..20 | ForEach-Object avec la même commande curl à l'intérieur.
2. Dans la sortie, vous verrez 20 lignes avec le code de réponse et le temps. Tous les codes doivent être 200, et le temps ne doit pas dépasser 5-6 secondes.
3. Si une ou deux requêtes sur vingt ont pris plus, c'est acceptable pour un réseau mobile. Si une requête sur trois part en timeout, revenez à l'étape 6 et vérifiez la limite de connexions et la rotation.

Test dans une application réelle

1. Ouvrez un profil de navigateur antidetect avec le proxy configuré et cliquez sur vérifier la connexion. Le résultat doit arriver en 2-4 secondes et afficher l'IP de l'opérateur mobile.
2. Ouvrez une page lourde, par exemple le fil d'un réseau social. Elle doit se charger complètement en 10-15 secondes.
3. Laissez l'onglet ouvert pendant 10 minutes et actualisez la page. Si elle se charge, la connexion survit aux pauses et ne se coupe pas par inactivité.
4. Pour les scripts : lancez une tâche de travail sur 50-100 requêtes et regardez le pourcentage de réussite. Objectif : au moins 95 % sans réessais.

Indicateurs de réussite : le port est accessible, le temps de réponse est prévisible, l'application ne se plaint pas de timeouts pendant 30 minutes de travail, et vous savez exactement laquelle des six étapes était la cause du problème. Ce dernier point est particulièrement précieux : la prochaine fois, vous commencerez le diagnostic par là.

Erreurs typiques et leurs solutions

Voici les situations que les utilisateurs de proxys mobiles rencontrent le plus souvent. Format : ce que vous voyez, pourquoi cela se produit, que faire.

Le proxy fonctionne depuis le téléphone mais pas depuis l'ordinateur

Cause : le pare-feu ou l'antivirus sur l'ordinateur bloque la connexion sortante vers un port non standard, ou votre IP domestique ne correspond pas à la liste blanche et le téléphone s'authentifie autrement.

Solution : faites le test rapide avec désactivation du pare-feu de l'étape 4. Si cela n'a pas aidé, comparez l'IP externe de l'ordinateur avec la liste blanche selon les instructions de l'étape 6.

La connexion s'établit mais la page ne se charge pas

Cause : vous avez indiqué un port HTTP là où l'application attend SOCKS5, ou inversement. La connexion s'ouvre, mais l'application et le proxy parlent des langues différentes et les données ne passent pas.

Solution : vérifiez les deux protocoles via curl avec les préfixes http:// et socks5:// et réglez dans l'application celui qui a fonctionné.

Cela fonctionnait une semaine, puis a cessé sans changements de votre côté

Cause : l'IP externe de votre fournisseur d'accès a changé et l'authentification par IP est configurée dans l'espace client du proxy. Autre possibilité : une mise à jour de l'antivirus a ajouté une nouvelle règle de blocage.

Solution : mettez à jour la liste blanche ou passez à l'authentification par mot de passe. Vérifiez la liste des règles de blocage dans le pare-feu selon les instructions de l'étape 4.

Timeouts uniquement le soir

Cause : surcharge du réseau cellulaire dans la région où se trouve le modem proxy. C'est une particularité de l'Internet mobile, pas une panne.

Solution : augmentez le timeout de lecture à 45-60 secondes pour les heures du soir, ajoutez des réessais et, si possible, déplacez les tâches lourdes vers le matin.

Une requête sur dix échoue en timeout

Cause : coïncidence des requêtes avec le moment de la rotation automatique d'IP, ou dépassement de la limite de connexions parallèles.

Solution : passez la rotation en mode changement par lien et appelez-la entre les lots de requêtes. Réduisez le nombre de threads à 5-10.

Ne fonctionne pas au bureau, fonctionne à la maison

Cause : la passerelle d'entreprise ne laisse passer que les ports 80 et 443.

Solution : demandez à l'administrateur l'autorisation d'une IP et d'un port précis, ou obtenez du fournisseur de proxy un port dans la plage standard.

Test-NetConnection affiche True, mais le navigateur reste bloqué

Cause : le port est ouvert, mais dans le navigateur un autre port, une autre adresse sont configurés, ou une exception système est activée qui fait que le trafic contourne le proxy. Il est aussi possible qu'une extension de proxy entre en conflit avec les paramètres système.

Solution : comparez caractère par caractère l'adresse et le port dans le navigateur avec ce que vous avez vérifié par commande. Désactivez toutes les extensions liées au proxy et configurez le proxy d'une seule manière.

Les petites pages s'ouvrent, les grandes se bloquent

Cause : MTU incorrect sur le routeur ou chez le fournisseur. Les paquets volumineux ne passent pas.

Solution : déterminez le MTU avec la commande ping avec l'option -f de l'étape 5 et réglez-le dans le routeur.

Fonctionnalités supplémentaires pour utilisateurs avancés

Si la connexion de base est rétablie et que vous voulez plus de contrôle, cette section est pour vous. Voici des outils et approches qui transforment un diagnostic ponctuel en surveillance continue.

Observer les paquets : Wireshark et tcpdump

Quand les commandes des étapes principales ne donnent pas de réponse claire, on peut observer directement le trafic réseau.

1. Sous Linux ou macOS, exécutez :

   sudo tcpdump -i any host 185.10.20.30 and port 30001 -nn

   Sous Windows, installez Wireshark et dans le filtre d'affichage saisissez ip.addr == 185.10.20.30 and tcp.port == 30001.
2. Lancez la vérification du port de l'étape 2 et regardez les paquets capturés.
3. Si vous voyez des paquets sortants avec le drapeau SYN mais pas de SYN-ACK en retour, vos paquets partent mais la réponse ne revient pas. Le blocage est quelque part en dehors de l'ordinateur.
4. Si les paquets SYN sont totalement absents, ils sont rejetés par le pare-feu local avant même de sortir sur le réseau.
5. Si un RST arrive en réponse, le port sur le serveur est fermé ou le serveur vous refuse précisément.

Réessais automatiques avec pause exponentielle

Le réseau mobile est par nature instable. Au lieu d'échouer au premier timeout, configurez des réessais avec délai exponentiel : première tentative après 1 seconde, deuxième après 2, troisième après 4. En Python, cela se fait via un adaptateur avec la classe Retry d'urllib3, en Node.js via le paquet axios-retry. Trois réessais avec ce schéma éliminent 90 % des timeouts aléatoires sans perte de données.

Connexions persistantes et pools

Chaque nouvelle connexion TCP via un proxy mobile coûte 100 à 500 millisecondes d'établissement. Si votre script ouvre une nouvelle connexion à chaque requête, vous perdez du temps et atteignez plus vite la limite. Utilisez des sessions : en Python requests.Session, en Node.js un agent avec keepAlive: true. Une seule connexion sera réutilisée pour des dizaines de requêtes.

Surveillance de la disponibilité

Configurez une vérification simple toutes les minutes : un script fait une requête via le proxy et enregistre le temps de réponse et le code. En une semaine, vous obtiendrez une image des heures où le proxy est plus rapide et de celles où il attrape des timeouts. Cela permettra de planifier la charge et de voir la dégradation à l'avance, plutôt que de l'apprendre par des tâches cassées.

*/1 * * * * curl -x http://login:password@proxy.example.net:30001 -s -o /dev/null -m 20 -w "$(date +%H:%M) %{http_code} %{time_total}\n" https://api.ipify.org >> /var/log/proxy-check.log

DNS via le proxy

Par défaut, certaines applications résolvent les noms de domaine localement, et non via le proxy. Cela peut entraîner des fuites d'information et des situations où le DNS local renvoie une adresse inaccessible depuis le réseau mobile. Dans les paramètres des navigateurs et des antidetect, cherchez l'option « DNS via le proxy » ou utilisez le protocole socks5h au lieu de socks5 dans curl et Python : la lettre h signifie que les noms seront résolus par le proxy lui-même.

Passer à un port standard

Si vous travaillez souvent depuis différents réseaux, demandez à votre fournisseur la possibilité d'attribuer au proxy le port 443 ou 8080. Ces ports sont ouverts pratiquement partout, et vous n'aurez plus à vous battre avec les pare-feu d'entreprise à chaque fois.

Réglage fin de la rotation

Scénario avancé : lier le changement d'IP à la logique de l'application. Avant de commencer un nouveau lot de requêtes, le script appelle le lien de changement d'IP, attend 10-15 secondes, vérifie via api.ipify.org que l'adresse a bien changé, et seulement ensuite commence le travail. Ainsi, vous excluez totalement les timeouts dus à une coïncidence entre une requête et la rotation.

Conseil : ajoutez dans le log de chaque requête non seulement l'heure, mais aussi l'IP actuelle du proxy. Quand, dans un mois, vous analyserez pourquoi les indicateurs ont chuté, la corrélation entre des IP spécifiques et les timeouts vous indiquera immédiatement quelles adresses de l'opérateur étaient problématiques.

FAQ : questions fréquentes sur le diagnostic

Le serveur proxy ne répond pas mais le ping passe. Qu'est-ce que cela signifie ?

Le ping vérifie uniquement la disponibilité de l'IP via le protocole ICMP, pas l'ouverture du port. Le serveur peut être vivant et répondre au ping, mais le port proxy être filtré par un pare-feu ou le service sur ce port ne pas être démarré. Vérifiez toujours précisément le port TCP avec les commandes de l'étape 2.

Combien de temps attendre avant de considérer que le proxy ne répond pas ?

Pour établir une connexion avec un proxy mobile, jusqu'à 1 seconde est normal, la limite est de 10 secondes. Pour recevoir les données, jusqu'à 5 secondes est normal, la limite est de 30-45 secondes. Si la connexion ne s'est pas établie en 10 secondes, attendre plus longtemps n'a pas de sens : la réponse n'arrivera pas.

Peut-on simplement désactiver le pare-feu et travailler ainsi ?

Non. La désactivation de la protection n'est acceptable que pendant une minute pour tester une hypothèse. Ensuite, créez une règle ciblée pour l'application ou le port concerné, comme décrit à l'étape 4, et réactivez le pare-feu. Un ordinateur sans protection sur le réseau est un risque pour vos comptes et vos données.

Pourquoi le proxy fonctionne-t-il dans un navigateur et pas dans un autre ?

Généralement parce qu'un navigateur utilise les paramètres proxy système et l'autre les siens, avec des données différentes. Autre possibilité : le pare-feu a autorisé un exécutable et pas l'autre. Vérifiez les paramètres des deux navigateurs et la liste des règles du pare-feu.

Comment savoir si le problème vient de la rotation d'IP et non de mes paramètres ?

Notez l'heure de chaque timeout pendant une heure et comparez avec l'intervalle de rotation de l'espace client. Si les timeouts arrivent avec la même périodicité que le changement d'IP, c'est la rotation. Passez au changement par lien et le problème disparaîtra.

Est-il obligatoire d'utiliser le terminal ? N'existe-t-il pas d'outils graphiques ?

Le terminal est plus rapide et plus précis, mais il existe des alternatives. Les navigateurs antidetect intègrent une vérification de proxy avec affichage du temps de réponse. Il existe des programmes de bureau pour vérifier des listes de proxys avec indication des ports ouverts. Cependant, pour trouver la cause précisément chez vous, le terminal est irremplaçable : il montre à quelle étape la connexion s'est arrêtée.

Que faire si les six étapes sont passées et que le problème persiste ?

Écrivez au support du fournisseur de proxy et joignez : la sortie de Test-NetConnection ou nc, la sortie de curl avec l'option -v, le résultat du traçage, votre IP externe, l'heure des tentatives et l'information de savoir si le proxy fonctionne depuis un autre réseau. Avec de telles données, le spécialiste trouvera la cause en une réponse, et non en cinq questions de clarification.

Faut-il redémarrer l'ordinateur après modification des règles du pare-feu ?

Non, les règles du pare-feu Windows, macOS et Linux s'appliquent instantanément. Le redémarrage n'est nécessaire que pour le routeur après modification du MTU ou des profils de sécurité, et encore, pas sur tous les modèles.

Peut-on utiliser la même approche pour les proxys datacenter ?

Oui, les étapes 1 à 5 sont universelles pour tout type de proxy. L'étape 3 diffère : les proxys datacenter répondent plus vite et les timeouts peuvent être plus courts. Et l'étape 6 : les proxys datacenter n'ont pas de rotation par reconnexion du modem, donc il n'y aura pas de pauses au moment du changement d'IP.

Conclusion

Résumons. Vous avez appris à ne pas paniquer face au message indiquant que le serveur proxy ne répond pas, mais à analyser la situation maillon par maillon. D'abord, vous avez déterminé si le proxy fonctionne au moins depuis quelque part. Ensuite, vous avez vérifié si le port est ouvert précisément depuis votre appareil. Vous avez compris les timeouts et fait la différence entre timeout de connexion et timeout de lecture. Vous avez vérifié le pare-feu et l'antivirus et créé une règle ciblée au lieu de désactiver la protection. Vous avez étudié le routeur, le MTU et la passerelle d'entreprise. Et enfin, vous vous êtes assuré que le proxy accepte précisément vous : liste blanche, modem, rotation, limites.

Le résultat principal n'est même pas que la connexion soit rétablie. Il est que vous disposez maintenant d'une méthode. La prochaine fois que quelque chose se bloquera, vous ne tâtonnerez pas et ne parcourrez pas les paramètres au hasard. Vous ouvrirez le terminal, exécuterez deux commandes et saurez en une minute à quel maillon de la chaîne se trouve la coupure.

Que faire ensuite

1. Conservez le fichier avec les commandes utiles et vos données proxy dans un endroit pratique. C'est votre kit de premiers secours.
2. Passez l'authentification à identifiant et mot de passe si vous utilisez encore la liste blanche depuis un ordinateur domestique.
3. Vérifiez les timeouts dans toutes les applications qui fonctionnent via des proxys mobiles et alignez-les sur les valeurs recommandées.
4. Configurez la surveillance à la minute de la section avancée sur au moins un proxy, pour voir dans une semaine l'image réelle de la stabilité.

Vers quoi évoluer

Le niveau suivant, c'est l'automatisation de la gestion des pannes : réessais avec pause exponentielle, rotation pilotée, pools de connexions et journalisation de chaque requête avec liaison à l'IP. Une fois cela maîtrisé, vous ne remarquerez plus les timeouts isolés : votre système les gérera lui-même et vous ne verrez que les métriques finales. Bonne chance dans votre travail, et que vos proxys répondent toujours du premier coup.