Die Debugger-Verbindung von PyCharm außerhalb der Proxy-Kette halten

Proxychains um einen Python-Debugprozess kann zwei verschiedene Verbindungen abfangen: die ausgehende Dienstverbindung des Skripts und seine lokale Verbindung zurück zu PyCharm. Der Debugger braucht letztere lokal.

Wo IDE und Host einen Interpreter-Wrapper unterstützen, richten Sie ihn auf den tatsächlichen Interpreter des Projekts:

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

Ersetzen Sie beide Pfade der ausführbaren Dateien und den Konfigurationspfad. Die Weitergabe von "$@" erhält die einzelnen Debugger-Argumente der IDE. exec verhindert, dass der gestartete Prozess eine unnötige Wrapper-Shell zwischen der IDE und ihrem Kind zurücklässt.

In dieser eigenen Proxychains-Konfiguration behalten Sie die vorgesehene Kette bei und ergänzen die passende direkte Loopback-Ausnahme:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Diese Regeln umgehen die Kette für numerische Loopback-Ziele. Die mitgelieferte Upstream-Konfiguration dokumentiert Einschränkungen beim Hostnamen-Abgleich mit proxy_dns, daher ist beim Diagnostizieren dieses Wegs die tatsächliche numerische Loopback-Adresse des Debuggers vorzuziehen. Legen Sie das Subnetz für das entfernte DNS-Mapping nicht in denselben ausgeschlossenen Bereich.

Die Identität des Interpreters bewahren

Die Verwendung von /usr/bin/python3 im Wrapper kann stillschweigend eine andere Umgebung aus dem .venv des Projekts auswählen. Fehlende Pakete erscheinen dann als proxybedingter Fehler, obwohl ein anderer Interpreter gestartet wurde.

Proxychains beruht auf unterstützter Abfangung dynamischer Bibliotheken. Eine IDE, die einen Wrapper als Interpreter ablehnt, ein geschützter macOS-Prozess oder ein statisch gelinkter Netzwerkclient ist eine separate Kompatibilitätsbedingung. Begrenzen Sie die Anordnung auf den vorgesehenen Python-Prozess und prüfen Sie den gewählten Interpreter in der Konfiguration der IDE.