Windows Network Load Balancing (NLB): How It Works and How to Configure It

Windows Network Load Balancing (NLB) lets multiple Windows Server hosts share a virtual IP address and distribute incoming network traffic. It is a Layer 4 feature for TCP and UDP services, not a reverse proxy or application-aware load balancer.

NLB remains relevant when you operate an existing Windows cluster, but Microsoft now marks it as deprecated and no longer in active feature development. That does not mean it has already been removed; it does mean a new deployment should have a clear compatibility reason and a migration plan. This guide explains the architecture, network requirements, legacy setup workflow, and alternatives.

What Is Windows Network Load Balancing?

NLB is a Windows Server feature that groups two or more hosts into a virtual cluster. Clients connect to a cluster virtual IP (VIP), while each host retains a dedicated IP address for management and host-specific communication. NLB distributes supported TCP or UDP traffic across the cluster according to port rules and affinity settings.

Unlike a standalone appliance or reverse proxy, NLB runs on the cluster hosts and does not terminate and recreate client connections. It provides basic Layer 4 distribution and host-level availability; it does not understand URLs, HTTP status codes, application readiness, or deployment versions.

Why NLB Exists—and Its Limits

NLB was designed to add capacity and tolerate a host becoming unavailable without requiring a separate load-balancer appliance. It is most useful for straightforward, largely stateless services whose clients can reconnect after a node change.

Its limits matter when assessing an existing design:

• NLB has no application-level health probes. A host can remain part of the cluster even when its web service or application is unhealthy.
• It does not provide TLS termination, HTTP path or host routing, a web application firewall, or deployment-aware traffic shifting.
• It does not replicate application data or sessions. Affinity can direct a client’s flows to one host, but it is not a shared session store.
• Failures and membership changes trigger convergence, during which traffic distribution changes and some active connections can be interrupted.
• Microsoft lists NLB as deprecated and recommends evaluating other load-balancing options for new designs.

Before keeping NLB, establish whether the application, operating system, and surrounding network still meet their support and security requirements. For an existing deployment, document an exit path rather than assuming the feature will continue gaining capabilities.

How NLB Works

The request path is:

Client resolves service name → DNS returns the cluster VIP → the network delivers packets to the NLB-enabled hosts → each host applies the cluster’s port rules → one eligible host processes the flow → the response returns to the client.

Each host runs a copy of the application and participates in the same NLB configuration. NLB’s network driver applies a distributed filtering algorithm to incoming traffic; there is no central proxy that accepts a request and then forwards it to a backend. The host’s dedicated IP remains available for administration, while clients normally use the VIP.

Hosts exchange heartbeat information. If a host leaves or rejoins, the remaining hosts converge on a new distribution. Convergence restores cluster membership and traffic assignment; it does not synchronize application state or guarantee that an existing TCP session survives.

Network Modes

The mode determines how the cluster appears to switches and routers. Confirm the chosen mode with the network team before configuring a production VLAN.

All adapters in a cluster must use a consistent unicast or multicast mode. A switch configuration that works in a lab may behave differently across routed VLANs, virtual switches, or hardware models.

Port Rules and Affinity

Port rules define which destination ports and protocols NLB handles and how it assigns traffic. Keep rules limited to the application ports that clients need; a broad rule can expose services unintentionally.

Affinity controls whether separate flows from the same client are likely to reach the same host:

Affinity does not copy sessions or data between nodes. For stateful applications, use an application-supported shared state store or another architecture that preserves consistency.

Real-World Use Cases

NLB may still be encountered in:

• A legacy IIS farm whose deployment and network dependencies are already built around a Windows VIP.
• A simple TCP or UDP service where the application is installed identically on every host and an external monitor checks application health.
• A migration period in which an existing NLB service must remain available while a replacement is tested.

It is a poor fit for a new internet-facing application that needs TLS offload, URL routing, WAF protection, per-request health checks, canary releases, or global traffic management. It is also not a solution for data replication or application-level high availability by itself.

Practical Considerations for Existing Clusters

Plan the Network First

Record each host’s dedicated IP, the shared VIP, subnet and VLAN, DNS name, port rules, affinity, and host priority. Confirm the switch and router behavior for the selected MAC mode, whether IGMP snooping is required, and which firewalls must allow the application and NLB management traffic.

Test on the actual network path: virtual switches, NIC teaming, routing, and security appliances can affect behavior. Keep management access separate from client traffic where the design permits, and restrict administration to approved hosts and operators.

Install and Inspect the Feature

On each intended Windows Server host, use an elevated PowerShell session. Installing the management tools makes the NLB Manager and PowerShell module available where supported:

Install-WindowsFeature -Name NLB -IncludeManagementTools

Get-WindowsFeature -Name NLB
Import-Module Nlb
Get-Command -Module Nlb

For an existing cluster, inspect membership before changing configuration:

$clusterHost = 'nlb01.contoso.example'
$clusterName = 'web-cluster'

Get-NlbCluster -HostName $clusterHost
Get-NlbClusterNode -HostName $clusterHost -ClusterName $clusterName

Replace the example host and cluster names with values from your environment. Use NLB Manager or reviewed PowerShell commands to create or modify a cluster; the VIP, adapter, port rules, and affinity must match the actual network and application. Microsoft’s NLB PowerShell cmdlet reference is archived, so verify cmdlet behavior on the installed Windows Server release before automating changes.

Validate Service Health, Not Just VIP Reachability

Run connectivity tests from representative client networks and verify the application response on each backend. For example:

Test-NetConnection -ComputerName '192.0.2.50' -Port 443
curl.exe --fail --silent --show-error https://service.example/health

Test-NetConnection confirms that a TCP port is reachable; it does not prove that the application is healthy or that NLB is distributing traffic as intended. Compare a host-specific response or application log across multiple client source addresses, taking the configured affinity into account. Test a planned node removal and recovery in a maintenance window, and monitor application-level health independently of the NLB host state.

For day-to-day diagnosis, review the Windows event log and relevant network counters. See the guides to Windows event log analysis and Performance Monitor. If maintenance tasks are scripted, follow the Windows PowerShell automation guide and Task Scheduler guide.

Compare Alternatives Before a New Deployment

The right replacement depends on where the service runs and which protocol, health, security, and routing features it needs. Microsoft’s load-balancing options overview compares service roles; the Azure Load Balancer overview describes its Layer 4 scope. For Microsoft guidance on NLB’s lifecycle and replacement direction, read the Windows Server deprecated-features list and the Network Load Balancing documentation.

Common Misconceptions

• “Deprecated means removed.” Not necessarily. Microsoft currently marks NLB as deprecated and no longer in active feature development. Check the current support documentation for the exact server release and plan to migrate.
• “The VIP checks whether my application works.” The VIP and NLB host membership do not replace an HTTP or application-level health check. Monitor the service separately.
• “Affinity makes a stateful application highly available.” Affinity can steer a client’s traffic to one host, but it does not replicate in-memory sessions or application data.
• “Every client gets an equal share.” Port rules and affinity influence assignment. A small number of clients, shared NAT addresses, or affinity settings can result in an uneven workload.
• “A node change guarantees uninterrupted sessions.” Convergence changes traffic assignment; applications and clients must tolerate reconnects and recover state safely.
• “IGMP removes the need for switch planning.” IGMP can reduce unnecessary multicast forwarding when the network supports it, but the VIP, multicast membership, and routed path still need validation.

Related Articles

• Load-balancing algorithms: Layer 4 vs. Layer 7
• Reverse-proxy architecture with Traefik and NGINX
• High-availability clusters for Hyper-V
• Windows Server configuration best practices