Each Redis Cluster node needs two TCP ports open: the client port, such as 6379, and the cluster bus port, which by default is the client port plus 10000, so 16379. Open the client port to your applications and the bus port to the other cluster nodes, and to nobody else.
What the cluster bus is
The Redis Cluster documentation describes the bus as a node to node channel using a binary protocol suited to low bandwidth and processing time. Nodes use it for failure detection, configuration updates and failover authorization. It says clients should never try to talk to the bus port and should use the normal command port instead. It also tells you to open both ports in your firewall, because without the bus port the nodes cannot talk to each other.
The bus port is set by adding 10000 to the data port unless you override it with the cluster-port setting.
A simple access matrix
| Port | Who needs it | Who should not have it |
|---|---|---|
| Client port (6379 by default) | Application servers, admin hosts | The internet, other networks |
| Cluster bus port (16379 by default) | Other cluster nodes | Applications, the internet |
The second row is a design recommendation, drawn from the documentation's statement that clients do not use the bus. Verify it in your own environment by testing that applications still work after you tighten the rule.
Steps to lock it down
- List every cluster node and its two ports. Check for a cluster-port override in each configuration so you do not assume 16379 when it is something else.
- Write firewall or security group rules that allow the bus port only from the node addresses. In Kubernetes, use a network policy that selects the cluster pods.
- Allow the client port only from the namespaces, subnets or security groups that run your applications.
- Turn on TLS for the bus by setting tls-cluster to yes, as described in How do you enable TLS for Redis clients, replicas and cluster?.
- Check from a host outside the allowed set that both ports are closed. A successful connection from the wrong place is a finding.
Why the bus deserves attention
Redis is designed for trusted clients in trusted environments. Its documentation says exposing it directly to the internet or to untrusted clients is usually not a good idea. The bus is easy to forget because applications never use it, so it often ends up covered by a broad allow rule written for convenience, such as allowing the entire port range inside a subnet.
If your cluster spans cloud accounts or networks, look for rules that expose the bus beyond the nodes that need it. Stale rules tend to survive node replacement because they were written against a subnet and not against the instances.
Keep checking after launch
A one time firewall review does not hold for long. Nodes move, rules get widened during an incident, and a copied template adds an open range. Schedule a recurring check that tests both ports from outside.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how ongoing monitoring catches change after an initial review, and think about which of your firewall rules could drift.
Safeguard's asset discovery can help you find the Redis hosts running in your estate. The free scan is a quick way to start on your code and dependencies.
Quick check
Is 16379 always the cluster bus port?
No. It is the default when the client port is 6379. The bus port is the data port plus 10000 unless you set cluster-port to something else.
Should my application be able to reach the bus port?
The documentation says clients should not communicate with it. Restrict it to cluster nodes and test.
Sources
Last reviewed: 19 October 2026.
