השאירו את חיבור הדיבאגר של PyCharm מחוץ לשרשרת הפרוקסי
עטפו את מתרגם הפייתון הנבחר עבור Proxychains תוך שמירה על הארגומנטים ועל מסלול loopback ישיר אל הדיבאגר.
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.