Erreur proxy 407, 502, 504 et tunnel failed : diagnostic pas à pas pour débutants

Introduction : ce que ce guide va vous apporter

Si vous travaillez avec des proxys mobiles, tôt ou tard vous verrez apparaître dans les logs d'un parseur, dans la console d'un navigateur anti-détection ou directement dans la fenêtre d'un compte publicitaire une ligne du type « 407 Proxy Authentication Required », « 502 Bad Gateway », « 504 Gateway Timeout » ou le court et effrayant « tunnel failed ». À ce moment-là, une erreur de serveur proxy ressemble à une boîte noire : impossible de savoir si le proxy lui-même est en cause, si c'est votre outil, le site cible ou simplement un mot de passe obsolète. Ce guide transforme cette boîte noire en un plan d'action clair.

Nous limitons volontairement le sujet : nous analysons uniquement les codes et messages renvoyés par la couche proxy. Les timeouts réseau au niveau de la connexion (quand il n'y a aucune réponse et que le client interrompt lui-même l'attente) sont traités séparément dans le blog, et nous ne les dupliquons pas ici. Si votre log affiche précisément un code ou la mention d'un tunnel, vous êtes au bon endroit.

Ce que vous allez obtenir

• Vous comprendrez ce que signifie chacune des quatre erreurs et à quel endroit précis de la chaîne « votre outil — proxy — site cible » elle apparaît.
• Vous saurez déterminer en deux à trois minutes la source du problème grâce à l'utilitaire curl présent sur tout système.
• Vous disposerez de procédures prêtes à l'emploi pour les erreurs 407, 502, 504 et tunnel failed, utilisables comme une check-list.
• Vous configurerez votre logiciel pour qu'il réagisse correctement à chaque code : certaines erreurs doivent être réessayées, d'autres non.
• Vous tiendrez un journal personnel des incidents qui vous fera gagner des heures lors du prochain dysfonctionnement.

À qui s'adresse ce guide

Ce guide est écrit pour les marketeurs, les spécialistes d'arbitrage, les propriétaires de petites équipes et les développeurs qui utilisent des proxys mobiles sans être obligés d'être ingénieurs réseau. La majeure partie est pensée pour les débutants : chaque commande est expliquée, chaque action est détaillée. Pour ceux qui écrivent leurs propres scripts et veulent aller plus loin, un bloc avancé est proposé à la fin.

Ce qu'il faut savoir au préalable

Il suffit de savoir ouvrir un terminal ou une invite de commandes, y copier du texte et lire le résultat. Comprendre ce qu'est une adresse IP et un port aide, mais nous le rappellerons brièvement. Aucune expérience en programmation n'est requise.

Combien de temps cela prendra

La lecture complète et le premier diagnostic demanderont entre 60 et 120 minutes. Si vous êtes confronté à une erreur précise, allez directement à l'étape concernée : chaque erreur demande 15 à 25 minutes, vérifications comprises.

Préparation : outils et accès

Diagnostiquer les erreurs de la couche proxy ne nécessite pas d'installer des logiciels lourds. Presque tout est déjà présent dans votre système d'exploitation. Il vaut toutefois mieux se préparer à l'avance pour ne pas chercher des mots de passe ou un fichier de configuration au moment du problème.

Outils nécessaires

1. Un terminal ou une invite de commandes. Sous Windows 10 et 11, ouvrez le menu « Démarrer », tapez « cmd » ou « PowerShell » et appuyez sur Entrée. Sur macOS, ouvrez « Applications », puis « Utilitaires », puis « Terminal ». Sous Linux, le terminal s'ouvre généralement avec Ctrl+Alt+T.
2. L'utilitaire curl. Il est intégré à Windows depuis la version 10 (build 1803), à macOS et à la plupart des distributions Linux. Vérifiez : tapez dans le terminal curl --version et appuyez sur Entrée. Une ligne avec le numéro de version doit apparaître, par exemple « curl 8.x.x ». Si la commande n'est pas reconnue, installez curl via le gestionnaire de paquets de votre système.
3. Un navigateur classique avec les outils de développement. Tout navigateur moderne où la touche F12 ouvre un panneau avec l'onglet « Network » (Réseau) convient.
4. Un éditeur de texte pour tenir le journal des incidents. Le Bloc-notes suffit, mais un éditeur avec coloration syntaxique est plus pratique pour lire la structure des logs.
5. Votre outil de travail : navigateur anti-détection, parseur, gestionnaire de comptes publicitaires ou script personnel. Nous aurons besoin d'accéder à ses paramètres proxy et à ses logs.

Accès nécessaires

• L'accès à votre espace client chez le fournisseur de proxys. Pour les utilisateurs de mobileproxy.space, il s'agit de la page de gestion de vos canaux, où figurent l'hôte, le port, le login, le mot de passe, le type d'authentification et le lien de changement d'IP.
• Les identifiants à jour d'au moins un proxy : adresse (hôte), port, login et mot de passe, ou IP confirmée pour l'authentification par adresse.
• La connaissance du protocole utilisé : proxy HTTP(S) ou SOCKS5. Cette information figure également dans l'espace client.

Configuration requise

N'importe quel système d'exploitation sorti ces huit dernières années. Une connexion Internet permettant d'atteindre l'hôte du proxy. Rien de plus.

Sauvegardes

Avant de modifier les paramètres du proxy dans votre outil de travail, sauvegardez l'état actuel. Cela prend cinq minutes et évite de « réparer » une erreur tout en perdant la configuration de dix comptes.

1. Dans le navigateur anti-détection, exportez la liste des profils avec leurs paramètres proxy. La fonction d'export se trouve généralement dans le menu des profils et génère un fichier CSV ou JSON.
2. Dans le parseur ou le script, copiez le fichier de configuration dans un dossier séparé avec la date dans le nom, par exemple « config_backup_2026-03-14 ».
3. Depuis l'espace client, copiez dans un fichier texte les identifiants de tous les canaux. Conservez ce fichier à l'abri des regards indiscrets.
4. Notez l'IP actuelle de votre ordinateur ou serveur. Elle sera utile si vous utilisez l'authentification par IP.

Conseil : créez un fichier texte « Journal proxy » et notez-y chaque erreur au format « date, heure, code, hôte du proxy, site cible, action effectuée, ce qui a fonctionné ». Au bout d'un mois, vous aurez une base de connaissances personnelle plus utile que n'importe quel article.

Vérification : le terminal s'ouvre, la commande curl affiche la version, vous êtes connecté à l'espace client et voyez les identifiants d'au moins un proxy, les sauvegardes de configuration sont dans un dossier séparé. Vous pouvez continuer.

Notions de base : comment fonctionne la couche proxy et d'où viennent les codes

Pour corriger une erreur de serveur proxy de manière réfléchie plutôt que par tâtonnement, il faut visualiser le chemin de la requête. Il se compose de trois segments, et chacune de nos quatre erreurs vit sur son propre segment.

Les trois segments du chemin de la requête

• Client — proxy. Votre navigateur, parseur ou script se connecte à l'hôte et au port du proxy. C'est sur ce segment que l'authentification est vérifiée. C'est là que naît l'erreur 407 et une partie des cas de tunnel failed.
• Proxy — réseau mobile — site cible. Le serveur proxy, après avoir reçu votre requête, ouvre en son nom une connexion via le modem équipé d'une carte SIM de l'opérateur vers le site voulu. C'est là que surviennent les 502 et 504.
• Site cible — chemin retour. La réponse du site revient par les mêmes nœuds. Si le site renvoie son propre code, par exemple 403 ou 429, ce n'est plus une erreur de la couche proxy, et il est important d'apprendre à les distinguer.

Les classes de codes en langage simple

Un code de réponse est un nombre à trois chiffres que le serveur envoie sur la première ligne de sa réponse. Le premier chiffre indique la classe. Les codes 4xx signifient « problème de votre côté, corrigez la requête ». Les codes 5xx signifient « problème du côté du serveur ou au-delà ». Pour la couche proxy, cela se traduit ainsi :

• 407 Proxy Authentication Required — le proxy dit : « Je ne sais pas qui tu es, ou tes données sont incorrectes ». Classe 4xx : à corriger chez vous.
• 502 Bad Gateway — le proxy dit : « J'ai essayé d'aller plus loin, mais j'ai reçu une coupure ou des données illisibles au lieu d'une réponse ». Classe 5xx : le problème est derrière le proxy ou dans le proxy lui-même.
• 504 Gateway Timeout — le proxy dit : « J'ai attendu la réponse du nœud suivant le temps imparti et je ne l'ai pas reçue ». C'est aussi du 5xx.

Différence entre le code 504 et un timeout réseau

C'est la distinction clé de tout cet article. Quand vous voyez le code 504, cela signifie que le serveur proxy est vivant, a accepté votre requête, a lui-même attendu la réponse du site et vous a lui-même signalé l'échec. La connexion entre vous et le proxy fonctionnait parfaitement. En revanche, quand votre client affiche « connection timed out » ou « operation timed out » sans code, cela signifie qu'il n'y a eu aucune réponse et que la coupure vient de votre outil. Le premier cas fait l'objet de ce guide. Le second est traité dans d'autres articles du blog. Un signe simple : s'il y a un nombre à trois chiffres dans la réponse, lisez la suite ici.

Qu'est-ce qu'un tunnel et pourquoi il « tombe »

Quand vous ouvrez un site en HTTPS via un proxy HTTP, le navigateur envoie d'abord au proxy une commande spéciale CONNECT avec l'adresse et le port de destination. Le proxy ouvre une connexion avec le site et répond « 200 Connection established ». Ensuite, un flux chiffré traverse le proxy, lequel ne le lit plus. Une telle connexion s'appelle un tunnel. Si le proxy répond à la commande CONNECT par autre chose que 200, le client affiche « tunnel failed » et indique généralement quel code est arrivé. Autrement dit, tunnel failed n'est pas une erreur autonome, mais une enveloppe autour d'un des codes.

Deux modes d'authentification

• Login et mot de passe. Le client les transmet dans l'en-tête Proxy-Authorization. C'est le mode le plus répandu, et la source la plus fréquente de 407.
• Authentification par IP. Vous indiquez à l'avance dans votre espace client l'adresse de votre ordinateur ou serveur, et le proxy accepte toutes les requêtes depuis cette adresse sans mot de passe. Pratique, mais se casse quand votre IP change.

En-têtes de service qui révèlent l'auteur de la réponse

Le proxy ajoute souvent à ses réponses les en-têtes Via, Proxy-Agent ou X-Proxy. Les sites cibles ne les mettent pas. Si une réponse avec code 502 contient un en-tête Proxy-Agent, vous savez avec certitude que c'est le proxy qui a répondu. Si aucun en-tête de ce type n'apparaît, mais qu'il y a un Server avec le nom du serveur web du site, c'est le site qui répond. Nous utiliserons activement ce critère.

Conseil : retenez la règle mnémotechnique : « un 4, cherchez chez vous ; un 5, cherchez derrière le proxy ; tunnel, regardez le nombre à côté ». Elle résout la moitié des cas sans lire la suite.

Étape 1 : Déterminer qui exactement a renvoyé l'erreur

Objectif de l'étape : établir en quelques minutes si c'est le serveur proxy, le site cible ou votre propre outil qui a répondu, et consigner le texte complet de la réponse pour la suite.

Instructions

1. Ouvrez votre espace client et copiez les identifiants du proxy problématique : hôte, port, login, mot de passe. Pour l'exemple, supposons que l'hôte est proxy.example.net, le port 8080, le login user1, le mot de passe pass1. Remplacez par vos propres valeurs.
2. Ouvrez le terminal.
3. Tapez la commande en remplaçant les identifiants et l'adresse cible par les vôtres, puis appuyez sur Entrée : curl -v -x http://user1:pass1@proxy.example.net:8080 https://example.com/. L'option -v active la sortie détaillée, l'option -x définit le proxy.
4. Attendez la fin de la commande. Cela prend généralement une à trois secondes. Si la commande « reste bloquée » plus de 30 secondes, appuyez sur Ctrl+C : il s'agit probablement d'un timeout réseau, pas d'un code, et ce n'est pas notre sujet.
5. Dans la sortie, repérez les lignes commençant par le symbole « > » (ce que curl a envoyé) et par le symbole « < » (ce qui est revenu en réponse). La première ligne de réponse sera du type « HTTP/1.1 407 Proxy Authentication Required » ou « HTTP/1.1 200 Connection established ».
6. Regardez la ligne portant la mention CONNECT. Si juste après elle apparaît un code différent de 200, c'est le proxy qui a renvoyé l'erreur au stade du tunnel. Si CONNECT a reçu 200 et que le code d'erreur arrive plus tard, après les lignes du handshake TLS, c'est le site cible qui a répondu.
7. Repérez les en-têtes de la réponse. La présence de Proxy-Agent, Via ou d'en-têtes de service similaires indique sans ambiguïté le proxy. Un en-tête Server avec le nom du serveur web et un en-tête Set-Cookie indiquent le site cible.
8. Répétez la même commande sans l'option -x, donc en direct : curl -v https://example.com/. Si le site répond 200 et qu'à travers le proxy on obtient un 5xx, le problème est localisé après le proxy.
9. Répétez la commande via le proxy, mais vers un autre site, par exemple une grande ressource stable. Si le second site s'ouvre, le problème est lié à une destination précise, pas au proxy en général.
10. Copiez toute la sortie dans le journal proxy avec la date et l'heure. Vous en aurez besoin aux étapes suivantes.

Alternative via le navigateur

Si travailler dans le terminal n'est pas pratique, ouvrez le navigateur configuré avec le proxy, appuyez sur F12, allez dans l'onglet « Network », cochez « Preserve log » (Conserver le journal), rechargez la page. Dans la liste des requêtes, repérez la ligne au code rouge, cliquez dessus et, dans l'onglet « Headers », examinez le bloc « Response Headers ». La logique est la même : cherchez les en-têtes de service du proxy. L'inconvénient est que le navigateur masque souvent les détails du stade CONNECT ; pour tunnel failed, le terminal est donc préférable.

Attention : la commande avec l'option -v affiche le login et le mot de passe du proxy en clair. Ne collez pas cette sortie dans des chats publics, des tickets de support ou des captures d'écran sans remplacer le mot de passe par des astérisques.

Conseil : ajoutez à la commande l'option -sS avec -o et la mention d'un périphérique vide pour ne pas encombrer l'écran avec le corps de la réponse : curl -sS -v -o /dev/null -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Sous Windows, remplacez /dev/null par NUL.

Résultat attendu

Le journal contient une entrée avec la réponse complète, et vous pouvez affirmer l'un des trois cas : « c'est le proxy qui a répondu au stade de l'authentification », « c'est le proxy qui a répondu au stade de l'appel au site » ou « c'est le site lui-même qui a répondu ». Cela vous oriente vers l'étape 2, les étapes 3-4, ou hors du périmètre de cet article.

Problèmes possibles

• La commande affiche « Could not resolve proxy ». Faute de frappe dans l'hôte. Vérifiez caractère par caractère avec l'espace client.
• La commande affiche « Failed to connect to proxy ». Port fermé ou incorrect. C'est un problème de transport, pas un code ; vérifiez le port et essayez un autre canal.
• La sortie s'arrête à la ligne TLS sans code. Le tunnel est établi, mais le site n'a pas répondu dans le temps imparti par votre client. Ne confondez pas avec un 504 : pas de code, donc ce n'est pas notre cas.

Vérification : vous savez nommer l'auteur de la réponse et le code ou la phrase exacte, et la ligne de sortie curl est enregistrée dans le journal.

Étape 2 : Corriger l'erreur 407 Proxy Authentication Required

Objectif de l'étape : obtenir que le proxy réponde « 200 Connection established » à la commande CONNECT au lieu de 407, et comprendre la cause pour que l'erreur ne revienne pas.

Pourquoi le 407 survient

Le proxy n'a pas accepté vos identifiants. Les causes sont généralement au nombre de six, et nous les vérifierons par ordre croissant de difficulté : faute de frappe, caractères spéciaux dans le mot de passe, changement de votre IP en authentification par adresse, expiration du canal, outil qui ne transmet rien, cache de données obsolètes dans le navigateur.

Instructions

1. Ouvrez votre espace client et trouvez le canal problématique. Vérifiez que sa durée de validité n'est pas expirée et que le statut est actif. Si la durée est dépassée, renouvelez-la et relancez la requête une minute plus tard ; dans ce cas, inutile d'aller plus loin.
2. Vérifiez quel type d'authentification est activé pour le canal : login/mot de passe ou par IP. Beaucoup de panneaux permettent d'activer les deux en même temps.
3. Si l'authentification par IP est activée, relevez l'adresse externe actuelle de votre ordinateur ou serveur. Ouvrez dans le navigateur, sans proxy, n'importe quel service affichant votre IP et comparez avec l'adresse enregistrée dans l'espace client. Les fournisseurs d'accès et les opérateurs mobiles changent souvent l'adresse après un redémarrage du routeur. Si les adresses diffèrent, mettez-la à jour dans l'espace client et attendez une à deux minutes : les modifications ne s'appliquent pas instantanément.
4. Si vous utilisez login et mot de passe, recopiez-les depuis l'espace client, sans les retaper à la main. Collez-les dans la commande curl de l'étape 1 et lancez. La moitié des cas de 407 se règlent ici.
5. Regardez le mot de passe. S'il contient les caractères @, :, /, #, ?, % ou un espace, il faut les encoder lors du passage dans la chaîne d'adresse. Le symbole @ devient %40, le deux-points %3A, le dièse %23, le signe pour cent %25. Par exemple, le mot de passe p@ss:1 s'écrit dans l'URL p%40ss%3A1. Pour éviter l'encodage, transmettez les données via une option dédiée : curl -v -x proxy.example.net:8080 --proxy-user user1:p@ss:1 https://example.com/. Ici, curl gère lui-même les caractères spéciaux.
6. Si curl passe mais que votre outil de travail reçoit toujours un 407, le problème vient de l'outil. Ouvrez ses paramètres proxy. Vérifiez que le login et le mot de passe sont saisis dans des champs séparés, et non collés à l'adresse si le logiciel ne l'attend pas. Vérifiez qu'il n'y a pas d'espace en fin de mot de passe : cela arrive souvent lors du copier-coller.
7. Dans le navigateur anti-détection, ouvrez les paramètres du profil concerné, pas les paramètres globaux. Beaucoup d'utilisateurs modifient le mot de passe dans la liste générale des proxys, mais le profil conserve une ancienne copie. Réenregistrez le proxy dans le profil et redémarrez le profil.
8. Si le navigateur a mémorisé les anciennes données et ne demande pas les nouvelles, effacez les mots de passe enregistrés pour cet hôte dans les paramètres du navigateur ou créez un nouveau profil pour tester.
9. Prêtez attention à l'en-tête Proxy-Authenticate dans la réponse 407. S'il indique « Basic », le proxy attend une paire login/mot de passe classique. Si une autre méthode est indiquée, votre outil doit la prendre en charge ; pour les proxys mobiles, on utilise presque toujours Basic, et une incohérence signifie une erreur dans le type de proxy configuré.
10. Relancez la requête curl et vérifiez que CONNECT reçoit maintenant 200.

Attention : n'essayez pas de « résoudre » un 407 par une répétition massive de requêtes. Certains serveurs proxy bloquent temporairement l'adresse après une série d'authentifications incorrectes, et vous obtiendrez un problème supplémentaire par-dessus le premier. Un test, une correction, un test.

Conseil : si vous avez plusieurs dizaines de canaux, conservez-les dans un tableau où le login et le mot de passe sont dans des colonnes séparées, avec à côté une colonne contenant le mot de passe déjà encodé pour l'URL. Vous ne vous tromperez jamais de version à insérer.

Résultat attendu

Dans la sortie curl, la ligne de réponse à CONNECT est devenue « HTTP/1.1 200 Connection established », le site renvoie du contenu. Dans votre outil, les requêtes passent. Le journal indique la cause : faute de frappe, encodage, changement d'IP, expiration ou cache.

Problèmes possibles

• Le code 407 arrive deux fois : d'abord sur CONNECT, puis à l'intérieur du tunnel. Cela indique que l'outil n'envoie les données qu'à un seul stade. Mettez à jour le programme ou activez l'option de transmission de l'authentification au CONNECT.
• L'espace client dit que l'IP est ajoutée, mais le 407 persiste. Vous passez probablement par un réseau d'entreprise ou un serveur à plusieurs adresses sortantes. Vérifiez l'adresse depuis la machine d'où partent réellement les requêtes.
• Cela fonctionne chez vous, pas chez un collègue avec les mêmes données. En authentification par IP, c'est normal : votre collègue a une autre adresse. Passez au login/mot de passe ou ajoutez une seconde IP.

Vérification : trois requêtes consécutives via curl et via votre outil ont abouti sans 407, la cause est notée dans le journal.

Étape 3 : Comprendre l'erreur 502 Bad Gateway renvoyée par le proxy

Objectif de l'étape : distinguer un incident bref au moment du changement d'IP d'un problème durable lié à une destination ou à un canal, et choisir la bonne réaction dans chaque cas.

Pourquoi le proxy renvoie 502

Le proxy a accepté votre requête, a tenté d'ouvrir une connexion plus loin et a reçu une coupure, un refus ou une réponse illisible. Pour les proxys mobiles, les causes typiques sont les suivantes : le modem était en train de changer d'adresse IP ou de se réenregistrer sur le réseau de l'opérateur ; le site cible a réinitialisé la connexion ; le proxy n'a pas pu résoudre le nom de domaine du site ; le canal est saturé par un trop grand nombre de flux simultanés ; le site est inaccessible pour tout le monde.

Instructions

1. Notez l'heure exacte d'apparition du 502, avec les secondes. C'est important pour le point suivant.
2. Ouvrez dans l'espace client l'historique des changements d'IP de ce canal, ou rappelez-vous si une rotation automatique planifiée est activée. Si la rotation s'est déclenchée aux mêmes secondes que l'erreur, vous êtes face à un comportement normal : pendant le changement d'adresse, les requêtes reçoivent un 502 pendant deux à dix secondes. La solution est de réessayer après une pause.
3. Attendez dix secondes et relancez la commande curl de l'étape 1. Si la réponse est devenue 200, notez dans le journal « 502 au moment de la rotation » et passez à la configuration des tentatives à l'étape 6.
4. Si le 502 se répète durablement, testez un autre site via le même proxy. S'il s'ouvre, le problème vient de la destination. S'il ne s'ouvre pas, le problème vient du canal.
5. Pour un problème de destination : ouvrez le site cible directement sans proxy. S'il est inaccessible même en direct ou renvoie un 5xx, le proxy n'y est pour rien : le site est en panne. S'il fonctionne en direct, le site coupe probablement les connexions provenant des adresses de cet opérateur. Changez d'IP via le lien de l'espace client et réessayez. Si cela ne suffit pas, essayez un canal d'un autre opérateur ou d'une autre région.
6. Pour un problème de canal : vérifiez dans l'espace client l'état de l'équipement. Beaucoup de fournisseurs proposent un indicateur d'état du modem. Un statut rouge ou jaune signifie que le canal est en cours de rétablissement, et il ne reste qu'à attendre ou à basculer sur un canal de secours.
7. Vérifiez la charge. Regardez dans votre outil combien de flux simultanés passent par ce canal. Un canal mobile a une bande passante limitée, et au-delà de dizaines de connexions parallèles, le proxy commence à rejeter une partie des requêtes précisément en 502. Divisez le parallélisme par deux et refaites le test.
8. Vérifiez si cela n'est pas lié au DNS. Faites une requête vers le site par son adresse IP au lieu du nom de domaine, si le site le permet, ou passez au schéma socks5h, où les noms sont résolus par le proxy, et comparez le résultat. Si par nom c'est 502 et par IP tout fonctionne, le problème vient de la résolution de noms côté proxy ; signalez le nom de domaine exact au fournisseur.
9. Si rien n'a fonctionné pendant 15 minutes, rassemblez la sortie curl -v, l'heure, l'hôte du canal, le domaine cible et envoyez-le au support du fournisseur. Une information correctement rassemblée réduit la résolution d'une journée à une heure.

Conseil : avec une rotation planifiée, synchronisez à l'avance les pauses de votre outil avec l'intervalle de changement d'IP. Si l'adresse change toutes les 5 minutes, faites marquer une pause de 15 secondes au parseur au début de chaque tranche de cinq minutes. Le nombre de 502 chutera presque à zéro sans une seule ligne de code complexe.

Résultat attendu

Vous savez précisément à quelle catégorie appartient votre 502 : moment de rotation, destination précise, saturation du canal, panne d'équipement ou indisponibilité du site. Pour les trois premières, vous avez un correctif ; pour les deux dernières, vous savez qu'il faut attendre et à qui écrire.

Problèmes possibles

• Le 502 arrive uniquement sur les gros fichiers. Le site ferme la connexion en raison d'un débit trop lent. Réduisez la taille des données demandées ou utilisez un canal avec une meilleure couverture.
• Le 502 provient du site, pas du proxy. Vérifiez les en-têtes : s'il y a le Server du site et pas de Proxy-Agent, c'est une défaillance interne du site, réessayez plus tard.
• Le 502 alterne avec des 200 sans logique apparente. Signe classique de saturation du canal. Réduisez le parallélisme jusqu'à obtenir un résultat stable.

Vérification : dix requêtes consécutives avec une pause de deux secondes via le canal problématique vers un site stable renvoient 200, ou vous avez en main un ticket au support avec toutes les données.

Étape 4 : Gérer le code 504 Gateway Timeout

Objectif de l'étape : comprendre à quel segment derrière le proxy le temps se perd, et réduire la part de 504 à un niveau acceptable, sans confondre le code avec un timeout réseau du client.

Ce que signifie précisément un 504 renvoyé par le proxy

Le serveur proxy a sa propre limite d'attente interne pour la réponse du site. Quand le site ne répond pas dans cette limite, le proxy arrête d'attendre et vous signale honnêtement l'échec par le code 504. Votre client, lui, n'a pas coupé la connexion, la réponse est arrivée. C'est pourquoi il est important que la limite d'attente de votre outil soit supérieure à celle du proxy : sinon vous verrez un timeout réseau sans code et ne pourrez pas comprendre ce qui se passe.

Instructions

1. Vérifiez la limite d'attente dans votre outil. Dans la plupart des programmes, elle s'appelle timeout, « temps d'attente de la réponse » ou « Read timeout ». Si elle est inférieure à 30 secondes, mettez-la temporairement à 60. C'est une étape de diagnostic : vous devez attendre le code du proxy.
2. Mesurez le temps de réponse via le proxy. Exécutez : curl -sS -o /dev/null -w "%{http_code} %{time_connect} %{time_starttransfer} %{time_total}" -x http://user1:pass1@proxy.example.net:8080 https://example.com/. L'option -w affiche quatre nombres : le code, le temps jusqu'à la connexion, le temps jusqu'au premier octet et le temps total en secondes.
3. Exécutez la même commande sans l'option -x. Comparez le temps jusqu'au premier octet. Si en direct le site répond en 0,4 seconde et qu'à travers le proxy il répond en 8 secondes, le retard sur le segment « proxy — site » est important, et un 504 apparaîtra à la moindre fluctuation du réseau mobile.
4. Vérifiez sur quelle requête le 504 apparaît. Faites une requête méthode HEAD, qui ne charge pas le corps de la page : curl -I -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Si HEAD passe et que GET de la page donne un 504, le problème vient de la taille ou de la lenteur de génération de la page, pas de la connexion elle-même.
5. Changez l'IP du canal via le lien de l'espace client. Le réseau mobile est hétérogène : une adresse peut aboutir à une station de base saturée, une autre à une station libre. Refaites la mesure. Si le temps chute de plusieurs fois, ajoutez une règle dans votre outil : en cas de 504, changer d'abord l'IP, puis réessayer.
6. Vérifiez la lourdeur de la page cible. Certains sites ne renvoient une réponse qu'après de longues opérations serveur. Si votre objectif est une donnée précise, essayez d'appeler une adresse plus légère sur le même site : une API, une version mobile, une page sans paramètres de tri.
7. Si le 504 n'arrive que sur un domaine précis et uniquement via les canaux d'un opérateur, notez-le dans le journal et redistribuez le travail sur ce domaine vers des canaux d'un autre opérateur.
8. Remettez la limite d'attente de votre outil à une valeur de travail, mais désormais consciemment : elle doit être légèrement supérieure au temps de réponse typique via le proxy et inférieure à ce que vous êtes prêt à attendre dans le cadre de votre tâche. Pour la plupart des scénarios, c'est 30 à 45 secondes.

Attention : ne mettez pas la limite d'attente de votre outil à plusieurs minutes « au cas où » et ne la laissez pas ainsi pour toujours. Un flux bloqué occupera une place dans la file, et une dizaine de flux bloqués donnera l'illusion que le proxy ne fonctionne pas, alors que le problème vient d'un seul site lent.

Conseil : ajoutez dans le log de votre outil une colonne « temps jusqu'au premier octet ». Elle permet de voir si le canal se dégrade progressivement ou chute brutalement. Une croissance progressive indique une saturation ou une mauvaise couverture ; une chute brutale indique plutôt une rotation ou un incident chez l'opérateur.

Résultat attendu

Vous connaissez le temps de réponse typique via chaque canal, vous avez fixé dans votre outil une limite supérieure à celle du proxy, et les 504 sont devenus un événement rare traité automatiquement.

Problèmes possibles

• Vous avez augmenté la limite et recevez maintenant un timeout réseau au lieu de 504. Cela signifie que le proxy attend plus longtemps que prévu, ou que la connexion au proxy est instable. Cela dépasse le cadre des codes, consultez les articles voisins sur les timeouts.
• 504 uniquement à certaines heures. Pic de charge du soir sur les réseaux mobiles. Décalez les tâches lourdes la nuit ou le matin.
• 504 sur la première requête vers un nouveau site, puis tout est rapide. Résolution de nom et établissement de la connexion côté proxy. Ajoutez une requête de préchauffage avant la série principale.

Vérification : une série de vingt requêtes vers un site de travail montre un temps jusqu'au premier octet dans une plage prévisible et pas plus d'un ou deux 504, et votre outil change l'IP et réessaie en cas de 504.

Étape 5 : Corriger l'erreur tunnel failed

Objectif de l'étape : apprendre à lire le nombre à côté de la phrase tunnel failed, le relier à la cause réelle et corriger les paramètres de protocole, de port et de type de proxy.

À quoi cela ressemble et ce que cela signifie

Dans curl, le message se présente ainsi : « CONNECT tunnel failed, response 407 ». Dans les navigateurs et les solutions anti-détection, on trouve les phrases « Proxy tunnel failed », « Unable to establish tunnel » ou « Tunnel connection failed ». Le point commun : le client a envoyé la commande CONNECT et le proxy a répondu autre chose que 200. Le nombre à côté est le code lui-même, et son traitement se ramène aux étapes précédentes plus quelques cas particuliers qui ne se manifestent qu'au stade du tunnel.

Instructions

1. Lancez curl avec l'option -v vers une adresse HTTPS et trouvez la ligne tunnel failed. Notez le nombre après le mot response.
2. S'il s'agit de 407, revenez à l'étape 2. La différence est unique : assurez-vous que votre outil transmet l'authentification au stade CONNECT. Dans d'anciennes versions de certains programmes, la case « Authentification proxy » ne s'applique qu'aux requêtes HTTP, et le tunnel part sans mot de passe.
3. S'il s'agit de 502 ou 504, revenez aux étapes 3 et 4. Le proxy n'a pas pu ouvrir de connexion au port 443 du site ou n'a pas attendu sa réponse.
4. S'il s'agit de 403, le proxy a refusé d'ouvrir le tunnel vers le port ou l'hôte indiqué. Vérifiez à quel port vous vous connectez. Les proxys mobiles autorisent généralement les tunnels vers 443 et quelques ports courants. Si votre service écoute sur un port non standard, vérifiez dans l'espace client ou auprès du fournisseur s'il est autorisé.
5. S'il s'agit de 400, le proxy n'a pas compris la commande. La cause la plus fréquente : vous avez indiqué un proxy SOCKS5 comme HTTP, ou l'inverse. Ouvrez l'espace client et regardez quel protocole et quel port sont attribués. Chez beaucoup de fournisseurs, les ports HTTP et SOCKS5 d'un même canal sont différents.
6. Corrigez le schéma dans la commande. Pour SOCKS5, utilisez : curl -v -x socks5h://user1:pass1@proxy.example.net:1080 https://example.com/. La lettre h dans socks5h signifie que les noms de domaine sont résolus par le proxy, et non par votre ordinateur. Pour les proxys mobiles, c'est la variante à privilégier.
7. Si vous êtes dans un navigateur anti-détection, ouvrez les paramètres proxy du profil et repérez la liste déroulante du type : HTTP, HTTPS, SOCKS5. Sélectionnez celui indiqué dans l'espace client et vérifiez le port. Après sauvegarde, redémarrez complètement le profil, pas seulement l'onglet.
8. Si le nombre à côté de tunnel failed est absent et qu'il n'y a que la phrase, activez la journalisation avancée dans l'outil ou reproduisez la situation via curl pour obtenir le code.
9. Vérifiez que votre outil ne tente pas d'établir une connexion TLS avec le proxy lui-même. Certains programmes, lorsque vous sélectionnez le type « HTTPS », chiffrent non seulement le trafic vers le site, mais aussi la connexion au proxy. Si le proxy ne le supporte pas, vous obtiendrez tunnel failed ou une erreur de handshake. Passez au type « HTTP » pour la connexion au proxy : le trafic vers le site reste de toute façon chiffré à l'intérieur du tunnel.
10. Relancez le test et vérifiez que CONNECT reçoit 200 et que la page se charge.

Conseil : faites de deux courtes requêtes de test une routine quotidienne : une vers une adresse en HTTP, la seconde vers la même adresse en HTTPS. Si la première passe et que la seconde échoue avec tunnel failed, vous comprenez en une seconde que le problème est dans le tunnel, pas dans l'authentification ou le canal.

Résultat attendu

La phrase tunnel failed a disparu des logs, le bon type et le bon port sont notés pour chaque canal, et votre outil n'applique pas de chiffrement superflu à la connexion au proxy.

Problèmes possibles

• Le tunnel s'établit, puis une erreur de certificat apparaît. Ce n'est plus la couche proxy : le site ou votre magasin de certificats local. Vérifiez la date et l'heure de l'ordinateur.
• Cela fonctionne dans curl, pas dans votre outil avec les mêmes données. L'outil applique un autre schéma ou ajoute son propre préfixe. Consultez sa documentation sur le format de la chaîne proxy.
• tunnel failed uniquement pour un site. Le site utilise un port non standard, revenez au point concernant le 403.

Vérification : une requête HTTPS via curl et via votre outil renvoie 200 sur CONNECT, le type et le port de tous les canaux sont notés dans le tableau.

Étape 6 : Configurer la bonne réaction de l'outil à chaque code

Objectif de l'étape : faire en sorte que les erreurs de serveur proxy soient traitées automatiquement : certaines réessayées après une pause, d'autres déclenchant immédiatement une alerte, et que vous obteniez des logs compréhensibles plutôt qu'un flot de lignes rouges.

Principe : toutes les erreurs ne se valent pas

Réessayer une requête sur 407 est inutile : le mot de passe ne deviendra pas correct à force. Réessayer sur un 502 au moment de la rotation est nécessaire : tout remarchera dans cinq secondes. Réessayer sur un 504 est préférable après un changement d'IP. Ces trois règles constituent la base d'une gestion saine des erreurs.

Instructions pour un outil prêt à l'emploi

1. Ouvrez les paramètres du parseur ou du gestionnaire de comptes et trouvez la section chargée des tentatives. Elle peut s'appeler « Retries », « Tentatives », « Gestion des erreurs ».
2. Fixez le nombre de tentatives pour les 5xx à 3, et la pause initiale à 5 secondes en la doublant à chaque fois : 5, 10, 20 secondes. Cette croissance des pauses s'appelle un délai exponentiel et évite que votre outil n'achève un canal déjà saturé.
3. Si l'outil permet de définir une liste de codes à réessayer, indiquez 502 et 504. N'y incluez pas 407.
4. Trouvez le réglage d'action en cas de 407. S'il n'existe pas, réglez le nombre de tentatives générales au minimum et activez la notification des requêtes échouées. Votre but est de voir le 407 dans les premières minutes, pas après une journée d'arrêt.
5. Repérez le champ destiné au lien de changement d'IP, s'il existe. Collez-y le lien de l'espace client correspondant au canal et activez l'option « Changer d'IP en cas d'erreur » ou « Rotation en cas d'échec ».
6. Limitez le nombre de flux simultanés par canal mobile. Commencez par 3-5 et augmentez jusqu'à ce que la part de 502 reste sous un pour cent.
7. Activez un log détaillé avec sauvegarde du code de réponse et des en-têtes. Vérifiez que le log montre la différence entre un code du proxy et un code du site : beaucoup de programmes l'affichent dans une colonne séparée « Proxy status ».
8. Enregistrez les paramètres, redémarrez l'outil et lancez une série de test de 50 requêtes.

Instructions pour un script personnel

Si vous écrivez du code, la logique est la même. En pseudo-code Python avec la bibliothèque requests, cela ressemble à ceci :

proxies = {"http": "socks5h://user1:pass1@proxy.example.net:1080", "https": "socks5h://user1:pass1@proxy.example.net:1080"} for attempt in range(3): r = session.get(url, proxies=proxies, timeout=45) if r.status_code == 407: alert("auth failed") break if r.status_code in (502, 504): rotate_ip() sleep(5 * 2 ** attempt) continue break

Notez trois points. Premier : sur 407, on sort immédiatement de la boucle et on envoie une notification. Deuxième : sur 502 et 504, on change d'abord l'IP, puis on attend une pause croissante. Troisième : la valeur de timeout est choisie pour attendre le code du proxy au lieu de couper la connexion trop tôt.

Attention : dans certaines bibliothèques, une erreur au stade CONNECT n'arrive pas comme une réponse avec code, mais comme une exception dont le texte contient tunnel failed et un nombre. Capturez ces exceptions séparément et extrayez le code du texte, sinon votre logique de tentatives ne se déclenchera pas.

Conseil : calculez la part de chaque code par canal sur une journée et affichez-la dans un tableau simple. Un canal dont les 5xx sont durablement plus élevés que les autres mérite d'être vérifié en premier, même s'il fonctionne formellement.

Résultat attendu

Votre outil réessaie automatiquement les requêtes sur 502 et 504 avec une pause croissante et un changement d'IP, signale immédiatement les 407, limite le nombre de flux et tient un log séparant les codes du proxy et ceux du site.

Problèmes possibles

• L'outil réessaie aussi les 407, ce qui entraîne un blocage temporaire de l'adresse par le proxy. Désactivez complètement les tentatives pour les 4xx ou réduisez le nombre total de tentatives à une seule.
• Après activation de la rotation en cas d'erreur, l'IP change trop souvent. Introduisez un intervalle minimal entre changements, par exemple 60 secondes, pour qu'une série de 502 ne provoque pas cinq rotations d'affilée.
• Le log grossit jusqu'à plusieurs gigaoctets. N'écrivez les en-têtes que pour les réponses portant un code d'erreur, et pour un 200, conservez une seule ligne.

Vérification : la série de test de 50 requêtes s'est déroulée sans intervention manuelle, le log montre des tentatives avec pauses de 5, 10, 20 secondes pour les 5xx, et avec un mauvais mot de passe, l'outil s'est arrêté et a émis une notification de 407.

Vérification du résultat : check-list et tests

Parcourez la liste et cochez chaque point. Si un seul n'est pas satisfait, revenez à l'étape correspondante.

Check-list

• La commande curl avec l'option -v s'exécute, et vous savez repérer dans la sortie la ligne de réponse à CONNECT et les en-têtes de service du proxy.
• Pour chaque canal, le tableau contient l'hôte, le port, le type de protocole, le mode d'authentification et le mot de passe encodé.
• En authentification par IP, l'adresse actuelle de votre machine correspond à celle de l'espace client.
• Une requête HTTPS via chaque canal reçoit 200 sur CONNECT.
• Le temps typique jusqu'au premier octet via chaque canal est mesuré, et la limite d'attente de l'outil le dépasse avec une marge.
• L'outil est configuré pour réessayer uniquement les 502 et 504, avec des pauses de 5, 10, 20 secondes et un changement d'IP avant la nouvelle tentative.
• En cas de 407, l'outil s'arrête et notifie.
• Le nombre de flux par canal est limité, et la part de 5xx sur la série de test est inférieure à un pour cent.
• Le journal des incidents est tenu et contient au moins une entrée entièrement analysée.

Comment tester

1. Saisissez volontairement un mauvais mot de passe et lancez une requête. Attendu : 407 dans curl et notification dans l'outil, sans série de tentatives.
2. Remettez le bon mot de passe et lancez 30 requêtes vers un site stable avec une pause d'une seconde. Attendu : toutes en 200, ou pas plus d'un 5xx avec une nouvelle tentative réussie.
3. Pendant la série, cliquez sur le lien de changement d'IP dans l'espace client. Attendu : un ou deux 502 dans le log, puis une nouvelle tentative automatique et la poursuite de la série.
4. Indiquez dans les paramètres le type SOCKS5 pour un canal attribué en HTTP et faites une requête. Attendu : tunnel failed ou une erreur de protocole que vous reconnaîtrez en une seconde. Remettez le bon type.

Indicateurs de réussite

La part des erreurs de la couche proxy dans les séries de travail ne dépasse pas un à deux pour cent, chaque erreur est classée par code, et aucune ne nécessite d'intervention manuelle, sauf le 407. Le temps de réaction à un 407 se compte en minutes, pas en heures.

Erreurs typiques et solutions

Problème : 407 après chaque redémarrage du routeur

Cause : authentification par IP, et votre fournisseur attribue une adresse dynamique.

Solution : passez à l'authentification par login/mot de passe, ou activez les deux modes en même temps. Si vous avez besoin de l'IP, demandez une adresse statique à votre fournisseur d'accès.

Problème : le mot de passe est correct, mais 407 dans le navigateur alors que curl passe

Cause : le navigateur ou le profil anti-détection a mis en cache les anciennes données.

Solution : réenregistrez le proxy dans les paramètres du profil concerné et redémarrez le profil ; au besoin, effacez les mots de passe enregistrés pour l'hôte du proxy.

Problème : 502 exactement toutes les N minutes

Cause : cela coïncide avec l'intervalle de rotation automatique des IP.

Solution : synchronisez les pauses de l'outil avec le calendrier de rotation, ou passez au changement d'IP via lien aux moments opportuns entre les tâches.

Problème : 502 avec beaucoup de flux, tout va bien avec peu

Cause : saturation du canal mobile.

Solution : réduisez le parallélisme à 3-5 flux par canal et répartissez la charge sur plusieurs canaux.

Problème : 504 uniquement sur un site, les autres sont rapides

Cause : le site génère lentement ses pages ou limite les adresses des opérateurs mobiles.

Solution : utilisez des adresses plus légères du site, changez d'IP avant de réessayer, et en cas de problème persistant, transférez le travail sur ce site vers un canal d'un autre opérateur.

Problème : au lieu d'un 504, une coupure sans code apparaît

Cause : la limite d'attente de l'outil est inférieure à la limite interne du proxy.

Solution : augmentez la limite de l'outil jusqu'à une valeur permettant d'obtenir le code, généralement 30 à 60 secondes.

Problème : tunnel failed, response 400

Cause : le port SOCKS5 est indiqué comme proxy HTTP, ou l'inverse.

Solution : vérifiez le type et le port avec l'espace client ; pour SOCKS5, utilisez le schéma socks5h, pour HTTP, http.

Problème : tunnel failed, response 403 vers un port non standard

Cause : le proxy n'autorise pas les tunnels vers ce port.

Solution : renseignez-vous auprès du fournisseur sur la liste des ports autorisés et, si possible, reconfigurez le service cible sur le port 443.

Problème : le code 502 ou 504 arrive avec un en-tête Server provenant du site

Cause : c'est la réponse du site lui-même, pas de la couche proxy : le site a un problème avec ses propres services internes.

Solution : attendez et réessayez plus tard ; changer de proxy n'aidera pas.

Fonctionnalités supplémentaires pour utilisateurs avancés

Si le diagnostic de base est maîtrisé, les astuces suivantes rendront la gestion des erreurs de la couche proxy quasi automatique.

Transmission manuelle de l'en-tête d'authentification

Il est parfois utile de vérifier comment le proxy réagit à un en-tête précis. Encodez la paire login:motdepasse en Base64 avec n'importe quel outil local et transmettez l'en-tête vous-même : curl -v -x proxy.example.net:8080 -H "Proxy-Authorization: Basic dXNlcjE6cGFzczE=" http://example.com/. Cette méthode fonctionne pour les requêtes HTTP classiques et aide à comprendre si le proxy accepte les données, indépendamment de la façon dont votre outil les forme. Pour CONNECT, utilisez l'option --proxy-header au lieu de -H.

Résolution des noms côté proxy

Le schéma socks5h et le tunnel HTTP transmettent le nom de domaine au serveur proxy au lieu de le résoudre localement. Cela offre deux avantages : le site voit une requête provenant entièrement du réseau mobile, et vous évitez les divergences où votre DNS local renvoie une adresse et le réseau de l'opérateur une autre. Si vous voyez des 502 uniquement en résolution locale, passer à socks5h résout souvent le problème sans contacter le fournisseur.

Automatisation via l'API du fournisseur

mobileproxy.space dispose d'une interface programmatique pour changer d'IP et obtenir le statut des canaux. Intégrez l'appel de changement d'IP dans le gestionnaire de 504, et la vérification du statut du canal dans celui des 502 persistants. Votre script décidera alors lui-même de réessayer via le même canal ou de basculer sur un canal de secours. Algorithme simple : trois 502 consécutifs en une minute — demander le statut ; si le canal est en bon état, changer d'IP ; sinon, marquer le canal indisponible pendant cinq minutes et passer au suivant.

Séparation des métriques proxy et site

Créez dans votre système de monitoring deux métriques distinctes : les codes arrivant avec les en-têtes du proxy, et ceux arrivant sans. La première parle de la santé de votre infrastructure proxy, la seconde du comportement des sites cibles. Tant qu'elles sont mélangées, vous chercherez une erreur de serveur proxy là où il n'y en a pas, et inversement.

Pool de canaux pondérés

Attribuez à chaque canal un poids qui diminue à chaque 5xx et se rétablit lentement avec le temps. Répartissez les requêtes proportionnellement aux poids. Cette approche détourne automatiquement la charge d'un opérateur ou d'une région problématique et la restaure quand le canal se rétablit, sans un seul basculement manuel.

Export HAR depuis le navigateur

Pour les cas complexes dans un navigateur anti-détection, ouvrez l'onglet Network, reproduisez l'erreur et choisissez « Save all as HAR ». Le fichier contient tous les en-têtes de requête et de réponse, y compris les stades invisibles dans le log habituel du programme. Avant de l'envoyer au support, supprimez du fichier les valeurs Proxy-Authorization et les cookies.

Optimisation des limites d'attente

Rassemblez sur une semaine les statistiques de temps jusqu'au premier octet par canal et par destination. Fixez la limite d'attente de l'outil au niveau du 95e centile plus 10 secondes. Une telle limite coupe rarement des requêtes vivantes et libère en même temps rapidement les flux en cas de blocage réel.

FAQ : questions fréquentes sur le diagnostic

Comment savoir si le 502 vient du proxy et non du site ?

Regardez les en-têtes de la réponse. S'il y a Proxy-Agent, Via ou d'autres en-têtes de service du proxy, sans Set-Cookie ni Server du site, la réponse vient du proxy. En complément : si le code est arrivé immédiatement en réponse à CONNECT, c'est certainement le proxy.

Faut-il réessayer une requête en cas de 407 ?

Non. Les identifiants ne deviendront pas corrects à force de réessayer, et une série de tentatives incorrectes peut entraîner un blocage temporaire de votre adresse côté proxy. Corrigez les données et réessayez une seule fois.

Pourquoi tout fonctionne dans curl mais pas dans mon outil ?

Le plus souvent, l'outil forme différemment la chaîne proxy, n'encode pas les caractères spéciaux du mot de passe, applique un autre type de protocole ou ne transmet pas l'authentification au CONNECT. Comparez caractère par caractère la chaîne exacte des paramètres de l'outil avec la commande curl qui fonctionne.

Comment saisir correctement un mot de passe avec des caractères spéciaux ?

Dans la chaîne d'adresse, encodez : @ en %40, : en %3A, # en %23, % en %25, l'espace en %20. Dans les champs séparés de login et de mot de passe, saisissez le mot de passe tel quel, sans encodage.

Quelle différence entre un 504 et le timeout évoqué dans d'autres articles ?

Le 504 est un code que le proxy a renvoyé lui-même après avoir atteint sa propre limite d'attente de la réponse du site. Le timeout sans code signifie que votre client a coupé la connexion sans rien recevoir. Les deux se traitent différemment, c'est pourquoi ils sont séparés dans des articles distincts.

Combien de flux peut-on faire passer par un canal mobile ?

Il n'y a pas de chiffre universel. Commencez par 3-5 et augmentez jusqu'à ce que la part de 502 reste sous un pour cent. Pour les pages lourdes, le nombre sera plus faible ; pour des requêtes API légères, plus élevé.

Faut-il changer d'IP à chaque erreur ?

Sur 504 et 502 persistants, oui, c'est la première action. Sur 407, non, le changement d'IP n'influence pas l'authentification. Fixez un intervalle minimal entre changements pour qu'une série d'erreurs ne déclenche pas une avalanche de rotations.

Que transmettre au support pour résoudre la question plus vite ?

La sortie complète de curl -v avec le mot de passe remplacé par des astérisques, l'heure exacte avec les secondes et le fuseau horaire, l'hôte et le port du canal, le domaine cible, le mode d'authentification et le résultat d'une requête directe sans proxy. Avec un tel ensemble, le support répond généralement dès le premier message.

Peut-on utiliser HTTPS pour la connexion au proxy lui-même ?

Uniquement si le fournisseur le prend explicitement en charge. Dans la plupart des cas, pour les proxys mobiles, la connexion au proxy se fait en HTTP classique ou SOCKS5, et le chiffrement du trafic vers le site est assuré par le tunnel. Activer un chiffrement superflu vers le proxy provoque un tunnel failed ou une erreur de handshake.

Conclusion

Vous avez parcouru le chemin depuis une ligne rouge incompréhensible dans les logs jusqu'à un système complet de diagnostic. Vous savez désormais déterminer qui a exactement renvoyé la réponse, vous lisez le 407 comme un signal pour vérifier les identifiants et le mode d'authentification, le 502 comme un signe d'incident derrière le proxy ou au moment d'une rotation, le 504 comme le rapport honnête du proxy sur un site lent, et tunnel failed comme une enveloppe autour de l'un de ces codes avec un indice sous forme de nombre. Votre outil ne réessaie plus l'inutile et ne renonce plus face au temporaire.

Que faire ensuite

1. Tenez un journal des incidents pendant au moins un mois. Dès deux semaines, vous remarquerez des schémas récurrents et éliminerez leurs causes.
2. Une fois par semaine, révisez la part des codes par canal et redistribuez la charge.
3. Automatisez le changement d'IP et la vérification de statut via l'API du fournisseur, pour que les 5xx de routine se règlent sans vous.
4. Parcourez les articles voisins du blog sur les timeouts réseau et le comportement des sites cibles, pour couvrir les deux segments restants du chemin de la requête.

Vers quoi progresser

Le niveau suivant consiste à construire votre propre pool de canaux pondérés avec monitoring, où une erreur de serveur proxy devient non pas un motif de panique, mais un point sur un graphique que le système traite de lui-même. Vous disposez déjà de tous les outils pour cela : la compréhension des codes, curl, l'espace client du fournisseur et l'habitude de tout noter. Bon travail et que vos 200 soient stables.