أبقِ اتصال مُنقِّح 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.