Redis returns `NOPROTO sorry, this protocol version is not supported` when a client tries to negotiate an unsupported protocol version during the HELLO handshake, typically when requesting RESP3 on a server that only supports RESP2. Modern clients auto-negotiate to RESP3 by default, but older Redis versions or disabled RESP3 configurations reject this upgrade. This guide explains the protocol mismatch, common scenarios, and how to downgrade or enable the correct protocol version.
When Redis responds with "NOPROTO sorry, this protocol version is not supported," it means the client issued a `HELLO` command requesting a specific RESP (REdis Serialization Protocol) version that the server does not support. The HELLO command is used during connection handshake to negotiate protocol capabilities—clients typically send `HELLO 3` to request RESP3 features, but if the server only implements RESP2 or has RESP3 disabled, it returns this error. This error is part of the RESP3 specification and indicates a version mismatch between client and server. Redis 6.0+ introduced RESP3, and Redis 7.2+ enabled it by default for new databases, but existing databases upgraded to 7.2 may have RESP3 disabled for compatibility. The client must handle this error by falling back to RESP2 or the user must configure the server to support the requested version.
Connect to the Redis server and verify its version and protocol capabilities:
# Check Redis version
redis-cli INFO server | grep redis_version
# Test if HELLO command is supported
redis-cli HELLO 3
# Expected output if RESP3 is supported:
# 1) "server"
# 2) "redis"
# 3) "version"
# 4) "7.2.0"
# ...
# If RESP3 is not supported, you'll see:
# (error) NOPROTO sorry, this protocol version is not supported
# OR
# (error) ERR unknown command 'HELLO'If the version is below 6.0, RESP3 is not available. If it's 7.2+ but returns NOPROTO, RESP3 may be disabled in configuration.
Most modern Redis clients support protocol version configuration. Set it to RESP2 to avoid the handshake error:
Node.js (node-redis v4+):
import { createClient } from 'redis';
const client = createClient({
url: 'redis://localhost:6379',
// Force RESP2
RESP: 2
});
await client.connect();Go (go-redis v9+):
import "github.com/redis/go-redis/v9"
client := redis.NewClient(&redis.Options{
Addr: "localhost:6379",
Protocol: 2, // Force RESP2
})Java (Lettuce 6+):
RedisURI redisUri = RedisURI.Builder
.redis("localhost", 6379)
.build();
RedisClient client = RedisClient.create(redisUri);
// Lettuce should auto-fallback on NOPROTO, but you can disable RESP3:
client.setOptions(ClientOptions.builder()
.protocolVersion(ProtocolVersion.RESP2)
.build());Check your client library documentation for the exact option name (protocol, RESP, protocolVersion).
If your Redis version is 7.2+ and RESP3 is disabled, you can enable it via configuration or during database creation:
For Redis Enterprise/Cloud (upgraded databases):
RESP3 may be disabled by default on databases upgraded from earlier versions. Check with your provider or create a new database instance that has RESP3 enabled by default.
For self-hosted Redis 7.2+:
There is no explicit redis.conf setting to disable RESP3—it should be available by default. If HELLO 3 still fails, verify:
# Ensure no custom module or proxy is blocking HELLO
redis-cli COMMAND INFO HELLO
# Check for any custom command rename/disable in redis.conf
grep -i "rename-command" /etc/redis/redis.confIf using a Redis cluster or proxy like Twemproxy, upgrade to versions that support RESP3 or continue using RESP2 on the client.
Older client versions may not implement automatic fallback from RESP3 to RESP2. Upgrade to the latest stable version:
# Node.js
npm install redis@latest
# Python
pip install --upgrade redis
# Go
go get github.com/redis/go-redis/v9@latest
# Java (Maven)
# Update pom.xml to Lettuce 6.3+ which includes better NOPROTO handlingLettuce versions 6.3+ and go-redis v9.3+ implement automatic protocol downgrade when receiving NOPROTO, so the connection retries with RESP2 without user intervention. Check the release notes for your client library to confirm this feature is included.
The RESP3 specification defines NOPROTO as the correct error response when a requested protocol version is unavailable, but older Redis versions (pre-6.0) return -ERR unknown command 'HELLO' instead because the HELLO command itself doesn't exist. Clients must handle both error types to maintain backward compatibility.
Redis 7.2 introduced a breaking change for some deployments: upgraded databases (not freshly created) have RESP3 disabled to prevent compatibility issues, but the error response changed from -ERR unknown command 'HELLO' to -NOPROTO, which broke Lettuce and other clients that only checked for the former. This led to GitHub issues like lettuce#2170 and lettuce#2455, prompting client libraries to implement automatic RESP2 fallback on any HELLO failure.
When debugging, note that RESP3 provides significant benefits (push events, better type mapping, out-of-band data) but is not required for most workloads. If you control both client and server, enabling RESP3 is recommended for new deployments, but forcing RESP2 is a safe and pragmatic solution for legacy or managed Redis instances.
ERR Unbalanced XREAD list of streams
How to fix "ERR Unbalanced XREAD list" in Redis
ERR syntax error
How to fix "ERR syntax error" in Redis
ConnectionError: Error while reading from socket
ConnectionError: Error while reading from socket in redis-py
ERR unknown command
How to fix ERR unknown command in Redis
Command timed out
How to fix 'Command timed out' in ioredis