Ինչու 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 թեկնածուների անտարբեր զտումը կարող է կտրել միացումներ, որոնք պետք է օգտագործեին մեկը։ Ուղղեք սխալ կանոնը ձեր բացահայտած ամենափոքր շրջանակով։