Un port proxy n'accepte pas de connexion sans authentification : sinon, n'importe qui connaissant l'adresse et le port pourrait l'utiliser. Les fournisseurs proposent deux moyens de dire au port « celui-ci est autorisé » : fixer une paire identifiant-mot de passe ou inscrire l'IP externe du client dans une liste blanche. Ces méthodes ne sont pas interchangeables : chacune a sa propre défaillance, son propre point de fuite et son propre confort pour le travail en équipe. Voyons laquelle choisir selon votre infrastructure.

Comment fonctionnent les deux méthodes

L'identifiant et le mot de passe sont transmis dans la requête de connexion elle-même, soit dans l'URL du proxy (login:password@host:port), soit dans un en-tête d'autorisation distinct. Le port vérifie la paire à chaque connexion, quelle que soit l'origine de la requête. C'est le contrôle classique « qui êtes-vous », lié aux identifiants et non au lieu de connexion.

La liste blanche d'IP fonctionne autrement : le port connaît à l'avance la liste des adresses externes autorisées à se connecter sans mot de passe. Le contrôle ne porte pas sur « qui êtes-vous » mais sur « d'où venez-vous » : on compare l'IP d'où provient la requête TCP vers le proxy. Si l'adresse externe du client ne correspond pas à celle inscrite dans la liste, la connexion est refusée avant toute tentative d'authentification.

Quand la liste blanche d'IP est plus pratique

La liste blanche fait gagner du temps lorsque l'adresse externe du client est stable : serveur dédié, accès de bureau avec IP statique, VPS dans le cloud. Il suffit d'inscrire l'adresse une fois dans l'espace client, et la connexion se fait ensuite sans mot de passe dans chaque script, ce qui simplifie les configurations et supprime le risque de publier la paire par erreur dans un dépôt. Pour l'automatisation côté serveur, où un script tourne pendant des années depuis le même hôte, c'est l'option la moins coûteuse en efforts. Avant de vous appuyer sur une liste blanche, assurez-vous que le canal offre des métriques stables : sinon, la stabilité de l'adresse peut masquer la dégradation de la connexion elle-même.

L'inconvénient est unique, mais fatal : si l'IP externe du serveur change (l'hébergeur attribue une nouvelle adresse après un redémarrage, migration vers un autre centre de données, changement de forfait chez l'opérateur), la liste blanche ne reconnaît plus le client instantanément et sans avertissement. Le script reçoit un refus de connexion et non une erreur d'authentification, ce qui est plus long à diagnostiquer : le code semble fonctionner, le proxy semble payé, mais le trafic ne passe tout simplement pas.

Quand l'identifiant et le mot de passe sont indispensables

Une adresse externe dynamique rend la liste blanche inutile par principe. Connexion domestique avec reconnexion DHCP, accès mobile, ordinateur portable qui se connecte chaque jour depuis un nouvel endroit : dans ces scénarios, l'adresse IP du client change plus vite que la liste ne peut être mise à jour dans l'espace client du fournisseur. L'identifiant et le mot de passe sont alors la seule méthode qui fonctionne : l'authentification ne dépend pas de l'endroit physique d'où provient la requête.

Deuxième cas : de nombreuses machines avec une seule paire d'accès. Lorsque plusieurs collaborateurs ou plusieurs serveurs aux adresses différentes et imprévisibles utilisent le proxy, inscrire chaque IP à la main dans la liste blanche est inefficace, et avec une infrastructure cloud en autoscaling, c'est tout simplement impossible : les nouvelles instances reçoivent dynamiquement de nouvelles adresses. La logique est similaire dans les équipes qui gèrent des comptes via un navigateur antidetect : chaque collaborateur a son propre profil et sa propre IP, et fixer une adresse dans la liste blanche pour chacun n'a aucun sens.

Risques de fuite de la paire identifiant-mot de passe

L'identifiant et le mot de passe ont un point faible que la liste blanche n'a pas : la paire d'accès est un secret, et un secret peut fuiter. Elle se retrouve dans les journaux de l'application lors du débogage, dans l'historique des commandes du shell, dans un dépôt public après un commit accidentel de la configuration, dans une conversation lors du partage de l'accès avec un collègue. Celui qui obtient la paire se connecte depuis n'importe quelle IP : le proxy ne vérifie pas d'où vient la requête, seulement qui a fourni le bon mot de passe.

À cet égard, la liste blanche est plus robuste : même si quelqu'un découvre l'adresse et le port du proxy, il ne pourra pas se connecter sans avoir fait inscrire sa propre IP externe dans la liste. Il n'y a pas de secret à copier et à emporter : il y a un lien avec une infrastructure qu'un tiers ne contrôle pas.

Que choisir pour le travail en équipe

Une approche mixte est généralement plus pertinente qu'une solution universelle unique. Pour une infrastructure serveur stable, la liste blanche : moins de secrets dans les configurations, risque de fuite réduit. Pour les collaborateurs itinérants ou en accès domestique, pour les environnements de test et pour les intégrations via API, l'identifiant et le mot de passe, mais avec une rotation obligatoire : si la paire a été transmise dans une conversation ou utilisée lors d'un test, mieux vaut la changer que la laisser sans limite de durée. Vous pouvez vérifier quelle méthode est disponible sur un port donné, et pour quel volume de trafic, dans l'espace client lors de l'attribution de l'adresse.

Questions fréquentes

Peut-on utiliser les deux méthodes en même temps sur un même port ?

En général, un port applique un seul schéma de contrôle, défini lors de l'attribution, mais rien n'empêche de garder plusieurs ports pour différents scénarios : certains avec liste blanche pour les serveurs, d'autres avec identifiant et mot de passe pour les usages mobiles et itinérants.

Pourquoi le proxy a-t-il soudain cessé d'accepter les connexions sans modification du code ?

La cause la plus fréquente est le changement de l'IP externe du client inscrite dans la liste blanche. Vérifiez l'adresse sortante actuelle du serveur et comparez-la à la liste de l'espace client ; l'hébergeur peut changer l'adresse lors d'un redémarrage ou d'une migration.

Qu'est-il plus sûr de conserver dans la configuration : un mot de passe ou une liste blanche ?

Si l'infrastructure est stable, la liste blanche est plus sûre : la configuration ne contient aucun secret copiable. Si l'adresse du client change, l'identifiant et le mot de passe sont inévitables ; il faut alors les conserver dans des variables d'environnement ou un gestionnaire de secrets, et non en clair dans le dépôt.

Vous pouvez choisir le type d'authentification et mettre en place l'accès adapté à votre infrastructure dans la rubrique proxys. Vous y voyez aussi quels canaux acceptent la liste blanche et lesquels ne sont fournis qu'avec identifiant et mot de passe : mieux vaut le vérifier avant le paiement plutôt qu'après le premier refus de connexion.