針對 Azure Load Balancer 後端流量回應進行疑難排解Troubleshoot Azure Load Balancer backend traffic responses

本頁面提供 Azure Load Balancer 問題的疑難排解資訊。This page provides troubleshooting information for Azure Load Balancer questions.

負載平衡器後方的 VM 未回應所設定資料連接埠上的流量VMs behind Load Balancer are not responding to traffic on the configured data port

如果後端集區 VM 列為健康狀態良好,而且會回應健康狀態探查,但仍未參與負載平衡,或未回應資料流量,可能是因為下列其中一個原因︰If a backend pool VM is listed as healthy and responds to the health probes, but is still not participating in the Load Balancing, or is not responding to the data traffic, it may be due to any of the following reasons:

  • 負載平衡器後端集區 VM 未接聽資料連接埠Load Balancer Backend pool VM is not listening on the data port
  • 網路安全性群組封鎖負載平衡器後端集區 VM 上的連接埠Network security group is blocking the port on the Load Balancer backend pool VM
  • 從相同的 VM 和 NIC 存取負載平衡器Accessing the Load Balancer from the same VM and NIC
  • 從參與的負載平衡器後端集區 VM 存取網際網路負載平衡器前端Accessing the Internet Load Balancer frontend from the participating Load Balancer backend pool VM

原因 1:負載平衡器後端集區 VM 未接聽資料連接埠Cause 1: Load Balancer backend pool VM is not listening on the data port

如果 VM 未回應資料流量,則可能是因為參與的 VM 上未開啟目標連接埠,或 VM 未接聽該連接埠。If a VM does not respond to the data traffic, it may be because either the target port is not open on the participating VM, or, the VM is not listening on that port.

驗證和解決方式Validation and resolution

  1. 登入後端 VM。Log in to the backend VM.
  2. 開啟命令提示字元並執行下列命令以驗證有應用程式正在接聽資料連接埠︰Open a command prompt and run the following command to validate there is an application listening on the data port:
    netstat -annetstat -an
  3. 如果連接埠未列為 "LISTENING" 狀態,請設定正確的接聽程式連接埠。If the port is not listed with State "LISTENING", configure the proper listener port
  4. 如果連接埠標示為 LISTENING,則請檢查該連接埠上的目標應用程式是否有任何可能的問題。If the port is marked as Listening, then check the target application on that port for any possible issues.

原因 2:網路安全性群組封鎖負載平衡器後端集區 VM 上的連接埠Cause 2: Network security group is blocking the port on the Load Balancer backend pool VM

如果在子網路或 VM 上設定的一或多個網路安全性群組封鎖來源 IP 或連接埠,VM 就無法回應。If one or more network security groups configured on the subnet or on the VM, is blocking the source IP or port, then the VM is unable to respond.

對於公用負載平衡器,網際網路用戶端的 IP 位址將會用於用戶端與負載平衡器後端 VM 之間的通訊。For the public load balancer, the IP address of the Internet clients will be used for communication between the clients and the load balancer backend VMs. 請確定後端 VM 的網路安全性群組中允許用戶端的 IP 位址。Make sure the IP address of the clients are allowed in the backend VM's network security group.

  1. 列出在後端 VM 上設定的網路安全性群組。List the network security groups configured on the backend VM. 如需詳細資訊,請參閱管理網路安全性群組For more information, see Manage network security groups
  2. 從網路安全性群組的清單中,檢查︰From the list of network security groups, check if:
    • 資料連接埠上的傳入或傳出流量是否有干擾。the incoming or outgoing traffic on the data port has interference.
    • VM 之 NIC 上或子網路上的 [全部拒絕] 網路安全性群組規則的優先順序是否高於允許負載平衡器探查與流量的預設規則 (網路安全性群組必須允許 168.63.129.16 的負載平衡器 IP,亦即探查連接埠)。a Deny All network security group rule on the NIC of the VM or the subnet that has a higher priority that the default rule that allows Load Balancer probes and traffic (network security groups must allow Load Balancer IP of 168.63.129.16, that is probe port)
  3. 如果有任何規則封鎖流量,請移除並重新設定這些規則以允許資料流量。If any of the rules are blocking the traffic, remove and reconfigure those rules to allow the data traffic.
  4. 測試 VM 現在是否已開始回應健康狀態探查。Test if the VM has now started to respond to the health probes.

原因 3:從相同的 VM 和網路介面存取負載平衡器Cause 3: Accessing the Load Balancer from the same VM and Network interface

如果負載平衡器之後端 VM 中裝載的應用程式嘗試透過相同的網路介面存取相同後端 VM 中裝載的另一個應用程式,這是不支援的案例,因此將會失敗。If your application hosted in the backend VM of a Load Balancer is trying to access another application hosted in the same backend VM over the same Network Interface, it is an unsupported scenario and will fail.

解決方式 您可以透過下列其中一個方法解決這個問題:Resolution You can resolve this issue via one of the following methods:

  • 每個應用程式都設定個別的後端集區 VM。Configure separate backend pool VMs per application.
  • 在有兩個 NIC 的 VM 中設定應用程式,讓每個應用程式使用自己的網路介面和 IP 位址。Configure the application in dual NIC VMs so each application was using its own Network interface and IP address.

原因 4:從參與的負載平衡器後端集區 VM 存取內部負載平衡器前端Cause 4: Accessing the internal Load Balancer frontend from the participating Load Balancer backend pool VM

如果在 VNet 內設定內部 Load Balancer,且其中一個參與的後端 VM 嘗試存取內部 Load Balancer 前端,則當流程對應至原始 VM 時,會發生失敗。If an internal Load Balancer is configured inside a VNet, and one of the participant backend VMs is trying to access the internal Load Balancer frontend, failures can occur when the flow is mapped to the originating VM. 不支援此狀況。This scenario is not supported.

解決方式 有數種方式可為此案例排除障礙,包括使用 Proxy。Resolution There are several ways to unblock this scenario, including using a proxy. 請評估使用應用程式閘道或其他第三方 Proxy (例如 nginx 或 haproxy)。Evaluate Application Gateway or other 3rd party proxies (for example, nginx or haproxy). 如需應用程式閘道的詳細資訊,請參閱應用程式閘道的概觀For more information about Application Gateway, see Overview of Application Gateway

詳細資料 內部 Load Balancer 不會將輸出起始連線轉譯為內部 負載平衡器的前端,因為這兩者都位於私人 IP 位址空間中。Details Internal Load Balancers don't translate outbound originated connections to the front end of an internal Load Balancer because both are in private IP address space. 公用 Load Balancer 提供從虛擬網路內的私人 IP 位址到公用 IP 位址的輸出連線Public Load Balancers provide outbound connections from private IP addresses inside the virtual network to public IP addresses. 對於內部 Load Balancer,此方法可避免在無需轉譯的專屬內部 IP 位址空間中將 SNAT 連接埠耗盡。For internal Load Balancers, this approach avoids potential SNAT port exhaustion inside a unique internal IP address space, where translation isn't required.

其副作用是,如果後端集區 VM 的輸出流程嘗試將流量流程至其集區中的內部 Load Balancer 前端,並且對應回本身,則這兩個流程互不相符。A side effect is that if an outbound flow from a VM in the back-end pool attempts a flow to front end of the internal Load Balancer in its pool and is mapped back to itself, the two legs of the flow don't match. 由於兩者不相符,流程將會失敗。Because they don't match, the flow fails. 如果流程未對應回後端集區中建立前端流程的相同 VM,流程就會成功。The flow succeeds if the flow didn't map back to the same VM in the back-end pool that created the flow to the front end.

當流程對應回本身時,傳出流程似乎是來自 VM 而傳至前端,而對應的傳入流程似乎來自 VM 至而傳至本身。When the flow maps back to itself, the outbound flow appears to originate from the VM to the front end and the corresponding inbound flow appears to originate from the VM to itself. 以客體作業系統來看,相同流程的傳入和傳出部分在虛擬機器內部不相符。From the guest operating system's point of view, the inbound and outbound parts of the same flow don't match inside the virtual machine. TCP 堆疊無法將其中半數的流程視為相同流程的一部分。The TCP stack won't recognize these halves of the same flow as being part of the same flow. 來源與目的地不相符。The source and destination don't match. 當流程對應至後端集區中的任何其他 VM 時,半數流程將會相符,而 VM 就能回應流程。When the flow maps to any other VM in the back-end pool, the halves of the flow do match and the VM can respond to the flow.

此案例的徵兆是當流量回到其源自的相同後端時,發生間歇性連線逾時。The symptom for this scenario is intermittent connection timeouts when the flow returns to the same backend that originated the flow. 常見的因應措施包括在內部 Load Balancer 後方插入 Proxy 層,以及使用伺服器直接回傳 (DSR) 樣式規則。Common workarounds include insertion of a proxy layer behind the internal Load Balancer and using Direct Server Return (DSR) style rules. 如需詳細資訊,請參閱多個 Azure Load Balancer 前端For more information, see Multiple Frontends for Azure Load Balancer.

您可以結合內部 Load Balancer 與任何第三方 Proxy,或將內部應用程式閘道用於使用 HTTP/HTTPS 的 Proxy 案例。You can combine an internal Load Balancer with any third-party proxy or use internal Application Gateway for proxy scenarios with HTTP/HTTPS. 儘管可以使用公用 Load Balancer 來緩解此問題,但產生的案例容易造成 SNAT 耗盡While you could use a public Load Balancer to mitigate this issue, the resulting scenario is prone to SNAT exhaustion. 除非謹慎管理,否則請避免使用此替代方法。Avoid this second approach unless carefully managed.

後續步驟Next steps

如果上述步驟無法解決問題,請開啟 支援票證If the preceding steps do not resolve the issue, open a support ticket.