Priorité des variables de proxy et de contournement dans gRPC C-Core
Suivez la priorité du proxy et du contournement de gRPC Core sans supposer qu'une autre implémentation gRPC utilise le même mappeur.
Modifier http_proxy peut ne rien faire lorsqu'un réglage gRPC de priorité supérieure est déjà présent. Commencez par identifier l'implémentation : le comportement suivant appartient au mappeur HTTP de proxy par défaut de gRPC C-Core et à ses dépendants.
Le mappeur examine un argument de proxy de canal, puis grpc_proxy, puis https_proxy, puis http_proxy, et s'arrête à la première valeur configurée.
La détection du contournement a son propre ordre : no_grpc_proxy prime sur no_proxy. Une ancienne valeur à cet endroit peut expliquer pourquoi une cible évite un proxy pourtant configuré.
Ce mappeur utilise HTTP CONNECT. Son URI de proxy documenté attend un schéma HTTP ; un service gRPC protégé par TLS n'exige pas en soi un point de terminaison de proxy protégé par TLS. Vérifiez séparément l'authentification prise en charge au lieu de supposer qu'un schéma de connexion de navigateur est disponible. Pour une cible gRPC publique où les intermédiaires publics sont autorisés, la liste de proxys HTTP propose des points de terminaison candidats pour l'URI de proxy HTTP choisi ; confirmez l'accès à la cible CONNECT et au port réels.
Une implémentation gRPC en Java, Go, JavaScript ou autre peut avoir un code de transport et une configuration différents. N'appliquez pas une liste de variables C-Core comme règle universelle à tout ce qui s'appelle gRPC.
Pour un canal en échec, conservez le proxy sélectionné, la décision de contournement, la cible et l'étape d'erreur. Une API HTTP joignable via un autre client ne prouve pas que ce mappeur a utilisé les mêmes réglages ni que le proxy autorise la destination CONNECT requise.