Metu la SOCKS-intertraktadon de Netty antaŭ via aplikaĵa protokolo
Ordigi Netty SOCKS-prokuran tenilon antaŭ la aplikaĵa trafiko kaj konservi nesolvitan celon kiam DNS ĉe la prokura flanko estas intencita.
Por ekzistanta Netty bootstrap/pipeline, kie la SOCKS-servilo devus solvi la celon:
bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);
pipeline.addFirst(
new Socks5ProxyHandler(new InetSocketAddress("127.0.0.1", 1080))
);
bootstrap.connect(
InetSocketAddress.createUnresolved("example.com", 443)
);La prokura finpunkto estas loka pordo 1080; la nesolvita konekta celo estas example.com:443. Ne uzu la prokuran adreson por ambaŭ roloj kaj ne solvu la nomon antaŭ ol la tenilo ricevas ĝin. Por publikaj celoj sur permesita publika prokura vojo, la SOCKS5-prokura listo liveras kandidatojn por la prokura finpunkto de la tenilo.
Metu Socks5ProxyHandler antaŭ teniloj, kiuj interŝanĝas celan trafikon. Atendu ĝian prokuran konektan future, ne nur kanalon atingantan la aŭskultanton. Malakceptita metodo aŭ celo apartenas al ĉi tiu agorda etapo.
Por HTTPS, la sekva TLS-tavolo uzas la gastigan nomon de la celo, la postulatan kontrolon kaj fidon—ne la identecon de la SOCKS-finpunkto. Nur tiam komenciĝas la HTTP/aplikaĵa interŝanĝo.
La fragmento ne liveras eventajn buklojn, kanalajn tipojn, TLS/HTTP-tenilojn aŭ normalan eraran traktadon. Elektu la SOCKS-konstruanton kongruan al la aŭtentikigaj bezonoj; HTTP Basic-tenilo estas alia protokolo.
Uzu la no-op resolver nur tie, kie ĉi tiu malsupra tenilo posedas gastignoman solvon. Aliaj konektoj eble bezonas lokan serĉon. Tenu la eligon de la resolver, la prokuran future, TLS kaj la aplikaĵan rezulton aparte kiam vi diagnozas fiaskon.