L'application ignore le proxy : comment encapsuler le trafic

```html

Vous avez configuré un proxy dans les paramètres de Windows, redémarré le programme — et il utilise toujours votre IP domestique. Ou inversement : le navigateur passe correctement par le proxy, tandis que le client de bureau à côté continue d'afficher l'adresse réelle. Ce n'est pas un bug du proxy ni des identifiants défectueux. C'est une caractéristique fondamentale de la façon dont les systèmes d'exploitation gèrent le « proxy système » : il ne force pas, il propose seulement.

Ci-dessous, quatre méthodes fonctionnelles pour forcer une application spécifique à passer par SOCKS5, avec les limitations de chacune et les pièges sur lesquels la configuration échoue le plus souvent.

Pourquoi le proxy système ne fonctionne pas : vérité technique en bref

Il n'y a pas un seul « proxy système » dans Windows. Il existe au moins deux ensembles de paramètres indépendants. Le premier — WinINET : ce que vous modifiez dans « Paramètres → Réseau et Internet → Serveur proxy ». Il est utilisé par Internet Explorer/Edge, certaines applications .NET et tout ce qui utilise la pile HTTP standard de l'utilisateur. Le second — WinHTTP, utilisé par les services système et les processus en arrière-plan. Et voici la clé : WinHTTP n'utilise pas les paramètres WinINET, à moins que vous ne les importiez explicitement. Cela se fait avec la commande netsh winhttp import proxy source=ie, et — un détail important de la documentation Microsoft — la commande prend un instantané des paramètres actuels. Vous avez changé le proxy dans les paramètres plus tard ? L'instantané ne se met pas à jour automatiquement, vous devez exécuter la commande à nouveau.

Mais même l'importation ne sauve pas de la principale catégorie de problèmes. Un grand nombre de programmes ne demandent pas du tout au système : ils utilisent leur propre pile réseau et ouvrent des sockets TCP directement. C'est le cas de nombreux clients de bureau pour les réseaux sociaux et les messageries, des lanceurs de jeux, des torrents, certaines applications Electron avec une configuration intégrée, des utilitaires compilés en Go et Rust. Pour eux, la ligne « proxy » dans les paramètres du système d'exploitation n'existe tout simplement pas en tant que concept.

D'où la règle : si l'application n'a pas son propre champ pour le proxy, le seul moyen fiable est d'intercepter son trafic en dessous du niveau de l'application. Il existe quatre classes de méthodes, et elles diffèrent fondamentalement par leur coût, leur fiabilité et les droits requis.

Étape 0 : assurez-vous que le problème est bien celui-ci

Lancez l'application et vérifiez quelle IP elle affiche (profil de compte, page de service, tout indicateur intégré).
Ouvrez simultanément le navigateur via le même proxy et comparez l'adresse. IP différentes = l'application ignore la configuration système.
Vérifiez si le programme a ses propres paramètres de proxy — ils sont souvent cachés dans « Réseau », « Connexion » ou dans un fichier de configuration. Le support natif est toujours meilleur que l'interception externe : moins de couches, moins de pannes.
Vérifiez séparément le DNS. Si l'application résout les noms localement, et que le trafic passe par le proxy, votre fournisseur réel voit toujours où vous allez.

Méthode 1. Proxifier — standard commercial pour Windows et macOS

Proxifier intercepte les connexions des applications et les redirige vers le proxy spécifié selon des règles : vous pouvez définir « cet exe — via le proxy A, celui-là — via le proxy B, le reste — directement », diviser par ports et adresses de destination, construire une chaîne de plusieurs proxies.

Versions actuelles au moment de l'écriture : 4.14 pour Windows (sortie le 23 avril 2025) et 3.15 pour macOS (18 septembre 2025). Licence — 39,95 $ par copie, achat unique, à durée illimitée, avec des mises à jour mineures gratuites ; il y a un essai complet de 31 jours, des remises de gros à partir de deux copies et un remboursement dans les 30 jours.

Pratique de configuration :

Serveurs Proxy → Ajouter : indiquez l'adresse, le port, le protocole SOCKS5 et les identifiants. Cliquez sur Vérifier — le test doit réussir avant de créer des règles, sinon vous devrez déboguer deux problèmes à la fois.
Règles de Proxification → Ajouter : dans Applications, choisissez le fichier exécutable spécifique, dans Action — votre proxy.
Laissez la règle par défaut sur Direct, si vous ne voulez pas rediriger toute la machine. C'est l'erreur la plus fréquente des débutants : Default → Proxy met dans le tunnel à la fois le mise à jour du système d'exploitation, l'antivirus et le trafic supplémentaire pour lequel vous payez par gigaoctets.
Surveillez l'onglet Connexions en temps réel : vous pouvez voir quelle connexion est passée par le proxy et laquelle est passée directement.

Les points forts — maturité, règles stables et diagnostic clair. Les points faibles — coût et le fait qu'avec des systèmes anti-triche agressifs, l'interception par pilote peut être détectée.

Méthode 2. ProxiFyre — alternative gratuite sous Windows avec support UDP

Si le budget est nul et que la plateforme est Windows, il existe un projet ouvert ProxiFyre (licence AGPL-3.0). Il est construit sur NDISAPI/Windows Packet Filter — c'est-à-dire qu'il fonctionne au niveau du pilote de filtrage de paquets et sait faire ce qui manque souvent : encapsuler de manière transparente non seulement TCP, mais aussi UDP pour chaque application séparément. C'est essentiel pour tout ce qui utilise UDP et QUIC — canaux vocaux, clients de jeux, certaines connexions de navigateurs modernes.

Parmi les nouveautés dans les versions récentes : le support IPv6 est apparu dans v2.3.0, SOCKS5-over-TLS — dans v2.4.0, il y a des règles d'exclusion pour les applications et un catch-all pour toutes les autres. Exigences : Windows Packet Filter installé, bibliothèques d'exécution Visual Studio et droits d'administrateur.

La configuration se fait via un fichier de configuration avec une liste d'applications et des points de terminaison SOCKS5 qui leur sont associés. Le seuil d'entrée est plus élevé que pour Proxifier, mais vous ne payez pas et obtenez UDP.

Méthode 3. proxychains-ng — option rapide pour Linux, avec réserves

Classique pour les systèmes Unix : proxychains4 curl https://example.com. Le mécanisme — LD_PRELOAD : la bibliothèque remplace les appels de sockets dans le programme lié dynamiquement et les redirige vers SOCKS.

Limitations à connaître avant de construire votre flux de travail :

Uniquement TCP. UDP et ICMP ne sont pas encapsulés du tout — le ping via proxychains ne vérifie rien de significatif.
Uniquement des binaires liés dynamiquement. Les utilitaires compilés statiquement (situation typique pour Go) ignorent silencieusement LD_PRELOAD — le trafic passera directement, et vous ne le remarquerez pas.
Sur macOS, cela se heurte à SIP. La Protection de l'Intégrité du Système bloque le chargement de la bibliothèque dans les binaires système : proxychains4 ssh user@host ne fonctionnera pas. Une solution de contournement fonctionnelle consiste à copier le binaire dans votre répertoire (cp /usr/bin/ssh ~/.local/bin/) et à exécuter la copie. Je ne recommande pas de désactiver SIP pour des raisons de commodité : vous affaiblissez la protection de l'ensemble du système pour un seul utilitaire.

Pour des tâches ponctuelles (curl, script python, utilitaire en ligne de commande), proxychains reste le moyen le plus rapide — il s'installe par une seule commande et ne nécessite pas de droits root.

Méthode 4. Mode TUN : interception au niveau de l'interface virtuelle

La classe de solutions la plus universelle. Une interface réseau virtuelle est créée, les routes du système y sont redirigées, et la pile TCP/IP de l'utilisateur traite les paquets et les envoie à l'extérieur via SOCKS5. C'est ainsi que fonctionnent tun2socks (utilise la pile gVisor, gère TCP et UDP, disponible sur toutes les plateformes) et sing-box en mode TUN.

Le principal avantage par rapport à LD_PRELOAD : tout est intercepté, y compris les binaires statiques et les applications avec leur propre pile. Sing-box dispose également d'un routage par processus — les champs process_name, process_path et process_path_regex, ce qui permet de créer de véritables règles par application ; selon la documentation, cela est pris en charge sur Linux, Windows et macOS (sur les plateformes mobiles, les règles sont définies par le nom du package ou l'ID de bundle).

Deux pièges sur lesquels presque tout le monde trébuche :

Boucle de routage. Si tout le trafic passe par TUN, la connexion au serveur SOCKS5 essaie également de passer par TUN — le tunnel commence à s'auto-rediriger. Cela se résout par une route d'exception explicite vers l'IP du proxy via l'interface physique. C'est un problème connu et récurrent dans les configurations de sing-box.
Droits. La création d'une interface TUN et la modification de la table de routage nécessitent des droits root/admin. Sur une machine d'entreprise avec des politiques, cela peut être inaccessible.

Sur Linux, il existe deux autres approches apparentées : redsocks — interception via des règles iptables avec redirection vers un port local (uniquement Linux, nécessite des droits root), et sshuttle, qui établit un routage semblable à un VPN au-dessus d'un accès SSH ordinaire, contournant le problème classique « TCP sur TCP ».

Ce qui casse le plus souvent

Fuite DNS. Même avec un SOCKS5 correctement configuré, l'application peut résoudre des domaines localement. Vérifiez que la résolution passe par le proxy, et non par votre fournisseur.
SOCKS4 sélectionné au lieu de SOCKS5. SOCKS4 ne prend pas en charge UDP en principe et ne sait pas transmettre le nom de domaine dans certaines implémentations. Pour intercepter un trafic arbitraire, utilisez uniquement SOCKS5 — pourquoi c'est ainsi est expliqué en détail dans l'article sur les principes de fonctionnement de SOCKS5.
Proxy HTTP au lieu de SOCKS. Le proxy HTTP peut proxyfier HTTP et via CONNECT — connexions TLS. Le trafic TCP arbitraire d'un client de jeu ou d'une messagerie ne sera pas encapsulé.
Règle par défaut pour tout le trafic. En encapsulant toute la machine, vous consommez le trafic du pool résident pour les mises à jour et la télémétrie.
Absence de vérification après la configuration. Vérifiez toujours l'IP de sortie réelle de l'application elle-même, et non celle du navigateur à côté.

Quel type de proxy choisir pour l'interception

Techniquement, l'interception fonctionne avec n'importe quel point de terminaison SOCKS5, mais le choix du type détermine si votre scénario atteindra son objectif.

Résidentiels — lorsque l'application travaille avec un service qui évalue la réputation de l'IP : réseaux sociaux, places de marché, tableaux de publicité, formulaires de paiement. L'adresse du centre de données y est reconnue presque instantanément. Conviennent les proxies résidentiels avec support SOCKS5 et sessions persistantes — ce dernier est critique, car le changement d'IP en plein milieu d'une session active est perçu par l'anti-fraude comme plus problématique qu'une IP « étrangère » dès le départ.
Centre de données — pour des tâches techniques sans anti-fraude strict : accès à l'API, services internes, bancs de test, tout où la vitesse et la stabilité du canal sont importantes, et non l'apparence « résidentielle » de l'adresse. Ici, les proxies de centre de données offrent le meilleur ping et prévisibilité.
Mobiles — lorsque l'application est mobile par nature (émulateur, client de réseau social) et nécessite une confiance maximale de la plateforme.

À part cela : l'interception au niveau de l'application n'est pas un VPN, et il ne faut pas remplacer l'un par l'autre. Si vous avez besoin d'un canal sécurisé unique pour toute la machine, et non de différentes IP pour différents programmes, une comparaison des approches est disponible dans l'analyse WireGuard contre proxy.

Comment choisir une méthode en une minute

L'application a ses propres paramètres de proxy → utilisez-les, n'interceptez rien.
Windows, besoin de résultats aujourd'hui, budget disponible → Proxifier.
Windows, besoin de UDP et gratuitement → ProxiFyre.
Linux, tâche ponctuelle avec un utilitaire en ligne de commande → proxychains-ng.
Besoin d'intercepter un binaire statique, un jeu ou tout à la fois avec des règles par application → mode TUN (sing-box, tun2socks), sans oublier la route d'exception vers le proxy.

La conclusion principale est simple : « le proxy ne fonctionne pas » dans neuf cas sur dix signifie « le proxy n'est pas configuré au bon niveau ». La configuration système est une demande polie à l'application, tandis que l'interception au niveau du pilote, LD_PRELOAD ou de l'interface TUN est une contrainte. Choisissez le bon niveau, vérifiez l'IP de sortie réelle de l'application elle-même et n'oubliez pas le DNS — et le problème est résolu une fois pour toutes, au lieu de réapparaître après chaque mise à jour du programme.