Prioritet för proxy- och bypass-variabler i gRPC C-Core
Följ gRPC Cores proxy- och bypassprioritet utan att anta att en annan gRPC-implementering använder samma mapper.
Att ändra http_proxy kan göra ingenting när en gRPC-inställning med högre prioritet redan finns. Börja med att identifiera implementeringen: följande beteende hör till gRPC C-Cores standard-HTTP-proxymapper och det som beror på den.
Mappern kontrollerar ett kanalproxyargument, sedan grpc_proxy, sedan https_proxy, sedan http_proxy, och stannar vid det första konfigurerade värdet.
Bypassupptäckt har sin egen ordning: no_grpc_proxy har företräde framför no_proxy. Ett gammalt värde där kan förklara varför ett mål undviker en annars konfigurerad proxy.
Den här mappern använder HTTP CONNECT. Dess dokumenterade proxy-URI förväntar sig ett HTTP-schema; en TLS-skyddad gRPC-tjänst kräver inte i sig en TLS-skyddad proxyändpunkt. Kontrollera stödd autentisering separat i stället för att anta att någon webbläsarinloggning är tillgänglig. För ett offentligt gRPC-mål där offentliga mellanhänder är tillåtna erbjuder listan över HTTP-proxyer ändpunktskandidater för den valda HTTP-proxy-URI:n; bekräfta åtkomst till det faktiska CONNECT-målet och porten.
En Java-, Go-, JavaScript- eller annan gRPC-implementering kan ha annan transportkod och konfiguration. Använd inte en C-Core-variabellista som en universell regel för allt som kallas gRPC.
För en misslyckad kanal, behåll den valda proxyn, bypassbeslutet, målet och felsteget. Ett HTTP-API som nås via en annan klient bevisar inte att den här mappern använde samma inställningar eller att proxyn tillåter det nödvändiga CONNECT-målet.