Introduction

MOVED is not a Redis server bug. It is the cluster telling your client that the key belongs on a different node. A standalone client can talk to one Redis node just fine, but it does not understand hash slots or redirection, so the application keeps failing as soon as the request lands on a node that does not own the key.

Symptoms

  • The app returns MOVED 12182 10.0.0.14:6379 or similar redirection messages
  • A direct redis-cli test works on one node but not on another
  • Errors increase after resharding, failover, or node replacement
  • The application configuration still looks like a single-host Redis connection

Common Causes

  • The app uses a standalone Redis client against a Redis Cluster deployment
  • Only one seed node is configured, and the client never refreshes cluster topology
  • DNS or configuration still points to an old primary address
  • A connection pool was copied from a non-cluster environment without changes

Step-by-Step Fix

  1. 1.Verify the cluster is really returning a slot redirect
  2. 2.Confirm the server response with a cluster-aware CLI before changing application code.
bash
redis-cli -c -h 10.0.0.12 -p 6379 GET session:42
redis-cli -c -h 10.0.0.12 -p 6379 CLUSTER NODES
  1. 1.Replace the standalone client with a cluster-aware one
  2. 2.The client library must understand slot maps and automatic redirection.

```javascript import Redis from "ioredis";

const redis = new Redis.Cluster([ { host: "10.0.0.12", port: 6379 }, { host: "10.0.0.13", port: 6379 }, { host: "10.0.0.14", port: 6379 }, ]); ```

  1. 1.Seed more than one node and verify the current slot map
  2. 2.That prevents one stale address or one dead node from breaking cluster discovery.
bash
redis-cli -h 10.0.0.12 -p 6379 CLUSTER SLOTS
redis-cli -h 10.0.0.13 -p 6379 CLUSTER INFO
  1. 1.Retest after failover or resharding with the real application key pattern
  2. 2.A good fix should survive normal topology changes, not only a single happy-path request.
bash
redis-cli -c -h 10.0.0.12 -p 6379 SET session:42 ok
redis-cli -c -h 10.0.0.13 -p 6379 GET session:42

Prevention

  • Use cluster-aware clients from day one for any Redis Cluster deployment
  • Seed multiple nodes instead of one hardcoded endpoint
  • Revalidate cluster topology handling after failover drills and resharding
  • Keep standalone and cluster connection code paths separate in application config