Back to Port Numbers

11211 Memcached TCP Flagship

Reference for TCP port 11211, commonly associated with Memcached.

What it's for

Port 11211 is the default port for Memcached, a simple, high-performance in-memory key-value cache. It's used to reduce load on a primary database by caching frequently accessed data (query results, rendered page fragments, computed values) in memory, similarly to Redis but with a deliberately narrower feature set.

Protocol basics

  • Protocol: TCP is by far the most common transport, though Memcached also supports UDP — and it's specifically the UDP variant that has serious real-world security implications (see below).
  • Simple text-based protocol. Get/set/delete operations against string keys and values, with none of Redis's richer data structures — this simplicity is deliberate, trading flexibility for raw speed and a smaller resource footprint.
  • No authentication historically. Many Memcached deployments and default configurations don't require any credentials to connect and issue commands, relying entirely on network-level isolation for security.
  • Purely ephemeral, in-memory. There's no persistence layer at all — a restart clears everything, which is fine for its intended role as a cache but means it should never be treated as a source of truth for any data.

Security considerations

  • Memcached over UDP was the vector for the largest DDoS amplification attack ever recorded — in 2018, attackers used exposed, unauthenticated Memcached servers to launch an attack exceeding 1.3 Tbps against GitHub, exploiting the fact that a small forged request can trigger a response tens of thousands of times larger.
  • Disable UDP support entirely unless you have a specific reason to need it — most applications only need TCP, and UDP is specifically what enabled the amplification attack vector, since UDP's connectionless nature lets an attacker spoof the victim's IP as the source of the request.
  • Never expose port 11211 to the public internet, over TCP or UDP — Memcached has no meaningful built-in authentication in many common configurations, meaning direct exposure grants both a DDoS amplification vector and, in some cases, direct read/write access to cached data (which can include session tokens or other sensitive information).
  • Bind Memcached to a private/internal network interface only, never 0.0.0.0 on a publicly routable host, and enforce this at the firewall/security-group level as well, not just via application configuration.
  • Consider SASL authentication (supported in newer Memcached versions) for environments where an extra layer of access control is warranted beyond network isolation alone.

Troubleshooting

"Connection refused" on port 11211:

  • Memcached isn't running, or is bound only to 127.0.0.1 rather than the network interface your application needs

Cache appears empty after a deployment or restart:

  • Expected behavior — Memcached has no persistence, so any restart (including a routine deployment that restarts the service) clears all cached data. Applications should be designed to repopulate the cache gracefully rather than assuming it survives restarts

Application receiving stale data from cache:

  • Check the TTL (expiration time) set on cached keys — a common cause is caching data with too long a TTL relative to how often the underlying source data actually changes

Discovering Memcached unexpectedly reachable from outside your network:

  • Treat this as an urgent security issue, not routine troubleshooting — verify firewall rules and bind-address configuration immediately, and check whether the exposure has already been abused (unusual outbound traffic patterns, unfamiliar keys in the cache)

Comparison / FAQ

Port Protocol Key difference from 11211 (Memcached)
6379 (Redis) TCP Supports richer data structures (lists, sets, sorted sets, pub/sub) and optional persistence, at some cost to Memcached's raw simplicity
123 (NTP) UDP An unrelated protocol, but shares the same fundamental amplification-attack risk pattern when exposed and unauthenticated

Why was Memcached responsible for the largest DDoS attack ever recorded?

Because many exposed Memcached servers supported UDP with no authentication, and a small spoofed request could trigger a disproportionately massive response directed at a victim's spoofed IP address — the amplification factor (response size relative to request size) was exceptionally large compared to other commonly abused protocols.

Should I disable UDP support in Memcached even if I'm not using it?

Yes — if your application only uses TCP (the overwhelming majority do), disabling UDP entirely removes an attack vector with essentially no downside, since you weren't relying on it in the first place.

Is Memcached less secure than Redis by design?

Not inherently — both have historically shipped with weak or optional authentication in common configurations. Memcached's specific notoriety comes from the UDP amplification vector, which Redis (predominantly used over TCP) hasn't been associated with in the same way.

What happens to my cached data if the Memcached server restarts?

It's gone entirely — Memcached is purely in-memory with no persistence mechanism. Applications relying on Memcached should treat a cache miss (including one caused by a full restart) as a normal, expected condition to recover from gracefully, not an error state.