6379 Redis TCP Flagship

What it's for

Port 6379 is the default port for Redis, the in-memory data store used constantly for caching, session storage, rate limiting, pub/sub messaging, and as a lightweight queue backend. Because Redis keeps data in memory, it's dramatically faster for these use cases than querying a traditional disk-backed database, which is why it's such a common companion to MySQL/Postgres rather than a replacement for them.

Application servers connect to port 6379 to store and retrieve key-value data, often with very high request volume, since Redis is frequently in the hot path of request handling (checking a cache before hitting the primary database).

Protocol basics

• Protocol: TCP, for reliable command/response exchange.
• RESP (REdis Serialization Protocol). Redis uses its own simple, text-friendly binary protocol, which is part of why it's easy to interact with manually via redis-cli or even raw telnet/nc for basic debugging.
• Single-threaded command execution (core model). Historically, Redis processed commands one at a time on a single thread, making individual operations atomic without extra locking — modern Redis has added multi-threaded I/O for networking, but core command execution remains largely single-threaded for simplicity and consistency.
• In-memory with optional persistence. Data lives in RAM for speed, with optional disk persistence (RDB snapshots, AOF logs) so data can survive a restart — but this is a deliberate trade-off, not a given, and needs explicit configuration.

Security considerations

• Redis has historically shipped with no authentication required by default in many setups — an exposed, unauthenticated Redis instance on the public internet is a well-known, actively exploited misconfiguration (attackers have used exposed Redis to plant SSH keys and gain server access).
• Always require a strong password (requirepass) at minimum, and prefer Redis 6+'s ACL system for fine-grained user permissions where more control is needed.
• Never expose port 6379 directly to the internet. Like other database ports, it should sit behind a VPC/private network, reachable only from application servers that need it.
• Enable TLS if the connection between your application and Redis crosses any network boundary you don't fully control, which most managed Redis providers support and often enable by default.

Troubleshooting

"Connection refused" on port 6379:

• Redis isn't running, or is bound only to 127.0.0.1 (its default in many installations) rather than the network interface you're connecting from

"NOAUTH Authentication required":

• The Redis instance has a password set (requirepass) but your client isn't providing it — pass the password via your client library's auth parameter or redis-cli -a

Data disappearing after a restart:

• Expected if persistence (RDB/AOF) isn't enabled — Redis is in-memory by design, and without configured persistence, a restart clears all data

High memory usage / OOM errors:

• Check maxmemory and the configured eviction policy (maxmemory-policy) — without a sensible eviction policy, Redis can either reject writes or (depending on policy) evict keys unexpectedly under memory pressure

Comparison / FAQ

Why was my Redis server hacked even though I thought it was private?

The most common cause is a Redis instance bound to 0.0.0.0 (all interfaces) with no password, exposed on a cloud instance's public IP without a restrictive security group — Redis's historical lack of default authentication made this a widespread, easily automated attack pattern.

Does Redis replace my main database?

Not typically — Redis is almost always used alongside a primary database (MySQL, Postgres, etc.) as a fast cache or ephemeral data layer, not as the durable system of record, even though it can be configured with persistence for some use cases.

What's the difference between Redis and Memcached?

Redis supports much richer data structures (lists, hashes, sets, sorted sets) and additional features like pub/sub and persistence, while Memcached is a simpler, pure key-value cache. Memcached can be marginally more memory-efficient for the simplest caching use case, but Redis's flexibility covers far more scenarios.

Should I enable persistence on my Redis cache?

It depends on the use case — for a pure cache where losing data on restart is acceptable (since it can be repopulated from the primary database), persistence adds overhead without much benefit. For Redis used as a queue or primary data store for some feature, persistence becomes important.