Тримайте з'єднання налагоджувача 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.