Intégrer · Erreurs et dépannage
Tous les statuts auxquels la passerelle peut répondre et les éléments à modifier.
Les erreurs de passerelle sont accompagnées d'une courte raison dans le corps. Les erreurs de cible passent intactes. Distinguer les deux constitue l’essentiel du dépannage.
Réponses de la passerelle#
| Statut | La raison dans le corps | Parce que | Corriger |
|---|---|---|---|
| Authentification proxy 407 requise | invalid_credentials | Nom d'utilisateur ou mot de passe incorrect, ou l'adresse IP de connexion ne figure pas sur la liste blanche et aucune information d'identification n'a été envoyée | Copiez à nouveau la paire depuis le tableau de bord ; vérifiez la liste blanche par rapport curl https://api.ipify.org exécuter sans proxy |
| 400 requêtes incorrectes | paramètre_invalide : … | Un paramètre de nom d'utilisateur est inconnu ou mal formé, ou la combinaison n'est pas valide (-state- en dehors des États-Unis, -city- sans -cc-) | Corrigez la chaîne nommée dans le corps ; voir Ciblage & sessions |
| 402 Paiement requis | solde_insuffisant | Il ne reste plus de trafic sur le réseau du pool que vous utilisez ou le sous-utilisateur a atteint sa limite. | Achetez du trafic ou augmentez la limite de sous-utilisateurs ; vérifier GET /v1/balance |
| 403 Interdit | destination_bloquée | La destination ou le port n'est pas autorisé (port 25 ou une cible sur notre liste de refus), ou le compte est suspendu | Lisez la raison ; contactez-nous si vous pensez qu'une destination est mal répertoriée |
| 502 Mauvaise passerelle | no_exit_available / exit_failed | Aucun appareil en ligne pour les paramètres, ou l'appareil choisi a été abandonné en cours de requête | Réessayez une fois (la rotation choisit déjà une autre sortie) ; élargir le ciblage en cas de répétition |
| 504 Délai d'expiration de la passerelle | cible_timeout | La cible n'a pas répondu par la sortie dans le délai imparti | Réessayez avec une nouvelle adresse IP ; augmentez le délai d'attente de votre client si la cible est lente par nature |
Erreur de passerelle ou erreur de cible ?#
Une erreur de passerelle arrive avant tout octet de la cible : sur une requête HTTPS c'est la réponse au CONNECT, que la plupart des clients présentent comme une erreur de connexion ou de proxy plutôt que comme une réponse HTTP. Une erreur de cible arrive à l'intérieur du tunnel avec les propres en-têtes et corps de la cible. curl -v montre immédiatement la différence : regardez quelle réponse suit CONNECT.
Liste de contrôle de diagnostic#
- Exécutez la requête la plus simple :
curl -x http://USER:PASS@res.proxy-cyber.com:9000 https://api.ipify.orgsans paramètres. Si cela fonctionne, le problème vient d'un paramètre ou de votre client. - Vérifiez le schéma de proxy : l'URL du proxy commence par
http://(ousocks5h://sur 9001), jamaishttps://, même pour les cibles HTTPS. - Ajoutez les paramètres un par un.
400nomme le mauvais ;502sur une combinaison étroite signifie que personne n’y est en ligne pour le moment. - Utilisateurs de la liste blanche : comparez l'adresse dans Paramètres → Liste blanche avec la sortie de
curl https://api.ipify.orgsans proxy, exécuté sur la même machine. Les instances cloud sortent souvent via une passerelle NAT avec une adresse différente. - Vérifiez le solde du réseau que vous utilisez réellement : le trafic résidentiel et mobile sont des soldes distincts.
- Recherchez les variables d'environnement (
HTTP_PROXY,HTTPS_PROXY,ALL_PROXY,NO_PROXY) qui remplacent ce que vous transmettez dans le code. - Si la vérification du certificat TLS échoue, quelque chose entre vous et la passerelle intercepte TLS (proxy d'entreprise, antivirus). La passerelle ne touche jamais aux certificats.
Symptômes et leur cause habituelle#
| Tu vois | Signifie généralement | Fais ceci |
|---|---|---|
curl: (56) Received HTTP code 407 from proxy after CONNECT | Informations d'identification rejetées | Recopiez-les ; coder en pourcentage les caractères spéciaux si vous définissez votre propre mot de passe |
| La même IP à chaque demande | Votre client réutilise une connexion persistante ou vous avez laissé une -sid- dans le nom d'utilisateur | Fermez les connexions entre les requêtes ou supprimez l'identifiant de session |
Une IP différente à chaque demande bien que -sid- est réglé | La durée de vie est plus courte que l'intervalle entre les requêtes ou que l'identifiant change par requête (une valeur aléatoire dans un modèle) | Réparez l'identifiant, augmentez -ttl- |
Connection reset by peer mi-téléchargement | Le foyer s'est déconnecté | Réessayez ; avec la rotation, il utilise déjà une autre sortie ; lors d'une session persistante, la prochaine requête obtient une nouvelle adresse IP |
| Fonctionne en curl, échoue dans le navigateur | Le navigateur n'a pas de mot de passe proxy ou le drapeau ignore les informations d'identification | Utilisez l'authentification Dramaturge ou Marionnettiste, ou l'authentification liste blanche |
| Ciblez les réponses 403 ou un CAPTCHA | La cible note la visite, pas le proxy | Passez au résidentiel ou au mobile, ajoutez une session persistante pour les flux en plusieurs étapes, faites correspondre les en-têtes au pays de sortie, le rythme par domaine |
| Tout est lent | Sortie lointaine ou un foyer sur une ligne faible | Choisissez le pays le plus proche de la cible, gardez les sessions courtes pour que la suivante atterrisse sur une meilleure ligne, ou utilisez un centre de données ou un FAI pour une vitesse brute. |
SSL certificate problem | Interception TLS de votre côté | Supprimez l'interception ou faites confiance à sa racine ; la passerelle n'est pas impliquée |
Toujours coincé#
Envoyez-nous la demande exacte (informations d'identification supprimées), l'horodatage en UTC, le statut et le corps que vous avez reçus et l'adresse IP de sortie si la demande a abouti. Le page de contact explique comment joindre l'équipe ; les titulaires de compte ouvrent un ticket depuis le tableau de bord.