407이 반복된다고 해서 Java가 항상 잘못된 암호를 보낸 것은 아닙니다. JDK 참조 구현은 일반적으로 HTTPS CONNECT 터널링에서 Basic 인증을 비활성화합니다. Basic만 제공하는 프록시는 인증 콜백이 자격 증명을 제공하기 전에 거부될 수 있습니다.

자격 증명 콜백의 범위 제한

Java HTTP 클라이언트에 Authenticator를 연결하고 구성한 프록시에만 사용하도록 제한하세요:

String proxyHost = "203.0.113.10";
int proxyPort = 8080;
String password = System.getenv("PROXY_PASSWORD");
if (password == null) {
    throw new IllegalStateException("Set PROXY_PASSWORD");
}

java.net.Authenticator auth = new java.net.Authenticator() {
    @Override
    protected java.net.PasswordAuthentication getPasswordAuthentication() {
        if (getRequestorType() == RequestorType.PROXY
                && proxyHost.equals(getRequestingHost())
                && proxyPort == getRequestingPort()) {
            return new java.net.PasswordAuthentication(
                "proxy-user", password.toCharArray());
        }
        return null;
    }
};

java.net.http.HttpClient client = java.net.http.HttpClient.newBuilder()
    .proxy(java.net.ProxySelector.of(
        new java.net.InetSocketAddress(proxyHost, proxyPort)))
    .authenticator(auth)
    .connectTimeout(java.time.Duration.ofSeconds(5))
    .build();

이는 클라이언트의 설정 코드이며 전역 기본 인증기가 아닙니다. 문서용 주소를 바꾸고 해당 서비스에서 실제로 제공한 자격 증명을 사용하세요. 요청자 유형과 엔드포인트를 검사하면 동일한 콜백이 웹사이트의 인증 요구에 프록시 계정을 무심코 제공하는 일을 막을 수 있습니다.

어느 인증 단계에서 실패하는지 확인

JDK에는 일반 HTTP 프록시 연결과 CONNECT 터널링에 대해 각각 비활성화된 인증 방식 설정이 있습니다. 해당 이름은 jdk.http.auth.proxying.disabledSchemes과 jdk.http.auth.tunneling.disabledSchemes입니다.

이 때문에 HTTP 트래픽은 인증되지만 같은 프록시를 통한 HTTPS 터널은 실패할 수 있습니다. 다른 컴퓨터의 유효 기본값이 같다고 가정하지 말고 런타임의 conf/net.properties와 배포 정책을 확인하세요.

비활성화된 인증 방식 목록을 전역으로 비우는 것은 일반적인 프록시 해결책이 아닙니다. 평문 HTTP 프록시로 보낸 Basic 자격 증명은 이후 목적지와 맺는 TLS 연결로 보호되지 않습니다. 변경을 승인하기 전에 프록시 전송 방식, 인증 방법, 배포 정책을 검토하세요.

문서에 명시된 JDK의 내장 인증 동작도 프록시가 알리는 모든 인증 방식을 지원한다는 보장은 아닙니다. Authorization 또는 Proxy-Authorization 헤더를 수동으로 제공하면 자동 인증기 흐름이 바뀌므로 콜백 동작이 예제와 다를 때는 사용자 지정 헤더를 살펴보세요.

관련 글