Network Load Balancer 目標群組的 Health 檢

您可以利用一個或多個群組來登錄目標。一旦註冊程序完成且目標通過初始健全狀況檢查，負載平衡器就會立即開始將要求路由到新註冊的目標。註冊程序可能需要幾分鐘的時間才能完成，並開始運作狀態檢查。

Network Load Balancer 採用主動與被動運作狀態檢查來判定目標是否可用於處理請求。預設情況下，每個負載平衡器節點只會將請求路由至其可用區域內運作狀態良好的目標。若您啟用跨區域負載平衡功能，每個負載平衡器節點則會將請求路由至所有已啟用的可用區域內運作狀態良好的目標。如需詳細資訊，請參閱跨區域負載平衡。

憑藉被動的運作狀態檢查，負載平衡器將觀察各目標回應連線的情形。被動的運作狀態檢查使負載平衡器得以在主動的運作狀態檢查回報某目標運作狀態不佳之前即偵測出其運作狀態不佳。您無法停用、設定或監控被動的運作狀態檢查。UDP流量和已開啟黏性的目標群組不支援被動健康狀態檢查。如需詳細資訊，請參閱黏滯工作階段。

如果目標狀況不TCPRST佳，負載平衡器會傳送與目標相關聯之用戶端連線上收到的封包，除非健康狀態不良的目標觸發負載平衡器無法開啟。

如果目標群組在已啟用的可用區域中沒有健全狀況良好的目標，我們會從中移除對應子網路的 IP 位址，DNS以便無法將要求路由至該可用區域中的目標。如果所有目標在所有已啟用的可用區域中未同時通過運作狀態檢查，則負載平衡器會故障開啟。當您有空的目標群組時，網路負載平衡器也會無法開啟。故障開啟的影響是，允許流量傳輸到所有已啟用可用區域中的所有目標，無論其運作狀態為何。

如果目標群組設定了HTTPS健全狀況檢查，則其註冊的目標在僅支援 TLS 1.3 時失敗健全狀況檢查。這些目標必須支援舊版的TLS，例如 TLS 1.2。

對於HTTP或HTTPS健全狀況檢查要求，主機標頭包含負載平衡器節點的 IP 位址和監聽器連接埠，而不是目標的 IP 位址和健全狀況檢查連接埠。

如果您將接TLS聽程式新增至 Network Load Balancer，我們會執行接聽程式連線測試。由於TLS終止也會終止TCP連線，因此會在負載平衡器和目標之間建立新的TCP連線。因此，您可能會看到此測試的TCP連線從負載平衡器傳送到向TLS監聽器註冊的目標。您可以識別這些TCP連線，因為它們具有 Network Load Balancer 的來源 IP 位址，且連線不包含資料封包。

對於UDP服務，您可以使用目標群組的非UDP健全狀況檢查來測試目標使用狀態。您可以使用任何可用的健全狀況檢查 (TCPHTTP、或HTTPS) 以及目標上的任何連接埠來驗證UDP服務的可用性。如接收運作狀態檢查的服務失敗，您的目標將被視為無法使用。若要改善UDP服務健全狀況檢查的準確性，請設定接聽健全狀況檢查連接埠的服務，以追蹤UDP服務的狀態，並在服務無法使用時失敗健全狀況檢查。

運作狀態檢查設定

您將使用以下設定，為目標群組中的目標設定主動的運作狀態檢查。如果健全狀況檢查超過UnhealthyThresholdCount連續的失敗，負載平衡器會將目標停止服務。當健全狀況檢查超過HealthyThresholdCount連續成功時，負載平衡器會將目標重新啟用。

設定	描述	預設
HealthCheckProtocol	負載平衡器對目標執行運作狀態檢查時使用的通訊協定。可能的通訊協定為HTTPHTTPS、和TCP。預設為TCP通訊協定。如果目標類型為alb，則支援的健全狀況檢查通訊協定為HTTP和HTTPS。	TCP
HealthCheckPort	負載平衡器對目標執行運作狀態檢查時使用的連接埠。預設為使用每個目標從負載平衡器接收流量的連接埠。	每個目標從負載平衡器接收流量的連接埠。
HealthCheckPath	[HTTP/HTTPS健康狀態檢查] 健康狀態檢查路徑，作為健康狀態檢查目標上的目的地。預設為 /.	/
HealthCheckTimeoutSeconds	以秒為單位的時間量，若目標在此期間內毫無回應即表示運作狀態檢查失敗。範圍介於 2 到 120 秒之間。HTTP和HTTPS健康狀態檢查的預設值為 6 秒TCP和 10 秒。	HTTP健康檢查 6 秒，10 秒TCP和HTTPS健康檢查。
HealthCheckIntervalSeconds	個別目標每次執行運作狀態檢查的大約間隔時間量，以秒為單位。範圍介於 5–300 秒之間。預設為 30 秒。 重要 Network Load Balancer 的運作狀態檢查為分散式，並採用共識機制判定目標的運作狀態。因此，目標會接收超過所設定次數的運作狀態檢查。若要在使用HTTP健全狀況檢查時減少對目標的影響，請在目標上使用較簡單的目的地，例如靜態HTML檔案，或切換至TCP健全狀況檢查。	30 秒
HealthyThresholdCount	將運作狀態不佳的目標視為運作狀態良好之前，運作狀態檢查需連續成功的次數。範圍介於 2–10 之間。預設值為 5。	5
UnhealthyThresholdCount	將目標視為運作狀態不佳之前，運作狀態檢查需連續失敗的次數。範圍介於 2–10 之間。預設為 2。	2
Matcher	[HTTP/HTTPS健康狀態檢查] 檢查目標的成功回應時使用的HTTP代碼。範圍介於 200 到 599 之間。預設為 200 到 399 之間。	200-399

目標運作狀態

在負載平衡器向目標傳送運作狀態檢查請求之前，您必須向目標群組註冊該目標，由接聽程式規則中指定其目標群組，並確保負載平衡器已啟用該目標的可用區域。

下表說明已註冊目標的運作狀態可能的值。

Value	描述
initial	負載平衡器正在註冊目標或對目標執行初始運作狀態檢查。 相關原因代碼： Elb.RegistrationInProgress | Elb.InitialHealthChecking
healthy	目標的運作狀態良好。 相關原因代碼：無
unhealthy	目標未回應健全狀況檢查、未通過健全狀況檢查，或目標處於停止狀態。 相關原因碼：Target.FailedHealthChecks
draining	目標正在取消註冊，連接耗盡作業進行中。 相關原因碼：Target.DeregistrationInProgress
unhealthy.draining	目標未回應健康狀態檢查，或未通過健康狀態檢查，進入寬限期。目標支援現有的連線，而且在此寬限期內將不接受任何新連線。 相關原因碼：Target.FailedHealthChecks
unavailable	目標健全狀態無法使用。 相關原因碼：Elb.InternalError
unused	目標未向目標群組註冊、目標群組不會用於監聽器規則中，或目標位於未啟用的可用區域中。 相關原因碼：Target.NotRegistered | Target.NotInUse | Target.InvalidState | Target.IpUnusable

運作狀態檢查原因代碼

如果目標的狀態為除以外的任何值Healthy，則會API傳回原因代碼和問題描述，且主控台會在工具提示中顯示相同的描述。請注意，開頭為 Elb 的原因代碼源自負載平衡器端，而開頭為 Target 的原因代碼源自目標端。

原因代碼	描述
Elb.InitialHealthChecking	初始運作狀態檢查正進行中
Elb.InternalError	運作狀態檢查由於內部錯誤而失敗
Elb.RegistrationInProgress	目標註冊正進行中
Target.DeregistrationInProgress	目標取消註冊正進行中
Target.FailedHealthChecks	運作狀態檢查失敗
Target.InvalidState	目標處於停止狀態 目標處於終止狀態 目標處於終止或停止狀態 目標處於無效狀態
Target.IpUnusable	IP 地址不能做為目標，因為負載平衡器正在使用它
Target.NotInUse	目標群組未設定為接收來自負載平衡器的流量 目標位於負載平衡器未啟用的可用區域
Target.NotRegistered	目標未向目標群組註冊