Proxychains rond een Python-debugproces kan twee verschillende verbindingen onderscheppen: de uitgaande serviceverbinding van het script en de lokale verbinding terug naar PyCharm. De debugger heeft de laatste nodig om lokaal te blijven.

Waar de IDE en host een interpreter-wrapper ondersteunen, wijs die naar de werkelijke interpreter van het project:

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

Vervang beide paden naar de uitvoerbare bestanden en het configuratiepad. Het doorgeven van "$@" behoudt de afzonderlijke debuggerargumenten van de IDE. exec voorkomt dat het gestarte proces een overbodige wrapper-shell tussen de IDE en zijn kind achterlaat.

In die speciale Proxychains-configuratie behoudt u de bedoelde keten en voegt u de relevante directe loopback-uitzondering toe:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Deze regels omzeilen de keten voor numerieke loopback-bestemmingen. De meegeleverde upstream-configuratie documenteert beperkingen voor hostnaamafstemming met proxy_dns, dus geef bij het diagnosticeren van dat pad de voorkeur aan het werkelijke numerieke loopback-adres van de debugger. Plaats het subnet voor remote DNS-mapping niet binnen hetzelfde uitgesloten bereik.

Behoud de identiteit van de interpreter

Het gebruik van /usr/bin/python3 in de wrapper kan stil een andere omgeving uit de .venv van het project kiezen. Ontbrekende pakketten lijken dan op een proxygerelateerde fout, terwijl een andere interpreter is gestart.

Proxychains vertrouwt op ondersteunde onderschepping van dynamische bibliotheken. Een IDE die een wrapper als interpreter weigert, een beschermd macOS-proces of een statisch gelinkte netwerkclient is een aparte compatibiliteitsvoorwaarde. Beperk de opstelling tot het bedoelde Python-proces en verifieer de gekozen interpreter in de configuratie van de IDE.

Gerelateerde artikelen