gRPC C-Core におけるプロキシとバイパス変数の優先順位

より優先度の高い gRPC 設定がすでにある場合、http_proxy を変更しても何も起こりません。まず実装を特定してください。以下の動作は gRPC C-Core の既定の HTTP プロキシマッパーとその依存先に属します。

マッパーはチャネルのプロキシ引数、次に grpc_proxy、次に https_proxy、次に http_proxy を確認し、最初に設定された値で停止します。

バイパスの判定にも独自の順序があります。no_grpc_proxy は no_proxy より優先されます。そこに古い値があると、ある対象が本来設定されているプロキシを避ける理由を説明できる場合があります。

このマッパーは HTTP CONNECT を使います。文書化されたプロキシ URI は HTTP スキームを前提としており、TLS で保護された gRPC サービス自体が TLS で保護されたプロキシエンドポイントを必要とするわけではありません。ブラウザのログイン方式が使えると決めつけず、対応する認証を別途確認してください。公的な仲介者が許可される公開 gRPC 対象では、HTTPプロキシ一覧 が選択した HTTP プロキシ URI のエンドポイント候補を提供します。実際の CONNECT 対象とポートへの到達を確認してください。

Java、Go、JavaScript などの gRPC 実装では、トランスポートのコードや設定が異なる場合があります。C-Core の変数一覧を、gRPC と呼ばれるすべてに通用する規則として適用しないでください。

チャネルが失敗した場合は、選択したプロキシ、バイパスの判断、対象、エラーの段階を保持してください。別のクライアントで HTTP API に到達できても、このマッパーが同じ設定を使ったことや、プロキシが必要な CONNECT 宛先を許可していることは証明されません。