Proxifier + SOCKS5 : faites passer uniquement les applications de votre choix par un proxy

La plupart des configurations proxy sont tout ou rien. Soit vous modifiez un paramètre système et tout passe par le proxy, soit vous configurez une seule application et tout le reste l'ignore. Proxifier se place entre les deux : il intercepte les connexions sortantes au niveau de la socket et applique des règles — cette application utilise le proxy, celle-ci passe en direct, cet hôte est entièrement bloqué.

Cela en fait un choix naturel pour SOCKS5, car SOCKS5 peut transporter n'importe quel trafic TCP, pas seulement HTTP. Ce guide couvre les étapes de configuration, la décision DNS qui cause la plupart des fuites, et les règles qui vous empêchent de proxifier des choses que vous ne vouliez pas.

Une mise en garde avant de commencer : les noms de menus changent légèrement selon les versions de Proxifier et les plateformes. Les concepts ci-dessous restent stables, donc si un libellé ne correspond pas exactement, cherchez l'équivalent le plus proche.

Ce que Proxifier apporte que les paramètres système ne peuvent pas faire

Routage au niveau de l'application. Faites passer un navigateur par le proxy et laissez tout le reste en direct.
Routage au niveau de la cible. Proxifiez le trafic vers des domaines ou des plages d'IP spécifiques et laissez le reste passer en direct.
Proxification indépendante du protocole. N'importe quelle application TCP peut être routée via un proxy SOCKS5, même celle qui n'a aucun paramètre proxy propre.
Chaînage. Routez via un proxy, puis via un autre saut.
Un journal de trafic. Vous pouvez voir exactement quelle connexion est allée où, ce qui est inestimable lorsqu'une fuite se produit.

Avant de commencer : rassemblez les détails du proxy

Auprès de votre fournisseur de proxy, vous avez besoin de :

Nom d'hôte ou adresse IP, ainsi que le port.
Protocole : SOCKS5.
Nom d'utilisateur et mot de passe, si une authentification est requise.
Si le point de terminaison vous donne une IP rotative ou une session persistante, car cela détermine si les flux multiphases avec état fonctionneront.

Décidez dès le départ si la résolution DNS doit se faire au niveau du proxy. Avec SOCKS5, résoudre les noms d'hôtes sur votre propre machine est la source la plus courante de fuites de localisation. La plupart des fournisseurs exposent le DNS distant soit via un paramètre côté client, soit via un indicateur dans le nom d'utilisateur.

Étape 1 : ajouter le proxy SOCKS5 à Proxifier

Ouvrez le menu Profile et choisissez Proxy Servers.
Cliquez sur Add.
Saisissez l'adresse et le port, puis réglez le protocole sur SOCKS Version 5.
Si le proxy nécessite une authentification, activez-la et saisissez les identifiants.
Utilisez le bouton Check intégré pour confirmer que le proxy répond avant de construire des règles par-dessus.

Si la vérification échoue, la cause est presque toujours l'une de ces trois choses : un port erroné, des identifiants nécessitant un encodage URL à cause de caractères spéciaux, ou un fournisseur qui limite les connexions à des adresses IP en liste blanche.

Étape 2 : décider comment le DNS est géré

Voici le paramètre que la plupart des gens sautent, et c'est celui qui génère discrètement des fuites. Dans les paramètres de résolution de noms, généralement sous Profile puis Name Resolution, vous choisissez entre résoudre les noms d'hôtes localement ou au niveau du proxy.

Résoudre via le proxy lorsque votre objectif est de garder votre localisation réelle et vos requêtes DNS hors de l'équation. C'est l'équivalent SOCKS5 d'utiliser socks5h:// au lieu de socks5://.
Résoudre localement uniquement lorsque vous avez spécifiquement besoin d'un comportement DNS local, comme des noms split-horizon sur un réseau d'entreprise.

Si un site voit une géolocalisation correspondant à votre emplacement réel plutôt qu'à celui de votre proxy, c'est le premier paramètre à inspecter.

Étape 3 : écrire des règles de proxification

Les règles se trouvent sous Profile puis Proxification Rules. Elles sont évaluées dans l'ordre et la première correspondance gagne, donc l'ordre importe plus que chaque entrée individuelle.

Une structure de départ raisonnable :

Direct pour les adresses locales. Loopback et votre réseau local ne doivent jamais être proxifiés.
Direct pour le serveur proxy lui-même. Sans cela, certaines configurations essaient de renvoyer le trafic du proxy à travers le proxy.
Proxy pour les applications spécifiques qui vous intéressent. Une règle par exécutable, avec l'action réglée sur votre proxy SOCKS5.
Direct ou Block pour tout le reste. Choisissez délibérément lequel des deux vous voulez par défaut.

Chaque règle peut correspondre à :

Applications — noms ou chemins d'exécutables.
Hôtes cibles — domaines, jokers ou plages d'IP.
Ports cibles — utile pour envoyer uniquement, disons, le port 443 via le proxy.

Gardez la liste courte. Un ensemble de règles avec trente entrées qui se chevauchent est impossible à analyser quand quelque chose casse.

Étape 4 : vérifier que le trafic va là où vous pensez

La vérification comporte trois parties :

Dans le journal de trafic, confirmez que la connexion que vous venez d'établir est attribuée au proxy SOCKS5 plutôt qu'à Direct.
Depuis l'application, vérifiez l'IP rapportée par une page publique de vérification d'IP.
Depuis la ligne de commande, comparez une requête directe avec une requête proxifiée :

# En direct
curl -s https://api.ipify.org; echo

# Via le proxy SOCKS5 avec résolution DNS distante
curl -s --proxy socks5h://user:[email protected]:1080 https://api.ipify.org; echo

Si ces deux commandes donnent des résultats différents, votre règle ne correspond pas à l'application que vous pensiez cibler. C'est généralement un problème d'ordre, ou une règle qui correspond à un lanceur plutôt qu'au processus qui gère les connexions réseau.

Problèmes courants avec Proxifier + SOCKS5

Une règle correspond au lanceur, pas au processus. Les navigateurs et les environnements d'exécution engendrent souvent un processus enfant distinct qui ouvre les sockets. Faites correspondre le processus qui se connecte réellement.
Fuites DNS. Déjà abordé plus haut, mais cela reste la cause numéro un de « mon IP a changé, et pourtant le site sait toujours où je suis ».
Le client proxy lui-même est proxifié. Une boucle facile à créer avec une règle d'application trop large.
Conflits avec un VPN ou un pilote de filtre antivirus. L'interception réseau en couches est fragile. Si un client VPN est en cours d'exécution, testez d'abord Proxifier seul.
Applications sandboxées. Les applications exécutées dans un sandbox restreint peuvent ne pas être interceptables via le même mécanisme que les logiciels de bureau ordinaires.

Quand vous n'avez pas du tout besoin de Proxifier

Si seul votre navigateur a besoin du proxy, une configuration au niveau du navigateur est plus simple. Si vous avez besoin de SOCKS5 pour des outils en ligne de commande, un transfert dynamique SSH combiné à un wrapper comme proxychains fait un travail similaire. Si vous voulez que toutes les applications de l'appareil soient routées et que vous n'avez pas besoin de règles par application, un VPN est l'outil le plus adapté. Proxifier mérite sa place spécifiquement lorsque le besoin est un routage sélectif, par application.

À retenir

Ajoutez d'abord le proxy SOCKS5 et confirmez qu'il répond, décidez délibérément si le DNS se résout localement ou au niveau du proxy, puis gardez la liste de règles courte et ordonnée afin que la première correspondance soit toujours celle que vous attendez. Vérifiez avec le journal de trafic et avec une vérification d'IP — et considérez tout désaccord entre les deux comme un bug de correspondance de règle plutôt qu'un problème de proxy.