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

  1. Set protocol RESP2 in JedisClientConfig (RESP2 works on servers without HELLO).
  2. Omit the protocol setting to use the default.
  3. Upgrade the Redis server to >= 6.0 if RESP3 features (client-side caching, push messages) are required.
  4. 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

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


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)