Пріоритет змінних проксі та обходу в 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-проксі пропонує кандидатів кінцевих точок для вибраного URI HTTP-проксі; підтвердьте доступ до фактичної цілі CONNECT і порту.
Реалізація gRPC на Java, Go, JavaScript або іншій мові може мати інший транспортний код і конфігурацію. Не застосовуйте список змінних C-Core як універсальне правило до всього, що називається gRPC.
Для каналу, який не вдалося встановити, збережіть вибраний проксі, рішення про обхід, ціль і етап помилки. Доступний HTTP API через інший клієнт не доводить, що цей мапер використав ті самі налаштування або що проксі дозволяє потрібне призначення CONNECT.