یک شیء پروکسی جاوا یک مسیر را توصیف می‌کند. هنوز کلاینت شبکه است که تصمیم می‌گیرد کدام نوع مسیر را می‌تواند استفاده کند. این موضوع زمانی مهم است که نقطه پایانی موجود SOCKS صحبت می‌کند و برنامه از java.net.http.HttpClient استفاده می‌کند.

در پیاده‌سازی JDK 25 که اینجا بررسی شده است، کد درخواست کلاینت HTTP یک نامزد HTTP را از انتخاب‌گر می‌پذیرد. نامزد SOCKS باعث نمی‌شود که مذاکره SOCKS انجام دهد؛ پیاده‌سازی می‌تواند بدون پروکسی ادامه یابد. بنابراین پاسخ موفق شواهد کافی نیست که ورودی SOCKS یک انتخاب‌گر سفارشی استفاده شده است.

ابتدا انتقال را انتخاب کنید

برای برنامه موجود مبتنی بر URLConnection، می‌توان هنگام باز کردن اتصال یک پروکسی صریح پشتیبانی‌شده به گرداننده پروتکل داد:

Proxy route = new Proxy(Proxy.Type.SOCKS,
    new InetSocketAddress("proxy.example", 1080));
URLConnection connection = URI.create("https://service.example/")
    .toURL().openConnection(route);
connection.setConnectTimeout(5000);
connection.setReadTimeout(15000);

برای آزمون‌های مجاز روی هدف‌های عمومی، از یک نقطه پایانی SOCKS مناسب از سرویس خود یا از فهرست پروکسی SOCKS استفاده کنید. این یک API کلاینت متفاوت است، نه املای جایگزین HttpClient.Builder.proxy. نشانی مقصد را حفظ کنید تا HTTPS همچنان وب‌سایت موردنظر را شناسایی کند.

برنامه‌ای که باید java.net.http را نگه دارد، می‌تواند در عوض از یک نقطه پایانی پروکسی HTTP سازگار استفاده کند، از جمله یک آداپتور تأییدشده که اتصال SOCKS بعدی را بر عهده می‌گیرد. این کار یک مؤلفه واقعی و یک مرز دسترسی دیگر اضافه می‌کند؛ تغییر پورت 8080 به 1080 این ترجمه را فراهم نمی‌کند.

انتخاب و پذیرش را قابل مشاهده نگه دارید

هم نتیجه انتخاب‌گر و هم اتصالی را که کلاینت واقعاً باز می‌کند ثبت کنید. اولی خروجی سیاست را توصیف می‌کند؛ دومی مشخص می‌کند آیا پیاده‌سازی آن را پذیرفته است یا نه.

نتیجه‌گیری‌ها را به محیط اجرا و انتقال مورد استفاده گره بزنید. ویژگی‌های SOCKS ماشین مجازی جاوا که یک پیاده‌سازی سوکت استفاده می‌کند، وعده‌ای نیست که هر کتابخانه HTTP به آن‌ها مراجعه می‌کند. وقتی مسیر اجباری است، باید نوع پروکسی پشتیبانی‌نشده پیش از پذیرش یک درخواست مستقیم که ظاهراً موفق است تشخیص داده شود.

مقالات مرتبط