重要
Azure Front Door（經典版）不支援設定檔建立、新網域導入或受控憑證，並將於 2027 年 3 月 31 日
注意
本文章中的來源和來源群組是指 Azure Front Door (傳統) 設定的後端和後端集區。
本文說明有關如何將 Web 應用程式的部署與 Azure Front Door 映射的概念。 您將了解 Azure Front Door 設定中的「原點」和「原點群組」。
原始來源
來源是指 Azure Front Door 從中擷取內容的應用程式部署。 Azure Front Door 支援裝載於 Azure 中的來源，以及裝載於內部部署資料中心或其他雲端提供者的應用程式。 原點不應該與您的資料庫層或儲存層混淆。 原點應該視為應用程式後端的端點。 當您在 Front Door 設定中將原點新增至原點群組時，也必須設定下列設定：
原點類型：您想要新增的資源類型。 Front Door 支援從應用程式服務、雲端服務或儲存體自動探索您的應用程式後端。 若要使用 Azure 或甚至非 Azure 後端中的其他資源，請選取 [自訂主機]。
重要
在設定期間，API 不會驗證是否無法從 Front Door 環境存取原始端點。 確認 Front Door 可以連線到您的來源。
訂用帳戶和原點主機名稱：如果您未針對後端主機類型選取 [自訂主機]，請選擇適當的訂用帳戶和對應的後端主機名稱，以選取您的後端。
Private Link：Azure Front Door 進階版層支援使用 Private Link 將流量傳送至原點。 如需詳細資訊，請參閱使用 Private Link 保護您的原點。
憑證主體名稱驗證：在 Azure Front Door 與原點 TLS 連線期間，Azure Front Door 會驗證要求主機名稱是否符合原點所提供憑證中的主機名稱。 從安全性的觀點來看，Microsoft 不建議停用憑證主體名稱檢查。 如需詳細資訊，請參閱端對端 TLS 加密，特別是如果您想要停用此功能。
來源主機標頭：為每個請求發送到後端的主機標頭值。 如需詳細資訊，請參閱原點主機標頭。
優先順序。 當您想要針對所有流量使用主要服務後端時，請將優先順序指派給不同的後端。 此外，如果主要或備份後端無法使用，則提供備份。 如需詳細資訊，請參閱優先順序。
權重。 可以將權數指派給不同的後端，藉此平均或根據權數係數將流量分散到一組後端。 如需詳細資訊，請參閱權重。
重要
當來源停用時，對該來源的路由和健全狀態探查也會停用。
來源主機標頭
Azure Front Door 轉送至來源的要求會包含主機標頭欄位，來源會使用該欄位擷取目標資源。 此欄位的值通常來自包含主機標頭和連接埠的原點 URI。
例如，針對 www.contoso.com 提出的要求會有主機標頭 www.contoso.com。 如果您使用 Azure 入口網站來設定原點，則此欄位的預設值為原點的主機名稱。 如果您的原點是 contoso-westus.azurewebsites.net，則在 Azure 入口網站中，原點主機標頭的自動填入值會是 contoso-westus.azurewebsites.net。 不過，如果您使用 Azure Resource Manager 範本或其他方法，而且未明確設定此欄位，則 Front Door 會傳送傳入主機名稱作為主機標頭值。 如果已針對 www.contoso.com 提出要求，而且您的原點 contoso-westus.azurewebsites.net 有空的標頭欄位，則 Front Door 會將主機標頭設定為 www.contoso.com。
大部分的應用程式後端 (Azure Apps、Blob 儲存體和雲端服務) 都需要主機標頭符合後端的網域。 不過，路由至原點的前端主機會使用不同的主機名稱，例如 www.contoso.net。
如果您的原點要求主機標頭符合原點主機名稱，請確定原點主機標頭包含原點的主機名稱。
注意
如果您使用 App Service 作為原點，請確定 App Service 也已設定自訂網域名稱。 如需詳細資訊，請參閱 設置應用程式的現有自訂網域名稱。
設定來源的來源主機標頭
若要在來源群組區段中設定來源的來源主機標頭欄位：
開啟您的 Front Door 資源，然後選取包含要設定的來源的來源群組。
新增來源或編輯現有來源。
將原點主機標頭欄位設定為自訂值，或將其保留空白。 傳入要求的主機名稱會用來作為主機標頭值。
原始群組
Azure Front Door 中的原點群組是指一組原點，可接收其應用程式的類似流量。 您可以將原點群組定義為全球應用程式執行個體的邏輯群組，用於接收相同的流量，並以預期的行為回應。 這些來源可以部署到不同的區域或同一個區域內。 所有來源都可以部署為主動/主動或主動/被動組態。
來源群組會定義健全狀態探查如何評估來源。 其也會定義兩者之間的負載平衡方法。
健康情況探查
Azure Front Door 會將定期 HTTP/HTTPS 探查要求傳送至每個已設定的原點。 探測請求用於確定每個來源的鄰近性和健全性，以均衡端使用者請求的負載。 來源群組的健康探查設定會定義如何檢查應用程式後端的健康狀態。 下列設定適用於負載平衡設定：
路徑：用於原點群組中所有原點探查請求的 URL。 例如，如果您的其中一個原點是
contoso-westus.azurewebsites.net，並且路徑設定為 /probe/test.aspx，則 Front Door 會在通訊協定設定為 HTTP 的情況下，將健全狀態探查要求傳送至http://contoso-westus.azurewebsites.net/probe/test.aspx。通訊協定：定義當健康狀態探查要求要從 Front Door 傳送至原點時，要使用 HTTP 還是 HTTPS 通訊協定。
方法：用來傳送健康狀態探查的 HTTP 方法。 選項包括 GET 或 HEAD (預設)。
注意
為了降低後端的負載與成本，Front Door 建議健全狀態探查使用 HEAD 要求。
間隔 (秒)：定義對來源執行健全狀態探查的頻率，或每個 Front Door 環境傳送探查的間隔。
注意
若要加快容錯移轉速度，請將間隔設定為較低的值。 值設得越低，後端所收到的健康探查流量就越多。 例如，如果間隔設定為 30 秒，全域有 100 個 Front Door POP，則每個後端每分鐘會收到大約 200 個探查要求。
如需詳細資訊，請參閱健康狀態探查。
負載平衡設定
原點群組的負載平衡設定會定義我們評估健康狀態探查的方式。 這些設定會判斷原點是否狀況良好或狀況不良。 也會檢查如何平衡原點群組中不同原點之間的流量負載。 下列設定適用於負載平衡設定：
範例大小：識別我們需要考量多少個健全狀態探查範例，來評估來源健全狀態。
成功範例大小：定義前述範例大小，也就是判定來源良好所需的成功範例數。 例如，假設 Front Door 健全狀態探查間隔為 30 秒，樣本大小為 5，而成功的樣本大小為 3。 每次評估來源的健全狀態探查時，我們會查看 150 秒內的最後五個範例 (5 x 30)。 至少需要三次成功探查，才能宣告來源為良好。
延遲敏感度 (額外延遲)：定義您是否希望 Front Door 將要求傳送至延遲度量敏感度範圍內的原點，或是將要求轉送至最近的後端。
如需詳細資訊，請參閱最低延遲型路由方法。