本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
目標群組運作狀態檢查
您可以利用一個或多個群組來登錄目標。只要登錄程序一完成，負載平衡器就會開始將請求路由到新登錄的目標。註冊程序可能需要幾分鐘的時間才能完成，並開始運作狀態檢查。
Network Load Balancer 採用主動與被動運作狀態檢查來判定目標是否可用於處理請求。預設情況下，每個負載平衡器節點只會將請求路由至其可用區域內運作狀態良好的目標。若您啟用跨區域負載平衡功能，每個負載平衡器節點則會將請求路由至所有已啟用的可用區域內運作狀態良好的目標。如需詳細資訊，請參閱 跨區域負載平衡。
憑藉被動的運作狀態檢查，負載平衡器將觀察各目標回應連線的情形。被動的運作狀態檢查使負載平衡器得以在主動的運作狀態檢查回報某目標運作狀態不佳之前即偵測出其運作狀態不佳。您無法停用、設定或監控被動的運作狀態檢查。UDP 流量和已開啟黏性的目標群組不支援被動健全狀況檢查。如需詳細資訊，請參閱黏滯工作階段。
如果目標變得運作狀態不佳，負載平衡器會針對關聯目標的用戶端連線所接收的封包傳送 TCP RST，除非運作狀態不佳的目標觸發負載平衡器進入故障開放。
如目標群組在已啟用的可用區域無運作狀態良好的目標，我們將從 DNS 移除相應子網路的 IP 地址，以便請求無法路由至該可用區域的目標。如果所有目標在所有已啟用的可用區域中未同時通過運作狀態檢查，則負載平衡器會故障開啟。故障開啟的影響是，允許流量傳輸到所有已啟用可用區域中的所有目標，無論其運作狀態為何。
如果目標群組設定有 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 運作狀態檢查來測試目標可用性。您可利用任何可用的運作狀態檢查 (TCP、HTTP 或 HTTPS)，以及目標的任何連接埠來驗證 UDP 服務的可用性。如接收運作狀態檢查的服務失敗，您的目標將被視為無法使用。為改善 UDP 服務運作狀態檢查的準確性，將接聽運作狀態檢查連接埠的服務設為追蹤 UDP 服務的狀態，若服務無法使用，則運作狀態檢查會失敗。
運作狀態檢查設定
您將使用以下設定，為目標群組中的目標設定主動的運作狀態檢查。如果健全狀況檢查超過UnhealthyThresholdCount連續的失敗，負載平衡器會將目標停止服務。當健全狀況檢查超過HealthyThresholdCount連續的成功時，負載平衡器會將目標重新啟用。
| 設定 | 描述 | 預設 |
|---|---|---|
|
HealthCheckProtocol |
負載平衡器對目標執行運作狀態檢查時使用的通訊協定。可能的通訊協定包括 HTTP、HTTPS 和 TCP。預設為 TCP 通訊協定。如目標類型為 |
TCP |
|
HealthCheckPort |
負載平衡器對目標執行運作狀態檢查時使用的連接埠。預設為使用每個目標從負載平衡器接收流量的連接埠。 |
每個目標從負載平衡器接收流量的連接埠。 |
|
HealthCheckPath |
[HTTP/HTTPS 健全狀況檢查] 健全狀況檢查路徑，做為健全狀況檢查目標上的目的地。預設為 /. |
/ |
|
HealthCheckTimeoutSeconds |
以秒為單位的時間量，若目標在此期間內毫無回應即表示運作狀態檢查失敗。範圍介於 2 到 120 秒之間。針對 HTTP 運作狀態檢查預設值為 6 秒；針對 TCP 與 HTTPS 運作狀態檢查則為 10 秒。 |
針對 HTTP 運作狀態檢查為 6 秒；針對 TCP 與 HTTPS 運作狀態檢查則為 10 秒。 |
|
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 |
目標運作狀態
在負載平衡器向目標傳送運作狀態檢查請求之前，您必須向目標群組註冊該目標，由接聽程式規則中指定其目標群組，並確保負載平衡器已啟用該目標的可用區域。
下表說明已註冊目標的運作狀態可能的值。
| 值 | 描述 |
|---|---|
|
負載平衡器正在註冊目標或對目標執行初始運作狀態檢查。 相關原因代碼： |
|
目標的運作狀態良好。 相關原因代碼：無 |
|
目標未回應健全狀況檢查、未通過健全狀況檢查，或目標處於停止狀態。 相關原因碼： |
|
目標正在取消註冊，連接耗盡作業進行中。 相關原因碼： |
|
目標未回應健康狀態檢查，或未通過健康狀態檢查，進入寬限期。目標支援現有的連線，而且在此寬限期內將不接受任何新連線。 相關原因碼： |
|
目標健全狀態無法使用。 相關原因碼： |
|
目標未向目標群組註冊、目標群組不會用於監聽器規則中，或目標位於未啟用的可用區域中。 相關原因碼： |
運作狀態檢查原因代碼
如果目標的狀態是 Healthy 以外的任何值，API 將傳回問題的原因代碼和描述，而且主控台會以工具提示顯示同樣的描述。請注意，開頭為 Elb 的原因代碼源自負載平衡器端，而開頭為 Target 的原因代碼源自目標端。
| 原因代碼 | 描述 |
|---|---|
|
初始運作狀態檢查正進行中 |
|
運作狀態檢查由於內部錯誤而失敗 |
|
目標註冊正進行中 |
|
目標取消註冊正進行中 |
|
運作狀態檢查失敗 |
|
目標處於停止狀態 目標處於終止狀態 目標處於終止或停止狀態 目標處於無效狀態 |
|
IP 地址不能做為目標，因為負載平衡器正在使用它 |
|
目標群組未設定為接收來自負載平衡器的流量 目標位於負載平衡器未啟用的可用區域 |
|
目標未向目標群組註冊 |
檢查目標的運作狀態
您可以檢查已向目標群組註冊的各個目標的運作狀態。
使用 AWS CLI 檢查目標的運作狀態
使用 describe-target-health 命令。此命令的輸出包含目標的運作狀態。若狀態為 Healthy 以外的任何值，其將附上原因代碼。
接收有關狀態不良目標的電子郵件通知
使用 CloudWatch 警示觸發 Lambda 函數，以傳送有關健康狀態不良目標的詳細資訊。如需 step-by-step 指示，請參閱下列部落格文章：識別負載平衡器運作狀況不良的目標
修改目標群組的運作狀態檢查設定
您可以隨時修改目標群組的運作狀態檢查設定。
使用 AWS CLI 修改目標群組的運作狀態檢查設定
使用 modify-target-group 命令。
