Håll PyCharms debuggeranslutning utanför proxykedjan

Proxychains runt en Python-felsökningsprocess kan fånga två olika anslutningar: skriptets utgående tjänsteanslutning och dess lokala anslutning tillbaka till PyCharm. Debuggern behöver att den senare stannar lokalt.

Där IDE:n och värden stöder ett tolkomslag pekar du det mot projektets faktiska tolk:

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

Ersätt båda sökvägarna till de körbara filerna och konfigurationssökvägen. Att vidarebefordra "$@" bevarar IDE:ns enskilda debuggerargument. exec hindrar den startade processen från att lämna ett onödigt omslagsskal mellan IDE:n och dess barn.

I den dedikerade Proxychains-konfigurationen behåller du den avsedda kedjan och lägger till det relevanta direkta loopback-undantaget:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Dessa regler kringgår kedjan för numeriska loopback-mål. Den medföljande uppströmskonfigurationen dokumenterar begränsningar för värdnamnsmatchning med proxy_dns, så föredra debuggerns faktiska numeriska loopback-adress när den vägen diagnostiseras. Placera inte subnätet för fjärr-DNS-mappning inom samma undantagna intervall.

Bevara tolkens identitet

Att använda /usr/bin/python3 i omslaget kan tyst välja en annan miljö från projektets .venv. Saknade paket ser då ut som ett proxyrelaterat fel, trots att en annan tolk startades.

Proxychains förlitar sig på stödd avlyssning av dynamiska bibliotek. En IDE som avvisar ett omslag som tolk, en skyddad macOS-process eller en statiskt länkad nätverksklient är ett separat kompatibilitetsvillkor. Begränsa arrangemanget till den avsedda Python-processen och verifiera den valda tolken i IDE:ns konfiguration.