اتصال دیباگر PyCharm را بیرون از زنجیره پروکسی نگه دارید

Proxychains پیرامون یک فرایند دیباگ پایتون می‌تواند دو اتصال متفاوت را بگیرد: اتصال خروجی اسکریپت به سرویس و اتصال محلی آن بازگشت به 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 یا یک کلاینت شبکه با پیوند ایستا، شرط سازگاری جداگانه‌ای است. چیدمان را به فرایند پایتون مورد نظر محدود کنید و مفسر انتخاب‌شده را در پیکربندی IDE بررسی کنید.