Redis uses TCP port 6379 by default. Without a host or port option, redis-cli connects to 127.0.0.1:6379. If you change the server's port, update every application, worker, and monitoring check that connects to it.
A different port can resolve a local conflict or let you run multiple instances. It does not prevent unauthorised access. Review the listening address, firewall rules, authentication, and protected mode separately, and keep Redis inaccessible to untrusted clients.
The steps below show how to inspect the configured port and test a temporary instance before planning a production change.
Key takeaways
- Redis uses TCP port
6379by default. -
redis-cliconnects to127.0.0.1on port6379unless you pass another host or port. - On Ubuntu packages, the Redis server configuration file is commonly
/etc/redis/redis.conf. - Test a custom port with a temporary instance bound to loopback, then connect with
redis-cli -p 6380 PING. - Do not expose Redis directly to the public internet; bind it locally and use firewall rules.
- For related VPS operations, see the Virtarix guides to how to secure a VPS, Linux command line habits, and managed vs unmanaged VPS hosting.
What Redis port 6379 means
Port 6379 is the conventional Redis TCP port. When a local app, queue worker, cache library, or redis-cli command points to Redis without a custom port, it is often assuming 6379.
That default is convenient, but it can hide configuration mistakes. If one app connects to the default port while another Redis instance was moved to a custom port, you may be testing the wrong server. Always verify both the host and the port when troubleshooting.
The port is only one part of the connection. A secure Redis setup also depends on which network interface Redis binds to, whether protected mode applies, whether the host firewall allows the port, and whether authentication is configured for your deployment.
Check the current port and test a new one
Step 1: install Redis tools for a local test
Use a disposable Ubuntu environment for this example. The package installation commands require root privileges; use sudo before each command when working from an administrator account.
apt-get update
apt-get install -y redis-server
Package installation may start the default Redis service. Check the environment before starting a second instance, and use an unused port for the test.
Step 2: check the packaged Redis config path
On Ubuntu-packaged Redis, the Redis server manpage documents /etc/redis/redis.conf as the typical default configuration file.
grep -E '^port ' /etc/redis/redis.conf
On a production VPS, inspect the real config file used by your Redis service before editing anything, because custom deployments and containers may use a different path.
Step 3: test a custom Redis port safely
In the disposable environment, confirm that port 6380 is unused. Start a temporary process bound explicitly to loopback, test its response, and stop it afterward. Proceed to the client commands only if the new process starts successfully.
redis-server --bind 127.0.0.1 --port 6380 --daemonize yes
redis-cli -p 6380 PING
redis-cli -p 6380 shutdown
A PONG response confirms a Redis connection on that port. The shutdown command stops the instance listening there, which is why this test must use a free port in a disposable environment. It does not establish that production authentication or network restrictions are correct.
Use this as a lab pattern, not as your production change process. For a real service, update the managed configuration, restart through your service manager, and verify the application’s connection settings.
Changing the Redis port in production
For an Ubuntu-managed Redis service, the production port is normally controlled by the service configuration file. The common line is:
port 6379
Choose an unused TCP port and edit the configuration file the service actually loads. Update application connection strings, monitoring, and any relevant firewall rules, then restart through the service manager. If clients still use the old port, they will fail to connect even when Redis starts successfully.
Use a maintenance window if Redis backs sessions, queues, cache, rate limiting, or application state. Even a short Redis restart can affect user-facing behavior when the app depends on it.
Security checks before opening any Redis port
Redis documentation warns that exposing the Redis TCP port or UNIX socket to untrusted clients is unsafe. A public Redis port can allow destructive operations if the instance is not properly protected.
Before opening or changing the port on a VPS, confirm:
- Redis binds only to intended interfaces, such as loopback for local-only access;
- firewall rules allow only the intended clients, using private connectivity where required;
- application connection strings use the new host and port;
- protected mode and authentication settings match your deployment;
- monitoring checks the new port after the change;
- rollback notes explain how to return to the previous port.
A custom port does not replace those controls. Attackers scan broad port ranges. If Redis is public, moving from 6379 to another number is not enough.