很多.NET团队做高可用，第一反应是上Nginx或云厂商的ALB，往往忽略了Windows Server自带的NLB。NLB不需要额外买软件，不用改代码，在Windows生态里开箱即用。但它也有明显的局限——不检测应用健康、网络配置稍有不慎就翻车。这篇把NLB是什么、怎么接、适合谁、坑在哪说清楚，帮你快速判断它值不值得用。
NLB 是什么
NLB（Network Load Balancing）是Windows Server操作系统内置的网络负载均衡功能。它工作在传输层（第四层），基于TCP/IP协议将客户端请求分发到集群中的多台服务器上。NLB集群对外暴露一个虚拟IP地址（VIP），客户端访问这个VIP，NLB根据配置的端口规则将流量转发到集群内某台真实服务器。
官网：
https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-load-balancing
GitHub（PowerShell模块文档）：
https://github.com/MicrosoftDocs/windows-powershell-docs/tree/main/docset/winserver2025-ps/NetworkLoadBalancingClusters
核心机制与工程价值：
集群化流量分发：
最多支持32台服务器组成一个NLB集群，所有节点共享同一个虚拟IP。客户端感知不到后端有多台服务器，集群表现为一个逻辑节点。 故障自动剔除：
NLB节点之间通过心跳检测（默认每秒一个心跳包）判断彼此存活状态。节点离线后，流量在数秒内自动重新分发到其他节点。但要注意：NLB只检测节点是否在线，不检测应用程序是否正常工作——IIS停了，NLB照常把请求发过去。 三种运行模式：
单播（Unicast）、多播（Multicast）、IGMP多播。单播配置最简单但可能导致交换机洪泛；多播和IGMP多播对带宽利用更友好，但需要网络设备支持静态ARP或IGMP Snooping。集群内所有节点必须使用同一种模式。 无需改代码：
NLB工作在操作系统层面，应用本身不需要任何改造——这对遗留.NET Framework应用尤其友好。 运维成本低：
通过Windows Server的“网络负载平衡管理器”或PowerShell的 NetworkLoadBalancingClusters模块管理，Windows运维人员上手成本低。支持非HTTP协议：
NLB工作在四层，不仅能负载均衡IIS的HTTP/HTTPS流量，还能支持WCF服务、自定义TCP绑定的Windows服务、.NET Remoting甚至FTP服务。这些老项目往往没有现成的七层代理方案，NLB几乎是唯一不改代码就能实现高可用的路径。
怎么引入
NLB是Windows Server功能，不需要额外下载安装包。在每台要加入集群的服务器上通过服务器管理器添加角色和功能，勾选“网络负载平衡”即可。
PowerShell脚本接入方式（适合批量自动化部署）
以下脚本在首台节点（WEB01）上执行，创建集群并添加第二台节点：
# 1. 安装NLB功能（所有节点都需要执行，建议加上管理工具）
Install-WindowsFeature -Name NLB -IncludeManagementTools
# 2. 在首台节点（WEB01）上创建集群
# -InterfaceName 需替换为实际网卡名称，可通过 Get-NetAdapter 查看
New-NlbCluster -ClusterPrimaryIP "192.168.1.100" `
-InterfaceName "Ethernet" `
-OperationMode Unicast
# 3. 将默认的“所有端口（0-65535）”规则删掉
# NLB默认放行所有端口，生产环境建议精细化管理
Get-NlbClusterPortRule | Remove-NlbClusterPortRule -Force
# 4. 精确添加80端口规则（利用管道规避ClusterName参数不存在的Bug）
Get-NlbCluster |Add-NlbClusterPortRule -StartPort 80-EndPort 80-Protocol TCP -Affinity Single
# 5. 将第二台节点（WEB02）拉入集群
# -HostName 指定现有集群中的任一节点，-NewNodeName 指定新节点
Add-NlbClusterNode -HostName "WEB01" `
-NewNodeName "WEB02" `
-NewNodeInterface "Ethernet"图形化和脚本方式可混用——界面上创建的集群同样可以通过PowerShell管理，反之亦然。两种方式选择取决于团队习惯：少量服务器、临时测试用图形界面更直观；大批量部署或自动化运维场景建议优先脚本。
必须项：
每台节点的NLB功能已安装 每台节点配置静态IP（不能用DHCP） 集群虚拟IP与节点真实IP在同一子网 所有节点操作系统版本一致（跨版本混用存在兼容性风险） 集群内所有节点使用相同的操作模式
可选项：
双网卡：建议业务网卡和NLB心跳通信使用不同网卡 IGMP多播模式：如果交换机支持IGMP Snooping，可考虑启用 Drainstop：节点下线前先用 Drainstop排空现有连接，避免连接中断
验证是否接入成功：
打开“网络负载平衡管理器”，确认所有节点状态为“已聚合”（绿色对勾） 从客户端ping集群虚拟IP，确认可达 访问集群VIP上的服务（如HTTP），确认能正常返回 手动停止其中一台节点的NLB服务（管理器右键节点 → “停止”，或 Stop-NlbClusterNode -NodeName WEB01），观察流量是否在数秒内切换到其他节点
快速上手
示例1：最小可用接入——两台IIS服务器构成NLB集群
目标：两台Windows Server（WEB01、WEB02）上部署相同的IIS站点，通过NLB集群VIP对外提供服务。
前置条件：两台服务器已安装IIS，站点内容已同步（可用DFS或手动复制）。
PowerShell配置（在WEB01上执行）：
# 在WEB01和WEB02上分别安装NLB
Install-WindowsFeature -Name NLB -IncludeManagementTools
# WEB01上创建集群，VIP为192.168.1.100
New-NlbCluster -ClusterPrimaryIP "192.168.1.100" `
-InterfaceName "Ethernet" `
-OperationMode Unicast
# 删除默认端口规则
Get-NlbClusterPortRule | Remove-NlbClusterPortRule -Force
# 添加80端口规则
Get-NlbCluster |Add-NlbClusterPortRule -StartPort 80-EndPort 80-Protocol TCP -Affinity Single
# 添加WEB02到集群
Add-NlbClusterNode -HostName "WEB01" `
-NewNodeName "WEB02" `
-NewNodeInterface "Ethernet"预期输出：NLB管理器显示两个节点状态均为“已聚合”。客户端访问http://192.168.1.100能看到站点页面。
验证步骤：
访问VIP，确认页面正常返回 停止WEB01的NLB服务（管理器右键节点 → “停止”，或 Stop-NlbClusterNode -NodeName WEB01），再次访问VIP，确认请求被转发到WEB02重新启动WEB01的NLB服务（管理器右键节点 → “启动”），等待状态恢复“已聚合”
示例2：典型业务场景——ASP.NET Core应用+NLB + Redis共享Session
目标：多台服务器运行同一套ASP.NET Core应用，通过NLB分发流量，Session状态存储在Redis中，实现无状态水平扩展。
关键依赖：每台服务器安装.NET运行时；Redis作为分布式缓存（独立部署或云服务）。
核心配置（Program.cs）：
var builder = WebApplication.CreateBuilder(args);
// 配置Redis作为分布式Session存储
builder.Services.AddDistributedRedisCache(options =>
{
options.Configuration = "192.168.1.200:6379"; // Redis地址
options.InstanceName = "Session";
});
builder.Services.AddSession(options =>
{
options.IdleTimeout = TimeSpan.FromMinutes(30);
options.Cookie.HttpOnly = true;
options.Cookie.IsEssential = true;
});
var app = builder.Build();
app.UseSession();
app.MapGet("/", (HttpContext ctx) =>
{
var count = ctx.Session.GetInt32("Count") ?? 0;
count++;
ctx.Session.SetInt32("Count", count);
return$"访问次数：{count}，节点：{Environment.MachineName}";
});
app.Run();NLB端口规则配置（与示例1相同，80端口，亲和性选“单一”或“无”均可——因为Session已外置，不需要保持会话粘滞，选“无”可实现更均匀的轮询分发）。
预期输出：多次刷新页面，Environment.MachineName可能在WEB01和WEB02之间切换（取决于NLB的分发策略），但Session中的计数持续累加——说明Session在Redis中共享。
验证步骤：
在WEB01和WEB02上分别部署同一应用 配置NLB集群VIP 多次访问VIP，确认Session状态不丢失 停止其中一台节点的NLB服务，确认Session仍然可用
示例3：典型业务场景——HTTPS站点（NLB四层透传）
目标：NLB在四层透传TCP 443流量，SSL证书在每台后端服务器上独立配置，NLB不做SSL卸载。
图形化配置： 在端口规则页面添加443端口的规则，协议选TCP，亲和性选“单一”。
PowerShell配置：
Get-NlbCluster | Add-NlbClusterPortRule -StartPort 443 -EndPort 443 -Protocol TCP -Affinity Single
后端IIS绑定SSL证书（每台服务器独立导入证书，绑定到443端口）。
预期输出：客户端访问https://VIP，证书正常、页面正常返回。
验证步骤：
在各节点分别配置SSL证书（证书需一致或使用通配符证书） 通过浏览器访问 https://VIP，确认无证书警告抓包确认NLB没有解密流量，TCP payload原样透传
示例4：进阶能力——通过PowerShell脚本实现自动化节点上下线
目标：发布新版本时，通过脚本将节点从NLB集群中优雅摘除，更新完成后重新加入。
# 将节点置为"排空"状态——停止接收新连接，但保持现有连接
Suspend-NlbClusterNode -NodeName "WEB02"
# 等待现有连接处理完毕（可根据业务自定义等待时间）
Start-Sleep -Seconds 60
# 停止该节点的NLB服务
Stop-NlbClusterNode -NodeName "WEB02"
# ---- 在此执行应用更新 ----
# 启动NLB服务
Start-NlbClusterNode -NodeName "WEB02"
# 恢复节点接收流量
Resume-NlbClusterNode -NodeName "WEB02"图形化对应操作：右键节点 → “控制主机” → “排空” → 等待 → “停止” → 更新完成后右键 → “启动” → 再右键 → “恢复”。
预期输出：节点WEB02进入暂停状态后，新请求不再转发到该节点；已有连接继续服务直至完成。更新完成后恢复。
实战常见报错
AliveMsgTolerance默认值过大，或网络延迟高 | AliveMsgPeriod和AliveMsgTolerance值；检查网络质量 |
适用场景
高并发、无状态服务： NLB工作在四层，转发效率高、延迟低，适合对性能敏感的场景。单实例可支撑亿级并发连接。但如果业务对请求路由有七层需求（如按URL路径分发），NLB做不了——需要用ALB或反向代理。
Windows Server + IIS技术栈： 这是NLB最经典的落地场景。如果你的团队主要维护Windows Server上的.NET应用，NLB与IIS的集成度是最高的，运维成本也最低。
老旧TCP服务的救星： 很多.NET团队的后端还有WCF服务、自定义TCP绑定的Windows服务、.NET Remoting甚至FTP服务。这些场景下，Nginx/ALB这类七层代理要么原生不支持，要么需要大量改造。NLB工作在四层，不管上层协议是HTTP还是TCP，照单全收，这是NLB相比七层方案的独特优势。
微服务架构： 通常不建议直接拿NLB做微服务网关。微服务需要七层路由、灰度发布、熔断降级等能力，NLB只提供四层负载均衡。更常见的做法是：NLB作为入口的第一层（四层负载），后端接API网关（如Ocelot、YARP）或Kubernetes Ingress。
单体应用水平扩展： NLB非常适合。业务逻辑无状态或状态外置（如Session存Redis），加几台服务器、配好NLB，扩展就完成了。代码零改动。
前置条件：
应用必须是无状态或状态已外置（如Session存Redis/数据库）；如有状态应用依赖本地Session，开启 Affinity Single可基于源IP保持会话粘滞，但客户端IP变化或大量用户挤在同一NAT出口时会失效，需自行评估服务器必须在同一二层网络（除非用多播+静态路由） 所有节点操作系统版本需一致 网络设备需支持NLB所选的操作模式
风险：
NLB不检测应用健康，应用进程挂了但节点在线，流量照常转发 单播模式下可能引发交换机洪泛，影响整个网络性能 不支持跨子网集群（除非借助多播+静态路由等复杂配置）
实战建议
高频坑位1：单播模式导致交换机洪泛
触发条件： 采用默认的单播模式，NLB将所有节点的网卡MAC地址修改为同一个虚拟MAC地址。交换机MAC地址表混乱，将发往VIP的流量广播到所有端口。
错误表现： 网络性能骤降，非NLB节点也收到大量无关广播包，严重时整个网段瘫痪。
修复策略：
方案A：改用多播模式（需在交换机配置静态ARP和MAC表项） 方案B：在交换机和NLB节点之间加一台Hub 方案C：为NLB节点单独划分VLAN 方案D：启用IGMP多播模式（需交换机支持IGMP Snooping）
图形化修改操作模式：右键集群 → “群集属性” → “群集参数”选项卡 → 将“群集操作模式”从“单播”改为“多播”或“IGMP多播”。
高频坑位2：应用挂了但节点还在集群里
触发条件： IIS或ASP.NET Core进程崩溃，但操作系统正常运行，NLB心跳正常发送。
错误表现： 部分请求返回500或超时，监控显示节点在线但服务不可用。
修复策略：
部署外部健康检查脚本，定时探测应用端口/健康检查接口，发现问题时通过PowerShell暂停该节点的NLB服务 或在前端再加一层ARR（Application Request Routing），由ARR做七层健康检查 廉价平替方案：用Windows任务计划程序，写一个PowerShell脚本每分钟执行 Invoke-WebRequest访问本机localhost的健康检查接口。如果连续3次返回非200状态码，执行Stop-NlbClusterNode -NodeName $env:COMPUTERNAME让节点自残下线；应用恢复后再通过脚本执行Start-NlbClusterNode -NodeName $env:COMPUTERNAME重新上线。这是成本最低的应用级健康检查方案。
高频坑位3：跨Windows Server版本的节点混用
触发条件： 集群中混用不同版本的Windows Server（如2016和2019）。
错误表现： 节点无法聚合、心跳异常、流量分发不规则。实测跨版本混用存在较高概率的兼容性问题。
修复策略： 所有NLB节点统一使用相同版本的操作系统镜像。规划阶段就明确版本标准，避免临时拼凑。
其他建议
建议为NLB心跳配置独立网卡，避免心跳流量与业务流量互相干扰 节点下线时优先用“排空”（Drainstop）而非直接“停止”，避免粗暴切断现有连接 部署新版本时，逐台摘节点、更新、加回，实现零停机发布 定期检查事件日志中的NLB相关警告（Event ID 34等） 图形化管理器支持远程管理其他服务器的NLB集群：打开管理器 → “群集”菜单 → “连接到现存的” → 输入目标集群的任意节点IP
选型建议
更适合NLB的场景：
团队以Windows Server运维为主，不想引入额外的负载均衡软件 应用是传统的.NET Framework + IIS，改造为容器化或云原生成本高 只需要四层负载均衡，没有七层路由需求 服务器数量不多（2-8台），网络环境可控 对延迟敏感，需要四层的高转发效率 需要负载均衡的服务不是HTTP协议（如WCF、自定义TCP服务、FTP等）
不太适合NLB的场景：
需要七层路由（按URL、Header分发）——选ALB或反向代理（Nginx、YARP） 服务器分布在多个子网或混合云环境——选云厂商LB或软件定义LB 应用严重依赖本地Session，且客户端网络环境复杂（如移动端频繁切换IP，或大量客户端隐匿在同一个企业NAT大网IP后面导致负载极度不均衡）——NLB基于IP的亲和性在NAT场景下会失效 需要细粒度的健康检查（如检查具体API返回值）——NLB只做端口级检测 团队对Linux更熟悉、没有Windows Server运维能力
判断倾向： 如果你的应用跑在Windows Server上、只需要四层负载均衡，NLB是一个值得优先考虑的方案——成本低、上手快、与Windows生态集成好。但如果网络环境复杂或对七层路由有要求，不要把NLB硬撑到它不擅长的领域，前端加一层Nginx或YARP是更稳妥的做法。
参考建议：
小团队（2-3人）、并发量不大（百万级以下）、上线周期紧：NLB可以快速落地 中大规模（并发千万级以上）、有专职运维：建议NLB + ARR组合，或云厂商LB 容器化/K8s环境：不用NLB，用Ingress Controller或Service LoadBalancer
总结收尾
NLB解决的是Windows Server环境下多台服务器之间流量分发和故障转移的问题——开箱即用、不改代码、运维友好。图形化管理器让不熟悉命令行的运维人员也能十分钟内搭起一套集群。但它不检测应用健康、网络配置有坑，也不是七层路由的替代方案。如果你们的应用跑在Windows Server上、无状态、只需要四层负载均衡，NLB值得认真考虑；如果需要七层能力或网络环境复杂，别硬撑，加一层Nginx或YARP更稳妥。先从一个最小集群试起来，把网络模式和健康检查想清楚，再往生产推。
