Umieść negocjację SOCKS Netty przed protokołem swojej aplikacji

Ustaw obsługę proxy SOCKS Netty przed ruchem aplikacji i zachowaj nierozwiązany cel, gdy DNS po stronie proxy jest zamierzony.

Dla istniejącego bootstrap/pipeline Netty, w którym serwer SOCKS ma rozwiązać cel:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

pipeline.addFirst(
    new Socks5ProxyHandler(new InetSocketAddress("127.0.0.1", 1080))
);

bootstrap.connect(
    InetSocketAddress.createUnresolved("example.com", 443)
);

Punkt końcowy proxy to lokalny port 1080; nierozwiązany cel połączenia to example.com:443. Nie używaj adresu proxy do obu ról i nie rozwiązuj nazwy, zanim obsługa ją otrzyma. Dla celów publicznych na dozwolonej publicznej trasie proxy lista proxy SOCKS5 dostarcza kandydatów dla punktu końcowego proxy obsługi.

Umieść Socks5ProxyHandler przed obsługą wymieniającą ruch do celu. Czekaj na future połączenia proxy, nie tylko na kanał docierający do nasłuchu. Odrzucona metoda lub cel należą do tego etapu konfiguracji.

Dla HTTPS następna warstwa TLS używa nazwy hosta celu, wymaganej weryfikacji i zaufania—nie tożsamości punktu końcowego SOCKS. Dopiero wtedy zaczyna się wymiana HTTP/aplikacji.

Fragment nie dostarcza pętli zdarzeń, typów kanałów, obsługi TLS/HTTP ani normalnej obsługi błędów. Wybierz konstruktor SOCKS dopasowany do potrzeb uwierzytelniania; obsługa HTTP Basic to inny protokół.

Używaj resolvera no-op tylko tam, gdzie ta dalsza obsługa posiada rozwiązywanie nazw hostów. Inne połączenia mogą wymagać wyszukiwania lokalnego. Podczas diagnozowania awarii trzymaj osobno dane wyjściowe resolvera, future proxy, TLS i wynik aplikacji.

Powiązane artykuły