Приоритет на прокси и байпас променливите в gRPC C-Core
Проследете приоритета на прокси и байпаса в gRPC Core, без да предполагате, че друга реализация на gRPC използва същия мапер.
Промяната на http_proxy може да не направи нищо, ако вече има настройка на gRPC с по-висок приоритет. Започнете с идентифициране на реализацията: следното поведение принадлежи на мапера по подразбиране за HTTP прокси на gRPC C-Core и на зависимите от него компоненти.
Маперът проверява аргумента за прокси на канала, после grpc_proxy, после https_proxy, после http_proxy и спира при първата зададена стойност.
Откриването на байпас има свой собствен ред: no_grpc_proxy има предимство пред no_proxy. Стара стойност там може да обясни защо дадена цел заобикаля иначе зададено прокси.
Този мапер използва HTTP CONNECT. Документираният му URI за прокси очаква схема HTTP; защитена с TLS услуга на gRPC сама по себе си не изисква защитена с TLS крайна точка на прокси. Проверявайте поддържаната автентикация отделно, вместо да предполагате, че е налична каквато и да е схема за вход в браузър. За публична цел на gRPC, при която са разрешени публични посредници, списъка с HTTP проксита предлага кандидати за крайни точки за избрания URI на HTTP прокси; потвърдете достъпа до действителната цел на CONNECT и порта.
Реализация на gRPC на Java, Go, JavaScript или друг език може да има различен транспортен код и конфигурация. Не прилагайте списъка с променливи на C-Core като универсално правило за всичко, наречено gRPC.
При неуспешен канал запазете избраното прокси, решението за байпас, целта и етапа на грешката. Достъпен HTTP API през друг клиент не доказва, че този мапер е използвал същите настройки или че проксито разрешава необходимата дестинация за CONNECT.