Distributed systems

Redis MOVED and ASK — redirects your cluster client must understand

Written and reviewed by Sahil Srivastav

Redis ClusterTopology discoveryResharding
MOVED 3999 127.0.0.1:6381
ASK 3999 127.0.0.1:6381

What this error actually means

The header contains two illustrative protocol replies with a local address; a real reply names the affected slot and destination. MOVED says the request reached a node that is not the owner for that slot. ASK is a temporary redirection used during migration, where this particular request should be attempted at the indicated node.

A cluster-aware client treats these as routing information. A plain client can surface them as application errors because it assumes one endpoint owns all keys. A seed connection is only an entry point: the client normally needs to discover and connect to the nodes that own its keys.

ASK has an important connection-level requirement. The destination must receive ASKING and the redirected command on the same connection, with the command following the permission. Sending ASKING through one redis-cli process and the command through a second opens different connections and does not implement the protocol.

Causes, most common first

  1. 1The client is configured as single-node against a cluster. Connecting to one cluster node does not make all commands local to that node. The application needs the library’s cluster mode, including topology discovery and redirect handling, rather than a retry wrapper around a standalone connection.
  2. 2The cached slot map is stale. Topology changes can invalidate the client’s previous ownership map. A supported client refreshes routing and bounds redirect retries. A custom fixed mapping or disabled refresh keeps sending requests to the wrong place.
  3. 3Advertised node addresses are inaccessible. NAT, container addresses, DNS or TLS identity can make the destination supplied by the cluster unusable from the caller. A successful connection to the seed endpoint proves only that the seed is reachable, not every advertised data endpoint.
  4. 4ASK is handled as a permanent move or loses connection affinity. Updating slot ownership permanently on ASK can misroute later commands. Separately, a pool that sends ASKING and the command on different sockets loses the one-connection permission needed during migration.

When you see it

  • A plain redis-cli connection returns MOVED for some keys but not others
  • The application works until resharding or failover changes slot ownership
  • Redirects point to private addresses unreachable from the application network
  • ASK repeats because a custom client sends ASKING on a different pooled connection

How to diagnose it

Step 1

Compare plain and cluster-aware CLI behaviour

For a local cluster whose seed is on port 6379, redis-cli -c follows redirects. Use a read-only GET against a known key. If this succeeds while the application fails, inspect application client mode and topology handling.

redis-cli -p 6379 GET example:key
redis-cli -c -p 6379 GET example:key

Step 2

Inspect the cluster’s topology view

CLUSTER NODES is widely available across Redis Cluster versions and shows node addresses, roles and slot assignments. Compare the advertised endpoints with the network and TLS configuration actually usable by the application.

redis-cli -p 6379 CLUSTER NODES
redis-cli -p 6379 CLUSTER INFO

Step 3

Check the key’s slot and redirect destination

Calculate the slot for the actual transmitted key, including client prefixes. Correlate it with the MOVED or ASK reply and any migration state. Do not hardcode the example slot or loopback address from this page into application routing.

redis-cli -p 6379 CLUSTER KEYSLOT example:key

Step 4

Trace connection affinity for a custom ASK handler

Log connection identity and command order in a staging migration. Confirm that ASKING and the redirected request share the target connection without unrelated commands interleaving. A pair of individually successful pool checkouts does not establish this ordering.

The fix

Use the supported cluster client mode and provide reachable seed nodes. Allow topology refresh and bounded redirect handling. Make authentication and TLS configuration valid for every discovered node; a seed-only connection setting can leave routing correct but subsequent handshakes broken.

For MOVED, refresh the slot route or topology according to the library’s implementation, then retry within a finite request budget. Persistent redirect loops deserve topology and address investigation rather than an unlimited retry count. Record the slot and destination to make that investigation possible.

For ASK, temporarily send the command to the indicated node after ASKING on the same connection. Do not permanently replace slot ownership merely because of ASK. Prefer a maintained client’s migration support over implementing connection-affine redirect logic in an application wrapper.

Fix advertised-address reachability through the deployment’s supported networking or client address-mapping configuration. Then exercise a reshard and failover from the real application network. Normal GET success against one key proves neither migration handling nor access to every shard.

How to stop it coming back

  • Include controlled slot migration in integration testing, rather than validating only an unchanged cluster.
  • Monitor redirect retries, topology refresh failures and per-node connection errors separately.
  • Keep node address advertisement, firewall access and TLS names consistent when moving a cluster between networks.

Practise production debugging in a real repository

Reading about a failure and reproducing one are different skills. Gronex ships broken backend repositories with failing test suites that encode the real invariant, so you debug from evidence instead of memorising symptoms.

FAQ

Is MOVED a server outage?

Usually it is routing information, not a loss of the key. If the advertised destination is unreachable, the application still has an availability problem, but the root cause is often client configuration or network topology.

Can I send ASKING once when a pool starts?

No. It is a connection-scoped permission for the following redirected command, not a permanent cluster mode. It must be paired correctly for the request being redirected.

Does -c fix every cluster error?

No. Redirect support does not repair CROSSSLOT, missing slot coverage, authentication failures or unreachable nodes. Keep the original server reply and diagnose that specific mechanism.

Related

Redis CROSSSLOT diagnosisRedis READONLY after failover

Other errors engineers hit next to this one

Full error and symptom index →