Дръжте debug връзката на 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.