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.

Похожие статьи