Prioriteit van proxy- en bypass-variabelen in gRPC C-Core
Volg de proxy- en bypassprioriteit van gRPC Core zonder aan te nemen dat een andere gRPC-implementatie dezelfde mapper gebruikt.
Het wijzigen van http_proxy kan niets doen wanneer er al een gRPC-instelling met hogere prioriteit bestaat. Begin met het identificeren van de implementatie: het volgende gedrag hoort bij de standaard HTTP-proxymapper van gRPC C-Core en zijn afhankelijkheden.
De mapper controleert een kanaalproxy-argument, dan grpc_proxy, dan https_proxy, dan http_proxy, en stopt bij de eerste geconfigureerde waarde.
Bypass-detectie heeft een eigen volgorde: no_grpc_proxy gaat voor op no_proxy. Een oude waarde daar kan verklaren waarom een doel een verder geconfigureerde proxy vermijdt.
Deze mapper gebruikt HTTP CONNECT. De gedocumenteerde proxy-URI verwacht een HTTP-schema; een met TLS beveiligde gRPC-service vereist op zichzelf geen met TLS beveiligd proxy-eindpunt. Controleer ondersteunde authenticatie apart in plaats van aan te nemen dat een willekeurig browseraanmeldingsschema beschikbaar is. Voor een openbaar gRPC-doel waar openbare tussenpartijen zijn toegestaan, biedt de lijst met HTTP-proxy's eindpuntkandidaten voor de gekozen HTTP-proxy-URI; bevestig toegang tot het werkelijke CONNECT-doel en de poort.
Een Java-, Go-, JavaScript- of andere gRPC-implementatie kan andere transportcode en configuratie hebben. Pas een C-Core-variabelenlijst niet toe als universele regel voor alles wat gRPC heet.
Bewaar voor een mislukte kanaal de gekozen proxy, de bypass-beslissing, het doel en de faser waarin de fout optrad. Een HTTP-API die via een andere client bereikbaar is, bewijst niet dat deze mapper dezelfde instellingen gebruikte of dat de proxy de vereiste CONNECT-bestemming toestaat.