重要
Azure Front Door（經典版）將於 2027 年 3 月 31 日退休。 由於該服務即將退休，不再支援設定檔建立、新網域導入或管理憑證。 為避免服務中斷，遷移至Azure Front Door標準版或高級版。 如需詳細資訊，請參閱 Azure Front Door (傳統版) 淘汰。
注意
在本篇文章中，origin 與 origin 群組 指的是 Azure Front Door（經典）配置的後端伺服器與後端伺服器池。
為了判斷特定 Azure Front Door 環境中每個源的健康狀況與接近程度，每個 Front Door 設定檔會定期向你設定的所有源頭發送合成的 HTTP 或 HTTPS 請求。 Front Door 接著會使用健全狀態探查的回應來判斷要將用戶端要求路由至哪個最佳來源。
警告
由於每個 Azure Front Door 邊緣位置都會向來源發送健全狀態探查，因此來源的健全狀態探查量可能會很高。 探查數量取決於客戶流量所在位置以及健全狀態探查頻率。 如果 Azure Front Door 的邊緣位置沒有收到來自終端使用者的真實流量，來自該邊緣位置的健康探測頻率會比設定頻率降低。 如果流量到達所有 Azure Front Door 邊緣位置，則健全狀態探查數量可能會因健全狀態探查頻率而變高。
使用預設探針頻率 30 秒時，要大致估算每分鐘對某原點的健康探針體積，將邊緣位置數乘以每分鐘兩次請求。 如果未將流量傳送至所有邊緣位置，探查要求會較少。 如需邊緣位置清單，請參閱依區域的邊緣位置。
支援的通訊協定
Azure Front Door 支援透過 HTTP 或 HTTPS 通訊協定傳送探查。 這些探測器使用配置給客戶端請求路由相同的 TCP 埠口，且無法更改。 Front Door 的 HTTP 或 HTTPS 探查會包含一個 User-Agent 標頭，其值設定為 Edge Health Probe。
健全狀態探查支援的 HTTP 方法
Azure Front Door 支援下列 HTTP 方法來傳送健全狀態探查：
- GET：GET 方法會擷取由 Request-URI 所識別的任何資訊 (以實體形式呈現)。
- HEAD：HEAD 方法等同於 GET，不同之處在於伺服器不得在回應中傳回訊息本文。 對於新的 Front Door 設定檔，探查方法預設為 HEAD。
提示
為了降低對來源的負載與成本，請使用 HEAD 請求進行健全狀態探查。
健康狀況探查回應
| 回覆 | 描述 |
|---|---|
| 判斷健康情況 | 200 OK 狀態碼表示原點狀況良好。 任何其他狀態碼都會被視為失敗。 如果基於任何原因未收到有效的 HTTP 探查回應，則探查將會視為失敗。 |
| 測量延遲 | 延遲是以實際時間測量，從探查要求發送前一刻開始，到 Front Door 收到回應最後一個位元組為止。 Front Door 會針對每個要求使用新的 TCP 連線。 此測量不會偏向具有既有預熱連線的來源。 |
Front Door 如何判定來源的健全狀態
Azure Front Door 在所有演算法之間使用三步驟程序來判斷健康情況。
排除已停用的來源。
排除有健康探針錯誤的來源：
Front Door 會查看最近的 n 次健全狀態探查回應。 如果至少 有 x 個反應是健康的，則該來源被視為健康的。
將載入平衡設定中的 SampleSize 屬性改為設定 n。
在負載平衡設定中將 SuccessSamplesRequired 屬性改為設定 x。
針對原點群組中狀況良好的原點集合，Front Door 會測量並維護每個原點的延遲。
注意
如果單一端點屬於多個起點群組，Front Door 會優化發送給起點的健康探測數量，以降低起點的負載。 Front Door 會根據設定的最低取樣間隔發送健康探針請求。 同一健康探針的回應決定了所有起源群組中終點的健康狀況。
完整的健全狀態探查失敗
如果來源群組中的每個來源健全狀態探查皆失敗，Front Door 會將所有來源視為狀況不良，並在所有來源之間以輪詢方式分配流量。 當原點恢復到健康狀態時，Front Door 會恢復正常的負載平衡演算法。
停用健全狀態探查
如果您的來源群組只有一個來源，您可以停用健全狀態探查以降低應用程式負載。 如果你的起源群組有多個起源且啟用了多個起源，你就無法關閉健康探針。
注意
如果來源群組只有單一來源，該來源接收到的健全狀態探查會較少。 這種情況可能會導致來源健康指標下滑，但你的流量不會受到影響。