Mbajeni lidhjen e debugger-it të PyCharm jashtë zinxhirit të proxy-t

Proxychains rreth një procesi debug të Python mund të kapin dy lidhje të ndryshme: lidhjen dalëse të shërbimit të skriptit dhe lidhjen e tij lokale përsëri drejt PyCharm. Debugger-i ka nevojë që e dyta të mbetet lokale.

Kur IDE-ja dhe hosti mbështesin një mbështjellës interpretuesi, drejtojeni atë drejt interpretuesit aktual të projektit:

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

Zëvendësoni të dy shtigjet e skedarëve të ekzekutueshëm dhe shtegun e konfigurimit. Përcjellja e "$@" ruan argumentet individuale të debugger-it nga IDE-ja. exec pengon procesin e nisur të lërë një shell mbështjellës të panevojshëm midis IDE-së dhe fëmijës së saj.

Në atë konfigurim të dedikuar të Proxychains, mbani zinxhirin e synuar dhe shtoni përjashtimin përkatës të drejtpërdrejtë loopback:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Këto rregulla anashkalojnë zinxhirin për destinacione numerike loopback. Konfigurimi i ofruar i rrjedhës së sipërme dokumenton kufizimet për përputhjen e emrave të hosteve me proxy_dns, prandaj gjatë diagnostikimit të asaj rruge preferoni adresën reale numerike loopback të debugger-it. Mos e vendosni nënrrjetin e hartëzimit DNS në distancë brenda të njëjtit interval të përjashtuar.

Ruani identitetin e interpretuesit

Përdorimi i /usr/bin/python3 në mbështjellës mund të zgjedhë në heshtje një mjedis tjetër nga .venv i projektit. Paketat që mungojnë atëherë duken si dështim i lidhur me proxy-n, ndonëse nisi një interpretues tjetër.

Proxychains mbështetet në përgjimin e mbështetur të bibliotekave dinamike. Refuzimi nga IDE-ja i një mbështjellësi si interpretues, një proces i mbrojtur i macOS ose një klient rrjeti i lidhur statikisht janë një kusht i veçantë përputhshmërie. Kufizoni rregullimin te procesi i synuar i Python dhe verifikoni interpretuesin e zgjedhur në konfigurimin e IDE-së.