關於 FCM 訊息

Firebase 雲端通訊 (FCM) 提供多種訊息傳遞選項 和功能本頁資訊的用途是 協助您瞭解不同類型的 FCM 訊息，以及 以及他們可以運用的

訊息類型

透過 FCM，您可以傳送兩種類型的訊息給客戶：

  • 通知訊息，有時可視為「顯示訊息」。這些都會由 FCM SDK 自動處理。
  • 資料訊息由用戶端應用程式處理。

通知訊息包含一組預先定義的鍵，可供使用者查看。 相對地，資料訊息只包含使用者定義的自訂鍵/值 配對。通知訊息可包含選用欄位 資料酬載這兩種訊息類型的酬載上限為 4096 個位元組，除非 從 Firebase 控制台傳送訊息，強制執行 1, 000 個半形字元 我們會自動向帳單帳戶扣款 並每月或在您達到用量上限時發送帳單

應用情境 傳送方式
通知訊息 FCM SDK 會在使用者裝置上顯示訊息 代表用戶端應用程式在背景執行時。 在其他情況下，如果應用程式的運作時間在前景運作， 應用程式的程式碼會決定其行為。 通知訊息包含一組預先定義的鍵，以及一組使用者可見的鍵 自訂鍵/值組合的選用資料酬載。

  1. 在受信任的環境，例如 Cloud Functions 或應用程式伺服器 Admin SDK 或 HTTP v1 API。設定 notification 鍵。 可能具有選用的資料酬載。一律可收合。

    查看 顯示通知和傳送要求酬載的範例。

  2. 使用 通知撰寫者：輸入訊息文字、標題等，然後傳送。 提供自訂資料來新增選用資料酬載。
資料訊息 用戶端應用程式負責處理資料訊息。資料訊息 只有不含保留鍵名稱的自訂鍵/值組合 (請見下方說明)。 在 這類信任的環境中 Cloud Functions 或應用程式伺服器 Admin SDK 或 FCM 伺服器通訊協定。在傳送要求中，設定 data 鍵。

在希望 FCM SDK 處理顯示畫面時使用通知訊息 每當您的應用程式在背景執行時，就會自動通知您。 如要與 或自己的用戶端應用程式碼

FCM 可傳送通知訊息，其中包含選用資料 酬載。在這種情況下，FCM 會負責顯示通知 酬載，而用戶端應用程式則會處理資料酬載。

通知訊息

若是測試或行銷和使用者再參與，您可以傳送 通知訊息 Firebase 控制台提供以數據分析為基礎的功能 A/B 測試 改善行銷訊息

如要使用 Admin SDK 或 FCM 通訊協定，請使用以下引數設定 notification 金鑰： 提供一組必要的預先定義鍵/值選項，以供使用者查看 部分通知訊息舉例而言，這裡的例子是 JSON 格式 通知訊息使用者預期能看到 標題為「葡萄牙對丹麥」的訊息以及文字 「非常相符！」應用程式：

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

在應用程式啟用後，系統會將通知訊息傳送到通知匣 都是在背景執行如果是前景應用程式，訊息會由以下應用程式處理： 回呼函式。

請參閱 HTTP v1 通訊協定通知物件。 參考文件 ，瞭解可用於建構通知的完整預先定義鍵清單 訊息。

資料訊息

為您的自訂鍵/值組合設定適當的鍵，以便： 將資料酬載傳送至用戶端應用程式

舉例來說 JSON 格式的訊息 (位於與上述相同的 IM 應用程式中) 資訊封裝在通用 data 索引鍵中 用戶端應用程式才能解讀內容：

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    }
  }
}

上述範例顯示頂層或常見的 data 欄位用法。 這會由所有收到該訊息的平台上的客戶解譯。 在每個平台上，用戶端應用程式都會收到資料酬載 回呼函式。

加密資料訊息

Android 傳輸層 (請參閱 FCM 架構)。 採用點對點加密技術視您的 您可以視需求決定是否要為資料訊息加入端對端加密。 FCM 未提供端對端解決方案。 不過，您也可以使用外部解決方案 如 Capillary 或 DTLS。

含有選用資料酬載的通知訊息

透過程式或 Firebase 控制台，您可以傳送通知 的訊息，其中包含自訂鍵/值組合的選用酬載。於 通知編輯器，請使用以下位置中的自訂資料欄位： 進階選項。

接收包含通知和資料訊息時的應用程式行為 取決於應用程式是在背景執行，還是 基本上，不論應用程式當時是否處於啟用狀態 收據。

  • 在 背景，應用程式就會在 通知匣，並只在使用者情況下處理資料酬載 輕觸通知。
  • 在前景執行時，應用程式會收到訊息 具有兩個酬載可用的物件

以下是 JSON 格式的訊息 notification 鍵和 data 鍵：

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

自訂所有平台的訊息

Firebase Admin SDK 和 FCM v1 HTTP 通訊協定都能允許您的訊息 要求設定所有可用欄位 message敬上 物件。這包括：

  • 一組常用欄位，可供「所有」應用程式執行個體解譯 接收訊息。
  • 平台專屬欄位組合，例如 AndroidConfig 和 WebpushConfig 只由在指定平台上運作的應用程式執行個體解譯

平台特定區塊可讓您靈活自訂 以確保能在收到更新時正確處理 FCM 後端會將所有指定的參數納入考量，然後自訂 訊息。

使用常用欄位的時機

如有下列情況，請使用常用欄位：

  • 指定所有平台上的應用程式執行個體 (Apple、Android 和網頁)
  • 傳送訊息至主題

所有應用程式執行個體 (無論平台為何) 都可以解讀下列常見元素 欄位：

使用平台專屬欄位的時機

使用平台專屬欄位執行下列操作：

  • 僅將欄位傳送至特定平台
  • 除了常用欄位以外，也傳送平台專屬欄位

如果您只想將值傳送到特定平台，請不要使用 常用欄位；使用平台專屬欄位例如傳送通知 只能在 Apple 平台和網路上使用，而不適用於 Android 平台，您 欄位，一個用於 Apple，另一個用於網頁。

您傳送的特定訊息 配送選項 就必須使用平台專屬的欄位來設定這些欄位 您可以為每個平台指定不同的值 您期望的行為但即使您想為各個群組 平台，您必須使用平台專屬欄位。這是因為每個平台 這個值可能無法以略有方式解讀 在 Android 裝置上設為到期時間 (以秒為單位)，在 Apple 上則設為 到期日。

範例：含有平台特定傳送選項的通知訊息

下列 v1 要求會傳送常用通知標題和 同時傳送部分平台專屬覆寫內容 具體來說，要求如下：

  • 為 Android 和 Web 平台設定較長的存留時間，同時將 APN (Apple 平台) 訊息優先順序設為低設定
  • 設定適當的按鍵，定義使用者在 Android 和 Apple 上輕觸通知的結果：分別為 click_action 和 category。
{
  "message":{
     "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
     "notification":{
       "title":"Match update",
       "body":"Arsenal goal in added time, score is now 3-0"
     },
     "android":{
       "ttl":"86400s",
       "notification"{
         "click_action":"OPEN_ACTIVITY_1"
       }
     },
     "apns": {
       "headers": {
         "apns-priority": "5",
       },
       "payload": {
         "aps": {
           "category": "NEW_MESSAGE_CATEGORY"
         }
       }
     },
     "webpush":{
       "headers":{
         "TTL":"86400"
       }
     }
   }
 }

請參閱 HTTP v1 參考文件。 以便完整瞭解 在訊息內文中加入特定平台的區塊如要進一步瞭解 建構傳送要求，內含訊息內文；請參閱 建構傳送要求。

外送選項

FCM 針對傳送至以下服務的郵件提供特定一組特定傳送選項 Android 裝置，也允許使用者在 Apple 平台和網路。例如「可收合」支援 在 Apple 裝置上透過 FCM collapse_key 使用 Android 裝置 apns-collapse-id 以及在 JavaScript/網頁上透過 Topic 存取。詳情請參閱 說明及參考文件

不可收合且可收合的訊息

不可收合的訊息表示每封郵件都有 傳送到裝置。非可收合的訊息能提供 而不是提供可收合的訊息，像是無內容的「連線偵測」到 以便與伺服器連線以擷取資料。

無法收合訊息的常見用途包括即時通訊訊息或 重要的訊息。 以即時訊息應用程式為例，您應該會想傳遞所有訊息，因為 每則訊息的內容都不同

如果是 Android 系統，最多只能儲存 100 則訊息 收合。如果 達到上限，所有儲存的訊息都會遭到捨棄。裝置重新開機時 便會收到一則特別訊息，說明已達到上限 接著，應用程式就能妥善處理情況，通常是透過要求 從應用程式伺服器同步處理

可收合訊息是一種可以由 新訊息。

可收合訊息的常見用途是判斷訊息 用來同步處理伺服器資料的行動應用程式。一個 例如將運動應用程式更新為最新得分的運動應用程式 只有最新訊息相關。

如要在 Android 裝置上將郵件標示為可收合，請加入 collapse_key 參數位於 訊息酬載根據預設，收合鍵為應用程式套件名稱 在 Firebase 控制台註冊。FCM 伺服器可以 需要同時儲存四則可收合的訊息 每個裝置的收合鍵，且各有不同的收合鍵。如果超過這個上限， 僅限 FCM 保留 四個收合鍵，無法保證保留哪些鍵。

根據預設，沒有酬載的主題訊息可收合。通知訊息 一律可收合，且會忽略 collapse_key 參數。

我該使用下列何者？

從效能的角度來看，可收合訊息更理想 前提是您的應用程式不需要使用不可收合的訊息。不過 使用可收合訊息時 FCM 最多只能使用四個不同的收合鍵 按 FCM 劃分 註冊權杖不得超過這個數字 可能會導致無法預期的結果

應用情境 傳送方式
不可收合 每則訊息對用戶端應用程式來說都很重要，因此必須 廣告放送。 除了通知訊息之外，凡是 預設值。
可折疊 出現較新的訊息，並顯示較舊相關訊息時 與用戶端應用程式無關，FCM 會取代舊訊息。 例如： 或過期的訊息，用來從伺服器啟動資料同步處理作業 通知訊息 請在訊息要求中設定適當的參數：
  • collapseKey (Android)
  • Apple 的「apns-collapse-id」
  • 網頁版 Topic
  • 舊版通訊協定中的 collapse_key (所有平台)

設定郵件優先順序

為下游郵件指定放送優先順序的方式有兩種： 一般優先順序與高優先順序雖然 平台、正常與高優先順序訊息的傳送作業 輸入：

  • 一般優先順序。 當應用程式位於以下位置時，系統會立即傳送一般優先順序的郵件 前景。如果是在背景執行的應用程式，供應資料 延遲時間。適用於較不具時效性的郵件，例如 接收新電子郵件的通知、保持 UI 同步，或在應用程式中同步應用程式資料 選擇「一般放送優先順序」

  • 高優先順序，FCM 會嘗試放送高優先順序 訊息。 高優先順序的郵件通常具有時效性，而且可供使用者查看。

以下是透過 FCM 傳送的一般優先順序郵件範例 透過 HTTP v1 通訊協定通知雜誌 有可供下載的新內容：

{
  "message":{
    "topic":"subscriber-updates",
    "notification":{
      "body" : "This week's edition is now available.",
      "title" : "NewsMagazine.com",
    },
    "data" : {
      "volume" : "3.21.15",
      "contents" : "http://www.news-magazine.com/world-week/21659772"
    },
    "android":{
      "priority":"normal"
    },
    "apns":{
      "headers":{
        "apns-priority":"5"
      }
    },
    "webpush": {
      "headers": {
        "Urgency": "high"
      }
    }
  }
}

如需更多關於平台設定訊息優先順序的詳細資訊：

設定訊息的效期

FCM 通常會在訊息送出後立即傳送， 不過，這個程序不一定有辦法執行。舉例來說，如果平台是 Android、裝置可能已關機、處於離線狀態或無法使用。 或者 FCM 可能會刻意延遲訊息 避免應用程式耗用過多資源 影響電池續航力

此時，FCM 會儲存訊息並盡快傳送 然後盡可能安排時間這在大部分情況下是正常的， 也就是說，遲到的訊息可能永遠 無法傳送舉例來說， 訊息是來電或視訊通訊通知，只有意義 等候一小段時間，通話就會終止。或者訊息是 建立活動邀請時，如果活動結束後收到邀請，活動就會失敗。

在 Android 和網頁/JavaScript 上，您可以指定 撰寫新的電子郵件訊息這個值必須是介於 0 至 2,419,200 秒 (28) 之間的時間長度 天) 的值，且對應至 FCM 作業的時間長度上限 儲存與嘗試傳送訊息不含此項目的要求 欄位的預設值是四週的最長期間。

以下是這項功能可能的用途：

  • 視訊通訊來電
  • 邀請活動即將到期
  • 日曆活動

指定訊息效期還有一個好處 FCM 無法在含有 存留時間值 (0 秒) FCM 會盡可能處理那些必須 狀態會「現在或從未」請注意， time_to_live值： 0 代表無法立即傳送的郵件遭到捨棄。不過 因為系統不會儲存這類訊息，因此可將 傳送通知訊息。

以下是包含存留時間的要求範例：

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    },
    "apns":{
      "headers":{
        "apns-expiration":"1604750400"
      }
    },
    "android":{
      "ttl":"4500s"
    },
    "webpush":{
      "headers":{
        "TTL":"4500"
      }
    }
  }
}

訊息的生命週期

應用程式伺服器將訊息發布到 FCM 並收到訊息時 ID 傳回，不表示訊息已傳送至 裝置。而是表示訂單已接受交付。會發生的情況 訊息在接受後取決於許多因素。

在最理想的情況下，如果裝置已連接到 FCM， 如果螢幕已開啟且沒有節流限制， 立即配送。

如果裝置處於「打盹」狀態卻處於「打盹」模式，系統就會儲存優先順序較低的訊息 。且 這時 collapse_key 旗標就派上用場了：如果有 已經儲存含有相同收合金鑰 (和註冊權杖) 的訊息 並等待 郵件傳送後，舊郵件會遭到捨棄，新訊息也要改寫 (舊訊息會由新郵件收合)。不過，如果廣告處於收合狀態 金鑰未設定，新舊郵件都會儲存以供日後傳送。

如果裝置未連上 FCM，訊息的儲存期限為 建立連線 (同樣遵循收合鍵規則)。如果 建立連線後，FCM 會將所有待傳送的訊息 裝置。如果裝置一直無法連線 (例如恢復原廠設定)，訊息最終會逾時， 就會從 FCM 儲存空間捨棄。預設逾時為四週 除非設定了 time_to_live 標記。

如何深入瞭解訊息的傳送情形：

    如要深入瞭解如何在 Android 或 Apple 平台上傳送訊息，請參閱 FCM 報表資訊主頁，其中記錄 透過 Apple 和 Android 裝置傳送及開啟的訊息數量，以及 「曝光」資料Android 應用程式 (使用者看到的通知)。

針對已啟用直接頻道訊息功能的 Android 裝置，如果 裝置已超過一個月未連線至 FCM。 FCM 仍會接受訊息，但會立即捨棄訊息。如果 裝置會在您上次傳送的資料訊息後四週內連線 您的用戶端會收到 onDeletedMessages() 回呼。 接著，應用程式就能妥善處理情況，通常是透過要求 從應用程式伺服器同步處理

最後，FCM 會嘗試將訊息傳送到裝置 解除安裝應用程式後，FCM 會立即捨棄該訊息， 會導致註冊憑證失效。日後會嘗試傳送訊息 裝置會導致 NotRegistered 錯誤。

節流與配額

我們的目標是一律傳送所有透過 FCM 傳送的訊息。不過 傳送每則郵件有時會導致整體使用者體驗不佳。 在其他情況下，我們需要提供界線，以確保 FCM 能夠提供 可擴充的服務上述限制的類型與配額 能協助我們平衡這些重要因素

下游訊息節流

HTTP v1 API 以專案為單位，針對下游導入每分鐘配額 傳送訊息每分鐘 60 萬則訊息的預設配額涵蓋超過 99% FCM 開發人員同時確保系統穩定性和 將高聳專案造成的影響降到最低。

異常流量模式 以免超出配額錯誤超過配額上限 情境中，系統會提供 HTTP 狀態碼 429 (QUOTA_EXCEEDED)，直到 系統會在一分鐘內補充配額。而 429 回應也會傳回 超載的情況，所以我們強烈建議您根據 發布建議。

注意事項：

  • 下游配額測量的是訊息，而非要求。
  • 用戶端錯誤 (HTTP 狀態碼 400 到 499) 會列入計算 (不含 429)。
  • 配額是以分鐘為單位，但這些分鐘數與時針不一致。

監控配額

您可以在 Google Cloud 控制台中查看配額、用量和錯誤：

  1. 前往 Google Cloud 控制台。
  2. 選取「API 與」服務
  3. 在表格中選取「Firebase Cloud Messaging API」。
  4. 選取「配額與系統限制：

注意：這些圖表並非與配額分鐘數精確一致， 如果流量似乎低於配額，系統可能會放送 429 錯誤。

申請提高配額

要求提高配額之前，請確認下列事項：

  • 您的用量會定期至少連續 5 分鐘達到 80% 的配額量 每天。
  • 您可以在5% 用戶端錯誤率，尤其是在流量高峰期間。
  • 您遵守大量傳送訊息的最佳做法。

如果您符合這些條件，即可提出配額提高要求，最多可申請 +25% 和 FCM 將盡力滿足要求 但不保證能提高。

隨著即將上線，如果您需要更多下游訊息配額，或 為臨時性活動，請至少提前 15 天申請配額，以利系統進行這項作業 有足夠的時間處理要求針對大型要求 (每分鐘超過 1,800 萬則訊息)，至少 需要提前 30 天通知。產品上市和特殊活動要求都仍處於上線狀態 並遵循用戶端錯誤率和最佳做法規定。

另請參閱 FCM 配額的常見問題。

主題訊息數量上限

主題訂閱新增/移除率的上限為每項專案 3,000 QPS。

如需查看訊息傳送率，請參閱跳轉調節。

擴散傳遞熱量

訊息擴散功能是指將訊息傳送到多部裝置的程序，例如 指定主題和群組或搭配使用 通知編輯器 指定目標對像或使用者區隔

訊息傳送功能不會立即傳送，因此您偶爾會 同時進行擴散傳遞作業。我們對並行訊息的數量 每項專案各有 1,000 的傳遞流量。之後我們可能會拒絕其他擴散傳遞要求 也可以延後傳遞要求，直到處理已 擴散傳遞程序完成。

實際可達成的擴散率會受到專案數量的影響 同時要求擴散傳遞網路。每秒查詢 10,000 次的擴散率 儘管個別專案並沒有罕見，但這個數字並非保證， 將對系統造成的負擔請特別注意 可用的擴散器容量會分配給專案，而非擴散傳遞資料 要求。因此，如果專案有兩個擴散傳遞作業，則每個擴散傳遞群 則只能看到可用風扇率的一半若要盡量提高 風扇速度是指一次只能進行一個啟用的擴散傳遞作業。

可收合訊息節流

如上所述，可收合的訊息屬於無內容通知， 即可收合如果開發人員重複 太常發送訊息給應用程式，我們會延遲 (節流) 訊息，以減少 以及可能對使用者電池 造成的影響

舉例來說，假設您傳送大量新的電子郵件同步要求至單一 裝置，我們可能會將下一次電子郵件同步要求延後幾分鐘， 裝置能以較低的平均速率同步。這項調節措施會嚴格執行， 減少使用者遇到的電池影響

如果您的應用情境需要高強度的傳送模式，則不可收合的郵件可能 做出正確的選擇對於此類郵件，請務必在 以降低電池成本

每個應用程式只能有 20 則可收合訊息，且每個應用程式只能顯示 20 則訊息， 每 3 分鐘補充 1 則訊息。

XMPP 伺服器節流

我們限制您連線到 FCM XMPP 伺服器的頻率，上限為 400 個 每項專案的每分鐘配額這應該不會是郵件傳送時發生的問題，但 確保系統穩定性至關重要每項專案 FCM 允許並行 2500 個連線。

針對使用 XMPP 的上游訊息，FCM 限制 每分鐘 1,500,000 次上游訊息 以避免超載上游目的地伺服器。

為防止電池效能，每個裝置每分鐘的上游訊息次數會限制在每分鐘 1,000 次 並排除不良的應用程式行為

單一裝置的訊息傳送頻率上限

以 Android 裝置來說，您每分鐘最多可傳送 240 則訊息，每小時最多傳送 5,000 則訊息至單一訊息 裝置。這個高門檻的用意是方便短期流量暴增 例如使用者在聊天室中快速互動的情況這項限制可避免發生錯誤 避免不慎消耗裝置電量

針對 iOS 裝置，系統會在速率超過 APN 限制時傳回錯誤。

FCM 通訊埠和防火牆

如果貴機構設有防火牆 您必須將其設為允許行動裝置 才能使用 FCM 接收訊息。 FCM 通常使用通訊埠 5228，但有時會使用 443、5229 和 5230。

如果是透過你網路連線的裝置，FCM 無法提供 因為我們的 IP 範圍太常變更，您的防火牆規則也會發生問題 版本可能會過時，連帶影響到無須專人管理在理想情況下 通訊埠 5228-5230443，沒有 IP 限制。不過，前提是必須提供 IP 位址 限制，請將 goog.json 中列出的所有 IP 位址加入許可清單。 這份大型清單會定期更新， 每月定期執行規則造成問題的可能原因 防火牆 IP 限制通常交錯且難以診斷。

我們也提供一組可加入許可清單 (而非 IP) 的網域名稱 讓我們看看 DNS 解析 進一步探索內部和外部位址這些主機名稱已列於下方。如果我們開始使用 主機名稱，系統就會更新這裡的清單為防火牆使用網域名稱 規則不一定會在防火牆裝置中運作。

要開啟的 TCP 通訊埠：

  • 5228
  • 5229
  • 5230
  • 443

要開啟的主機名稱：

  • mtalk.google.com
  • mtalk4.google.com
  • mtalk-staging.google.com
  • mtalk-dev.google.com
  • alt1-mtalk.google.com
  • alt2-mtalk.google.com
  • alt3-mtalk.google.com
  • alt4-mtalk.google.com
  • alt5-mtalk.google.com
  • alt6-mtalk.google.com
  • alt7-mtalk.google.com
  • alt8-mtalk.google.com
  • android.apis.google.com
  • device-provisioning.googleapis.com
  • firebaseinstallations.googleapis.com

網路位址轉譯和/或有狀態封包檢查防火牆：

如果您的網路實作網路位址轉譯 (NAT) 或有狀態封包 檢查 (SPI)，實作 30 分鐘或更長時間的逾時 通訊埠 5228-5230這讓我們可以提供 同時減少使用者手機 裝置。

VPN 互動和略過性

Firebase 雲端通訊採取多項步驟，確保推送訊息 連線與伺服器之間的連線相當穩定，而且連線頻繁 使用 VPN 會變得複雜

VPN 會遮蓋 FCM 需要調整的基礎資訊 以盡可能提升穩定性電池續航力。在某些情況下，VPN 會主動 中斷長期連線，導致使用者因錯過或失敗 延遲顯示訊息，或導致電池耗電過高如果 VPN 設定允許 我們使用加密連線 (透過基本網路) 略過 VPN 例如 Wi-Fi 或 LTE)。 無須專人管理FCM 對略過 VPN 的使用方式 FCM 推播通知管道。其他 FCM 流量，例如 註冊流量也會使用 VPN (如果已啟用)。FCM 通知後 連線略過 VPN 也不會享有 VPN 提供的額外好處 例如 IP 遮蓋

不同 VPN 能使用不同方法，控制是否 才能被略過如需操作說明，請參閱該 VPN 的說明文件。

如果未設定略過 VPN，Firebase 雲端通訊將 請使用 VPN 網路連線至伺服器這可能會導致 郵件延遲一段時間且可能增加耗電量 雲端通訊的用量，以便維持 VPN 的連線 以獲得最佳效能和最安全的連線

憑證

視您實作的 FCM 功能而定，您可能需要使用 擷取自 Firebase 專案中的憑證：

專案 ID Firebase 專案的專屬 ID，用來向 FCM v1 HTTP 端點。此值為 於 中提供 Firebase 控制台的「設定」窗格。
註冊權杖

識別每個用戶端應用程式執行個體的專屬權杖字串。 必須為單一裝置和裝置提供註冊權杖 群組訊息。請注意， 註冊權杖必須保密。
寄件者 ID 您在建立 Firebase 專案時建立的專屬數值。 於 中提供 Firebase 控制台的「雲端通訊」分頁 「設定」窗格。傳送者 ID 可用來識別 傳送訊息到用戶端應用程式。
存取權杖 一種短期 OAuth 2.0 憑證，可授權對 HTTP v1 的要求 也能使用 Google Cloud CLI 或 Compute Engine API這個權杖與屬於 您的 Firebase 專案。如要建立及輪替存取權杖，請按照 所述步驟 授權傳送要求。
伺服器金鑰 (適用於 **已淘汰** 的舊版通訊協定)

伺服器 授權應用程式伺服器 存取 Google 服務，包括透過 已淘汰的 Firebase 雲端通訊 舊版通訊協定

重要事項：請勿在 用戶端程式碼。另外，請僅使用伺服器金鑰來驗證您的 應用程式伺服器Android、Apple 平台和瀏覽器金鑰的拒絕依據如下： FCM。