Avant qu’un proxy n’approche du code applicatif, il vaut mieux prouver qu’il fonctionne depuis un outil que vous pouvez inspecter. cURL et Postman sont les deux outils vers lesquels la plupart des développeurs se tournent, et tous deux gèrent bien les proxies une fois configurés, mais chacun possède un paramètre qui produit un comportement déroutant si vous le manquez. Voici la configuration qui fonctionne pour les deux, les indicateurs de débogage qui comptent, et les pièges.
Les détails de connexion sont les mêmes partout : hôte p.shifter.io, port 443, et un nom d’utilisateur qui porte votre ciblage. La référence de format se trouve dans comment se connecter à un proxy résidentiel.
cURL
La configuration entière tient en un seul indicateur.
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json-x et --proxy sont la même chose. Exécutez cela deux fois et l’adresse devrait différer, ce qui confirme à la fois les identifiants et la rotation en une seule étape.
Le ciblage se fait dans le nom d’utilisateur, donc rien d’autre dans la commande ne change :
# sortie allemande
curl -x customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
# session persistante, dix minutes
curl -x customer-USERNAME-country-de-sid-abc123-ttl-600:PASSWORD@p.shifter.io:443 https://ipinfo.io/jsonGarder les identifiants hors de l’historique de votre shell
Intégrer un mot de passe dans l’URL le place dans votre historique et dans toute liste de processus. Deux meilleures options :
# identifiants passés séparément
curl -x p.shifter.io:443 -U customer-USERNAME-country-de:PASSWORD https://ipinfo.io/json
# ou depuis l'environnement
export PROXY_USER="customer-USERNAME-country-de"
export PROXY_PASS="..."
curl -x p.shifter.io:443 -U "$PROXY_USER:$PROXY_PASS" https://ipinfo.io/jsonNotez que -U correspond aux identifiants du proxy et -u aux identifiants pour le site cible. Confondre les deux est une cause fréquente d’un 407 avec un mot de passe parfaitement correct.
Indicateurs de débogage à connaître
# voir la poignée de main du proxy et si l'authentification a réussi
curl -v -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
# répartition du temps : où passe réellement la latence
curl -o /dev/null -s -w "connect: %{time_connect}s ttfb: %{time_starttransfer}s total: %{time_total}s\n" \
-x customer-USERNAME:PASSWORD@p.shifter.io:443 https://example.comCe second est le moyen le plus rapide de distinguer une connexion proxy lente d’une cible lente, ce qui constitue le premier embranchement dans pourquoi les requêtes expirent et le point de départ pour réduire la latence.
SOCKS5 dans cURL, et le piège
Si vous utilisez SOCKS5 plutôt que HTTP, le schéma compte plus qu’il n’y paraît :
# fuite DNS : votre machine résout le nom d'hôte
curl -x socks5://customer-USERNAME:PASSWORD@p.shifter.io:443 https://example.com
# correct : le proxy le résout
curl -x socks5h://customer-USERNAME:PASSWORD@p.shifter.io:443 https://example.comLe h fait toute la différence, et se tromper signifie que vos requêtes DNS partent depuis votre propre localisation, ce qui peut renvoyer des résultats régionalement incorrects. Détails dans prévenir les fuites DNS.
Un indicateur à ne jamais déployer
--proxy-insecure désactive la vérification de certificat sur le tronçon proxy. C’est parfois utile pour confirmer qu’une erreur TLS est un problème de certificat plutôt qu’autre chose, mais cela ne doit jamais apparaître dans quoi que ce soit de permanent.
Postman
La prise en charge des proxies par Postman est solide, mais elle se configure dans les paramètres de l’application plutôt que par requête, ce qui surprend les personnes qui s’attendent à la trouver sur la requête elle-même.
La configurer
Ouvrez Settings, puis l’onglet Proxy. Désactivez l’option de proxy système et activez la configuration de proxy personnalisée. Définissez le serveur proxy sur p.shifter.io et le port sur 443, cochez à la fois HTTP et HTTPS, puis activez l’authentification proxy et saisissez votre nom d’utilisateur, y compris tout indicateur de ciblage, et votre mot de passe.
Cette configuration est globale à l’application Postman, ce qui est le point à garder en tête : une fois définie, chaque requête de chaque collection passe par le proxy jusqu’à ce que vous le désactiviez. Si vous testez également des services internes, ils seront acheminés eux aussi, ce qui n’est généralement pas souhaité.
Le paramètre qui casse tout
Dans Settings puis General, il y a SSL certificate verification. Si vous rencontrez des erreurs de certificat via le proxy et que vous la désactivez, souvenez-vous que vous avez désactivé la vérification pour tout ce que fait Postman, pas seulement pour la requête proxifiée. Réactivez-la ensuite. Si vous voyez des erreurs de certificat, cela vaut la peine d’être compris plutôt que d’être simplement désactivé.
Changer de ciblage sans tout retaper
Comme le ciblage se trouve dans le nom d’utilisateur, changer de pays revient à modifier un seul champ. Les variables Postman rendent cela moins fastidieux : définissez un environnement avec une variable pour le nom d’utilisateur du proxy, puis changez d’environnement pour changer de marché. La boîte de dialogue des paramètres proxy accepte la syntaxe de variable, donc customer-USERNAME-country-{{market}} permet de changer de pays en changeant l’environnement actif plutôt qu’en ouvrant les paramètres chaque fois.
Vérifier que cela fonctionne
Envoyez un GET vers https://ipinfo.io/json et lisez la réponse. Elle devrait indiquer une adresse dans le pays que vous avez ciblé, pas la vôtre. Envoyez-le deux fois sans sid dans le nom d’utilisateur et l’adresse devrait changer.
Si l’adresse est la vôtre, le proxy n’est pas appliqué du tout : vérifiez que la configuration de proxy personnalisée est bien activée et que HTTP et HTTPS sont tous deux cochés.
Le Collection Runner
Pour tester à un volume légèrement plus important, le Collection Runner exécutera une collection de manière répétée à travers la même configuration proxy. Ajoutez un délai entre les itérations plutôt que de tourner à plein régime, car une rafale de requêtes identiques est le moyen le plus rapide d’obtenir qu’une cible cesse de répondre, selon limitation de débit et throttling.
Quand quelque chose échoue
Quatre réponses couvrent presque tout, et chacune pointe vers quelque chose de spécifique.
407 signifie que les identifiants ont été rejetés, ou qu’un indicateur dans le nom d’utilisateur est malformé, car une valeur non reconnue rend tout le nom d’utilisateur non analysable. Testez d’abord le nom d’utilisateur nu sans indicateurs ; si cela fonctionne, ajoutez-les un par un. Le chemin complet dans corriger les erreurs 407.
502 signifie que vos identifiants étaient corrects mais que rien ne correspondait à votre filtre à ce moment-là. Élargissez-le, ou passez de la ville au pays.
509 signifie que le forfait de bande passante est épuisé avec le dépassement désactivé.
Connexion refusée ou blocage signifie que vous n’avez jamais atteint la passerelle. Vérifiez nc -vz p.shifter.io 443 avant de supposer un problème de proxy, et confirmez que vous ne visez pas un hôte obsolète.
L’index plus large se trouve dans erreurs courantes des proxies résidentiels.
Passer des outils au code
Une fois que les deux outils fonctionnent, les quatre mêmes valeurs se transposent directement dans ce que vous construisez, et les schémas côté client se trouvent dans utiliser des proxies résidentiels avec Python. Une chose ne se transpose pas : dans le code applicatif, la réutilisation de connexion signifie que les requêtes envoyées via un tunnel existant conservent la même adresse de sortie, ce qui ressemble exactement à un échec de rotation. Cette surprise est traitée dans l’IP ne tourne pas.
L’essentiel
Dans cURL, tout se résume à -x, avec -U pour garder les identifiants hors de l’URL, -v pour voir la poignée de main, et -w pour savoir si la lenteur vient du proxy ou de la cible ; si vous utilisez SOCKS5, utilisez socks5h pour que le DNS se résolve au niveau du proxy. Dans Postman, la configuration se trouve dans les paramètres de l’application plutôt que sur la requête, elle s’applique donc globalement jusqu’à ce que vous la désactiviez, et le bouton de vérification SSL est à l’échelle de l’application plutôt que spécifique à une requête. Dans les deux cas, le ciblage se trouve dans le nom d’utilisateur, donc changer de pays ne signifie jamais changer d’hôte, de port, ou quoi que ce soit d’autre. Prouvez que cela fonctionne dans un outil que vous pouvez inspecter avant de le mettre dans le code, et lisez les échecs par code de statut.
La passerelle derrière tout cela est les proxies résidentiels, un seul hôte et une seule paire d’identifiants pour tous les pays et modes de session, facturés par GB afin que les tests ne coûtent que la bande passante qu’ils utilisent.