مذاکره 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 بدون‌عمل فقط جایی استفاده کنید که این هندلر پایین‌دستی مالک حل نام میزبان است. اتصال‌های دیگر ممکن است به جستجوی محلی نیاز داشته باشند. هنگام عیب‌یابی یک خرابی، خروجی resolver، future پروکسی، TLS و نتیجه برنامه را جدا نگه دارید.