Firebase Admin Node httpAgent: proxy-täckning per tjänst
Fastställ vilka Firebase Admin Node-åtgärder som använder den konfigurerade HTTP-agenten innan du antar att all SDK-trafik använder samma proxy.
Ett autentiseringsanrop fungerar via proxyn, men en databasanslutning misslyckas. I ett Firebase-program kan det vara en transportskillnad snarare än en tillfällig proxy.
Programalternativet httpAgent i Admin Node SDK gäller tjänster som gör REST-anrop, bland annat Auth och Messaging. Dess dokumenterade omfattning utesluter Realtime Database och Firestore. Även autentiseringsuppgiftsobjekt har sin egen agentkonfiguration via motsvarande fabriksmetoder.
| Misslyckad åtgärd | Konfiguration att granska |
|---|---|
| Ett Admin REST-tjänsteanrop | Programmets HTTP-agent |
| Hämtning av en autentiseringstoken | HTTP-konfigurationen för autentiseringsuppgiftsobjektet |
| En databasanslutning | Databasklientens eget transportstöd |
Därför kan ett tillägg av en agent vid initiering inte garantera att varje senare anslutning tar samma väg. Notera den misslyckade tjänsten och destinationen innan du ändrar en konfiguration som redan fungerar för en annan tjänst.
Äldre diskussioner blandar också Firebases kommandoradsverktyg med program-SDK:er. En CLI-rättelse för att läsa http_proxy bevisar inte att en databasklient i din Node-process använder samma alternativ.
Använd det stödda konfigurationsgränssnittet för den transport du faktiskt behöver. Att patcha ett inbäddat WebSocket-beroende kan se ut att påverka en anslutning medan en annan väg förblir oförändrad, och det gör en framtida beroendeuppdatering svårare att förstå.