Hou PyCharm se ontfouterverbinding buite die proxyketting

Proxychains rondom 'n Python-ontfoutproses kan twee verskillende verbindings vang: die skrip se uitgaande diensverbinding en sy plaaslike verbinding terug na PyCharm. Die ontfouter het die laaste een nodig om plaaslik te bly.

Waar die IDE en gasheer 'n tolk-wrapper ondersteun, wys dit na die projek se werklike tolk:

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

Vervang albei lêerpadlyne en die konfigurasiepad. Die deurgee van "$@" behou die IDE se individuele ontfouterargumente. exec verhoed dat die gestarte proses 'n onnodige wrapper-dop tussen die IDE en sy kind laat.

In daardie toegewyde Proxychains-konfigurasie hou jy die beoogde ketting en voeg die betrokke direkte loopback-uitsondering by:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Hierdie reëls omseil die ketting vir numeriese loopback-bestemmings. Die verskafde opstroom-konfigurasie dokumenteer beperkings vir gasheernaam-passing met proxy_dns, so verkies die ontfouter se werklike numeriese loopback-adres wanneer daardie pad gediagnoseer word. Moenie die remote DNS-kaartsubnet binne dieselfde uitgeslote reeks plaas nie.

Behou die tolk se identiteit

Om /usr/bin/python3 in die wrapper te gebruik, kan stilweg 'n ander omgewing uit die projek se .venv kies. Ontbrekende pakkette lyk dan soos 'n proxy-verwante fout, al het 'n ander tolk begin.

Proxychains maak staat op ondersteunde dinamiese-biblioteekonderskepping. 'n IDE wat 'n wrapper as 'n tolk verwerp, 'n beskermde macOS-proses of 'n staties gekoppelde netwerkklient is 'n aparte versoenbaarheidstoestand. Hou die reëling beperk tot die beoogde Python-proses en verifieer die gekose tolk in die IDE se konfigurasie.