Hold PyCharms debuggerforbindelse utenfor proxykjeden

Proxychains rundt en Python-feilsøkingsprosess kan fange to forskjellige forbindelser: skriptets utgående tjenesteforbindelse og dets lokale forbindelse tilbake til PyCharm. Debuggeren trenger at sistnevnte blir lokal.

Der IDE-en og verten støtter en tolkeinnpakning, pek den mot prosjektets faktiske tolk:

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

Erstatt begge banene til de kjørbare filene og konfigurasjonsbanen. Videresending av "$@" bevarer IDE-ens individuelle debuggerargumenter. exec hindrer at den startede prosessen etterlater et unødvendig innpakningsskall mellom IDE-en og barnet sitt.

I den dedikerte Proxychains-konfigurasjonen beholder du den tiltenkte kjeden og legger til det relevante direkte loopback-unntaket:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Disse reglene omgår kjeden for numeriske loopback-mål. Den medfølgende oppstrømskonfigurasjonen dokumenterer begrensninger for vertsnavnmatching med proxy_dns, så foretrekk debuggerens faktiske numeriske loopback-adresse når den veien diagnostiseres. Ikke legg subnettet for ekstern DNS-mapping innenfor samme utelukkede område.

Bevar tolkens identitet

Bruk av /usr/bin/python3 i innpakningen kan stille velge et annet miljø fra prosjektets .venv. Manglende pakker ser da ut som en proxyrelatert feil, selv om en annen tolk ble startet.

Proxychains er avhengig av støttet avskjæring av dynamiske biblioteker. En IDE som avviser en innpakning som tolk, en beskyttet macOS-prosess eller en statisk lenket nettverksklient er en egen kompatibilitetsbetingelse. Begrens ordningen til den tiltenkte Python-prosessen, og verifiser den valgte tolken i IDE-ens konfigurasjon.