یک درخواست جاوا می‌تواند با چندین ورودی پروکسی روبه‌رو شود: پیکربندی صریح کلاینت، انتخاب‌گر پیش‌فرض، ویژگی‌های شبکهٔ 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 آگاهانه تنظیم کنید.

پاسخ‌های تاریخی ترکیب‌های مشخصی از دیالوگ‌های قدیمی ویندوز و JDKهای قدیمی را توصیف می‌کنند. آن گزارش‌ها می‌توانند خاستگاه یک راه‌حل موقت را توضیح دهند، اما ثابت نمی‌کنند که یک محیط اجرای کنونی همان باگ را دارد. پیش از تغییر تنظیمات سیستم‌عامل برای همهٔ برنامه‌ها، نسخهٔ محیط اجرا و خروجی انتخاب‌گر را ثبت کنید.

اگر برنامه برای یک کلاینت به پروکسی HTTP نیاز دارد، یک پیکربندی صریح پروکسی می‌تواند آن نیاز را روشن‌تر کند. اگر به مسیریابی خودکار مرکزی نیاز دارد، بررسی کنید چرا انتخاب‌گر ورودی غیرمنتظرهٔ SOCKS را دریافت یا بازگرداند.

یک انتخاب‌گر سفارشی باید عبورهای عمدی و مدیریت خطا را حفظ کند. فیلتر کردن بی‌رویهٔ همهٔ گزینه‌های SOCKS می‌تواند اتصالاتی را که قرار بود از یکی استفاده کنند بشکند. قاعدهٔ نادرست را با کوچک‌ترین دامنه‌ای که می‌توانید مشخص کنید اصلاح کنید.

مقالات مرتبط