gRPC C-Core Proxy and Bypass Variable Precedence
Trace gRPC Core's proxy and bypass precedence without assuming another gRPC implementation uses the same mapper.
Changing http_proxy can do nothing when a higher-priority gRPC setting is already present. Start by identifying the implementation: the following behavior belongs to gRPC C-Core's default HTTP proxy mapper and its dependents.
The mapper checks a channel proxy argument, then grpc_proxy, then https_proxy, then http_proxy, stopping at the first configured value.
Bypass discovery has its own order: no_grpc_proxy takes precedence over no_proxy. An old value there can explain why one target avoids an otherwise configured proxy.
This mapper uses HTTP CONNECT. Its documented proxy URI expects an HTTP scheme; a TLS-protected gRPC service does not by itself require a TLS-protected proxy endpoint. Check supported authentication separately rather than assuming that any browser login scheme is available. For a public gRPC target where public intermediaries are permitted, the HTTP proxy list offers endpoint candidates for the selected HTTP proxy URI; confirm access to the actual CONNECT target and port.
A Java, Go, JavaScript, or other gRPC implementation can have different transport code and configuration. Do not apply a C-Core variable list as a universal rule for everything named gRPC.
For a failed channel, retain the selected proxy, bypass decision, target, and error stage. A reachable HTTP API through another client does not establish that this mapper used the same settings or that the proxy permits the required CONNECT destination.