Firebase Admin Node httpAgent: покрытие прокси по сервисам
Определите, какие операции Firebase Admin Node используют настроенный HTTP-агент, прежде чем предполагать, что весь трафик SDK идёт через один и тот же прокси.
Вызов аутентификации работает через прокси, а соединение с базой данных завершается ошибкой. В приложении Firebase это может быть разница в транспорте, а не периодически пропадающий прокси.
Параметр приложения httpAgent в Admin Node SDK применяется к сервисам, выполняющим REST-вызовы, включая Auth и Messaging. Его документированная область не включает Realtime Database и Firestore. Объекты учётных данных также имеют собственную конфигурацию агента через соответствующие фабричные методы.
| Сбойная операция | Проверяемая конфигурация |
|---|---|
| Вызов сервиса Admin REST | HTTP-агент приложения |
| Получение токена учётных данных | HTTP-конфигурация объекта учётных данных |
| Соединение с базой данных | Собственная поддержка транспорта клиента базы данных |
Поэтому добавление агента при инициализации не может гарантировать, что каждое последующее соединение пойдёт тем же путём. Запишите сбойный сервис и пункт назначения, прежде чем менять конфигурацию, которая уже работает для другого сервиса.
Старые обсуждения также смешивают инструмент командной строки Firebase с SDK приложений. Исправление в CLI для чтения http_proxy не доказывает, что клиент базы данных внутри вашего процесса Node использует тот же параметр.
Используйте поддерживаемый интерфейс конфигурации для того транспорта, который вам действительно нужен. Исправление вложенной зависимости WebSocket может выглядеть как влияние на одно соединение, тогда как другой путь остаётся неизменным, и затрудняет понимание будущего обновления зависимостей.