redis/jedis · error · JedisProtocolNotSupportedException
Server does not support HELLO
Error message
Server does not support HELLO
What it means
During protocol enforcement, if the server responds to HELLO with an unknown-command error, Jedis translates it into JedisProtocolNotSupportedException "Server does not support HELLO". HELLO exists only in Redis 6.0+, so the server is older (or a pseudo-Redis that lacks HELLO) and RESP3 cannot be negotiated.
Solutions
- Set protocol RESP2 in JedisClientConfig (RESP2 works on servers without HELLO).
- Omit the protocol setting to use the default.
- Upgrade the Redis server to >= 6.0 if RESP3 features (client-side caching, push messages) are required.
- Verify the endpoint is a genuine Redis 6+ server, not a proxy that filters HELLO.
Example fix
// before
JedisClientConfig config = DefaultJedisClientConfig.builder()
.protocol(RedisProtocol.RESP3) // Redis 5.x server -> Server does not support HELLO
.build();
// after
JedisClientConfig config = DefaultJedisClientConfig.builder()
.protocol(RedisProtocol.RESP2) // compatible with pre-6.0 servers
.build(); Defensive patterns
Strategy: fallback
Validate before calling
// detect support before requesting RESP3: HELLO exists only on Redis >= 6.0 // e.g. run INFO server and parse redis_version, or attempt HELLO and check for unknown-command errors
Try / catch
try {
return connectWithProtocol(RedisProtocol.RESP3);
} catch (JedisProtocolNotSupportedException e) {
// server lacks HELLO (Redis < 6.0 or filtering proxy): fall back to RESP2
return connectWithProtocol(RedisProtocol.RESP2);
} Prevention
- Check the server's redis_version before enabling RESP3.
- Maintain an env-specific protocol setting (RESP2 for older fleets).
- Avoid Redis-subset proxies if you need RESP3 features.
- Upgrade Redis to >= 6.0 to use HELLO-based negotiation.
When it happens
Trigger: Connecting to Redis < 6.0 (e.g. Redis 5.x), or to a service speaking a Redis subset (some proxies, caches, serverless Redis emulators) while requesting RESP3 via JedisClientConfig.protocol(RESP3).
Common situations: Managed environments offering only older Redis versions; cloud/enterprise proxies that strip HELLO; apps migrated to RESP3 then deployed against an old fleet.
Related errors
- Bulk reply length is less than expected
- Unsupported protocol:
- Jedis does not support RESP3 protocol auto-negotiation…
- binary ft.search is not implemented with resp3.
- HELLO response is missing the protocol version field
AI-assisted analysis of redis/jedis@6dac31d4c2 (2026-09-08).
Data as JSON: /api/errors/fd181ed57c817264.
Report an issue: GitHub.
Appendix: source
Thrown at src/main/java/redis/clients/jedis/ProtocolHandshake.java:145
* @param credentials credentials used for authentication if required (may be {@code null})
* @return the {@code HELLO} response containing negotiated protocol and server metadata
* @throws IllegalArgumentException if {@code protocol} is {@code null}
* @throws JedisProtocolNotSupportedException if the server does not support the requested
* protocol
* @throws JedisAccessControlException if authentication fails and cannot be recovered
*/
private HelloResult enforceProtocolWithAuth(RedisProtocol protocol,
RedisCredentials credentials) {
if (protocol == null) {
throw new IllegalArgumentException("protocol must not be null");
}
try {
try {
return connection.hello(protocol, credentials);
} catch (JedisDataException e) {
if (isUnknownCommandError(e)) {
throw new JedisProtocolNotSupportedException("Server does not support HELLO", e);
} else {
throw e;
}
}
} catch (JedisAccessControlException e) {
// Redis 6.0.x (before 6.2.2) has a bug where HELLO with AUTH fails if the default user
// requires authentication — the server demands AUTH before allowing HELLO.
// See: https://github.com/redis/redis/issues/8558
// See: https://github.com/redis/lettuce/issues/2592
if (isNoAuthError(e)) {
connection.authenticate(credentials);
return connection.hello(protocol, credentials);
} else {
throw e;
}
}
}View on GitHub (pinned to 6dac31d4c2)