Proxy y precedencia de variables de omisión en gRPC C-Core
Siga la precedencia de proxy y omisión de gRPC Core sin suponer que otra implementación de gRPC usa el mismo asignador.
Cambiar http_proxy puede no hacer nada si ya existe un ajuste de gRPC con mayor prioridad. Empiece identificando la implementación: el comportamiento siguiente pertenece al asignador HTTP de proxy predeterminado de gRPC C-Core y a sus dependientes.
El asignador comprueba un argumento de proxy de canal, luego grpc_proxy, luego https_proxy, luego http_proxy, y se detiene en el primer valor configurado.
El descubrimiento de omisiones tiene su propio orden: no_grpc_proxy tiene precedencia sobre no_proxy. Un valor antiguo ahí puede explicar por qué un destino evita un proxy configurado de otro modo.
Este asignador usa HTTP CONNECT. Su URI de proxy documentado espera un esquema HTTP; un servicio gRPC protegido con TLS no requiere por sí mismo un extremo de proxy protegido con TLS. Compruebe la autenticación admitida por separado en lugar de suponer que está disponible cualquier esquema de inicio de sesión del navegador. Para un destino gRPC público donde se permiten intermediarios públicos, la lista de proxies HTTP ofrece candidatos de extremo para el URI de proxy HTTP seleccionado; confirme el acceso al destino y puerto reales de CONNECT.
Una implementación de gRPC en Java, Go, JavaScript u otro lenguaje puede tener código de transporte y configuración distintos. No aplique una lista de variables de C-Core como regla universal a todo lo que se llama gRPC.
Para un canal fallido, conserve el proxy seleccionado, la decisión de omisión, el destino y la etapa del error. Una API HTTP accesible desde otro cliente no demuestra que este asignador usara los mismos ajustes ni que el proxy permita el destino CONNECT requerido.