Azure Front Door 的常見問題集

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

Azure Front Door 是一項服務，可為您的 Web 應用程式提供許多優點，例如動態網站加速 (DSA)，其可改善網站的效能和使用者體驗。 Azure Front Door 也會處理 TLS/SSL 卸載和端對端 TLS，其可增強 Web 流量的安全性和加密。 此外，Azure Front Door 還提供 Web 應用程式防火牆、以 Cookie 為基礎的工作階段親和性、URL 路徑型路由、免費憑證和多個網域管理等等。 若要深入了解 Azure Front Door 的特性和功能，請參閱階層比較。

Azure Front Door 和 Azure 應用程式閘道都是 HTTP/HTTPS 流量的負載平衡器，但它們有不同的範圍。 Front Door 是一項全域服務，可跨區域散發要求，而應用程式閘道是區域服務，可平衡區域內的要求。 Azure Front Door 可用於縮放單位、叢集或戳記單位，而 Azure 應用程式閘道則與相同縮放單位中的 VM、容器或其他資源搭配運作。

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

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

鏈結兩個 CDN 通常不是建議的方法，它會運作，但隨附下列缺點

1. CDN 的最後一英里加速利用讓連線串流與原點保持一起，並尋找來源的最佳路徑以達到最佳結果。 將兩個 CDN 鏈結在一起通常會否定最後一英里加速的一些優點。
2. 在第二個 CDN 上，安全性控制會變得較不有效。 任何以用戶端 IP 為基礎的 ACLing 都不會在第二個 CDN 上運作，因為第二個 CDN 會將第一個 CDN 的結束節點視為用戶端 IP。 仍會檢查內容承載。
3. 許多組織無法處理針對兩個CDN鏈結的疑難解答複雜度，而且當發生問題時，很難找出哪些CDN發生問題。

若要使用 Azure Front Door，您必須具有可公開存取的公用 VIP 或 DNS 名稱。 Azure Front Door 會使用公用 IP 將流量路由至您的來源。 常見的案例是在 Front Door 後方部署 Azure Load Balancer。 您也可以使用 Private Link 搭配 Azure Front Door 進階，以連線到內部負載平衡器。 如需詳細資訊，請參閱啟用 Private Link 搭配內部負載平衡器。

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

Azure Front Door 針對用戶端連線支援 HTTP/2 通訊協定。 不過，後端集區通訊會使用 HTTP/1.1 通訊協定。 HTTP/2 支援預設為開啟。

您可以針對 Azure Front Door 使用不同的來源類型，例如：

• 儲存體 (Azure Blob、傳統、靜態網站)
• 雲端服務
• 應用程式服務
• 靜態 Web 應用程式
• API 管理
• 應用程式閘道
• 公用 IP 位址
• Azure Spring Apps
• 容器執行個體
• 容器應用程式
• 具有公用存取的任何自訂主機名稱。

來源必須具有可公開解析的公用 IP 或 DNS 主機名稱。 只要可公開存取，您就可以混合和比對來自不同地區、區域或甚至 Azure 外部的後端。

Azure Front Door 不限於任何 Azure 區域，可在全球運作。 建立 Front Door 時必須選擇的唯一位置是資源群組的位置，這會決定資源群組中繼資料的儲存位置。 Front Door 設定檔是全域資源，且其設定會散發到全球所有邊緣位置。

如需為 Azure Front Door 提供全域負載平衡和內容傳遞的存在點 (POP) 的完整清單，請參閱 Azure Front Door POP 位置。 此清單會隨著新 POP 新增或移除而定期更新。 您也可以使用 Azure Resource Manager API，以程式設計方式查詢目前的 POP 清單。

Azure Front Door 是一項服務，可將您的應用程式散發到全球的多個區域。 它會使用由其所有客戶共用的通用基礎結構，但您可以自訂自己的 Front Door 設定檔來設定應用程式的特定需求。 其他客戶的設定不會影響您的 Front Door 設定，其與他們的設定隔離。

您可以使用 Azure Front Door 重新導向 URL 的主機、路徑和查詢字串元件。 若要了解如何設定 URL 重新導向，請參閱 URL 重新導向。

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

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

Front Door 前端 Anycast 的 IP 位址是固定的，只要您使用 Front Door，就可能不會變更。 不過，Front Door 前端 Anycast 的固定 IP 位址並非保證。 避免直接依賴 IP。

Azure Front Door 是動態服務，會將流量路由至最佳的可用後端。 目前未提供靜態或專用前端 Anycast IP。

是。 請參閱存取記錄底下的MatchedRulesSetName 屬性。

是。 如需詳細資訊，請參閱 Microsoft 針對 HTTP/2 的 DDoS 攻擊回應。

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 標頭。

新 Front Door 設定的部署時間會根據變更的類型而有所不同。 一般而言，變更需要 3 到 20 分鐘的時間，才能傳播到全球所有邊緣位置。

對路由或來源群組/後端集區的更新是無縫順暢的，而且不會造成任何停機 (假設新的設定正確)。 憑證更新也會是不可部分完成，因此不會有中斷的風險。

否。 目前，Azure Front Door 僅支援從邊緣到來源的 HTTP/1.1。 若要讓 gRPC 能夠運作，需要 HTTP/2。

• Front Door Standard/Premium 和 Azure CDN 配置檔可以在資源群組或訂用帳戶之間移動，而不需要停機。 若要執行移動，請遵循這些 指示。
• Front Door 傳統不支援在資源群組或訂用帳戶之間移動。 您可以改為 將傳統配置檔移 轉至標準/進階，然後執行移動。
• 如果客戶有與 Front Door Standard/Premium 相關聯的 WAF，則移動作業將會失敗。 客戶必須先解除與 WAF 原則的關聯，然後移動再建立關聯。

若要使用 Azure Front Door 標準、進階或 (傳統) 層，您需要可公開解析的公用 IP 或 DNS 名稱。 可公開解析的公用 IP 或 DNS 名稱的這項需求，會允許 Azure Front Door 將流量路由至後端資源。 您可以使用應用程式閘道或 Azure Load Balancer 等 Azure 資源，將流量路由至虛擬網路中的資源。 如果您使用 Front Door 進階層，您可以使用 Private Link，以使用私人端點連線至內部負載平衡器後方的來源。 如需詳細資訊，請參閱使用 Private Link 保護來源。

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

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

例如，如果您在 Azure App Service 上裝載應用程式，設定 Front Door 的方式取決於您擁有的應用程式執行個體數目：

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

若要深入了解，請參閱 Azure Front Door中的來源和來源群組。

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

大部分規則集的設定更新會在 20 分鐘內完成。 更新完成之後，將會立即套用規則。

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

這兩個設定檔都會使用相同的 Azure 邊緣網站來處理傳入要求，這會導致此限制讓您無法將一個 Azure Front Door 設定檔巢狀置於另一個後方。 此設定會導致路由衝突和效能問題。 因此，如果您需要對應用程式使用多個設定檔，您應該確保您的 Azure Front Door 設定檔是獨立的，且未鏈結在一起。

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 服務標籤案例的詳細資訊，請參閱可用的服務標籤。

Azure Front Door 有 5 秒的逾時，用於從用戶端接收標頭。 如果在建立 TCP/TLS 連線之後，用戶端未在 5 秒內將標頭傳送至 Azure Front Door，則會終止連線。 您無法設定此逾時值。

Azure Front Door 有 90 秒的 HTTP 保持連線逾時。 如果用戶端未傳送資料達 90 秒，則會終止連線，這是 Azure Front Door 的 HTTP 保持運作逾時。 您無法設定此逾時值。

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

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

Azure Front Door Private Link 功能與區域無關，即使您選擇與來源所在區域不同的區域，仍可運作。 在這種情況下，為了確保延遲較低，當您選擇啟用 Azure Front Door Private Link 端點時，應該一律挑選最接近來源的 Azure 區域。 我們正在啟用更多區域的支援。 支援新區域之後，您可以遵循這些 指示 ，逐漸將流量轉移至新區域。

Azure Front Door 是一個平台，可在世界各地散發流量，並可擴大以符合應用程式的需求。 它會使用 Microsoft 的全球網路邊緣來提供全域負載平衡功能，讓您在發生失敗時，將整個應用程式或特定微服務切換至不同的區域或雲端。

若要避免在傳遞大型檔案時發生錯誤，請確定您的來源伺服器在回應中包含 Content-Range 標頭，且標頭值符合回應本文的實際大小。

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

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

2022 年 11 月 8 日之後建立的 Azure Front Door (標準、進階和傳統層) 或來自 Microsoft (傳統) 的 Azure CDN 標準資源，已啟用網域前置封鎖。 如果兩個網域屬於相同的訂用帳戶，而且包含在路由/路由規則中，我們會允許該差異，而非封鎖具有不相符 SNI 和主機標頭的要求。 網域前置封鎖強制執行將於 2024 年 1 月 22 日針對所有現有網域開始。 強制執行最多可能需要兩週才能傳播到所有區域。

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

• 用戶端會收到 HTTP 421 Misdirected Request 錯誤碼回應。
• Azure Front Door 會在 [錯誤資訊] 屬性底下的診斷記錄中記錄區塊，並具有 SSLMismatchedSNI 值。

如需網域前置的詳細資訊，請參閱在 Azure 內針對網域前置保護我們的方法 (英文)，以及在 Azure Front Door 和來自 Microsoft (傳統) 的 Azure CDN 標準上禁止網域前置 (英文)。

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

您可以選擇搭配 Azure Front Door 使用 TLS 1.0、1.1、1.2 或 1.3。 若要深入了解，請閱讀 Azure Front Door 端對端 TLS 一文。

Azure Front Door 是一項服務，可提供快速且安全的 Web 傳遞。 它可讓您定義 Web 流量在多個區域和端點之間路由和最佳化的方式。 Azure Front Door 資源，例如 Front Door 設定檔和路由規則，只有在啟用時才會計費。 不過，Web 應用程式防火牆 (WAF) 原則和規則一律會計費，而不論其狀態為何。 即使您停用 WAF 原則或規則，仍會衍生您的成本。

否。

否。

AFD 不支援大於 8 MB 的內容動態壓縮。 不過，如果內容已經由來源壓縮，Front Door 支援在支援範圍要求且未啟用區塊傳輸編碼的情況下，提供超過 8 MB 的靜態壓縮內容。

否。

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

您可以將診斷記錄儲存在其自己的儲存體帳戶中，然後選擇保留多久時間。 或者，診斷記錄可以傳送至事件中樞或 Azure 監視器記錄。 如需詳細資訊，請參閱 Azure Front Door 診斷。

若要存取 Azure Front Door 的稽核記錄，您必須造訪入口網站。 從功能表頁面選取您的 Front Door，然後選取 [活動記錄]。 活動記錄提供 Azure Front Door 作業的記錄。

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

若要了解如何為 Azure Front Door 標準和進階建立警示，請參閱設定警示。

下一步

• 了解如何建立 Azure Front Door 設定檔。
• 了解 Azure Front Door 結構。