L'accès à un service proxy payant s'ouvre de deux manières : soit vous envoyez à chaque requête un nom d'utilisateur et un mot de passe , soit vous déclarez votre adresse IP publique dans le panneau du fournisseur pour constituer une whitelist (liste d'autorisation). Les deux résolvent le même problème — « cette connexion appartient-elle réellement à l'abonné ? » — mais donnent des résultats très différents au quotidien.
Dans cet article, nous voyons comment ces deux méthodes fonctionnent au niveau du protocole, laquelle est la bonne selon le scénario, et quels codes d'erreur vous rencontrerez.
Méthode 1 : nom d'utilisateur et mot de passe
Dans cette méthode, les identifiants sont envoyés au proxy à chaque connexion. Le format varie selon le protocole :
- Proxy HTTP :
Proxy-Authorization: Basic <base64(kullanici:sifre)>le header est ajouté. - SOCKS5 : la sous-négociation username/password définie dans la RFC 1929 est effectuée ; le nom d'utilisateur et le mot de passe sont envoyés en binaire.
Côté HTTP, le déroulement est le suivant : le client envoie une requête sans identifiants, le proxy répond par 407 Proxy Authentication Required , le client ajoute les identifiants et répète la requête.
La plupart des clients effectuent ces deux tours automatiquement. curl et les navigateurs, face à un 407, ajoutent les identifiants et répètent la requête ; les bibliothèques HTTP simples, elles, ne réessaient parfois pas et renvoient directement une erreur.
Basic la méthode ne chiffre pasles identifiants, elle les encode seulement en Base64. Le Base64 est un encodage réversible. La confidentialité des identifiants dépend donc de la sécurité de la connexion vers le proxy elle-même.
Méthode 2 : whitelist IP
Dans le modèle whitelist, il n'y a pas de mot de passe. Vous ajoutez votre propre adresse IP publique dans le panneau du fournisseur ; le proxy n'accepte que les connexions provenant de cette adresse. Comme aucun identifiant n'est transporté, le côté client devient très simple : curl -x http://proxy.example.com:8080 https://example.com suffit.
La question décisive de ce modèle est la suivante : votre adresse IP publique est-elle fixe ? Sur la plupart des connexions résidentielles, l'IP est dynamique et change au redémarrage du modem. Dès qu'elle change, la whitelist devient caduque et toutes les connexions sont refusées.
Le choix se résume largement à la question « avez-vous une IP fixe ? ». Pour les automatisations tournant sur un serveur, la whitelist convient mieux ; pour un usage nomade, c'est le nom d'utilisateur/mot de passe.
Quelle méthode pour quel scénario ?
Scraper ou bot tournant sur un serveur
L'IP de votre VPS est fixe ; choisissez la whitelist. Les identifiants ne sont pas inscrits dans le code ni dans une variable d'environnement, et la surface de fuite se réduit. Pour les scénarios d'automatisation c'est le réglage par défaut que nous recommandons.
Usage manuel depuis un ordinateur portable
Si vous passez du bureau à la maison puis au café, votre IP change sans cesse. Utilisez le nom d'utilisateur/mot de passe ; cela fonctionne sans problème depuis n'importe quel réseau.
Usage partagé au sein d'une équipe
Si vous devez pouvoir répondre à la question « qui a consommé combien de trafic ? », créez un utilisateur distinct par personne. Avec une whitelist, toute l'équipe apparaît sous une seule identité.
Profils multiples avec un navigateur antidetect
Si chaque profil doit recevoir une IP de sortie différente, le nom d'utilisateur/mot de passe est indispensable, car la sélection de session est le plus souvent encodée dans le nom d'utilisateur (par exemple user-session-a1).
Encoder l'information de session dans le nom d'utilisateur
Un schéma est répandu dans les pools residential : le nom d'utilisateur n'est pas seulement une identité, il porte aussi une commande . Par exemple :
Le caractère séparateur et les noms de paramètres varient d'un fournisseur à l'autre. Référez-vous à la documentation de votre panneau ; le format présenté ici sert uniquement à illustrer la structure.
L'avantage de cette conception est qu'aucun appel d'API n'est nécessaire côté client : vous changez de pays ou de session en modifiant le nom d'utilisateur. L'inconvénient est l'allongement des identifiants et le fait qu'une faute de frappe entraîne des changements de comportement silencieux. La logique du rotating proxy dans notre article qui l'explique, nous détaillons l'effet de ce modèle sur la gestion des sessions.
Erreurs fréquentes
La différence entre 407 et 403 est essentielle : 407 signifie « présentez votre identité », tandis que 403 signifie « j'ai vu votre identité, vous n'avez pas les droits ».
Le piège des caractères spéciaux
Lorsque vous écrivez les identifiants au format URL, certains caractères du mot de passe se confondent avec les séparateurs. Dans l'expression http://user:p@ss@ip:8080 le second @ est pris pour un séparateur et la connexion ne peut pas être établie. La solution est l'encodage pourcent :
| Caractère | Forme encodée | Caractère | Forme encodée |
|---|---|---|---|
@ | %40 | / | %2F |
: | %3A | # | %23 |
? | %3F | % | %25 |
Une approche plus robuste consiste à fournir les identifiants dans les champs dédiés du client plutôt que de les intégrer à l'URL. Python requests, Node undici et l'option --proxy-user de curl le prennent en charge.
Lire les identifiants depuis une variable d'environnement plutôt que de les inscrire dans le code évite leur fuite dans le contrôle de version et facilite leur rotation.
Qu'est-ce qui change du point de vue de la sécurité ?
Les deux méthodes comportent des risques différents. Dans le modèle nom d'utilisateur/mot de passe, le secret peut être dérobé: une ligne de commande tombée dans un fichier de log, un fichier de configuration échappé dans le contrôle de version ou une capture d'écran suffisent. Dans le modèle whitelist, il n'y a pas de secret, mais il existe un risque de partage d'IP : toute personne sur le même réseau de bureau peut utiliser votre proxy sans le savoir.
La configuration la plus solide consiste à combiner les deux : restreignez la source avec une whitelist et ajoutez par-dessus un nom d'utilisateur/mot de passe. La plupart des fournisseurs professionnels prennent en charge ce modèle hybride. Côté confidentialité, si vous vous demandez ce que voit le proxy, le proxy est-il sûr notre article propose un cadre complet ; pour les tests de fuite, DNS leak et fuite WebRTC vous pouvez utiliser nos outils.
Règles pratiques pour la gestion des identifiants
- Utilisez des variables d'environnement, ne les écrivez pas dans le code.
- Créez des identifiants distincts pour chaque environnement : développement, test et production ne doivent pas partager le même mot de passe.
- Définissez des quotas et des limites; un identifiant ayant fuité ne doit pas consommer un trafic illimité.
- Faites-les tourner régulièrement; changez-les impérativement après le départ d'un membre de l'équipe.
- Masquez-les dans les logs; la sortie de débogage ne doit pas écrire le mot de passe en clair.
Résumé
La whitelist IP est la solution la plus propre et la moins exposée aux fuites sur des serveurs à IP fixe. Le nom d'utilisateur et le mot de passe sont, eux, incontournables pour un usage nomade et pour les scénarios exigeant plusieurs sessions. Pour décider, il suffit de répondre à trois questions : « mon IP est-elle fixe ? », « combien de personnes vont l'utiliser ? » et « dois-je envoyer un paramètre de session ? ». Pour tester votre configuration, vous pouvez utiliser Savoir si un proxy datacenter suffit dépend du niveau de protection de la cible, et cela se mesure. Prenez la connexion directe comme référence et faites un test comparatif à la même cadence ; choisissez le palier selon le taux de réussite. Mettre en place une logique de montée par paliers et accumuler des statistiques par cible réduit au minimum le coût comme la perte de vitesse. Pour commencer, vous pouvez consulter et vérifier votre IP de sortie Mon adresse IP avec.