Држете ја дебагерската врска на 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.