Lower, steadier latency
The application payload stays on the kernel packet path instead of moving through a scheduled userspace worker.
XLB vs NGINX
NGINX is an excellent web server and application proxy. Pure TCP load balancing at millions of requests per second is a different job. XLB performs backend selection and packet rewriting in the Linux kernel, avoiding userspace payload copies, separate proxy sockets, and the worker tuning that comes with a large NGINX tier.
Why teams choose XLB
NGINX earns its place when you need HTTP processing and a broad proxy feature set. XLB is built for teams that need the most efficient TCP load-balancing tier possible.
The application payload stays on the kernel packet path instead of moving through a scheduled userspace worker.
XLB focuses every load-balancer CPU cycle on backend selection and packet routing for pure L4 workloads.
No worker counts, connection limits, buffers, open-file settings, or application-specific proxy configuration to tune.
| What matters | NGINX | XLB |
|---|---|---|
| Primary design | Web server, reverse proxy, content cache, and TCP or UDP stream proxy | Focused high-performance IPv4 and TCP Layer 4 load balancer |
| Data path | Client session is accepted by a worker and proxied to an upstream server | Backend selection and packet rewriting run in the Linux kernel |
| Connection work | Client and proxied-server connections both consume worker capacity | One end-to-end connection without two proxy sockets |
| Application payload | Passes through userspace stream proxy buffers | Never copied through a userspace load-balancer process |
| Server footprint | General-purpose proxy fleet sized for workload and configuration | About half the servers as a practical evaluation target for pure L4 |
| Tuning | Worker, connection, open-file, buffer, and OS limits may require sizing | Completely tuning free |
| Kubernetes updates | Handled by an ingress controller, integration, or configuration automation | Direct Kubernetes Service and Ready Pod discovery |
| Observability | NGINX logs, status modules, NGINX Plus dashboards, and external tools | Built-in console plus premade Grafana and Datadog configurations through OpenTelemetry |
| Software model | NGINX Open Source or commercial NGINX Plus subscription | Flat negotiated commercial license and support |
Purpose-built for L4
NGINX workers are designed to process and proxy connections across a broad set of use cases. XLB removes that general-purpose proxy layer from pure TCP traffic. The result is a shorter path, fewer server resources per unit of traffic, and fewer operational settings to own.
Packets remain in the kernel data path instead of depending on userspace workers, proxy buffers, and process scheduling.
XLB routes the client connection to the selected backend without maintaining another bidirectional proxy connection for it.
Deploy XLB with a listener and backend source. It selects its fast path automatically and keeps Kubernetes backends current.
Common questions
NGINX stream proxying accepts a client session and proxies it to an upstream server. XLB selects a backend and rewrites packets in the Linux kernel instead. The application payload does not pass through userspace proxy buffers, and XLB does not maintain separate client-side and backend-side sockets.
No. XLB is completely tuning free. NGINX capacity can involve worker processes, worker connections, open-file limits, buffers, and operating-system settings. XLB does not expose an application-specific proxy tuning surface.
Yes. Point XLB to a Kubernetes Service and it watches the selected Ready Pods directly. The pool updates automatically during scaling, rolling deployments, and readiness changes.
NGINX Open Source is free to use, while NGINX Plus is a commercial subscription with license and usage-reporting requirements. XLB is a supported commercial product with a flat negotiated fee that is not metered by request, connection, byte, or traffic volume.
Official product references
Competitor details on this page are based on the vendor’s own documentation.
Prove it with your workload
Bring your current topology, traffic profile, or cloud bill. We’ll scope a representative XLB evaluation.