Precedência de variáveis de proxy e bypass no gRPC C-Core
Siga a precedência de proxy e bypass do gRPC Core sem presumir que outra implementação de gRPC usa o mesmo mapeador.
Alterar http_proxy pode não fazer nada se já existir uma definição de gRPC com prioridade mais alta. Comece por identificar a implementação: o comportamento a seguir pertence ao mapeador HTTP de proxy padrão do gRPC C-Core e aos seus dependentes.
O mapeador verifica um argumento de proxy do canal, depois grpc_proxy, depois https_proxy, depois http_proxy, e para no primeiro valor configurado.
A descoberta de bypass tem a sua própria ordem: no_grpc_proxy tem precedência sobre no_proxy. Um valor antigo ali pode explicar por que um destino evita um proxy configurado de outra forma.
Este mapeador usa HTTP CONNECT. O seu URI de proxy documentado espera um esquema HTTP; um serviço gRPC protegido por TLS não exige, por si só, um endpoint de proxy protegido por TLS. Verifique a autenticação suportada separadamente em vez de presumir que qualquer esquema de início de sessão do navegador está disponível. Para um destino gRPC público onde intermediários públicos são permitidos, a lista de proxies HTTP oferece candidatos a endpoint para o URI de proxy HTTP escolhido; confirme o acesso ao destino e à porta reais de CONNECT.
Uma implementação de gRPC em Java, Go, JavaScript ou outra linguagem pode ter código de transporte e configuração diferentes. Não aplique uma lista de variáveis do C-Core como regra universal a tudo o que se chama gRPC.
Para um canal com falha, mantenha o proxy escolhido, a decisão de bypass, o destino e a fase do erro. Uma API HTTP acessível através de outro cliente não prova que este mapeador usou as mesmas definições nem que o proxy permite o destino CONNECT necessário.