Diagnosing Redis maxclients and TCP TIME_WAIT Socket Exhaustion in WooCommerce

When running a high-traffic WooCommerce store, aggressive object caching using Redis is practically mandatory to keep PHP execution times low. However, during flash sales or massive traffic spikes, your previously snappy store might suddenly collapse, throwing cryptic 502 Bad Gateway errors, PHP warnings about Redis connections, or stalling completely.

A common but deeply misunderstood root cause in these scenarios is the dreaded TCP TIME_WAIT socket exhaustion coupled with Redis maxclients limits. In this technical deep-dive, we’ll explore how to diagnose, mitigate, and permanently fix this issue at the Linux kernel and Redis configuration levels.

The Symptoms: Connection Drops and 502s

Typically, the issue manifests in your application or PHP-FPM error logs:

[17-Sep-2026 14:12:05 UTC] PHP Warning:  Redis::connect(): Cannot assign requested address in /var/www/html/wp-content/object-cache.php on line 410
[17-Sep-2026 14:12:05 UTC] PHP Fatal error:  Uncaught RedisException: Redis server went away in /var/www/html/wp-content/object-cache.php

Or, if you check your Redis server logs (/var/log/redis/redis-server.log):

31024:M 17 Sep 2026 14:12:05.123 # Possible SECURITY ATTACK detected. It looks like somebody is sending bad or short packets.
31024:M 17 Sep 2026 14:12:05.456 - Accepted 127.0.0.1:54321
31024:M 17 Sep 2026 14:12:06.002 # ERR max number of clients reached

Step 1: Diagnosing Socket Exhaustion

The Cannot assign requested address (EADDRNOTAVAIL) error usually implies that the local system has run out of ephemeral ports to establish new outbound TCP connections to the Redis server.

To confirm this, run ss -s on your web server:

$ ss -s
Total: 3502
TCP:   42105 (estab 1205, closed 40500, orphaned 12, timewait 40102)

Transport Total     IP        IPv6
RAW       1         1         0
UDP       12        9         3
TCP       3500      3490      10

Notice the massive number of sockets in the timewait state (40,102).

When a PHP script finishes execution, it closes the Redis TCP connection. In the TCP protocol, the side that initiates the close (in this case, PHP/Web Server) must keep the socket in a TIME_WAIT state for typically 60 seconds (defined by TCP_TIMEWAIT_LEN in the kernel, hardcoded in Linux). If your WooCommerce store handles 1,000 requests per second, and each request opens a new Redis connection, you will quickly exhaust the ~28,000 available local ports (by default, ports 32768 to 60999).

Step 2: Kernel Tuning via Sysctl

To immediately mitigate ephemeral port exhaustion, you need to instruct the Linux kernel to expand the port range and allow the reuse of TIME_WAIT sockets.

Edit /etc/sysctl.conf or create a file in /etc/sysctl.d/99-redis-tuning.conf:

# Increase the ephemeral port range
net.ipv4.ip_local_port_range = 1024 65535

# Allow reuse of sockets in TIME_WAIT state for new connections
net.ipv4.tcp_tw_reuse = 1

# Decrease the time default TCP fin timeout (optional, helps clear state faster)
net.ipv4.tcp_fin_timeout = 15

# Increase the maximum number of sockets allowed in TIME_WAIT
net.ipv4.tcp_max_tw_buckets = 2000000

Apply the changes:

sysctl -p /etc/sysctl.d/99-redis-tuning.conf

Note: Avoid enabling net.ipv4.tcp_tw_recycle on modern kernels (it was actually removed in Linux 4.12) as it causes issues with NAT.

Step 3: Fixing Redis maxclients

While tcp_tw_reuse helps the web server recycle ports, Redis itself might still block incoming connections if the maxclients limit is hit. The default is usually 10,000.

Check your current connected clients and the limit:

$ redis-cli info clients
# Clients
connected_clients:10000
cluster_connections:0
maxclients:10000
client_recent_max_input_buffer:2048
client_recent_max_output_buffer:0

If connected_clients is hitting maxclients, increase it in /etc/redis/redis.conf:

maxclients 65000

Restart Redis (systemctl restart redis-server). Important: Ensure your system’s open file descriptor limit (ulimit -n) is set higher than 65000, otherwise Redis will silently fall back to a lower maxclients value. Adjust this in your systemd service file:

[Service]
LimitNOFILE=70000

Step 4: Persistent Connections (The Real Fix)

Tuning the kernel is treating the symptom. The root cause is establishing a new TCP connection for every single PHP request.

In your WordPress wp-config.php, if you are using the popular Redis Object Cache plugin (or similar), ensure you enable persistent connections (pconnect). This reuses the same TCP connection across multiple PHP requests via PHP-FPM workers.

define( 'WP_REDIS_SCHEME', 'tcp' );
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', '6379' );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
// The magic bullet for TIME_WAIT issues:
define( 'WP_REDIS_PERSISTENT', true ); 

Or, even better, if Redis is running on the same server, switch to Unix sockets, which bypass the TCP networking stack entirely, offering lower latency and zero port exhaustion.

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/var/run/redis/redis-server.sock' );

Scaling Beyond Single Servers

When your WooCommerce store scales beyond what a single server can handle, splitting your web tier from your database and Redis cache becomes necessary.

However, introducing network latency between your PHP servers and Redis instances can exacerbate connection overhead. This is when you should look into upgrading to robust bare-metal environments to bypass shared networking limits and prevent TCP Socket Exhaustion. Migrating heavy database and caching nodes to high-performance Dedicated Servers provides the dedicated CPU clock speeds and massive RAM required for heavy WooCommerce database queries. For regional stores needing optimal latency in South Asia, deploying your infrastructure on Dedicated Servers in Pakistan ensures ultra-fast TTFB for your local customers while giving you full root access to execute these granular kernel optimizations.

By understanding the relationship between Linux TCP behavior, Redis connection handling, and PHP-FPM request lifecycles, you can ensure your WooCommerce store remains stable during even the most extreme checkout events.