Gardez la connexion du débogueur de PyCharm hors de la chaîne proxy

Proxychains autour d'un processus de débogage Python peut intercepter deux connexions différentes : la connexion de service sortante du script et sa connexion locale vers PyCharm. Le débogueur a besoin que la seconde reste locale.

Là où l'IDE et l'hôte prennent en charge un enveloppeur d'interpréteur, pointez-le vers l'interpréteur réel du projet :

#!/bin/sh
exec /usr/bin/proxychains4 -f /home/alex/proxychains-debug.conf "/home/alex/project/.venv/bin/python" "$@"

Remplacez les deux chemins des exécutables et le chemin de configuration. Transmettre "$@" préserve les arguments individuels du débogueur de l'IDE. exec empêche le processus lancé de laisser un shell d'enveloppe inutile entre l'IDE et son enfant.

Dans cette configuration Proxychains dédiée, conservez la chaîne prévue et ajoutez l'exception loopback directe appropriée :

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Ces règles contournent la chaîne pour les destinations loopback numériques. La configuration amont fournie documente des restrictions pour la correspondance des noms d'hôte avec proxy_dns, donc privilégiez l'adresse loopback numérique réelle du débogueur lors du diagnostic de ce chemin. Ne placez pas le sous-réseau de mappage DNS distant dans la même plage exclue.

Préserver l'identité de l'interpréteur

Utiliser /usr/bin/python3 dans l'enveloppeur peut sélectionner silencieusement un autre environnement du .venv du projet. Les paquets manquants ressemblent alors à une panne liée au proxy, alors qu'un autre interpréteur a démarré.

Proxychains repose sur l'interception prise en charge des bibliothèques dynamiques. Un IDE qui refuse un enveloppeur comme interpréteur, un processus macOS protégé ou un client réseau lié statiquement sont une condition de compatibilité distincte. Limitez le dispositif au processus Python prévu et vérifiez l'interpréteur sélectionné dans la configuration de l'IDE.