מחבר מודע ל-SOCKS עבור שקעי TCP של Python

שקע Python גולמי אינו מנהל משא ומתן על פרוקסי רק מפני ש-http_proxy קיים. עבור יישום שמדבר בפרוטוקול TCP משלו, השתמשו במחבר שמבין את השירות בקצה הפרוקסי.

כאשר PySocks כבר זמין, צרו את החיבור באופן מפורש:

import socks

with socks.socksocket() as connection:
    connection.set_proxy(socks.SOCKS5, '203.0.113.10', 1080)
    connection.settimeout(10)
    connection.connect(('example.com', 12345))
    # Exchange the destination protocol here.

החליפו את כתובת התיעוד ואת פורט היעד. עבור יעד ציבורי מורשה, בחרו מועמד מרשימת פרוקסי SOCKS5 רק לאחר שבדקתם שהוא מתיר את פורט היעד של היישום. בדקו את החבילה המותקנת, את השיטות הנתמכות ואת דרישות הקצה מול ממשק PySocks.

שאר היישום מחליף את הפרוטוקול שלו מעל החיבור שהוקם. אם אותו פרוטוקול משתמש ב-TLS, התחילו אותו לאחר משא ומתן הפרוקסי ואמתו את שם המארח האמיתי של היעד. אימות הפרוקסי מבסס את המסלול; הוא אינו מספק את הכניסה ליעד או הצפנה.

מאזין SOCKS זקוק למשא ומתן SOCKS. שירות HTTP זקוק למחבר שתומך ב-CONNECT עבור יעד TCP שרירותי ועלול לסרב לפורט שלו. בחרו את המחבר לפי השירות שמוצע בפועל, במקום לשנות כתובת ולהשאיר את לחיצת היד השגויה.

שמרו את ההחלפה מקומית. הקצאת מחלקה ל-socket.socket עלולה להשפיע על ייבוא וספריות לא קשורים. אם ספרייה אחרת אחראית ליצירת שקעים, השתמשו במפעל החיבורים או באפשרות הפרוקסי המתועדים שלה; מילון שהיא לעולם אינה קוראת בו אינו יכול לשנות את החיבור הזה.