關於 FCM 訊息

Firebase 雲端通訊 (FCM) 提供多種訊息傳遞選項和功能。本頁資訊旨在協助您瞭解不同類型的 FCM 訊息，以及您可以如何處理這些訊息。

訊息類型

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

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

通知訊息包含一組預先定義的鍵，可供使用者查看。相對地，資料訊息僅包含使用者定義的自訂鍵/值組合。通知訊息可包含選用的資料酬載。這兩種訊息類型的酬載上限皆為 4,096 個位元組，不過從 Firebase 控制台傳送訊息時，會強制執行 1000 個字元的限制。

應用情境 傳送方式
通知訊息 當用戶端應用程式在背景執行時，FCM SDK 會代表用戶端應用程式向使用者顯示訊息。否則，如果應用程式在收到通知時在前景執行，則應用程式的程式碼會決定行為。通知訊息包含一組預先定義的使用者可查看鍵和自訂鍵/值組合的選用資料酬載。

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

    請參閱 顯示通知範例，並傳送要求酬載。

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

如果您希望 FCM SDK 在應用程式於背景執行時自動顯示通知，請使用通知訊息。如要以自己的用戶端應用程式程式碼處理訊息，請使用資料訊息。

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

通知訊息

針對測試或行銷和使用者再次互動，您可以使用 Firebase 控制台傳送通知訊息。Firebase 主控台提供以分析為基礎的 A/B 測試，協助您調整及改善行銷訊息。

如要使用 Admin SDK 或 FCM 通訊協定以程式輔助方式傳送通知訊息，請為 notification 鍵設定一組必要的預先定義鍵/值選項，供使用者在通知訊息中看見的部分使用。例如，以下是即時訊息應用程式中的 JSON 格式通知訊息。使用者應該可以在裝置上看到標題為「葡萄牙 vs. 丹麥」的訊息，以及「非常符合！」的文字：

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

當應用程式在背景執行時，通知訊息會傳送至通知匣。如果是前景中的應用程式，訊息會由回呼函式處理。

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

資料訊息

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

舉例來說，以下是和上述 IM 應用程式中的 JSON 格式訊息，其中資訊封裝在常見的 data 索引鍵中，用戶端應用程式應可解讀內容：

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

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

加密資料訊息

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

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

無論是透過程式或 Firebase 主控台，您都可以傳送包含自訂鍵/值組合選擇酬載的通知訊息。在 通知編輯器中，使用「進階選項」中的「自訂資料」欄位。

收到包含通知和資料酬載的訊息時，應用程式行為取決於應用程式是在背景還是前景運作 (大致上是指收到訊息時是否處於活動狀態)。

  • 在背景執行時，應用程式會在通知匣中收到通知酬載，並且只在使用者輕觸通知時才處理資料酬載。
  • 在前景執行時，應用程式會收到包含兩個可用酬載的訊息物件。

以下是包含 notification 金鑰和 data 鍵的 JSON 格式訊息：

{
  "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 平台和網頁上提供類似的選項。舉例來說，Android 裝置支援 FCM 的 collapse_key、在 Apple 裝置上透過 apns-collapse-id，以及透過 Topic 的 JavaScript/網頁支援「可收合」訊息行為。詳情請參閱本節的說明以及相關參考說明文件。

不可收合且可收合的訊息

「無法收合」訊息表示每則訊息已傳送到裝置。非可收合訊息會提供一些實用內容，而不是向行動應用程式「連線偵測」(ping) 這類可收合的訊息，向行動應用程式連線至伺服器以擷取資料。

無法收合訊息的常見用途包括即時通訊訊息或重要訊息。舉例來說，在即時訊息應用程式中，您會想傳送每則訊息，因為每則訊息的內容都不同。

以 Android 來說，最多只能在未收合的情況下儲存 100 則訊息。如果達到上限，所有儲存的訊息都會遭到捨棄。裝置恢復連線後，就會收到已達到上限的特別訊息。接著，應用程式即可正確處理這個情況，通常是透過應用程式伺服器要求完整同步處理。

「可收合訊息」是尚未送達裝置的訊息，可能會以新訊息取代。

可收合訊息的常見用途是告知行動應用程式，以便同步處理伺服器中的資料。例如，運動應用程式會以最新分數更新使用者。 只有最新訊息相關。

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

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

我該使用下列何者？

如果應用程式不需要使用不可收合的訊息，就更適合從效能的角度選用可收合訊息。不過提醒您，如果您使用可收合的訊息，每個註冊權杖一次最多只能供 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，螢幕就會開啟且沒有節流限制，訊息會立即傳送。

如果裝置已連線，但是使用的是打盹功能，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 萬則訊息的預設配額為每分鐘 60 萬則訊息，涵蓋超過 99% 的 FCM 開發人員，同時兼顧系統的穩定性，並盡可能降低激增專案的影響。

異常流量模式可能導致超出配額錯誤。在這個超出配額的情況下，系統會放送 HTTP 狀態碼 429 (QUOTA_EXCEEDED)，直到在接下來的一分鐘中補充配額。在超載的情況下，系統也可能會傳回 429 回應，因此我們強烈建議您根據已發布的建議處理 429 錯誤。

注意事項：

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

監控配額

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

  1. 前往 Google Cloud 控制台。
  2. 選取「API 和服務」。
  3. 在表格中選取「Firebase Cloud Messaging API」。

注意：這些圖表並非準確且與配額分鐘數一致，因此當流量低於配額時，也可能會提供 429 秒的資料。

申請提高配額

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

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

如果您符合這些條件，最多可提交增加 25% 的配額申請，FCM 會盡力滿足這項要求 (無法保證能提高)。

由於即將發生啟動或暫時性事件，如果您需要取得更多下游訊息傳遞配額，請至少提前 15 天申請配額，這樣有充裕的時間能處理要求。如為大型要求 (每分鐘超過 1,800 萬則訊息)，則需要至少提前 30 天發出通知。啟動和特殊事件要求仍必須符合用戶端錯誤率和最佳做法要求。

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

主題訊息數量上限

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

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

擴散傳遞熱量

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

訊息擴散功能不會立即傳送，因此有時您會同時有多個粉絲群。每個專案的並行訊息散播數量上限為 1,000 個。之後，我們可能會拒絕其他擴散要求，或延遲擴散要求，直到部分正在的擴散作業完成為止。

實際可達成的擴散率會受到同時要求擴散的專案數量影響。單一專案 10,000 QPS 的擴散率並不常見，但這個數字並非保證，而是系統總負載的結果。請注意，可用的擴散容量會分配給各個專案，而非擴散要求。因此，如果您的專案有兩個進行中的擴散傳遞，則每個擴散傳遞只會看到一半的擴散率。如要盡可能提高粉絲群的速度，建議方法是一次僅有一個有效的擴散傳遞作業。

可收合訊息節流

如上所述，可收合的訊息屬於無內容通知，其設計為相互收合。如果開發人員過於頻繁地將相同訊息傳送至應用程式，我們會延遲 (節流) 訊息，降低對使用者電池造成的影響。

舉例來說，假如您將大量的新電子郵件同步要求傳送至單一裝置，我們可能會將下一次的電子郵件同步要求延遲幾分鐘，讓裝置能以較低的平均速率進行同步處理。這項節流會嚴格執行，以限制使用者耗用的電池影響。

如果您的用途需要高爆發模式的傳送模式，則不可收合的訊息可能是合適的選擇。對於這類訊息，請務必在這類訊息中加入內容，以降低電池成本。

我們限制了可收合訊息，每個應用程式最多可在每部裝置上傳送 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，因為我們的 IP 範圍變動頻率過高，而防火牆規則有可能過期，進而影響使用者體驗。最好在沒有 IP 限制的情況下，將通訊埠 5228-5230 和 443 加入許可清單。不過，如果您必須具有 IP 限制，建議您將 goog.json 中列出的所有 IP 位址加入許可清單。這份大型清單會定期更新，建議您每月更新規則。防火牆 IP 限製造成的問題經常間歇性且難以診斷。

我們也提供一組可加入許可清單 (而非 IP 位址) 的網域名稱。這些主機名稱已列於下方。如果我們開始使用其他主機名稱，就會更新這裡的清單在防火牆規則中使用網域名稱不一定適用於您的防火牆裝置。

要開啟的 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)，請為通訊埠 5228-5230 上的連線實作 30 分鐘以上的逾時。如此一來，我們便能提供可靠的連線能力，同時減少使用者行動裝置的耗電量。

VPN 互動和略過性

Firebase 雲端通訊會採取多項步驟，確保從手機到伺服器的推送訊息連線穩定且盡可能頻繁可用。使用 VPN 會變得複雜

VPN 會遮蓋 FCM 調整連線所需的基本資訊，盡可能提升穩定性和電池續航力。在某些情況下，VPN 會主動中斷長期連線，導致錯過或延遲的訊息，或耗用大量電力，導致使用者體驗不佳。當 VPN 設定為允許連線時，我們會使用加密連線 (透過基本網路 Wi-Fi 或 LTE) 略過 VPN，以便提供可靠、電池穩定的服務。FCM 對略過 VPN 的用法僅限於 FCM 推播通知管道。其他 FCM 流量 (例如註冊流量) 則會使用 VPN (如果已啟用的話)。FCM 連線略過 VPN 後，就無法享有 VPN 提供的額外優勢，例如 IP 遮罩。

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

若未設定略過 VPN，Firebase 雲端通訊將使用 VPN 網路連線至伺服器。這可能會導致訊息延遲一段時間，並有可能增加電池用量，因為雲端通訊是設法透過 VPN 連線維持連線。

憑證

視您實作的 FCM 功能而定，可能需要 Firebase 專案中的下列憑證：

專案 ID Firebase 專案的專屬 ID，用於向 FCM v1 HTTP 端點的要求。您可以前往 Firebase 控制台的「設定」窗格，查看這個值。
註冊權杖

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

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

重要事項：請勿將伺服器金鑰加進用戶端程式碼中的任何位置。此外，請確保僅使用伺服器金鑰來授權應用程式伺服器。Android、Apple 平台和瀏覽器金鑰會遭到 FCM 拒絕。