Étape 1 : qui a répondu ?#
Exécutez la requête ayant échoué avec curl -v. Un statut sur le CONNECT ligne, avant Connection established, vient de la passerelle ; un statut après qu'il vienne de la destination. Les navigateurs affichent les échecs de passerelle sous la forme ERR_TUNNEL_CONNECTION_FAILED ou ERR_PROXY_CONNECTION_FAILED.
Étape 2 : codes de passerelle#
| Coder | Signification du Proxy Cyber | Corriger |
|---|---|---|
| 407 invalid_credentials | Nom d'utilisateur ou mot de passe refusé | Copiez à nouveau la paire ; vérifier les espaces de fin ; L'adresse IP sur liste blanche a-t-elle changé ? |
| 400 paramètre_invalide | Un paramètre de nom d'utilisateur est inconnu ou mal formé | Vérifiez les clés et les valeurs : -cc-gb et non -cc-uk, -city- sans espaces, -ttl- de 1 min à 24h |
| 402 solde_insuffisant | Il ne reste plus aucun trafic ni solde | Recharger ; vérifiez le plafond de sous-utilisateur si vous en utilisez un |
| 403 destination_bloquée | Port ou destination non autorisé | Les cibles uniquement sur le port 25, UDP et IPv6 sont refusées par conception |
| 502 no_exit_available | Aucune sortie ne correspond à l'emplacement pour le moment | Élargir : supprimez -city- ou -asn-, conservez -cc- ; réessayez dans une minute |
| 502 exit_failed | La sortie a échoué avant la cible | Réessayez une fois ; la prochaine connexion choisit une autre sortie |
| 504 cible_timeout | La destination n'a pas répondu à temps | Réessayez ; vérifier la cible depuis un autre réseau |
Étape 3 : codes de destination#
| Coder | Cause probable | Corriger |
|---|---|---|
| 403 (page du site) | Type de sortie ou empreinte digitale rejetée | Sortie résidentielle ou mobile ; en-têtes clients réalistes ; session collante pour les flux |
| 429 | Limite de débit par IP | Rotation par connexion ; taux de sortie inférieur ; honorer Réessayer-Après |
| 200 avec des données vides | Bloc souple | Traitez comme 403 ; inspecter le contenu, pas le statut |
| 302 vers une page de défi | Vérification des robots | Ralentissez; vrai navigateur pour cette cible ; meilleur type de sortie |
| 5xx | Problème de cible | Reculez; pas un problème de proxy |
Échecs au niveau de la connexion#
- Une réinitialisation peut provenir du client, du chemin proxy ou de la destination. Enregistrez si cela s'est produit pendant CONNECT, la négociation TLS ou le transfert de données ; testez la même petite URL directement et via le proxy pour affiner le saut défaillant.
- Un délai d'inactivité peut provenir du client, de la passerelle, de la sortie ou de la destination. Enregistrez le temps écoulé et comparez les limites de connexion/lecture du client avec les paramètres de service attribués. Une réinitialisation de la connexion ne prouve pas en soi que la sortie résidentielle s'est déconnectée ; reproduisez l'erreur avec une petite requête avant de modifier la configuration.
- Erreurs TLS via le proxy : jamais normales. Recherchez un intercepteur local (proxy d'entreprise, antivirus) entre vous et la passerelle.
Étape 4 : décider#
- Corrigez les informations d'identification ou les paramètres avant de réessayer à plusieurs reprises. Une requête ayant échoué peut toujours transférer des octets ; vérifiez l'utilisation enregistrée et les conditions de facturation applicables plutôt que de supposer que chaque erreur est gratuite.
- La passerelle n'a trouvé aucune sortie → élargir l'emplacement.
- La cible bloque le type de sortie → déplacez la cible vers un réseau plus fort : centre de données → résidentiel → mobile.
- Classez la réponse avant de réessayer. Un 403 peut indiquer une règle d'accès qu'une autre IP ne résoudra pas. Pour 429, respectez Retry-After et réduisez le taux de requêtes ; utilisez une interruption limitée en cas de connexion temporaire ou de pannes de serveur. Réessayez les opérations de changement d'état uniquement lorsque vous pouvez empêcher les actions en double.
- Cible cassée → attendez.
Les questions que les gens posent#
Proxy Cyber renvoie-t-il jamais 429 ?
Un 429 peut être renvoyé par une destination ou un intermédiaire qui applique une limite tarifaire. Inspectez les en-têtes de réponse et l’échange CONNECT pour identifier la source. Préserver Retry-After lorsqu'il est présent, réduire la concurrence et conserver un court journal des horodatages et des ID de demande d'assistance ; changer d’IP ne remplace pas le respect de la limite.
Suis-je facturé pour les demandes ayant échoué ?
Estimez le trafic à partir d’un test représentatif, puis comparez le solde avant et après. Les corps de réponse, les téléchargements, les ressources du navigateur et les tentatives affectent tous la consommation. Confirmez les conditions de comptage et de remboursement applicables avant de payer ; ce guide ne promet pas que les demandes échouées sont gratuites ou que les fonds inutilisés sont automatiquement remboursables.