Nginx Tcp Load Balancing
You set up nginx tcp load balancing by adding a stream block to your main settings. This block listens on a port and sends raw network packets to an upstream server group. Engineering teams use this method to split database, message queue, and custom app traffic across nodes. Still, network routing works at layer four and only checks IP addresses and ports. When teams share broad database roles behind a load balancer, any user can run risky queries. How nginx tcp load balancing works in practi
NGINX Security Configuration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up nginx tcp load balancing by adding a stream block to your main settings. This block listens on a port and sends raw network packets to an upstream server group. Engineering teams use this method to split database, message queue, and custom app traffic across nodes. Still, network routing works at layer four and only checks IP addresses and ports. When teams share broad database roles behind a load balancer, any user can run risky queries.
How nginx tcp load balancing works in practice
Standard web routing reads HTTP headers at layer seven, while TCP routing works at layer four. The stream module opens a listening socket on the server and waits for client traffic. When a client reaches that port, the server picks a healthy backend node from its list. It opens a second link to that backend node and copies bytes back and forth.
Teams choose a routing rule to match their workload needs and server sizes. Round robin sends each new client link to the next server in the list. Least connections sends new traffic to the backend node with the fewest active links right now. Hash routing maps a client IP address to one backend node so state stays consistent.
Health checks run in the background to test if each backend port still responds. If a database node stops answering on its port, the router marks that node as down. It stops sending new traffic there until the node passes health checks again. You can also set up TLS termination on the router to decrypt incoming network traffic first.
What layer four routing solves and where it falls short
A TCP load balancer solves high availability and spreads network load across multiple backend servers. Apps only need one hostname and port to reach a whole cluster of databases or services. Admins can take a backend node offline for updates without breaking active app workflows. Network access lists on the router can also block unknown IP addresses from reaching the port.
Still, a layer four router does not read the protocol inside the raw byte stream. It sees packets moving between two IP addresses, not the user identity or the query text. Once a client passes the network check and logs in, the router allows every command through. It cannot tell a safe read query from a command that drops a table.
NGINX Security Configuration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Network logs only record client IP addresses, byte counts, session duration, and link status codes. Security teams cannot see which engineer ran a query or what data came back. In the same way, raw TCP routing cannot rewrite sensitive fields like emails or card numbers. Teams that need command auditing or field masking must inspect traffic at the protocol level.
Managing health checks and session timeouts
Long-lived database links behave in a different way than short web requests during a server restart. If a TCP router drops idle links too fast, apps see broken pipe errors in logs. Teams tune idle timeout settings on the router to match the keepalive timer on the database. This alignment prevents the router from closing a link that the app still holds in pool.
Passive health checks watch real client traffic and mark a node down after several failed attempts. Active health checks probe backend ports on a set timer even when no client traffic flows. Teams combine both checks with sensible timeout limits so bad nodes drop out within seconds. Careful tuning keeps traffic flowing while avoiding false alarms during brief network spikes.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between HTTP and TCP load balancing in Nginx?
HTTP load balancing works at layer seven and reads web headers, paths, and cookies to route requests. TCP load balancing works at layer four inside the stream context and routes raw network packets by IP and port.
Can Nginx TCP load balancing inspect SQL queries or mask data?
No, a layer four TCP router only forwards raw bytes between the client and the backend server. It does not parse database protocols, record SQL statements, or rewrite fields like phone numbers or national IDs.
How does Nginx handle TLS for TCP streams?
The stream module can either pass encrypted bytes straight through to the backend or terminate TLS on the router. TLS passthrough keeps encryption end to end, while TLS termination offloads decryption work from the backend servers.