How Many TCP Connections Can a Server Actually Handle? Limits and Tuning Guide

Maximum Number of Open Files on a Linux Server

Linux treats everything as a file, so the total number of open files is governed by three kernel parameters:

fs.file-max – system‑wide limit of open files (root is exempt).

soft nofile – per‑process soft limit.

fs.nr_open – per‑process hard limit (can be set per user).

These parameters are inter‑dependent:

If you raise soft nofile, you must also raise hard nofile because the effective value is the lower of the two.

Increasing hard nofile requires a corresponding increase of fs.nr_open, otherwise the system may become unbootable or users may be unable to log in.

Modifying fs.nr_open with echo "value" > /proc/sys/fs/nr_open is not persistent; a reboot will revert the change, so use sysctl instead.

Example: Raising the Maximum Open Files

To allow a process to open one million file descriptors, edit the configuration files as follows:

vim /etc/sysctl.conf

fs.file-max=1100000   # system‑wide buffer
fs.nr_open=1100000    # must be larger than hard nofile

Apply the changes: sysctl -p Then set per‑process limits:

vim /etc/security/limits.conf

soft nofile 1000000
hard nofile 1000000

How Many TCP Connections Can a Server Support?

A TCP connection is represented by a pair of socket kernel objects (the TCP four‑tuple). The theoretical maximum is 2^32 * 2^16 (~2×10^14) connections, but real limits are imposed by CPU and memory.

For idle ESTABLISHED connections, each consumes roughly 3.3 KB of RAM. On a 4 GB server, the practical upper bound is about one million concurrent connections. Adding data processing or encryption will increase memory and CPU usage, reducing the achievable count.

Maximum Connections a Client Machine Can Initiate

Clients consume a local port for each outbound connection. The port range is 0‑65535, but after reserving system ports the usable range is about 64 000.

Scenarios:

Case 1: Single client IP, single server IP, single server port → up to ~65 535 connections.

Case 2: Client has n IP addresses, same server setup → up to n × 65 535 connections.

Case 3: Server runs m services on different ports → up to 65 535 × m connections per client IP.

The kernel parameter net.ipv4.ip_local_port_range can be tuned to enlarge the client port range.

Other Practical Considerations

The backlog queue length is controlled by net.core.somaxconn (default 128). Raising it helps when many connections are established simultaneously.

When a process is killed and restarted, the OS may temporarily hold the previous port, causing “address already in use” errors.

Calling bind() on the client side forces a specific source port, which interferes with the kernel’s port‑allocation strategy; it is generally discouraged.

Linux manages sockets with hash tables for fast lookup of the TCP four‑tuple, and epoll uses a red‑black tree to efficiently add, delete, and search socket entries.

Typical Problems and Solutions

The “too many open files” error occurs when a process exceeds its file‑descriptor limit. Resolve it by increasing fs.file-max, soft nofile, and fs.nr_open, remembering their coupling relationships.

Estimating Server Count for Massive Long‑Lived Connections

Assume a push‑notification service must maintain 100 million idle TCP connections. With a 128 GB server, each connection uses ~3.3 KB, so a single machine can hold roughly 5 million connections (≈20 GB RAM). Therefore, about 20 such servers are sufficient for 100 million users.