Proxychains omkring en Python-debugproces kan fange to forskellige forbindelser: scriptets udgående serviceforbindelse og dets lokale forbindelse tilbage til PyCharm. Debuggeren har brug for, at sidstnævnte bliver lokal.

Hvor IDE'en og værten understøtter en fortolkerindpakning, skal du pege den mod projektets faktiske fortolker:

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

Erstat begge stier til de kørbare filer og konfigurationsstien. Videresendelse af "$@" bevarer IDE'ens individuelle debuggerargumenter. exec forhindrer, at den startede proces efterlader en unødvendig indpakningsshell mellem IDE'en og dens barn.

I den dedikerede Proxychains-konfiguration skal du beholde den tilsigtede kæde og tilføje den relevante direkte loopback-undtagelse:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Disse regler springer kæden over for numeriske loopback-destinationer. Den medfølgende upstream-konfiguration dokumenterer begrænsninger for værtsnavnmatchning med proxy_dns, så foretræk debuggerens faktiske numeriske loopback-adresse, når den vej diagnosticeres. Anbring ikke undermasken til fjern DNS-mapping inden for det samme udelukkede interval.

Bevar fortolkerens identitet

Brug af /usr/bin/python3 i indpakningen kan stille vælge et andet miljø fra projektets .venv. Manglende pakker ser derefter ud som en proxyrelateret fejl, selv om en anden fortolker blev startet.

Proxychains er afhængig af understøttet indgriben i dynamiske biblioteker. En IDE, der afviser en indpakning som fortolker, en beskyttet macOS-proces eller en statisk linket netværksklient er en separat kompatibilitetsbetingelse. Hold ordningen begrænset til den tilsigtede Python-proces, og verificer den valgte fortolker i IDE'ens konfiguration.

Relaterede artikler