Проксі і прыярытэт зменных абыходу ў 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.