Azure负载均衡器配置修改后不生效问题咨询

看起来你遇到的是配置显示生效但实际流量路由未变化的典型LB问题，我来帮你梳理几个最可能的遗漏点和排查步骤：

1. 优先检查后端池的健康探针状态 #

Azure LB只会把流量转发给通过健康探针检查的后端VM。即使你交换了后端池的配置，如果新池里的VM没通过探针，LB依然不会把流量导过去。

• 你可以在Azure门户的负载均衡器→后端池页面，查看每个VM的健康状态（绿色对勾是正常，红色叉是异常）。
• 用PowerShell验证：

  $rgName = "你的资源组名称"
  $lbName = "你的负载均衡器名称"
  $lb = Get-AzureRmLoadBalancer -ResourceGroupName $rgName -Name $lbName
  
  # 遍历所有后端池，查看健康状态
  foreach ($pool in $lb.BackendAddressPools) {
      Write-Host "=== 后端池: $($pool.Name) ==="
      $health = Get-AzureRmLoadBalancerBackendAddressPoolHealth -ResourceGroupName $rgName -LoadBalancerName $lbName -Name $pool.Name
      $health.HealthStatus
      $health.BackendAddresses | Select-Object Name, HealthStatus
  }
  

如果探针失败，先排查探针的端口、路径是否和VM上的服务匹配，VM的防火墙/NSG是否允许探针流量。

2. 会话亲和性导致旧连接保持在原后端池 #

如果你的负载均衡规则启用了会话亲和性（比如源IP、源IP+端口），已建立的TCP连接会被LB固定在原来的后端池，只有新发起的连接才会使用更新后的后端池配置。

• 检查规则的会话亲和性设置：

  $lb.LoadBalancingRules | Select-Object Name, SessionAffinity, SessionAffinityTimeoutInMinutes
  

• 测试时要使用新的客户端（或重启本地网络连接）发起请求，不要复用之前的旧连接，否则你会误以为LB没生效。

3. 确认Set-AzureRmLoadBalancer的执行是否完整 #

有时候如果只修改了负载均衡规则的局部属性，没有把完整的LB对象传递给Set-AzureRmLoadBalancer，可能会导致配置更新不彻底。建议检查你的脚本是否是以下正确流程：

# 1. 获取完整的LB对象
$lb = Get-AzureRmLoadBalancer -ResourceGroupName $rgName -Name $lbName

# 2. 交换两个规则的后端池（示例逻辑）
$tempPool = $lb.LoadBalancingRules[0].BackendAddressPool
$lb.LoadBalancingRules[0].BackendAddressPool = $lb.LoadBalancingRules[1].BackendAddressPool
$lb.LoadBalancingRules[1].BackendAddressPool = $tempPool

# 3. 提交完整的LB对象更新
Set-AzureRmLoadBalancer -LoadBalancer $lb

如果你的脚本跳过了获取完整对象的步骤，直接构造规则更新，可能会丢失其他依赖配置，导致实际生效异常。

4. 排查NSG/防火墙的流量拦截 #

新后端池中的VM对应的NSG（网络安全组）可能没有配置允许来自LB前端端口的入站流量。比如原来的后端池NSG允许80端口，但新池的NSG拒绝了，这会导致LB虽然把流量发过去，但VM接收不到，看起来LB没生效。

• 检查新后端池关联的NSG入站规则，确保允许LB规则对应的端口（比如HTTP的80、HTTPS的443）。

5. 考虑Azure配置传播延迟 #

虽然门户和Get-AzureRmLoadBalancer显示配置已更新，但Azure内部的配置同步可能需要几分钟时间（尤其是跨区域场景）。如果以上排查都没问题，可以等待10-15分钟后再测试新的连接。

内容的提问来源于stack exchange，提问作者albattran