Приоритет переменных прокси и обхода в 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.