Memcached 'Connection Refused' on Port 11211: Complete Linux Troubleshooting Guide

Understanding the 'Connection Refused' Error

When a client attempts to connect to Memcached on TCP port 11211 and receives Connection refused (errno ECONNREFUSED), the TCP three-way handshake never completes. The kernel at the target host responded with a RST packet, meaning one of two things: no process is listening on that port, or a firewall rule actively rejected the packet before it reached a socket.

This is distinct from a timeout (where packets are silently dropped by a firewall) or a host unreachable error (routing problem). ECONNREFUSED is deterministic — the host is reachable but the port is closed or blocked.

Common error messages across client stacks:

• telnet: connect to address 127.0.0.1: Connection refused
• MemcachePool::connect(): Can't connect to localhost:11211, Connection refused (111)
• pylibmc.Error: [11211] Connection refused
• Errno::ECONNREFUSED - Connection refused - connect(2) for "127.0.0.1" port 11211
• [ERROR] Failed to connect to memcached at 10.0.1.5:11211 after 3 retries
• net.ConnectError: connection refused (os error 111)

Step 1: Confirm Whether Memcached Is Running

Always start here. Configuration changes are useless if the service is not running.

systemctl status memcached

Look for Active: active (running). A status of inactive (dead), failed, or activating (auto-restart) means the process is not serving connections.

Verify at the network layer — confirm nothing is bound to 11211:

ss -tlnp | grep 11211

If this returns no output, no process is listening on port 11211. Proceed to Step 2.

Step 2: Start Memcached and Diagnose Crash Causes

Start the service:

sudo systemctl start memcached
sudo systemctl enable memcached

The enable flag ensures Memcached restarts automatically after a reboot.

If the service fails to start, inspect logs immediately:

journalctl -u memcached -n 100 --no-pager

On older systems without systemd:

tail -n 100 /var/log/syslog | grep -i memcached
tail -n 100 /var/log/messages | grep -i memcached

Common log entries that reveal the root cause:

• failed to listen on TCP port 11211: Address already in use — another process owns the port. Run sudo lsof -i :11211 to identify it.
• failed to daemonize: Permission denied — an OS security framework is blocking the bind. See Step 8.
• Cannot allocate memory — the requested -m memory exceeds available RAM.

Step 3: Check the Bind Address for Remote Connection Refused

By default on Debian and Ubuntu, Memcached binds exclusively to 127.0.0.1. Any client connecting from a different host will receive ECONNREFUSED even when the service is running perfectly.

Inspect the current bind address:

grep -E '^-l' /etc/memcached.conf

If the output is -l 127.0.0.1, change it to your server's private IP (preferred) or 0.0.0.0 (all interfaces):

sudo sed -i 's/^-l 127.0.0.1/-l 0.0.0.0/' /etc/memcached.conf
sudo systemctl restart memcached

On Red Hat, CentOS, and AlmaLinux, the configuration is /etc/sysconfig/memcached. Edit the OPTIONS line:

OPTIONS="-l 0.0.0.0 -u memcached"

Security warning: Memcached has no built-in authentication. Never bind to a public-facing IP without firewall restrictions. Always restrict access to trusted internal subnets (see Step 4).

Verify the new listener address:

ss -tlnp | grep 11211
# Expected: LISTEN 0 1024 0.0.0.0:11211  0.0.0.0:*  users:(("memcached"...))

Step 4: Open Firewall Access to Port 11211

Even with Memcached listening on 0.0.0.0, a host firewall can drop packets silently or reset the connection before they reach the process.

UFW (Ubuntu/Debian):

sudo ufw status verbose
# Open port only for trusted subnet:
sudo ufw allow from 10.10.0.0/24 to any port 11211 proto tcp comment 'memcached'
sudo ufw reload

firewalld (CentOS/RHEL/Fedora):

sudo firewall-cmd --list-all --zone=internal
sudo firewall-cmd --zone=internal --add-port=11211/tcp --permanent
sudo firewall-cmd --reload

iptables (direct):

sudo iptables -L INPUT -n -v | grep 11211
# Add ACCEPT before any DROP rule:
sudo iptables -I INPUT -s 10.10.0.0/24 -p tcp --dport 11211 -j ACCEPT
# Block all other access:
sudo iptables -A INPUT -p tcp --dport 11211 -j DROP
sudo iptables-save | sudo tee /etc/iptables/rules.v4

To confirm a firewall is the problem (versus no listener), use tcpdump from the client side to check whether RST packets or no response is received:

sudo tcpdump -i eth0 -n port 11211

Step 5: Diagnose Out-of-Memory Crash Loops

If Memcached restarts repeatedly, the Linux OOM killer is a frequent culprit. It terminates the highest-scoring memory consumer when the system runs critically low on RAM, and Memcached is often that process.

sudo dmesg -T | grep -i 'killed process' | grep memcached
sudo grep -i 'out of memory' /var/log/syslog | tail -20

A typical OOM kill message looks like:

[Sun Feb 22 04:15:33 2026] Out of memory: Kill process 22148 (memcached) score 881 or sacrifice child
[Sun Feb 22 04:15:33 2026] Killed process 22148 (memcached) total-vm:2097152kB, anon-rss:2048000kB, file-rss:0kB

Check and increase the memory limit in /etc/memcached.conf:

grep '^-m' /etc/memcached.conf
# Default is often -m 64 (64 MB)
sudo sed -i 's/^-m 64/-m 512/' /etc/memcached.conf
sudo systemctl restart memcached

Rule of thumb: allocate no more than 60% of total available RAM to Memcached, leaving headroom for the OS, kernel buffers, and other services.

Step 6: Check Maximum Connections

Memcached defaults to 1024 simultaneous connections. When curr_connections approaches this ceiling, new connection attempts are refused at the application level:

echo 'stats' | nc -q1 127.0.0.1 11211 | grep -E 'curr_connections|max_connections|connection_structures'

If curr_connections is close to max_connections, increase the limit in /etc/memcached.conf:

grep '^-c' /etc/memcached.conf
sudo sed -i 's/^-c 1024/-c 4096/' /etc/memcached.conf
sudo systemctl restart memcached

Also verify the OS file descriptor limit is sufficient for the new value:

cat /proc/$(pgrep memcached)/limits | grep 'open files'
# Or for the current shell:
ulimit -n

The open files limit must be at least max_connections + 10 (for internal file handles).

Step 7: Diagnosing Slow Memcached Performance

If Memcached is running but latency is high or cache effectiveness has dropped, inspect key statistics:

echo 'stats' | nc -q1 127.0.0.1 11211

Critical metrics to evaluate:

Reset stats and collect a fresh 60-second baseline:

echo 'stats reset' | nc -q1 127.0.0.1 11211
sleep 60
echo 'stats' | nc -q1 127.0.0.1 11211 | grep -E 'evictions|get_hits|get_misses|curr_connections|uptime'

Step 8: SELinux and AppArmor Issues

On SELinux-enforcing systems (RHEL, CentOS, AlmaLinux), Memcached may fail to bind to its port even with correct configuration. The service will appear to start but immediately fail with a permission error.

sudo ausearch -m avc -ts recent | grep memcached
sudo sealert -a /var/log/audit/audit.log | grep -A 10 memcached

Generate a targeted policy module rather than disabling SELinux enforcement:

sudo ausearch -m avc -ts recent | audit2allow -M memcached-custom
sudo semodule -i memcached-custom.pp

For AppArmor on Ubuntu:

sudo aa-status | grep memcached
# Switch to complain mode to diagnose without blocking:
sudo aa-complain /usr/sbin/memcached
journalctl -k | grep -i apparmor | grep memcached

Step 9: Verify End-to-End With a Live Connection Test

After applying any fix, validate the full connection cycle:

# Check port is open:
nc -zv 127.0.0.1 11211

# Read version string:
echo 'version' | nc -q1 127.0.0.1 11211
# Expected: VERSION 1.6.x

# Test set and get round-trip:
printf 'set diag_key 0 300 2\r\nOK\r\n' | nc -q1 127.0.0.1 11211
printf 'get diag_key\r\n' | nc -q1 127.0.0.1 11211
# Expected: VALUE diag_key 0 2\r\nOK\r\nEND

If the connection hangs with no output (versus an immediate refusal), the firewall is dropping packets rather than rejecting them. Run tcpdump -i any port 11211 on the server while the client connects to confirm traffic is arriving.