Diagnosing Memcached Connection Timeouts on Linux: Checks, Causes, and Fixes

The condition you'll actually see

Your application starts throwing intermittent Connection refused or client-side timeout errors when setting or getting keys. Sometimes it recovers on its own; sometimes every request fails until you intervene. Because Memcached failures are usually silent (clients often treat a miss and an outage identically), the first symptom is frequently elevated database load rather than an explicit error.

The useful takeaway: almost every Memcached timeout on a typical Linux host comes down to one of four causes — the daemon is down, it's out of memory, the port is unreachable, or the connection limit is saturated. You can check all four in under five minutes from the shell.

Cause and diagnostic map

Ordered checks

1. Is the daemon running? On the Memcached host, run systemctl status memcached (or ps -ef | grep memcached on non-systemd systems). Note the command line in the process listing — it shows the active -m, -c, and -p values, which you'll need later.
2. Is it listening where you expect? Run ss -tlnp | grep 11211. If it shows 127.0.0.1:11211 but clients connect from other hosts, the daemon is bound to localhost (the -l flag) and remote clients will always fail.
3. Can you talk to it locally? From the host, run telnet 127.0.0.1 11211 and type stats. You should get a block of counters. Key ones: curr_connections vs max_connections, evictions, bytes vs limit_maxbytes, and listen_disabled_num (nonzero means Memcached has refused new connections because it hit the limit).
4. Check the logs. journalctl -u memcached -n 100 on systemd systems. Look for out-of-memory lines or repeated connection errors.
5. Check the network path from a client. From an application server, run telnet cache-host 11211. If local telnet works but remote fails, inspect the firewall: firewall-cmd --list-all (firewalld) or iptables -L -n. On SELinux-enforcing systems, also check getenforce and recent denials in /var/log/audit/audit.log.

Fixes tied to each finding

Daemon down

Restart it with sudo systemctl restart memcached, then check journalctl -u memcached for why it died — an OOM-killer entry in dmesg means the host itself is memory-starved, not just Memcached.

Memory exhausted

If bytes is pinned at limit_maxbytes and evictions climbs rapidly, raise the allocation. Edit the startup config (/etc/memcached.conf on Debian/Ubuntu, /etc/sysconfig/memcached on RHEL-family) and increase -m (megabytes). Restart to apply. Warning: a restart flushes the entire cache. Expect a thundering-herd load spike on your backing store; restart during low traffic or warm the cache afterward.

Port or bind address wrong

Fix the -l and -p flags in the config and restart. Bind to a specific internal interface rather than 0.0.0.0 — Memcached has no authentication, so an open listen address plus a permissive firewall is a real exposure (this is exactly how the 2018 memcached UDP amplification attacks worked; UDP is disabled by default in modern builds, but TCP is still wide open if exposed).

Firewall blocking

With firewalld: sudo firewall-cmd --permanent --new-zone=memcached, add the app-server source IPs with --add-source=, then --add-port=11211/tcp and --reload. Restricting by source IP matters — do not open 11211 to the world.

Connection limit saturated

If listen_disabled_num is nonzero, either raise -c (default is 1024) or — usually better — fix the client side. A common bug is clients opening a new connection per request instead of using a persistent pool. Don't raise -c blindly: each connection costs a file descriptor, and an excessively high limit can destabilize the host. Check the daemon's fd ceiling with cat /proc/<pid>/limits.

Verifying the fix

Don't stop at "telnet connects." Run a quick end-to-end test from an application host. With Python and pymemcache:

from pymemcache.client import base
import time
c = base.Client(('cache-host.internal', 11211), connect_timeout=2, timeout=2)
for i in range(200):
    t0 = time.monotonic()
    c.set(f'probe:{i%10}', b'x'*256)
    assert c.get(f'probe:{i%10}') is not None
    dt = (time.monotonic()-t0)*1000
    assert dt < 50, f'slow op: {dt:.1f}ms'
print('ok')

Then re-check stats: cmd_set and cmd_get should have increased by roughly your test counts, curr_connections should stay well under the limit, and the log should show no new errors during the window.

When to escalate

Hand off to systems or network engineering when: timeouts persist after daemon, memory, port, and firewall all check out; OOM messages continue despite a larger -m (suggests a memory leak elsewhere on the host or genuinely undersized cache tier); or you see signs of network-layer trouble such as retransmits in ss -ti output or packet loss to the cache host. At that point the problem is no longer Memcached configuration, and further tuning of -m/-c will only mask it.

Version note: commands assume a systemd-based distro with Memcached 1.5+/1.6+. Config paths and default connection limits differ across distributions — confirm against your local memcached -h output.