Redis Default Port and Safe Changes

The default Redis port is 6379. Redis clients usually expect a local Redis server at 127.0.0.1:6379, and redis-cli uses that host and port unless you specify something else. On a VPS, the important question is not only “what is the Redis port?” It is also “who can reach that port?”

Changing the Redis port can help avoid a local conflict or separate multiple instances, but it is not a security control by itself. A Redis instance on a custom port is still dangerous if it is reachable from an untrusted network without the right bind, firewall, authentication, and protected-mode settings.

This guide explains the default Redis port, how to test a port, how to run a Redis instance on another port for verification, and what to check before changing production configuration.

Key takeaways

• Redis uses TCP port 6379 by default.
• redis-cli connects to 127.0.0.1 on port 6379 unless you pass another host or port.
• On Ubuntu packages, the Redis server configuration file is commonly /etc/redis/redis.conf.
• You can test a custom port with redis-server --port 6380 and 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.

Safe Redis port workflow

Step 1: Install Redis tools for a local test

On a disposable Ubuntu test server or container, install the Redis package so you can inspect the default configuration and run a temporary instance.

apt-get update
apt-get install -y redis-server

This article’s container proof used Ubuntu 24.04 and installed redis-server from the Ubuntu repositories before checking the default config and testing a custom port.

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

Before changing a production service, test the concept with a temporary Redis process on a non-default port.

redis-server --port 6380 --daemonize yes
redis-cli -p 6380 PING
redis-cli -p 6380 shutdown

A successful PING response proves that a Redis server is listening on the custom port and that redis-cli -p is targeting it. The shutdown command stops the temporary test instance.

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

Changing the port means editing the correct Redis configuration, choosing an unused TCP port, updating application connection strings, adjusting firewall rules, and restarting the managed Redis service. Do not change only the server port and forget the application. The most common result is a working Redis daemon that no app can reach.

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;
• the VPS firewall does not expose the port publicly unless there is a deliberate private-network design;
• 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.

Troubleshooting Redis port problems

Connection refused

The Redis server may not be running on that port, the service may have failed to restart, or the firewall may be blocking the connection. Confirm the configured port and test with redis-cli -p from the same host first.

App still connects to the old port

The application may have a cached environment variable, config file, container secret, or service definition still pointing to 6379. Update the app configuration and restart the app process that reads it.

Redis works locally but not remotely

That is often intentional. Redis should usually be bound to loopback or a private interface. If remote access is required, prefer private networking, firewall allowlists, and authentication rather than a public open port.

A port change did not apply

You may have edited a file that is not used by the running Redis service. Check the service’s actual startup configuration and deployment method. Package installs, containers, and source builds can use different paths.

When should you change the Redis port?

Change the Redis port when you have a clear operational reason: running multiple local Redis instances, avoiding a local service conflict, separating test and production instances, or matching a private-network architecture.

Do not change it just to “hide” Redis. Security comes from binding, firewalling, authentication, protected mode, network design, and least exposure. Port choice is only a routing detail.

If you want a clean VPS for Redis-backed applications, Virtarix Cloud VPS plans give you isolated Linux servers where you can test Redis configuration, app connection strings, and firewall behavior before changing production.

FAQ

What is the default Redis port?

The default Redis port is 6379. redis-cli also defaults to 127.0.0.1 and port 6379 unless another host or port is specified.

Can I change Redis to port 6380?

Yes. Redis can run on another port, and redis-server --port 6380 is a valid way to test a temporary instance. For a managed production service, change the service configuration and update the application connection settings too.

Does changing the Redis port make it secure?

No. A custom port does not secure Redis by itself. Keep Redis off untrusted networks, bind it to intended interfaces, use firewall rules, and configure authentication or protected-mode behavior for your deployment.

Summary

Redis port 6379 is the default that most local tools and applications expect. You can test or configure another port, but the port number is only one part of a safe Redis deployment.

On a VPS, the safer workflow is to verify the current Redis config, test the new port, update application settings, keep Redis bound to trusted interfaces, and confirm the service after restart. Do not rely on port obscurity for security.

Byline: Peter French — Updated 2026-05-18.