Azure Front Door 常見問題（FAQ）

Azure Front Door 是一項雲端服務，能更快且更可靠地交付您的應用程式。 它會使用第 7 層負載平衡，將流量散發到多個區域和端點。 它也提供動態網站加速 (DSA) 來最佳化 Web 效能和近乎即時的容錯移轉，以確保高可用性。 Azure Front Door 是一個完全受控的服務，所以你不用擔心擴展或維護。

Azure Front Door 和 Azure 應用程式閘道 都是用於 HTTP/HTTPS 流量的負載平衡器，但它們的範圍不同。 Front Door 是一項全域服務，可跨區域散發要求，而應用程式閘道是區域服務，可平衡區域內的要求。 Azure Front Door 支援規模單位、叢集或印章單元，而 Azure 應用程式閘道 則支援同一規模單位內的虛擬機、容器或其他資源。

你可以為 Azure Front Door 使用不同類型的起源，例如：

• Storage（Azure Blob、Classic、靜態網站）
• 雲端服務
• App Service
• 靜態 Web 應用程式
• API Management
• 應用程式閘道
• 公用IP位址
• Azure Spring 應用程式
• 容器執行個體
• 容器應用程式
• 具有公用存取的任何自訂主機名稱。

來源必須具有可公開解析的公用 IP 或 DNS 主機名稱。 你可以混合搭配來自不同區域、區域，甚至 Azure 以外的後端，只要它們是公開可存取的。

Azure Front Door 不限於任何 Azure 區域，而是在全球範圍內運作。 建立前門時，你唯一選擇的位置是資源群組的位置，這決定了該資源群組的元資料存放位置。 Front Door 設定檔是全域資源，且其設定會散發到全球所有邊緣位置。

若要查看提供 Azure Front Door 全球負載平衡與內容傳遞的完整接入點（POPs）清單，請參見 Azure Front Door POP 位置。 此清單會隨著新 POP 新增或移除而定期更新。 你也可以使用 Azure Resource Manager API 以程式化方式查詢目前的 POP 清單。

Azure Front Door 是一項服務，能將您的應用程式在全球多個區域分發。 它使用所有客戶共用的公共基礎設施，但你也可以自訂自己的 Front Door 設定檔，以配置應用程式的特定需求。 其他客戶的設定不會影響您的 Front Door 設定，其與他們的設定隔離。

Front Door 不會排序 Web 應用程式的路由。 相反地，它會選擇最符合要求的路由。 若要了解 Front Door 如何比對路由的要求，請參閱 Front Door 比對要求與路由規則的方式。

為確保 Front Door 功能的最佳效能，請僅允許來自 Azure Front Door 的流量到達您的原始來源。 因此，未經授權或惡意的要求會遇到 Front Door 的安全性和路由原則，並遭到拒絕存取。 若要了解如何保護您的來源，請參閱保護 Azure Front Door 來源的流量。

Azure Front Door 和 CDN 設定檔的單一建立、更新、刪除或 WAF 操作的設定傳播時間，可能要花最多 15 分鐘以增加安全性。 一次快取清除操作可在 10 分鐘內完成。 連續的變更可將總部署時間延長至約30分鐘。 每次組態更新，包括規則集調整、路由變更、起點或網域更新，以及 WAF 修改，都被視為全域操作。 如果你在第一個操作仍在傳播中（約 15 分鐘的期間內）時提交其他操作，系統會將這些操作排入佇列，並僅在前一個操作完成後才開始執行。 在此情境下，第一個操作會在最初的 15 分鐘內完成，後續的變更則在下一個視窗內處理。 正在進行的平台增強將進一步縮短這一時間。

提交多個清除要求

每個清除要求最多可以包含 100 個 URL （網域和路徑的組合）。 第一批藥劑經過處理後，約在10分鐘內生效。

如果你有超過 100 個 URL 需要清除，必須等待並確認第一批完成後，才能提交下一批。 如果你在上一批完成前提交新的清除請求，該請求會被拒絕。

範例：清除 256 個 URL

1. 提交初始清除要求中的前 100 個 URL。
2. 等待約10分鐘，確認第一批是否成功完成。
3. 在第二個請求中提交接下來的 101-200 個 URL。
4. 大約等10分鐘，等第二批完成。
5. 在第三個請求中提交剩餘的 201-256 個 URL。

對路由或來源群組/後端集區的更新是無縫順暢的，而且不會造成任何停機 (假設新的設定正確)。 憑證更新也是以原子性方式完成，因此不會停機。

• 你可以在沒有停機的情況下，在資源群組或訂閱之間移動 Front Door Standard/Premium 和 Azure CDN 設定檔。 若要執行移動，請遵循下列指示。
• Azure Front Door（經典版）不支援資源群組或訂閱之間的移動。 你可以先將 Azure Front Door（經典版）設定檔遷移到 Standard/Premium，然後執行遷移。
• 如果你將 WAF 政策與 Azure Front Door Standard 或 Premium 關聯，移動操作就會失敗。 您必須先解除 WAF 原則的關聯，完成移轉，然後再重新關聯該原則。

Azure Front Door 為您的網頁應用程式帶來許多好處，例如動態網站加速（DSA），能提升網站的效能與使用者體驗。 Azure Front Door 也處理 TLS/SSL 卸載與端對端 TLS，提升網站流量的安全性與加密。 此外，Azure Front Door 提供網頁應用程式防火牆、基於 Cookie 的會話親和性、基於 URL 路徑的路由、免費憑證、多域管理等功能。 欲了解更多 Azure Front Door 的功能與能力，請參閱 tier 比較。

Azure Front Door 支援 HTTP、HTTPS 和 HTTP/2。

Azure Front Door 預設支援 HTTP/2 用戶端連線。 未啟用 gRPC 的路由則使用 HTTP/1.1 與來源伺服器進行通訊。 在公開預覽期間，Front Door Standard 與 Premium 中啟用 gRPC 的路由在兩個連線上都使用 HTTPS 和 HTTP/2。 欲了解更多資訊，請參閱 Azure Front Door （preview）中的 gRPC 支援。

是的。 Azure Front Door Standard 和 Premium 在公開預覽中支援原生 gRPC。 啟用路由及其來源群組中所有來源的 gRPC。 HTTPS 和 HTTP/2 是從用戶端到 Front Door，以及從 Front Door 到來源所必需的。 關於配置與預覽限制，請參閱 Azure Front Door （preview）中的 gRPC 支援。

你可以用 Azure Front Door 重定向 URL 的 host、path 和查詢字串元件。 想了解如何設定 URL 重定向，請參見 URL 重定向。

是的。 請參閱 MatchedRulesSetName 下的 屬性。

是的。 欲了解更多資訊，請參閱 Microsoft回應針對 HTTP/2 的 DDoS 攻擊。

否。 Azure Front Door 無法強制客戶端流量到特定的 POP。 請求會被路由到最近的可用邊緣位置，以提升效能與可靠性。 如果你需要依地理位置限制存取，請使用 Azure Web 應用程式防火牆（WAF）自訂規則，條件為 GeoMatch。 這種做法會根據客戶端的國家/地區允許或阻擋請求，但不會將這些客戶端重新導向到其他國家/地區的 POP。 例如，如果您封鎖了國家/地區 A，來自國家/地區 A 的客戶端請求將被阻擋，無論哪個 POP 會為其提供服務。 欲了解更多資訊，請參閱 Azure WAF 在 Azure Front Door 中的地理過濾。

Azure Front Door 支援 X-Forwarded-For、X-Forwarded-Host 及 X-Forwarded-Proto 標頭。 這些標頭可協助 Front Door 識別來源用戶端 IP 和通訊協定。 如果 X-Forwarded-For 已存在，Front Door 會將用戶端通訊端 IP 新增至清單尾端。 否則，它會使用用戶端通訊端 IP 作為值來建立標頭。 針對 X-Forwarded-Host 和 X-Forwarded-Proto，Front Door 會以其自己的值取代現有的值。

如需詳細資訊，請參閱 Front Door 支援的 HTTP 標頭。

要使用 Azure Front Door Standard 或 Azure Front Door （classic），你需要一個公開 IP 位址或一個可公開解析的 DNS 名稱。 此要求允許 Azure Front Door 將流量路由至你的後端資源。 你可以使用 Azure 資源，如應用程式閘道器或 Azure 負載平衡器，將流量路由到虛擬網路中的資源。 如果您使用 Azure Front Door Premium，便可使用 Private Link，透過私人端點連線到位於內部負載平衡器後方的來源。 欲了解更多資訊，請參閱Secure origins with Private Link。

X-Azure-Ref客戶端回應和 Azure Front Door 存取日誌中顯示的值，代表 Azure Front Door 產生的主要請求相關識別碼。 僅在後端應用程式日誌中觀察到的額外 X-Azure-Ref 值屬於預期情況，這些值是在 Azure Front Door 平台中於要求處理期間產生的內部關聯識別碼。 這些內部識別碼由服務用於請求追蹤與診斷，並不表示多個用戶端請求。

否。 為了安全起見，Azure Front Door 僅支援在存取 金鑰保存庫 憑證時的受管理身份驗證。 欲了解更多資訊，請參閱Azure Front Door 中的使用受管理的身分。

否。 Azure Front Door 目前不支援與 Azure 事件中樞 的管理身份整合。

否。 Azure Front Door 目前不支援自訂錯誤頁面。

Front Door 後方的應用程式閘道在這些情況下很有用：

• 您不僅想要全域平衡流量，而且要平衡虛擬網路內的流量。 Front Door 只能在全域層級執行路徑型負載平衡，但應用程式閘道可以在虛擬網路內執行。
• 您需要連線清空，但 Front Door 不支援。 應用程式閘道可以為 VM 或容器啟用連線清空。
• 您想要卸載所有 TLS/SSL 處理，並只在您的虛擬網路中使用 HTTP 要求。 Front Door 後方的應用程式閘道可以達成此設定。
• 您想要在區域和伺服器層級使用工作階段親和性。 Front Door 可以將來自使用者工作階段的流量傳送至區域中的相同後端，但應用程式閘道可以將流量傳送至後端中的相同伺服器。

一般不建議將兩個 CDN 連結起來。 雖然可行，但有以下缺點：

1. CDN 的最後一哩加速是透過保持與起點的連線流並尋找通往起點的最佳路徑以達成最佳結果來運作。 將兩個 CDN 串接在一起，通常會削弱最後一哩加速的部分優點。
2. 第二個 CDN 的安全控管效果較差。 基於用戶端 IP 的存取控制無法運作，因為第二個 CDN 會將第一個 CDN 的出口節點識別為用戶端 IP。 內容酬載仍會受到檢查。
3. 串接兩個 CDN 會增加故障排除的複雜度。 當問題發生時，很難判斷是哪個 CDN 造成。

要使用 Azure Front Door，你必須擁有公開的 VIP 或一個公開可存取的 DNS 名稱。 Azure Front Door 使用公開 IP 將流量路由到你的來源。 常見的情況是在前門後方部署 Azure Load Balancer。 你也可以用 Private Link 搭配 Azure Front Door Premium 連接內部負載平衡器。 如需更多資訊，請參閱 啟用包含內部負載平衡器的私人連結。

Azure Front Door 和 Azure CDN 是兩項服務，可為您的應用程式提供快速且可靠的 Web 傳遞。 然而，它們彼此不相容，因為它們共用同一個 Azure 邊緣網站網絡，將內容傳送給使用者。 此共用網路會導致其路由和快取原則之間的衝突。 因此，你必須根據效能和安全需求，選擇 Azure Front Door 或 Azure CDN 來搭配應用程式。

兩個設定檔/端點都使用相同的 Azure edge POP 來處理傳入的要求，這會造成一項限制，使您無法將一個 Azure Front Door 設定檔/端點巢狀部署在另一個之後。 此設定會導致路由衝突和效能問題。 因此，如果你需要為應用程式使用多個設定檔/端點，應該確保 Azure Front Door 的配置檔/端點不會串連在一起。

Azure Front Door 使用單播路由進行名稱解析，並將要求路由到最佳的 接入點（POP）。 Unicast 取代了 Azure Front Door 先前使用的 Anycast 路由方式。

對位於 Azure Front Door 後方來源的名稱解析要求會送達 Front Door 的流量管理員端點。 Front Door 的流量管理員設定檔會使用來自全球 PoPs 的大量健全狀態與可用性訊號。 根據這些訊號，系統會傳回最佳 Front Door PoP 的 Unicast IP 位址。 當請求直接發送至返回的 IP 位址時，回應會遵循前門路由架構，然後返回給使用者或應用程式。

Azure Front Door 使用三個服務標籤來管理客戶端與來源之間的流量：

• AzureFrontDoor.Backend 服務標籤包含 Front Door 用來存取您的來源的 IP 位址。 設定來源的安全性時，您可以套用此服務標籤。
• AzureFrontDoor.Frontend 服務標籤包含用戶端用來連線 Front Door 的 IP 位址。 當你想控制能連接到Azure Front Door背後服務的出站流量時，可以套用 AzureFrontDoor.Frontend 服務標籤。
• AzureFrontDoor.FirstParty 服務標籤保留給託管在 Azure Front Door 上的一組 Microsoft 服務。

欲了解更多Azure Front Door服務標籤情境，請參見 available service tags。 為了在對 IP 位址進行任何的變更期間隨時掌握情況並採取適當的動作，請開發自動化流程，以利用 Service Tag Discovery API 或 JSON 檔案來定期擷取最新的 IP 位址。

來源群組是可以處理類似要求類型的來源集合。 針對每個不同的應用程式或工作負載，您需要不同的來源群組。

在來源群組中，您會為每個可處理要求的伺服器或服務建立來源。 如果你的 origin 有負載平衡器，例如 Azure 應用程式閘道，或是託管在有負載平衡器的 PaaS 上，那麼 origin 群組只有一個 origin。 您的來源會負責 Front Door 看不到的來源之間的容錯移轉和負載平衡。

舉例來說，如果你在 Azure App 服務 上架設應用程式，如何設定 Front Door 取決於你擁有多少應用程式實例：

• 單一區域部署：建立一個來源群組。 在該來源群組中，為 App Service 應用程式建立一個來源。 您的 App Service 應用程式可能會跨背景工作角色擴增，但 Front Door 會看到一個來源。
• 多區域主動/被動部署：建立一個來源群組。 在該來源群組中，為每個 App Service 應用程式建立一個來源。 設定每個來源的優先順序，讓主要應用程式具有高於備份應用程式的優先順序。
• 多區域主動/主動部署：建立一個來源群組。 在該來源群組中，為每個 App Service 應用程式建立一個來源。 將每個來源的優先順序設定為相同。 設定每個來源的權數，以控制可前往該來源的要求數。

如需了解更多，請參閱Azure Front Door 的起源及起源群組。

Azure Front Door 是一項為你的應用程式提供快速且可靠的網頁傳遞服務。 它提供快取、負載平衡、安全性和路由等功能。 不過，您需要注意一些適用於 Azure Front Door 的逾時和限制。 這些逾時和限制包括要求大小上限、回應大小上限、標頭大小上限、標頭數目上限、規則數目上限，以及來源群組數目上限。 你可以在 Azure Front Door 文件找到這些逾時和限制的詳細資訊。

大多數規則集會在 15 分鐘內更新設定。 該規則在更新結束後立即生效。

Azure Front Door 接收來自用戶端的標題時，逾時時間為 5 秒。 如果用戶端在與 Azure Front Door 建立 TCP/TLS 連線後 5 秒內未傳送標頭，該連線將被終止。 你無法設定這個逾時值。

Azure Front Door 的 HTTP Keep-Alive 逾時為 90 秒。 如果客戶端在 90 秒內沒有傳送資料，連線就會終止，這是 Azure Front Door 的 HTTP 保持連線逾時設定。 您無法設定此逾時值。

您無法針對多個 Front Door 端點使用相同的網域，因為 Front Door 必須針對每個要求區分路由 (通訊協定 + 主機 + 路徑組合)。 如果你在不同端點之間有重複路由，Azure Front Door 就無法正確處理這些請求。

目前，我們不提供將網域從一個端點移至另一個端點的選項，而不會中斷服務。 如果您想要將網域移轉至不同端點，則必須規劃一些停機。

Azure Front Door Private Link不依賴地區。 為了獲得最低延遲，啟用 Azure Front Door Private Link 端點時，選擇離你起點最近的支援Azure區域。 如果你的 Origin 地區在 Front Door Private Link 支援的地區列表中不被支援，請選擇下一個最近的地區。 流量從用戶端流向支援區域的Azure Front Door Private Link端點，然後經由Microsoft骨幹網路到你的起點，維持私密連線。 此配置因區域間的網路跳躍增加，會帶來額外的延遲。 你可以使用 Azure 網路的往返延遲統計數據，來判斷選擇下一個最近區域所產生的額外延遲。 當支援新區域時，你可以依照這些 指示 逐步將流量轉移到該區域。

Azure Front Door 是一個能將流量分散到全球的平台，並能根據你的應用程式需求擴展。 它利用 Microsoft 的全球邊緣網路提供全球負載平衡，若發生故障，您可以將整個應用程式或特定微服務移至不同區域或雲端。

為避免傳送大型檔案時出錯，請確保你的原始伺服器在回應中包含標 Content-Range 頭，且標頭值與回應主體的實際大小相符。

您可以在傳遞大型檔案中找到有關如何針對大型檔案傳遞設定來源和 Front Door 的詳細資料。

網域前置是一種網路技術，可讓攻擊者隱藏惡意要求的實際目的地，方法是在 TLS 交握和 HTTP 主機標頭中使用不同的網域名稱。

在 2022 年 11 月 8 日之後建立的 Azure Front Door (Standard、Premium 和 Classic 層) 或 Azure CDN Standard from Microsoft (傳統) 資源，已啟用網域前置封鎖。 我們不會阻擋 SNI 與主機標頭不符的請求，而是允許兩個網域屬於同一訂閱且包含在路由或路由規則中。 網域前端封鎖的執行於 2024 年 1 月 22 日開始。

當 Front Door 因不相符而封鎖要求時：

• 用戶端會收到 HTTP 421 Misdirected Request 錯誤碼回應。
• Azure Front Door 在診斷日誌中以 Error Info 屬性記錄該區塊，並以 SSLMismatchedSNI 的值記錄該區塊。

欲了解更多關於網域前置的資訊，請參閱 保護我們在 Azure 中的網域前置方法 及 禁止在 Azure Front Door 和 Azure CDN Standard from Microsoft（經典）中使用網域前置。

針對 2019 年 9 月之後建立的所有設定檔，Front Door 會使用 TLS 1.2 作為最低版本。

你可以選擇使用 TLS 1.2 或 1.3 搭配 Azure Front Door。 欲了解更多，請閱讀 Azure Front Door 端對端 TLS 文章。

是的。 Azure Front Door Standard 和 Premium 支援自訂網域的 TLS 密鑰交換政策。 選擇標準、增強或自訂，以獨立控制支援的經典及混合後量子群組，與協定版本及密碼套件分開。

標準是新舊設定檔的預設金鑰交換政策。 預設的 Front Door 網域一律使用 Standard，且不支援原則自訂。

混合後量子金鑰交換需要 TLS 1.3 及相容用戶端。 網域的金鑰交換政策控制的是客戶端到 Front Door 的連線，而非獨立的 Front Door 到來源的連線。 如果你允許 TLS 1.2，請在自訂政策中至少包含一個經典群組。

關於支援的群組、預設值及相容性考量，請參見 TLS 金鑰交換政策。

自 2025 年 8 月 15 日起，DigiCert 轉換至一個新的開源軟體（OSS）領域控制驗證（DCV）平台，旨在提升領域驗證流程的透明度與問責性。 DigiCert 不再支援指定 Azure 服務中傳統的 CNAME 委派 DCV 工作流程，用於網域控制驗證。 瞭解更多資訊

淘汰會影響依賴 CNAME 型驗證進行自動憑證發行和續約的服務，包括：

• Azure Front Door（經典版）
• 微軟的 Azure CDN（經典版）

Azure Front Door（經典版）和 Microsoft 的 Azure CDN（經典版）：

• 自 2025 年 8 月 15 日起，將不再支援新網域上線、建立新設定檔及 Azure 受控憑證。
• 自2026年4月14日起，現行的管理證書將被淘汰。 所有現有的管理憑證都會由客戶或 AFD 團隊遷移到 Azure Front Door 標準版或高級版。 請使用 Azure Front Door Standard 或 Premium 來管理憑證。

大多數情況下，不需要採取行動。 設定檔移轉完成後，若受控憑證的到期日在 45 天以內，Azure Front Door 會自動嘗試輪替該憑證。

• 如果你的網域是 CNAME 對應到 Azure Front Door，且符合 CAA 紀錄和網域狀態要求，憑證會自動輪替。 自動輪換工作每6至8小時執行一次，完成時間約為24至48小時。 如果自動輪換失敗，網域驗證狀態會變成「待驗證」，你可以重新驗證網域所有權，手動觸發驗證。
• 如果你的網域不符合這些驗證要求或 HTTPS 被停用，憑證狀態會變成待驗證，你必須重新驗證網域所有權。

若要在不等待自動輪替的情況下續約憑證，請手動重新驗證網域所有權，方法如下：

• 在第三步後，為待驗證的網域新增所需的 DNS 驗證紀錄
• 使用 PowerShell 或 Azure CLI 手動觸發驗證 （RefreshValidation）。

你無法停用 Azure Front Door 資源。 你只能刪除它們。 像是資料傳輸輸出、資料傳輸進出和請求這類可變計量器，當沒有流量時不會被收取，但即使沒有流量，基本費用也會被收取。 基本費用會持續收取，直到該個人檔案被刪除為止。 對於 Azure Front Door（經典版），WAF 政策和規則無論狀態如何都會被收費。 即使您停用 WAF 原則或規則，仍會衍生您的成本。

否。

否。

Front Door 不支援超過 8 MB 的內容動態壓縮。 然而，如果來源已先將內容壓縮，且支援範圍要求並且未啟用分塊傳輸編碼，Front Door 便支援提供大小超過 8 MB 的經壓縮靜態內容。

否。

如需記錄和其他診斷功能的詳細資訊，請參閱 Front Door 的監視計量和記錄。

您可以將診斷記錄儲存在其自己的儲存體帳戶中，然後選擇保留多久時間。 或者，你也可以將診斷日誌傳送到 Event Hubs 或 Azure 監視器 日誌。 欲了解更多資訊，請參閱Azure Front Door 診斷。

要存取 Azure Front Door 的稽核日誌，您需要造訪入口網站。 從選單頁面選擇你的前門，並選擇 活動記錄。 活動日誌會提供您 Azure Front Door 運作的紀錄。

你可以根據度量或記錄來為 Azure Front Door 設定警報。 如此一來，您就可以監視前端主機的效能和健康情況。

欲了解如何為標準版和高級版Azure Front Door建立警報，請參閱 configure alerts。

相關內容

• 建立 Azure Front Door 設定檔
• Azure Front Door 路由架構