Précisons d'emblée notre intérêt : nous sommes Geonode et nous vendons des proxys ; nous recevons donc beaucoup de messages du type « mon proxy ne fonctionne pas ». La première chose à dire, en toute honnêteté, c'est que le port n'est presque jamais le problème. D’après notre expérience, voici l’ordre de probabilité des causes : identifiants erronés, liste blanche d’adresses IP que vous avez oublié de mettre à jour, utilisation du port HTTP standard pour une requête HTTPS, blocage par la cible, et enfin, un numéro de port réellement incorrect. Si vous effectuez un débogage, parcourez cette liste plutôt que d’essayer des numéros de port au hasard — cette dernière approche semble productive, mais ne l’est presque jamais.
Cela dit, comprendre le rôle de ce numéro permet de mieux cerner l’ensemble des causes d’échec.
Qu'est-ce qu'un port, au juste ?
Une machine possède une adresse et de nombreux programmes susceptibles de générer du trafic réseau. Le numéro de port permet au système d'exploitation de savoir à quel programme appartient une connexion donnée.
L'adresse achemine le paquet vers la machine. Le port l'achemine vers le bon processus sur cette machine. Un même serveur peut faire tourner simultanément un serveur web sur le port 443, un démon SSH sur le port 22 et un proxy sur le port 8080, car chaque connexion comporte un port de destination qui l'achemine vers le bon écouteur.
Dans le cas spécifique d’un proxy, le port joue un rôle supplémentaire : un même serveur proxy écoute souvent sur plusieurs ports, chacun étant configuré différemment. Même logiciel, même machine, mais comportement différent selon le numéro auquel vous vous connectez. C’est pourquoi votre fournisseur vous remet une liste plutôt qu’une valeur unique — un point sur lequel nous reviendrons.
Les trois plages de ports
Les ports vont de 0 à 65535, et la RFC 6335 divise cet espace en trois plages :
| Plage | Nom | Numéros | Attribution |
|---|
| Système | Ports bien connus | 0–1023 | Attribués par l’IANA |
| Utilisateur | Ports enregistrés | 1024–49151 | Attribués par l’IANA |
| Dynamique | Ports privés ou éphémères | 49152–65535 | Jamais attribués |
Deux conséquences sont importantes dans la pratique.
Les ports système nécessitent généralement des privilèges élevés pour être liés. Sur les systèmes de type Unix, la liaison à un port inférieur à 1024 nécessite traditionnellement les droits root. C’est la raison directe pour laquelle les proxys s’installent généralement sur le port 8080 ou 3128 plutôt que sur le 80 : exécuter un proxy en tant que root pour s’approprier un port bas est un mauvais compromis pour un avantage purement esthétique.
Les ports dynamiques sont à l’origine de vos propres connexions. Lorsque vous vous connectez à un proxy sur le port 8080, votre machine choisit un port source éphémère dans la plage supérieure. Cela reste invisible jusqu’à ce que vous consultiez le journal d’un pare-feu et que vous vous demandiez pourquoi votre trafic semble provenir du port 51423.
Les ports proxy courants et ce que dit réellement l’IANA
C’est là que les idées reçues divergent des informations officielles, et cette divergence est instructive. Ces entrées proviennent du Registre des noms de service et des numéros de port de protocole de transport de l’IANA, extraites directement du fichier CSV publié.
| Port | Comment on l'appelle couramment | Ce que l'IANA enregistre réellement |
|---|
| 8080 | Le port proxy par défaut | http-alt — « HTTP Alternate (voir port 80) » |
| 3128 | Le port Squid | ndl-aas — « Port du serveur API actif » |
| 1080 | SOCKS | socks — « Socks » |
| 8118 | Privoxy | privoxy — « Proxy HTTP Privoxy » |
| 8888 | Port proxy alternatif | ddi-tcp-1 — « Serveur NewsEDGE TCP (TCP 1) » |
| 9050 | Tor SOCKS | versiera — « Versiera Agent Listener » |
| 8081 | Port proxy secondaire | sunproxyadmin — « Service d'administration du proxy Sun » |
Relisez ce tableau, car il remet en cause une idée reçue. Parmi les ports que tout le monde considère comme des « ports proxy », seuls les ports 1080 et 8118 sont associés à des services liés aux proxys.
Le port 3128 — universellement décrit comme le port par défaut de Squid, et c’est effectivement le cas — est enregistré pour un service qui n’a absolument rien à voir. Le port 8888, utilisé partout par les outils proxy, appartient à un produit d’actualités. Le port 9050, que tous les utilisateurs de Tor connaissent, est enregistré pour un agent de surveillance.
La leçon à en tirer n’est pas que ces outils fonctionnent mal. Le registre consigne les attributions demandées, et une grande partie des logiciels largement déployés a simplement choisi un numéro pratique qui est devenu une convention par l’usage plutôt que par l’enregistrement. La convention et l’enregistrement sont deux systèmes distincts, et en cas de conflit, c’est la convention que votre logiciel suit.
Conclusion pratique : le numéro de port ne vous donne aucune indication fiable sur ce qui est à l'écoute. Un proxy peut fonctionner sur n'importe quel port. Les numéros conventionnels existent parce que quelqu'un doit choisir une valeur par défaut, et non parce que ce numéro a une signification particulière.
Le port ne détermine pas le protocole
Il s'agit de l'erreur conceptuelle la plus courante dans ce domaine.
Le fait de se connecter au port 1080 ne signifie pas pour autant que votre connexion est de type SOCKS. Se connecter au port 8080 ne signifie pas pour autant qu’il s’agit d’une connexion HTTP. Le port détermine quel слушатель reçoit votre connexion ; le protocole est celui que ce слушатель prend en charge. En cas de incompatibilité, la connexion échoue d’une manière souvent déroutante : vous obtenez un délai d’expiration, une réinitialisation de la connexion ou un flux d’octets illisibles, plutôt qu’un message d’erreur utile.
Ainsi, lorsque votre fournisseur vous fournit un point de terminaison, vous avez besoin de trois informations, dont le port n’est qu’une parmi d’autres :
- L’hôte
- Le port
- Le protocole pris en charge par ce port — HTTP, HTTPS, SOCKS4 ou SOCKS5
La configuration du client doit indiquer explicitement le protocole. Dans curl, c’est le schéma de l’argument « -x » qui le précise :
curl -x http://proxy.example.com:8080 https://example.com
curl -x socks5://proxy.example.com:1080 https://example.com
curl -x socks5h://proxy.example.com:1080 https://example.com
Cette troisième forme est plus importante que la différence entre les deux premières. « socks5h » indique à curl d’envoyer le nom d’hôte au proxy pour qu’il le résolve ; « socks5 » effectue la résolution localement et envoie l’adresse. Il en résulte une fuite DNS : votre trafic passe par le proxy tandis que vos requêtes DNS sont adressées à votre propre résolveur, ce qui correspond exactement au type d’incohérence susceptible de faire signaler une session. Si vous utilisez SOCKS5 pour toute opération où il est important de donner l’impression d’être ailleurs, utilisez plutôt socks5h.
Comment un même port se comporte pour HTTP, HTTPS et SOCKS
Ces trois cas présentent des différences qui expliquent la plupart des symptômes prêtant à confusion.
HTTP simple via un proxy HTTP. Votre client envoie l’URL complète dans la ligne de requête et le proxy la récupère en votre nom. Le proxy voit tout et peut tout modifier.
HTTPS via un proxy HTTP. Votre client envoie une requête CONNECT et, si le proxy l’autorise, celui-ci ouvre un tunnel TCP et relaie les octets sans pouvoir les lire. C’est la raison pour laquelle un proxy HTTP gère le trafic HTTPS, et pourquoi le même port sert les deux protocoles.
Deux types de dysfonctionnements en découlent directement. Certains proxys limitent l’CONNECT à des ports de destination spécifiques — généralement le 443 — ; ainsi, une requête HTTPS vers un port non standard est refusée, tandis que la navigation classique fonctionne. De plus, certains ports sont configurés pour le HTTP simple uniquement, l’CONNECT étant entièrement désactivé ; le symptôme est que les requêtes HTTP fonctionnent et que les requêtes HTTPS échouent, ce qui ressemble à un problème de certificat alors qu’il n’en est rien.
SOCKS. La RFC 1928 définit le protocole SOCKS (SOCKS5) comme un protocole fonctionnant en dessous de la couche application. Il ne prend absolument pas en charge le protocole HTTP : il relaie les connexions TCP, ce qui le rend plus général qu’un proxy HTTP. Il fonctionne avec les protocoles qu’un proxy HTTP ne peut pas gérer, et il ne peut effectuer aucune opération spécifique à HTTP, telle que la mise en cache ou la réécriture d’en-têtes.
Si vous devez choisir : optez pour des proxys HTTP pour le trafic web lorsque vous souhaitez gérer les en-têtes ; utilisez un proxy SOCKS (SOCKS5) lorsque vous devez proxyer quelque chose qui n’est pas HTTP, ou lorsque vous souhaitez que le proxy en sache le moins possible.
Pourquoi les fournisseurs vous attribuent plusieurs ports
Les points de terminaison multiports peuvent dérouter les débutants, mais la logique est simple : le fournisseur intègre la configuration dans le numéro de port afin que vous n’ayez pas à la transmettre par un autre moyen.
Schémas courants :
Comportement de rotation. Un port fournit une nouvelle adresse de sortie à chaque requête ; un autre conserve la même adresse pendant une session de quelques minutes. Mêmes identifiants, même hôte, port différent.
Ciblage géographique. Un bloc de ports correspond à des pays ou à des régions.
Identité de session. Une plage de ports où chaque numéro correspond à une session persistante, de sorte que se connecter à plusieurs reprises au même port vous donne la même adresse de sortie.
Protocole. Un port utilise le protocole HTTP, un autre l’SOCKS5 (HTTPS).
Certains fournisseurs procèdent de la même manière en utilisant la syntaxe du nom d’utilisateur : ils ajoutent des paramètres au nom d’utilisateur plutôt que de faire varier le port. Les deux approches existent et aucune n’est meilleure que l’autre ; il vous suffit de consulter la documentation du service que vous avez acheté, car deviner peut entraîner une requête qui aboutit tout en produisant un résultat différent de celui escompté.
Ce dernier point mérite d’être souligné. Un port erroné dans un schéma de rotation ne génère généralement pas d’erreur. Il produit une requête fonctionnelle mais avec un comportement indésirable : une persistance de session que vous ne souhaitiez pas, ou un pays que vous n’aviez pas demandé. Il s’agit là de la catégorie d’échecs silencieux dont nous avons parlé dans Pourquoi il est important de tester les proxys, et la confusion au niveau des ports en est l’une des causes les plus courantes.
Dépannage : ce que chaque erreur vous indique
Chaque erreur correspond à une cause différente, et les interpréter correctement vous évite bien des conjectures.
| Symptôme | Cause probable | Vérification |
|---|
| Connexion refusée, immédiatement | Rien n'écoute sur ce port | Numéro de port, hôte |
| Délai d'attente dépassé, aucune réponse | Le pare-feu rejette les paquets sans avertissement | Règles de sortie, état du fournisseur d'accès |
| 407 Authentification par proxy requise | Identifiants incorrects ou manquants | Nom d'utilisateur, mot de passe, liste blanche d'adresses IP |
| Code 403 provenant du proxy lui-même | Authentifié, mais non autorisé | Limites du forfait, restrictions de destination |
| HTTP fonctionne, mais pas HTTPS | Protocole CONNECT | |
désactivé ou restreint sur ce port | Port du protocole, documentation du fournisseur d’accès |
| Octets indésirables ou erreurs de protocole | Incompatibilité de protocole | Ce port est-il HTTP ou SOCKS ? |
| Ça fonctionne, mais mauvais pays ou mauvaise session | Port incorrect dans un schéma multiport | Mappage des ports du fournisseur |
La distinction entre « connexion refusée » et « délai d'attente expiré » est la plus utile et la plus souvent négligée. « Refusé » signifie qu’une réponse a été donnée et rejetée — la machine est accessible et rien n’écoute sur ce port. « Délai d’attente » signifie qu’aucune réponse n’a été donnée — généralement un pare-feu qui rejette des paquets, soit de votre côté, soit entre vous et le proxy. Le premier cas indique un numéro de port incorrect ; le second n’en est presque jamais la cause.
Un test rapide d’isolation :
nc -zv proxy.example.com 8080
Si la connexion s’établit, le port est ouvert et accessible, et tout échec résiduel est lié à l’authentification ou au protocole plutôt qu’au réseau. Si ce n’est pas le cas, cessez de déboguer votre application — le problème se situe en amont.
Et le cas du code 407 mérite une mention particulière, car c’est le plus courant de tous et il ressemble à un problème de port pour ceux qui ne l’ont jamais rencontré auparavant. Ce n’en est pas un. Cela signifie que vous avez atteint le proxy avec succès et qu’il vous demande des identifiants que vous n’avez pas fournis, ou que vous avez fournis de manière erronée. Le port était correct.
Ports à ne pas exposer
Ceci s'applique si vous exploitez votre propre proxy plutôt que d'en acheter un.
N’exposez jamais un proxy non authentifié sur Internet. Un proxy ouvert est détecté en quelques heures — l’ensemble de l’espace d’adressage est analysé en permanence — et il sera utilisé pour relayer du trafic que vous n’avez pas autorisé, attribué à votre adresse. Les conséquences vont de l’ajout de votre adresse à des listes de blocage à des situations bien plus graves. Si un proxy est accessible depuis Internet, il doit nécessiter une authentification.
Limitez l’accès en fonction de l’adresse source lorsque c’est possible. Une liste blanche d’adresses IP, associée à des identifiants, constitue une amélioration significative par rapport aux seuls identifiants, et cela ne coûte rien.
Ne considérez pas qu’un port inhabituel constitue une protection. Déplacer un service vers le port 47281 ne le cache pas. L’analyse de toute la plage de ports d’un seul hôte ne prend que quelques secondes. L’obscurité ne vous apporte ici aucun avantage mesurable.
Limitez les destinations d’CONNECT. Un proxy qui effectue des CONNECT vers n’importe quel port sur n’importe quel hôte est un relais polyvalent. Le limiter au port 443 et aux destinations dont vous avez réellement besoin réduit considérablement les possibilités d’abus en cas de fuite des identifiants.
Liez-vous à localhost lorsque vous n’avez besoin que de l’environnement local. Un proxy utilisé uniquement par des logiciels sur la même machine doit écouter sur 127.0.0.1, et non sur 0.0.0.0. Cette simple ligne de configuration permet d’éviter toute une catégorie de problèmes, et il s’agit de l’erreur la plus courante dans les configurations auto-hébergées.
Questions fréquentes
Quel est le port par défaut d'un proxy ?
Il n'existe pas de valeur par défaut universelle. Le port 8080 est le plus couramment utilisé pour les proxys HTTP, le 3128 pour les installations Squid et le 1080 pour les proxys SOCKS. Aucun de ces ports n’est obligatoire — un proxy peut écouter sur n’importe quel port — et le registre de l’IANA n’enregistre même pas les ports 8080 ou 3128 comme services proxy. Utilisez toujours le port spécifié par votre fournisseur.
Le port 8080 est-il un port proxy ?
Par convention, souvent. Officiellement, l’IANA enregistre le 8080 comme « http-alt », décrit comme « HTTP Alternate (voir le port 80) » — un port alternatif pour serveur web, et non un port de proxy. Il est devenu une convention pour les proxys parce qu’il est facile à retenir et ne nécessite pas de privilèges root pour être lié, et non parce qu’il revêt une quelconque signification en tant que proxy.
Quel port utilise SOCKS5 ?
Le 1080 par convention, et c’est l’un des rares cas où la convention correspond à l’enregistrement : l’IANA répertorie le 1080 sous le nom « socks ». Les déploiements individuels varient — le port SOCKS de Tor est par défaut le 9050, que l’IANA enregistre sous une désignation sans aucun rapport.
Pourquoi mon proxy fonctionne-t-il pour HTTP mais pas pour HTTPS ?
Presque toujours parce que ce port n’autorise pas la méthode CONNECT, qui permet de faire passer le trafic HTTPS via un proxy HTTP, ou parce que l’CONNECT est limité à des ports de destination spécifiques. Vérifiez si votre fournisseur propose un port distinct pour HTTPS, et assurez-vous que le port de destination auquel vous vous connectez est autorisé.
Comment savoir quel port de proxy utiliser ?
Consultez la documentation de votre fournisseur d’accès. Il n’existe aucun moyen fiable de le déterminer par simple inspection, car le numéro de port ne fournit aucune indication fiable sur ce qui est à l’écoute. Si vous devez effectuer un test, la commande nc -zv host port vous indique si un service est à l’écoute, mais pas quel protocole il utilise.
Quelle est la différence entre un port proxy et un serveur proxy ?
Le serveur est le logiciel et la machine qui gèrent votre trafic. Le port correspond à l’un des points d’accès numérotés de cette machine auquel vous vous connectez. Un serveur écoute souvent sur plusieurs ports avec des configurations différentes — des comportements de rotation différents, des pays différents, des protocoles différents —, c’est pourquoi les fournisseurs vous fournissent une liste plutôt qu’un seul numéro.
Puis-je utiliser n’importe quel port pour un proxy ?
Techniquement oui, n’importe où entre 1024 et 65535 sans privilèges particuliers. En pratique, vous utilisez les ports attribués par votre fournisseur, car ils correspondent à la configuration de son côté. Si vous gérez votre propre proxy, évitez la plage dynamique au-delà de 49 152, car votre système d’exploitation attribue des ports source éphémères à partir de cette plage et les collisions provoquent des problèmes intermittents particulièrement difficiles à diagnostiquer.
Le numéro de port a-t-il une incidence sur la vitesse du proxy ?
Non. Le port est un détail d’adressage qui ne présente aucune caractéristique de performance en soi. Si différents ports chez un même fournisseur offrent des performances différentes, c’est parce qu’ils transitent par des infrastructures différentes ou qu’ils ont des comportements de rotation différents, et non en raison du numéro.
Conclusion
Le port proxy est un détail de routage : il indique à la machine de destination quel processus à l'écoute doit gérer votre connexion, et rien de plus. Le numéro en lui-même n’a aucune signification officielle, comme le montre clairement le registre de l’IANA : le 3128 n’est pas attribué à Squid, le 8888 appartient à un produit d’actualités et le 9050 est un agent de surveillance. Il s’agit de conventions établies par l’usage, et ce sont ces conventions que votre logiciel suit.
Ce que cela signifie en cas de problème : analysez le message d’erreur plutôt que de deviner des numéros. Une connexion refusée indique un port incorrect. Un délai d’expiration indique un pare-feu. Un code 407 signifie que le port était correct mais que vos identifiants ne l’étaient pas. Les erreurs de protocole signifient que vous vous êtes connecté à un écouteur SOCKS qui attendait du HTTP, ou l’inverse. Chaque symptôme identifie une couche différente, et changer de numéro de port n’aide que dans le premier cas.
Et lorsque plusieurs ports vous sont proposés pour un même point de terminaison, consultez la documentation plutôt que d’en choisir un au hasard. Le mode de défaillance dans ce cas n’est pas un message d’erreur — il s’agit d’une requête qui fonctionne tout en utilisant discrètement le mauvais pays ou un comportement de session incorrect, ce qui constitue une erreur bien plus coûteuse.
