I Java 11 eller nyare set du ein ProxySelector i klientbyggjaren. Proxy-eigenskapane for heile JVM-en vert då ikkje endra:

import java.net.InetSocketAddress;
import java.net.ProxySelector;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Duration;

public class ProxyExample {
    public static void main(String[] args) throws Exception {
        HttpClient client = HttpClient.newBuilder()
            .proxy(ProxySelector.of(
                new InetSocketAddress("203.0.113.10", 8080)))
            .connectTimeout(Duration.ofSeconds(5))
            .build();

        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create("https://example.com/"))
            .timeout(Duration.ofSeconds(15))
            .GET()
            .build();

        HttpResponse<String> response = client.send(
            request, HttpResponse.BodyHandlers.ofString());
        System.out.println(response.statusCode());
        System.out.println(response.body());
    }
}

Byt dokumentasjonsendepunktet med din HTTP-proxy; HTTP-proxylista har kandidatar å teste. ProxySelector.of tek ei socketadresse: bruk verten utan http://-prefiks og oppgi porten separat. Ho vel ein HTTP-proxy, ikkje SOCKS ut frå portnummeret. URI-en til førespurnaden er framleis den verkelege destinasjonen.

HTTPS kan gå gjennom denne HTTP-proxyen via ein tunnel. Destinasjonen treng ikkje nedgraderast, og oppsettet tyder ikkje at proxylyttaren sjølv støttar TLS.

Tilkoplingstidsavbrotet i klientbyggjaren gjeld når ei tilkopling vert oppretta; førespurnaden har sitt eige tidsavbrot. Hald begge synlege fordi ein førespurnad kan bruke ei eksisterande tilkopling om att. Eit nettverks-, autentiserings- eller tunnelunntak kan oppstå før noko svar frå destinasjonen, medan ein returnert feilstatus ikkje må gi eit unntak.

Bruk klienten om att for førespurnader med same rutingspolicy, slik at programmet kan dra nytte av tilkoplingshandteringa.

Relaterte artiklar