Use o provedor de canal do cliente gerado quando uma conexão Pub/Sub Java gRPC precisar de um proxy HTTP CONNECT. Uma configuração comum de URLConnection não estabelece esta configuração de canal.

Para o cliente topic-admin:

var channelProvider = TopicAdminSettings
    .defaultGrpcTransportProviderBuilder()
    .setChannelConfigurator(channel -> channel.proxyDetector(target ->
        HttpConnectProxiedSocketAddress.newBuilder()
            .setProxyAddress(new InetSocketAddress("proxy.example", 8080))
            .setTargetAddress((InetSocketAddress) target)
            .setUsername(proxyUser)
            .setPassword(proxyPassword)
            .build()))
    .build();

var settings = TopicAdminSettings.newBuilder()
    .setTransportChannelProvider(channelProvider)
    .build();
try (TopicAdminClient client = TopicAdminClient.create(settings)) {
    // Perform the application's intended topic-admin operation here.
}

TopicAdminClient e TopicAdminSettings são classes do Pub/Sub v1; HttpConnectProxiedSocketAddress vem de io.grpc e InetSocketAddress de java.net. O exemplo pressupõe o destino habitual de endereço de internet usado por este canal.

O detector devolve um endereço de conexão do proxy ao lado do destino original. O construtor gRPC exige que o endereço do proxy seja resolvido. Deixe o endpoint do serviço como Pub/Sub: substituí-lo pelo nome do host do proxy perderia o destino do serviço e a identidade TLS pretendida.

Remova as chamadas de utilizador/palavra-passe para um proxy sem autenticação; candidatos HTTP públicos encontram-se na lista de proxies HTTP. Essas chamadas são a interface de credenciais HTTP CONNECT, não SOCKS nem uma implementação geral de NTLM.

Se a falha ocorrer antes da operação gRPC enquanto credenciais criadas independentemente obtêm um token, inspecione a rota HTTP dessas credenciais. Está fora do provedor de canal mostrado aqui.

Artigos relacionados