Redisの「ERR Client sent AUTH, but no password is set」エラーの修正方法

TL;DR

RedisクライアントがAUTHコマンドを送信していますが、サーバー側にパスワードが設定されていません。クライアントの設定からパスワードを削除するか、redis.confにrequirepass yourpasswordを追加してRedisを再起動することで解決できます。クライアントとサーバーの設定を一致させることが重要です。

エラーの意味

Redisはredis.confにrequirepassが設定されている場合のみ認証を要求します。このディレクティブが存在しない（またはコメントアウトされている）場合、サーバーにはパスワードがありません。それにもかかわらず、クライアントがパスワードを送信しています。Redisはこれを無視せず、次のエラーをスローします：

ERR Client sent AUTH, but no password is set. Did you mean ACL SETUSER with >password?

これはNOAUTH Authentication requiredの逆のエラーと考えてください。あちらはクライアントが認証を忘れた場合のエラーです。こちらはクライアントが認証不要なサーバーに対して認証を行おうとしている場合のエラーです。よくある原因：

ステージング・本番環境（パスワード保護あり）の接続文字列を、パスワードなしのローカル開発用Redisにそのままコピーした。
redis.confからrequirepassを削除したが、アプリの設定を合わせて更新しなかった。
Docker Composeファイルで特定の環境のみ--requirepassを渡している。
Redis 6以降のACLシステムを使用しているが、クライアントが引き続きAUTH passwordのみ送信している。

修正方法1 — クライアントからパスワードを削除する（開発・ローカル環境向け）

認証不要なローカル環境で実行している場合は、クライアント側からのAUTH送信をやめるだけで解決します。

redis-cli

-aフラグを削除します：

# 誤り — AUTHを送信する
redis-cli -a mypassword ping

# 正しい — AUTHなし
redis-cli ping

Node.js (ioredis)

// passwordフィールドを完全に削除する
const redis = new Redis({
  host: '127.0.0.1',
  port: 6379,
  // password: 'mypassword'  ← 削除またはコメントアウト
});

Python (redis-py)

import redis

# password= を削除する
r = redis.Redis(host='localhost', port=6379, db=0)
# r = redis.Redis(host='localhost', port=6379, password='mypassword', db=0)  ← 旧設定

環境変数を使う方法

アプリがRedisのURLを環境変数から読み取っている場合、ローカル環境にステージングの認証情報が引き継がれていないか確認してください：

# ローカル .env — パスワードなし
REDIS_URL=redis://localhost:6379

# 本番 .env — パスワードあり
REDIS_URL=redis://:strongpassword@redis-host:6379

修正方法2 — Redisサーバーにrequirepassを追加する（開発環境以外に推奨）

逆のケース：クライアントは正しいパスワードを持っているが、サーバー側にパスワード要求の設定がされていない場合です。サーバー側で設定を行いましょう。

redis.confを編集する

# redis.confを見つける
# よくある場所：
# /etc/redis/redis.conf
# /etc/redis.conf
# /usr/local/etc/redis.conf

sudo nano /etc/redis/redis.conf

requirepassの行（おそらくコメントアウトされています）を見つけて設定します：

# 変更前：
# requirepass foobared

# 変更後：
requirepass yourStrongPassword

その後、Redisを再起動します：

sudo systemctl restart redis
# または
sudo service redis-server restart

Docker / Docker Compose

# docker run
docker run -d --name redis \
  -p 6379:6379 \
  redis:7 redis-server --requirepass yourStrongPassword

# docker-compose.yml
services:
  redis:
    image: redis:7
    command: redis-server --requirepass yourStrongPassword
    ports:
      - "6379:6379"

実行時に設定する（再起動不要・非永続）

redis-cli config set requirepass yourStrongPassword

**注意：**この変更はredis.confも更新しない限り、再起動時に失われます。簡単なテスト用には問題ありませんが、恒久的な設定には使用しないでください。

修正方法3 — Redis 6以降のACLシステム

エラーメッセージにヒントがあります："Did you mean ACL SETUSER with >password?" これはRedisがバージョン6で導入された新しい認証システムへの移行を促しているサインです。グローバルパスワードの代わりに、ACLではユーザーごとに認証情報を定義できます。

デフォルトユーザーにパスワードを設定するには：

# ACLでデフォルトユーザーのパスワードを設定する
redis-cli ACL SETUSER default on >yourpassword ~* &* +@all

# またはredis.conf内（ACLファイルまたはインライン）：
# user default on >yourpassword ~* &* +@all

まず、現在の状態を確認します：

redis-cli ACL LIST
# 出力例：
# user default on nopass ~* &* +@all  ← パスワード不要を意味する

nopassが表示されている場合、サーバーはパスワードなしで接続を受け入れており、クライアントはAUTHを送信すべきではありません。

修正の確認

上記のいずれかの変更後、簡単な動作確認を行います：

# 手動で認証をテストする
redis-cli -a yourStrongPassword ping
# 期待する結果：PONG

# サーバー設定を確認する
redis-cli -a yourStrongPassword config get requirepass
# 期待する結果：
# 1) "requirepass"
# 2) "yourStrongPassword"

# デフォルトユーザーのACLを確認する
redis-cli -a yourStrongPassword ACL WHOAMI
# 期待する結果："default"

PONGが返ってくれば、認証ハンドシェイクが正常に機能しています。

補足Tips

Redisには覚えやすいパスワードではなく、適切なランダムパスワードを生成して使用してください。Redisがネットワークインターフェースに誤って公開された場合、脆弱なパスワードは深刻なリスクになります。私はToolCraftのパスワードジェネレーターを使って、32文字のランダム文字列を数秒で生成しています。サーバーの認証情報を扱う際に重要な点として、このツールはブラウザ上で完全に動作し、サーバーへのアップロードは一切ありません。

ついでに確認しておくべきセキュリティ対策がさらに3つあります：

ネットワークアクセスが本当に必要な場合を除き、Redisを127.0.0.1にバインドしてください：redis.confにbind 127.0.0.1を追加します。
すべての環境でRedisの接続文字列を環境変数で管理してください。絶対にハードコードしないでください。
KubernetesでRedisを運用している場合は、パスワードをSecretに保存し、Redisのデプロイメントとアプリのポッド両方で環境変数として参照してください。