Trzymaj połączenie debuggera PyCharm poza łańcuchem proxy

Proxychains wokół procesu debugowania Pythona może przechwycić dwa różne połączenia: wychodzące połączenie skryptu z usługą oraz jego lokalne połączenie z powrotem do PyCharm. Debugger potrzebuje, aby to drugie pozostało lokalne.

Gdy IDE i host obsługują otoczkę interpretera, skieruj ją na rzeczywisty interpreter projektu:

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

Zastąp obie ścieżki plików wykonywalnych oraz ścieżkę konfiguracji. Przekazywanie "$@" zachowuje poszczególne argumenty debuggera z IDE. exec nie pozwala uruchomionemu procesowi pozostawić zbędnej powłoki otoczki między IDE a jego procesem potomnym.

W tej dedykowanej konfiguracji Proxychains zachowaj zamierzony łańcuch i dodaj odpowiedni bezpośredni wyjątek loopback:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Te reguły omijają łańcuch dla numerycznych celów loopback. Dołączona konfiguracja nadrzędna dokumentuje ograniczenia dopasowania nazw hostów z proxy_dns, więc podczas diagnozowania tej ścieżki preferuj rzeczywisty numeryczny adres loopback debuggera. Nie umieszczaj podsieci zdalnego mapowania DNS w tym samym wykluczonym zakresie.

Zachowaj tożsamość interpretera

Użycie /usr/bin/python3 w otoczce może po cichu wybrać inne środowisko z .venv projektu. Brakujące pakiety wyglądają wtedy jak awaria związana z proxy, choć uruchomiono inny interpreter.

Proxychains opiera się na obsługiwanym przechwytywaniu bibliotek dynamicznych. IDE odrzucające otoczkę jako interpreter, chroniony proces macOS lub statycznie linkowany klient sieciowy to odrębny warunek zgodności. Ogranicz układ do zamierzonego procesu Pythona i zweryfikuj wybrany interpreter w konfiguracji IDE.