gRPC C-Core의 프록시 및 바이패스 변수 우선순위
다른 gRPC 구현이 같은 매퍼를 쓴다고 가정하지 않고 gRPC 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 목적지를 허용한다는 것을 증명하지 않습니다.