本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Network Load Balancer 疑難排解
<a name="load-balancer-troubleshooting"></a>

以下資訊可協助您就 Network Load Balancer 問題進行疑難排解。

## 已註冊目標處於非服務中狀態
<a name="target-not-in-service"></a>

如果目標進入 `InService` 狀態所花的時間超過預期，表示該目標可能未通過運作狀態檢查。您的目標將處於非服務中狀態，除非通過一次運作狀態檢查。如需詳細資訊，請參閱[Network Load Balancer 目標群組的運作狀態檢查](target-group-health-checks.md)。

確認您的執行個體是否未通過運作狀態檢查，然後檢查以下各項：

**安全群組不允許流量**  
與執行個體相關聯的安全群組必須允許由負載平衡器使用運作狀態檢查連接埠和運作狀態檢查通訊協定傳來的流量。如需詳細資訊，請參閱[目標安全群組](target-group-register-targets.md#target-security-groups)。此外，負載平衡器的安全群組必須允許對執行個體的流量。如需詳細資訊，請參閱[更新 Network Load Balancer 的安全群組](load-balancer-security-groups.md)。

**網路存取控制清單 (ACL) 不允許流量**  
關聯執行個體子網路的網路 ACL 以及負載平衡器的子網路必須允許負載平衡器的流量與運作狀態檢查。如需詳細資訊，請參閱[網路 ACL](target-group-register-targets.md#network-acls)。

## 請求未路由至目標
<a name="requests-not-routed"></a>

檢查以下各項：

**安全群組不允許流量**  
與執行個體相關聯的安全群組必須允許透過接聽程式連接埠來自用戶端 IP 地址的流量 (若目標是由執行個體 ID 指定) 或來自負載平衡器節點的流量 (若目標是由 IP 地址指定)。如需詳細資訊，請參閱[目標安全群組](target-group-register-targets.md#target-security-groups)。此外，負載平衡器的安全群組必須允許對執行個體的流量。如需詳細資訊，請參閱[更新 Network Load Balancer 的安全群組](load-balancer-security-groups.md)。

**網路存取控制清單 (ACL) 不允許流量**  
與 VPC 的子網路相關聯的網路 ACL 必須允許負載平衡器和目標透過接聽程式連接埠進行雙向通訊。如需詳細資訊，請參閱[網路 ACL](target-group-register-targets.md#network-acls)。

**目標位於未啟用的可用區域**  
如果您在某個可用區域內註冊目標但未啟用該可用區域，這些已註冊目標將不會接收來自負載平衡器的流量。

**執行個體位於對等的 VPC**  
如果您在與負載平衡器 VPC 對等的 VPC 中有執行個體，您必須依 IP 地址向負載平衡器註冊這些執行個體，而不是依執行個體 ID。

**設定的伺服器 ID 與目標上設定的 ID 不相符**  
如果您使用的是 QUIC 接聽程式，請確定在目標上設定的 ID 符合使用 Network Load Balancer 目標群組設定的 ID。

## 目標接收到比預期更多的運作狀態檢查請求
<a name="health-check-interval"></a>

Network Load Balancer 的運作狀態檢查為分散式，並採用共識機制判定目標的運作狀態。因此，目標會接收超過由 `HealthCheckIntervalSeconds` 所設定次數的運作狀態檢查。

## 目標接收到比預期更少的運作狀態檢查請求
<a name="too-few-health-checks"></a>

檢查是否已啟用 `net.ipv4.tcp_tw_recycle`。此設定已知將導致負載平衡器出問題。使用 `net.ipv4.tcp_tw_reuse` 設定是較為安全的替代方法。

## 運作狀態不佳的目標接收到來自負載平衡器的請求
<a name="no-healthy-targets"></a>

當所有已登錄目標運作狀態均不佳時，就會發生此情況。如至少有一個運作狀態良好的已登錄目標，則 Network Load Balancer 僅會路由請求至運作狀態良好的已登錄目標。

若僅存在運作狀態不佳的已登錄目標，則 Network Load Balancer 會路由請求至所有已登錄目標，這稱為故障開放模式。當所有目標運作狀態均不佳且其各自可用區域均無可傳送請求的運作狀態良好目標時，Network Load Balancer 會執行此動作，而非從 DNS 移除所有 IP 地址。

## 目標因為主機標頭不相符而無法進行 HTTP 或 HTTPS 運作狀態檢查
<a name="host-header-mismatch"></a>

運作狀態檢查請求中的 HTTP 主機標頭包含負載平衡器節點的 IP 地址和接聽程式連接埠 (而不是目標的 IP 位址和運作狀態檢查連接埠)。如果您透過主機標頭映射傳入請求，則必須確保運作狀態檢查符合任何 HTTP 主機標頭。另一個選項是在不同的連接埠上新增個別的 HTTP 服務，並將目標群組設定為使用該連接埠進行運作狀態檢查。或者，請考慮使用 TCP 運作狀態檢查。

## 無法關聯安全群組與負載平衡器
<a name="load-balancer-security-groups-add"></a>

如 Network Load Balancer 於建立時無安全群組，則在建立之後將無法支援安全群組。您僅能在建立期間關聯安全群組與負載平衡器，或關聯原本利用安全群組建立的現有負載平衡器。

## 無法移除所有安全群組
<a name="load-balancer-security-groups-remove"></a>

如 Network Load Balancer 於建立時具安全群組，則必須至少隨時有一個與其關聯的安全群組。您無法同時從負載平衡器移除所有安全群組。

## 增加 TCP\$1ELB\$1Reset\$1Count 指標
<a name="elb-reset-count-metric"></a>

對於用戶端透過 Network Load Balancer 做出的每項 TCP 請求，將追蹤該連線狀態。若在比閒置逾時更長的時間內沒有由用戶端或目標透過連線傳送的資料，連線將關閉。如果用戶端或目標閒置逾時時間經過後傳送資料，就會收到一個 TCP RST 封包，表示連線不再有效。此外，如目標的運作狀態變為不佳，負載平衡器會針對關聯目標的用戶端連線所接收的封包傳送 TCP RST，除非運作狀態不佳的目標觸發負載平衡器進入故障開放。

如您在 `TCP_ELB_Reset_Count` 指標增加之前或增加當時看到 `UnhealthyHostCount` 指標遽增，很可能是因為目標開始出現故障但尚未標示為運作狀態不佳而傳送 TCP RST 封包。如您看到目標未標示為運作狀態不佳，但 `TCP_ELB_Reset_Count` 持續增加，您可檢查 VPC Flow Logs，了解是否有用戶端透過過期流量傳送資料。

## 目標向其負載平衡器發出的請求連線逾時
<a name="loopback-timeout"></a>

檢查目標群組是否啟用用戶端 IP 保留。當啟用用戶端 IP 保留時，不支援 NAT 迴路，也稱為假髮釘設定。

如果執行個體是向其註冊的負載平衡器的用戶端，且其已啟用用戶端 IP 保留，則只有在請求路由到不同的執行個體時，連線才會成功。如路由請求至傳送來源的相同執行個體，則連線會因來源與目的地 IP 地址相同而逾時。請注意，這適用於在相同 EC2 工作者節點執行個體中執行的 Amazon EKS Pod，即使它們具有不同的 IP 地址。

如果執行個體必須傳送請求至其註冊的負載平衡器，請執行以下其中一項操作：
+ 停用用戶端 IP 保留。反之，請使用 Proxy Protocol v2 來取得用戶端 IP 地址。
+ 確保必須相互通訊的各容器位於不同的容器執行個體。

## 若將目標移至 Network Load Balancer，效能會下降
<a name="load-balancer-performance"></a>

Classic Load Balancer 與 Application Load Balancer 均採用多工處理，但 Network Load Balancer 並非如此。因此，在 Network Load Balancer 後方的目標可接收更多 TCP 連線。請確定您的目標已準備好處理其可能接收到的連線請求量。

## 後端流程的連接埠配置錯誤
<a name="port-allocation-errors-privatelink"></a>

使用 PrivateLink 流量或停用[用戶端 IP 保留](edit-target-group-attributes.md#client-ip-preservation)時，Network Load Balancer 支援與每個唯一目標 (IP 地址和連接埠） 每分鐘 55，000 個同時連線或約 55，000 個連線。如果您超過這些限制，連接埠配置錯誤的機率會增加。您可以使用 `PortAllocationErrorCount` 指標追蹤連接埠配置錯誤。您可以使用 `ActiveFlowCount` 指標追蹤作用中的連線。如需詳細資訊，請參閱[Network Load Balancer 的CloudWatch 指標](load-balancer-cloudwatch-metrics.md)。

若要修正連接埠配置錯誤，建議您將目標新增至目標群組。

或者，如果您無法將目標新增至目標群組，則可以將最多 7 個[次要 IP 地址](edit-load-balancer-attributes.md#secondary-ip-addresses)新增至負載平衡器網路介面。次要 IP 地址會從對應子網路的 IPv4 CIDR 區塊自動配置。每個次要 IP 地址會耗用 6 個網路定址單位。請注意，在新增次要 IP 地址之後，您無法將其移除。釋放次要 IP 地址的唯一方法是刪除負載平衡器。

## 間歇 TCP 連線建立失敗或 TCP 連線建立延遲
<a name="intermittent-connection-failure"></a>

啟用用戶端 IP 地址保留時，用戶端可能會使用相同的來源暫時性連接埠連線到不同的目的地 IP 地址。啟用跨區域負載平衡或使用相同目標 IP 地址和註冊連接埠的不同 Network Load Balancer 時，這些目的地 IP 地址可以來自相同的負載平衡器 （位於不同的可用區域）。在這種情況下，如果這些連線路由到相同的目標 IP 地址和連接埠，目標將看到重複的連線，因為它們來自相同的用戶端 IP 地址和連接埠。這會導致建立其中一個連線時發生連線錯誤和延遲。當用戶端前方的 NAT 裝置，以及同時連線至多個 Network Load Balancer IP 地址時配置相同的來源 IP 地址和來源連接埠時，就會經常發生這種情況。

您可以透過增加用戶端或 NAT 裝置配置的來源暫時性連接埠數目，或增加負載平衡器的目標數目，來減少這種類型的連線錯誤。我們建議用戶端在這些連線失敗後變更重新連線時使用的來源連接埠。為了防止這種類型的連線錯誤，如果您使用單一 Network Load Balancer，您可以考慮停用跨區域負載平衡，或者如果使用多個 Network Load Balancer，您可以考慮不使用在多個目標群組中註冊的相同目標 IP 地址和連接埠。或者，您可以考慮停用用戶端 IP 保留。如果您需要用戶端 IP，您可以使用 Proxy Protocol v2 擷取用戶端 IP。若要進一步了解 Proxy Protocol v2，請參閱 [Proxy Protocol (代理通訊協定)](edit-target-group-attributes.md#proxy-protocol)。

## 佈建負載平衡器時的潛在故障
<a name="load-balancer-provision-failure"></a>

Network Load Balancer 在佈建時可能失敗的其中一個原因是，您使用已指派或配置到其他地方的 IP 地址 (例如，指派為 EC2 執行個體的次要 IP 地址)。此 IP 地址會讓負載平衡器無法進行設定，且其狀態為 `failed`。您可取消配置關聯的 IP 地址並重試建立程序來解決此問題。

## 流量在目標之間分佈不均勻
<a name="uneven-traffic-distribution"></a>

TCP 和 TLS 接聽程式路由 TCP 連線，UDP 接聽程式路由 UDP 串流。負載平衡器會使用流程雜湊演算法選取目標。來自用戶端的單一連線本質上是黏性的。

如果您注意到某些目標似乎比其他目標接收更多流量，建議您檢閱 VPC 流程日誌。比較每個目標 IP 地址的唯一連線數量。盡可能縮短時間範圍，因為目標註冊、取消註冊和運作狀態不佳的目標會影響這些連線號碼。

以下是連線可能分佈不均勻的可能案例：
+ 如果您從少量目標開始，然後稍後註冊其他目標，則原始目標仍會與用戶端連線。使用 HTTP 工作負載時，保持連線可確保用戶端重複使用連線。如果您降低 Web 應用程式的最大保持連線，用戶端會更頻繁地開啟新的連線。
+ 如果啟用目標群組黏性，則會有少量用戶端，而用戶端會透過具有單一來源 IP 地址的 NAT 裝置進行通訊，這些用戶端的連線會路由至相同的目標。
+ 如果停用跨區域負載平衡，且用戶端偏好來自其中一個負載平衡器區域的負載平衡器 IP 地址，則會在負載平衡器區域之間不平均地分配連線。

## DNS 名稱解析所包含的 IP 地址少於已啟用可用區域
<a name="dns-name-resolution"></a>

在理想情況，當可用區域至少有一個運作狀態良好的主機時，Network Load Balancer 會為每個已啟用的可用區域提供單一 IP 地址。若特定可用區域無運作狀態良好的主機，且已停用跨區域負載平衡，則該 AZ 的個別 Network Load Balancer IP 地址將從 DNS 移除。

例如，假設您的 Network Load Balancer 啟用三個可用區域，所有這些區域至少都有一個運作狀態良好的已登錄目標執行個體。
+ 如可用區域 A 的已登錄目標執行個體運作狀態變為不佳，則會從 DNS 移除 Network Load Balancer 可用區域 A 的對應 IP 地址。
+ 如任何兩個已啟用的可用區域無運作狀態良好的已登錄目標執行個體，則 Network Load Balancer 的相應兩個 IP 地址將從 DNS 移除。
+ 如所有已啟用的可用區域均無運作狀態良好的已登錄目標執行個體，則會啟用故障開放模式，而 DNS 會因此提供來自三個已啟用 AZ 的所有 IP 地址。

## IP 分段封包不會路由到目標
<a name="ip-fragmented-packets"></a>

Network Load Balancer 不支援非 UDP 流量的 IP 分段封包。

## 使用資源映射對運作狀態不佳的目標進行故障診斷
<a name="troubleshoot-with-resourcemap"></a>

如果您的 Network Load Balancer 目標未通過運作狀態檢查，您可以使用資源映射來尋找運作狀態不佳的目標，並根據失敗原因代碼採取動作。如需詳細資訊，請參閱[檢視 Network Load Balancer 資源映射](view-resource-map.md)。

資源映射提供兩種檢視：**概觀**和**運作狀態不佳的目標映射**。預設會選取**概觀**，並顯示所有負載平衡器的資源。選取**運作狀態不佳的目標映射**檢視只會顯示與 Network Load Balancer 相關聯的每個目標群組中運作狀態不佳的目標。

**注意**  
必須啟用**顯示資源詳細資訊**，才能檢視資源映射中所有適用資源的運作狀態檢查摘要和錯誤訊息。未啟用時，您必須選取每個資源以檢視其詳細資訊。

**目標群組**欄會顯示每個目標群組運作狀態良好和運作狀態不佳目標的摘要。這有助於判斷所有目標是否未通過運作狀態檢查，或只有特定目標未通過。如果目標群組中的所有目標都未通過運作狀態檢查，請檢查目標群組的運作狀態檢查設定。選取目標群組的名稱，以在新標籤中開啟其詳細資訊頁面。

**目標**欄會顯示每個目標的 TargetID 和目前運作狀態檢查狀態。當目標運作狀態不佳時，會顯示運作狀態檢查失敗原因代碼。當單一目標未通過運作狀態檢查時，請確認目標有足夠的資源。選取目標的 ID，在新標籤中開啟其詳細資訊頁面。

選取**匯出**可讓您選擇將 Network Load Balancer 資源映射的目前檢視匯出為 PDF。

確認您的執行個體運作狀態檢查失敗，然後根據故障原因程式碼檢查下列問題：
+ **運作狀態不佳：請求逾時**
  + 確認與您的目標和 Network Load Balancer 相關聯的安全群組和網路存取控制清單 (ACL) 未封鎖連線。
  + 確認目標有足夠的容量可以接受來自 Network Load Balancer 的連線。
  + 您可以在每個目標的應用程式日誌中檢視 Network Load Balancer 的運作狀態檢查回應。如需詳細資訊，請參閱[運作狀態檢查原因代碼](target-group-health-checks.md#target-health-reason-codes)。
+ **運作狀態不佳：FailedHealthChecks**
  + 確認目標正在接聽運作狀態檢查連接埠上的流量。
**使用 TLS 接聽程式時**  
您可以選擇用於前端連線的安全政策。用於後端連線的安全政策會根據使用的前端安全政策自動選取。如果您的任何接聽程式有：  
**FIPS 後量子 TLS 政策** - 後端連線使用 `ELBSecurityPolicy-TLS13-1-0-FIPS-PQ-2025-09`
**FIPS 政策** - 後端連線使用 `ELBSecurityPolicy-TLS13-1-0-FIPS-2023-04`
**後量子 TLS 政策** - 後端連線使用 `ELBSecurityPolicy-TLS13-1-0-PQ-2025-09`
**TLS 1.3 政策** - 後端連線使用 `ELBSecurityPolicy-TLS13-1-0-2021-06`
所有其他 TLS 政策後端連線都使用 `ELBSecurityPolicy-2016-08`
如需詳細資訊，請參閱 [安全政策](describe-ssl-policies.md)。
  + 驗證目標是否以安全政策指定的正確格式提供伺服器憑證和金鑰。
  + 確認目標支援一或多個相符的密碼，以及 Network Load Balancer 提供的通訊協定來建立 TLS 交握。