למה Java בחרה בפרוקסי SOCKS עבור בקשת ה-HTTP שלך

בקשה ב-Java יכולה לפגוש כמה מקורות פרוקסי: תצורת לקוח מפורשת, הבורר המוגדר כברירת מחדל, מאפייני הרשת של ה-JVM והגדרות מערכת הפעלה נתמכות. כאשר יומן מזכיר SOCKS באופן בלתי צפוי, זהה איזה מקור בחר בו.

עבור קוד שמשתמש בבורר ברירת המחדל, בדוק את ההחלטה עבור היעד המדויק:

URI target = URI.create("https://example.com/");
ProxySelector selector = ProxySelector.getDefault();
if (selector != null) {
    System.out.println(selector.select(target));
}

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

בדוק את ההגדרות האפקטיביות

עיין ב-http.proxyHost, ב-https.proxyHost, ב-socksProxyHost, בפורטים שלהם וב-java.net.useSystemProxies. תיעוד מאפייני הרשת של JDK מתאר את היקפם ואת קדימותם. גילוי פרוקסי המערכת נבדק באתחול; הגדר אותו במכוון בעת הפעלת ה-JVM.

תשובות היסטוריות מתארות שילובים מסוימים של דיאלוגים ישנים של Windows ו-JDK ישנים. הדוחות האלה יכולים להסביר את מקורו של פתרון, אך אינם מוכיחים שלסביבת ריצה עדכנית יש את אותו באג. רשום את גרסת סביבת הריצה ואת פלט הבורר לפני שינוי הגדרות מערכת ההפעלה עבור כל יישום.

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

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