Приоритет на прокси и бајпас променливите во 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 шема; gRPC услуга заштитена со TLS сама по себе не бара прокси крајна точка заштитена со TLS. Проверете ја поддржаната автентикација одделно наместо да претпоставите дека е достапна која било шема за најава во прелистувач. За јавна gRPC цел каде што се дозволени јавни посредници, листата со HTTP проксија нуди кандидати за крајни точки за избраниот HTTP прокси URI; потврдете пристап до вистинската CONNECT цел и порта.
Имплементација на gRPC во Java, Go, JavaScript или друг јазик може да има поинаков транспортен код и конфигурација. Не применувајте ја листата со C-Core променливи како универзално правило за сè што се нарекува gRPC.
За неуспешен канал, задржете го избраниот прокси, одлуката за бајпас, целта и фазата на грешката. Достапно HTTP API преку друг клиент не докажува дека овој мапер ги користел истите поставки или дека проксито ја дозволува потребната CONNECT дестинација.