Трымайце адладжванне PyCharm па-за ланцужком проксі

Proxychains вакол працэсу адладкі Python можа перахапіць два розныя злучэнні: зыходнае злучэнне скрыпта з сервісам і яго лакальнае злучэнне назад да PyCharm. Адладчыку патрэбна менавіта другое, каб застацца лакальным.

Калі IDE і хост падтрымліваюць абгортку інтэрпрэтатара, накіруйце яе на фактычны інтэрпрэтатар праекта:

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

Замяніце абодва шляхі да выканальных файлаў і шлях да канфігурацыі. Перадача "$@" захоўвае асобныя аргументы адладчыка ад IDE. exec не дае запушчанаму працэсу пакінуць непатрэбную абалонку-абгортку паміж IDE і яго нашчадкам.

У гэтай асобнай канфігурацыі Proxychains захавайце патрэбны ланцужок і дадайце адпаведнае прамое выключэнне loopback:

localnet 127.0.0.0/255.0.0.0
localnet ::1/128

Гэтыя правілы абыходзяць ланцужок для лікавых адрасоў loopback. Пастаўленая вышэй канфігурацыя дакументуе абмежаванні супастаўлення імён хостаў з proxy_dns, таму пры дыягностыцы гэтага шляху аддавайце перавагу фактычнаму лікаваму адрасу loopback адладчыка. Не змяшчайце падсетку аддаленага DNS-супастаўлення ў той жа выключаны дыяпазон.

Захоўвайце ідэнтычнасць інтэрпрэтатара

Выкарыстанне /usr/bin/python3 у абгортцы можа незаўважна выбраць іншае асяроддзе з .venv праекта. Тады адсутныя пакеты выглядаюць як збой, звязаны з проксі, хоць запусціўся іншы інтэрпрэтатар.

Proxychains абапіраецца на падтрымліваемае перахопліванне дынамічных бібліятэк. Адмова IDE прымаць абгортку як інтэрпрэтатар, абаронены працэс macOS або статычна скомпанаваны сеткавы кліент — гэта асобная ўмова сумяшчальнасці. Абмяжуйце схему патрэбным працэсам Python і праверце выбраны інтэрпрэтатар у наладах IDE.