Tenete la connessione del debugger di PyCharm fuori dalla catena proxy

Proxychains attorno a un processo di debug Python può intercettare due connessioni diverse: la connessione di servizio in uscita dello script e la sua connessione locale verso PyCharm. Il debugger ha bisogno che la seconda resti locale.

Dove l'IDE e l'host supportano un wrapper per l'interprete, puntatelo all'interprete reale del progetto:

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

Sostituite entrambi i percorsi degli eseguibili e il percorso di configurazione. Inoltrare "$@" preserva i singoli argomenti del debugger dell'IDE. exec impedisce al processo avviato di lasciare una shell wrapper superflua tra l'IDE e il suo figlio.

In quella configurazione Proxychains dedicata, mantenete la catena prevista e aggiungete l'eccezione loopback diretta appropriata:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Queste regole aggirano la catena per destinazioni loopback numeriche. La configurazione upstream fornita documenta restrizioni sulla corrispondenza dei nomi host con proxy_dns, quindi durante la diagnosi di quel percorso preferite l'indirizzo loopback numerico reale del debugger. Non inserite la sottorete di mappatura DNS remota nello stesso intervallo escluso.

Preservate l'identità dell'interprete

Usare /usr/bin/python3 nel wrapper può selezionare silenziosamente un altro ambiente dal .venv del progetto. I pacchetti mancanti sembrano allora un guasto legato al proxy, anche se è partito un interprete diverso.

Proxychains si basa sull'intercettazione supportata delle librerie dinamiche. Un IDE che rifiuta un wrapper come interprete, un processo macOS protetto o un client di rete collegato staticamente sono una condizione di compatibilità separata. Limitate la disposizione al processo Python previsto e verificate l'interprete selezionato nella configurazione dell'IDE.