הציבו את משא ומתן ה-SOCKS של Netty לפני פרוטוקול האפליקציה שלכם

עבור bootstrap/pipeline קיים של Netty שבו שרת ה-SOCKS אמור לפתור את היעד:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

pipeline.addFirst(
    new Socks5ProxyHandler(new InetSocketAddress("127.0.0.1", 1080))
);

bootstrap.connect(
    InetSocketAddress.createUnresolved("example.com", 443)
);

נקודת הקצה של הפרוקסי היא פורט מקומי 1080; יעד החיבור הלא פתור הוא example.com:443. אל תשתמשו בכתובת הפרוקסי לשני התפקידים ואל תפתרו את השם לפני שהמטפל מקבל אותו. עבור יעדים ציבוריים בנתיב פרוקסי ציבורי מותר, רשימת פרוקסי SOCKS5 מספקת מועמדים לנקודת הקצה של הפרוקסי של המטפל.

הציבו את Socks5ProxyHandler לפני מטפלים שמחליפים תעבורת יעד. המתינו ל-future של חיבור הפרוקסי, לא רק לערוץ שמגיע למאזין. שיטה או יעד שנדחו שייכים לשלב ההגדרה הזה.

ב-HTTPS, שכבת ה-TLS הבאה משתמשת בשם המארח של היעד, באימות ובאמון הנדרשים—לא בזהות נקודת הקצה של SOCKS. רק אז מתחיל חילופי ה-HTTP/אפליקציה.

הקטע אינו מספק לולאות אירועים, סוגי ערוצים, מטפלי TLS/HTTP או טיפול שגיאות רגיל. בחרו את בנאי ה-SOCKS המתאים לצורכי האימות; מטפל HTTP Basic הוא פרוטוקול אחר.

השתמשו ב-resolver מסוג no-op רק במקום שבו המטפל downstream הזה מחזיק בפתרון שם המארח. חיבורים אחרים עשויים להזדקק לחיפוש מקומי. שמרו בנפרד על פלט ה-resolver, ה-future של הפרוקסי, TLS ותוצאת האפליקציה בעת אבחון כשל.