The Redis default port is 6379. Every Redis client, server, and managed service uses 6379 when no other port is specified, and 6379 is the port a developer puts in a connection string when they want to talk to a Redis server. The port is a four-digit number that has become shorthand for “this is the Redis port,” and the port is the part the developer has to know to connect to a Redis server for the first time. The interesting part is why 6379 (it’s a phone-number easter egg from the author), the three other ports a real deployment touches (6380 for TLS, 16379 for cluster bus, 26379 for Sentinel), and the four gotchas (firewall, network ACL, container port mapping, IPv6) that quietly break a connection.
The reason “redis default port” is its own question and not just “redis connection” is that the port is the part of the connection that fails first. A Redis client that cannot connect to 6379 is a client that gives up before it can send the first command. The fix is in the port, the firewall, the network, or the client config.
Table of contents
- The short version
- The four ports a real Redis deployment touches
- The three places the default port comes from
- The five connection-string patterns a developer uses
- The four gotchas that quietly break a connection
- The way firewalls and managed services change the port story
- FAQ
The short version
A Redis server listens on TCP port 6379 by default. A Redis client connects to that port to send commands and receive responses. The connection is plain text by default, optionally encrypted with TLS, and optionally authenticated with a password or an ACL. The port is configurable in redis.conf (the port directive) and on the command line (redis-server --port 6380). The default is 6379, and the default is the right answer for most development and most production deployments.
The four ports a real Redis deployment touches
The default port is 6379, but a real Redis deployment touches four ports. The ports serve different purposes, and the developer who is running a real cluster has to know all four.
6379 — the Redis server port. The main port a Redis server listens on for client connections. The port is the one every developer knows, and the port is the one the developer puts in the connection string. The port is configurable, and the developer can run multiple Redis servers on the same host by using different ports (6379, 6380, 6381, etc.).
6380 — the TLS-enabled Redis port. A common convention, not a hard rule. A Redis server that has TLS enabled typically listens on a separate port (often 6380) so the plain-text port (6379) can be left closed or bound to localhost only. The convention is the one managed services use, and the convention is the one the developer should follow when setting up their own TLS-enabled Redis.
16379 — the Redis cluster bus port. A Redis cluster uses a separate port for the cluster bus (the gossip protocol that nodes use to discover each other, to share the slot map, and to elect the master). The port is the data port + 10000 (so 16379 for a default 6379, 16380 for 6380, etc.). The port is not for client traffic — the client only talks to the data port (6379). The port is for inter-node traffic, and the port has to be open between the cluster nodes.
26379 — the Redis Sentinel port. A Redis Sentinel deployment uses a separate port for the Sentinel daemon (which monitors the master, promotes a replica if the master fails, and reconfigures the clients). The port is the Sentinel’s listening port, not a Redis server’s listening port. The port is configurable, and 26379 is the convention. The port has to be open between the Sentinels and the clients (if the clients are using Sentinel-aware connection).
The four ports cover the typical production setup. There are also ports for the RedisInsight UI (typically 8001), for the RedisGears runtime (typically 5001), and for the RedisBloom, RediSearch, and RedisJSON modules (varies). The four are the ones the developer should learn first.
The three places the default port comes from
The 6379 default is a default, and defaults come from somewhere. The three places the default comes from are:
The redis.conf file. The Redis source ships with a redis.conf that has port 6379 as the default. The default is the one the server uses when no other config is provided, and the default is the one the developer sees when they start a Redis server for the first time.
The command line. The developer can override the port with redis-server --port 6380. The override is the right answer for a developer who is running multiple Redis servers on the same host, and the override is the right answer for a developer who is using a non-standard port for a reason (a firewall, a port conflict, a managed service convention).
The client library. Every Redis client library has a default port of 6379. The default is the one the client uses when no port is specified in the connection string, and the default is the one the developer can override with the port parameter or the redis://host:port/db URL.
The three places are the floor. The developer can also set the port in an environment variable (REDIS_PORT=6380), in a config file (most clients support a redis.conf-style file), or in a service discovery system (Consul, etcd, the cloud provider’s metadata service). The three are the ones the developer should know first.
The five connection-string patterns a developer uses
The connection string is the developer’s way of telling the client where the Redis server is. The five patterns that show up in real codebases are:
redis://localhost:6379. The localhost connection. The pattern is the right answer for a developer who is running Redis on their laptop, and the pattern is the right answer for a development environment. The pattern is the wrong answer for a production deployment, because Redis should not be on the same host as the application in production.
redis://user:password@host:6379/0. The authenticated connection. The pattern is the right answer for a production deployment, where Redis is on a different host and requires authentication. The 0 is the logical database (Redis has 16 logical databases by default, numbered 0–15). The pattern is the one most managed services use.
rediss://user:password@host:6380/0. The TLS-enabled connection. The rediss:// scheme (two s’s) is the convention for TLS, and the 6380 port is the convention for TLS-enabled Redis. The pattern is the right answer for a production deployment that requires encryption in transit.
redis://host:6379 with a Sentinel-aware client. The Sentinel-fronted connection. The pattern is the right answer for a deployment that uses Redis Sentinel for high availability. The client connects to the Sentinel (on 26379), the Sentinel tells the client which Redis server is the current master, and the client connects to the master (on 6379). The pattern is the right answer for a deployment where the master can change.
redis://host:6379 with a cluster-aware client. The cluster connection. The pattern is the right answer for a deployment that uses Redis cluster. The client connects to any node, the node tells the client about the cluster topology, and the client routes commands to the right node based on the key’s hash slot. The pattern is the right answer for a deployment where the data is sharded.
The five patterns are the floor. There are also patterns for Redis with SSL certificates (rediss://...&ssl_certfile=...), for Redis with ACLs (redis://user:password@...&username=...), and for Redis with multiple URLs (a comma-separated list for cluster discovery). The five are the ones the developer should learn first.
The four gotchas that quietly break a connection
A Redis client that cannot connect to 6379 is a client that the developer is going to spend an hour debugging. The four gotchas that quietly break a connection are:
The firewall is blocking the port. A Redis server on a private network is a server that the public internet cannot reach. The fix is to whitelist the client’s IP on the server’s firewall, or to use a managed service that exposes the port securely.
The container port is not mapped to the host. A Redis server running in a Docker container listens on 6379 inside the container, but the port is not accessible from the host unless the developer maps it with -p 6379:6379 (or -p 6380:6379 to map host 6380 to container 6379). The fix is to map the port correctly, and to use the mapped port in the connection string.
The server is bound to localhost only. A Redis server with bind 127.0.0.1 in redis.conf is a server that is only listening on the loopback interface. The fix is to either change the bind to 0.0.0.0 (listen on all interfaces) or to use a Unix socket, or to use a reverse proxy (like a VPN or a service mesh) to reach the server.
The client is using the wrong port. A developer who hardcodes localhost:6379 in the connection string but the server is on localhost:6380 is a developer who is going to see a “connection refused” error. The fix is to put the port in an environment variable, and to source the environment variable from the deployment’s secret manager.
The four gotchas are the floor. There are also gotchas from the server being in a different VPC, from the server’s TLS certificate not matching the hostname, from the client’s default port being different from the server’s, and from the server being in protected mode (which requires a password to connect). The four are the ones the developer will see most often.
The way firewalls and managed services change the port story
A Redis server on a developer’s laptop is on port 6379, and the developer’s laptop does not have a firewall in the way. A Redis server on a managed service is on a different port, behind a firewall, on a private network. The port story changes the moment the deployment leaves the laptop.
Managed services typically use a non-standard port. AWS ElastiCache, Redis Cloud, Upstash, and the like typically use a port like 6379 or 6380, but the port is often the same as the default to keep the connection string simple. The developer should check the managed service’s docs for the exact port, and should not assume it is 6379.
The port is usually behind a firewall. A managed Redis service is usually not exposed to the public internet. The developer has to whitelist the application’s IP, or run the application in the same VPC, or use a private endpoint. The firewall is the right answer for security, and the firewall is the part the developer has to know to make the connection work.
The port is usually behind a load balancer or a proxy. Some managed services put a proxy (like Envoy or a managed Redis proxy) in front of the Redis server. The proxy listens on the standard 6379 port, the proxy connects to the Redis server on a private network, and the developer does not have to know the server’s actual port. The pattern is the right answer for a developer who wants the connection to look like a normal Redis connection.
The port is the same on the server but different on the client. A developer who is using a managed service and trying to connect from their laptop is going to fail unless the laptop is on the same network as the service, or the service has a public endpoint. The fix is to use a bastion, a VPN, or a managed service with a public endpoint. The pattern is the right answer for a developer who is debugging from outside the production network.
The port story is the part that changes the moment the deployment leaves the laptop. The developer who knows the port story is the developer who is going to plan for the firewall, the network, and the proxy before the first call.
How this fits the rest of the stack
A Redis server rarely lives in isolation. The server usually sits behind an application, serves a cache, manages a session, or backs a queue. The platform that handles the cache should make the rest of the stack feel like part of the same conversation.
The services layer is the part of the platform that runs the long-lived API the Redis server caches for. The database layer is the part that holds the source of truth the cache is reading from. The static layer is the part that hosts the dashboard the developer uses to inspect the cache. The environment variables are the part that holds the connection string the API uses to connect to the cache.
A Redis server on a platform where the service, the database, the storage, and the secrets are all in the same place is a server the team is going to be able to debug. A Redis server on a platform where each piece is in a different console is a server the team is going to spend the first hour just opening the right tab.
For a team that wants to see the full cost of the project before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the cache, the worker, the bandwidth — each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
FAQ
What is the default port for Redis?
The default port for Redis is 6379. The server listens on this port by default, and the client connects to this port by default. The port is configurable in redis.conf (the port directive) and on the command line (redis-server --port 6380).
Why is the default port 6379?
The port number 6379 is a reference to the phone keypad, where the digits spell “MERZ” (6=MNO, 3=DEF, 7=PQRS, 9=WXYZ). The author of Redis, Salvatore Sanfilippo (antirez), chose the number as a play on the Italian word “merzo” (a play on “merda,” meaning something like “rubbish”). The number has become the convention, and the convention is the one every developer recognizes.
How do I change the default port for Redis?
Edit redis.conf and change the port directive, or pass --port 6380 on the command line. The change requires a restart. The developer should also update the firewall, the connection string, and any client configuration to use the new port.
What port does Redis use for TLS?
The convention is to use 6380 for TLS-enabled Redis, but this is not enforced. The developer can use any port for TLS, as long as the port is configured in redis.conf with tls-port 6380 and the client is configured to connect to that port with the rediss:// scheme.
What port does Redis cluster use for the bus?
The cluster bus port is the data port + 10000. So if the data port is 6379, the bus port is 16379. If the data port is 6380, the bus port is 16380. The bus port is for inter-node traffic (the gossip protocol that nodes use to discover each other), and the port is not for client traffic.
What port does Redis Sentinel use?
The convention is 26379 for Sentinel. The port is configurable in sentinel.conf with the port directive, and the port has to be open between the Sentinels and any Sentinel-aware clients.
How do I connect to Redis from another machine?
Whitelist the client’s IP on the server’s firewall, and use the server’s public IP in the connection string. If the server is on a private network, the developer has to use a VPN, a bastion, or a managed service with a public endpoint. The pattern is the right answer for a developer who is connecting from outside the production network.