WordPressサイト、管理画面、記事保存、外部連携で「401 Unauthorized」が出ることがあります。名前から「権限がない」と思われがちですが、HTTPの401は、対象へ必要な有効な認証情報がない、または送った認証情報が拒否された状態です。
認証には、サーバーのBasic認証、WordPressの通常ログイン、REST APIのCookieとnonce、Application Password、外部サービスのAPIトークンなどがあります。どの認証が失敗したかを分けずにWordPressの主パスワードを変更しても、直らない場合があります。
ログインやAPI実行を連打せず、認証情報をスクリーンショット、チャット、URL、公開ログへ載せないでください。試行を重ねると、アカウントロックや429のレート制限が追加されることがあります。
この記事では、401の発行元と認証方式を確認し、必要な資格情報だけを安全に修正する順番を解説します。
先に結論：401エラーは8段階で確認する
| 順番 | 確認すること | 目的 |
|---|---|---|
| 1 | ログイン・保存・APIの連打を止める | ロックや429を増やさない |
| 2 | 画面・URL・時刻・直前操作を記録する | 認証ログへつなぐ |
| 3 | 公開画面・wp-login・wp-admin・wp-jsonを分ける | 失敗した保護範囲を絞る |
| 4 | ブラウザ小窓・WordPress画面・API応答を見分ける | 認証方式を特定する |
| 5 | 401、応答本文、WWW-Authenticateを確認する | 要求された認証方式を知る |
| 6 | 認証情報を伏せてログを照合する | 欠落・失効・拒否の場所を確認する |
| 7 | 対象資格情報だけを修正・再発行する | 他の連携を壊さない |
| 8 | 重要機能と防御状態を再確認する | 復旧と安全性を両立する |
最初から全ユーザーのパスワード変更、全プラグイン停止、Basic認証削除を行いません。対象URLが求めている認証を確認してから、変更範囲を限定します。
401 Unauthorizedとは？
RFC 9110の401 Unauthorizedは、対象リソースに有効な認証資格情報がないため、要求が適用されていない状態です。401を生成するサーバーは、利用できる認証方式を示すWWW-Authenticateを少なくとも一つ返す必要があります。
資格情報を送っていたのに401になった場合、その資格情報が拒否されたことを示します。ユーザー名やパスワードの間違いだけでなく、期限切れ、失効、送信ヘッダーの欠落、違う環境用のトークンなども候補です。
なお、WordPressの通常ログインフォームで「パスワードが違います」と表示されても、HTTPステータスが必ず401とは限りません。Networkで実際のステータスを確認し、普通のログイン問題と、サーバー・APIの401を分けます。
400・401・403の違い
| 表示 | 主な意味 | 最初に確認するもの |
|---|---|---|
| 400 Bad Request | 要求の構文・内容・区切りなどを処理できない | URL、Cookie、ヘッダー、送信内容 |
| 401 Unauthorized | 有効な認証情報がない、または拒否された | WWW-Authenticate、認証方式、資格情報 |
| 403 Forbidden | 要求は理解されたが処理を拒否された | ユーザー権限、WAF、IP・アクセス制限 |
要求自体が不正な400なら、WordPressの400 Bad Requestを直す確認順へ進みます。有効な資格情報はあるのに許可されない403なら、WordPressの403 Forbiddenを安全に直す手順が対象です。
製品や独自プラグインが必ず仕様どおりの番号を返すとは限りません。番号だけで決めず、応答本文、WWW-Authenticate、失敗したURL、ログを合わせて確認します。
最初の10分で行う安全な初動
1．認証情報を保存せず、状況だけ記録する
エラー画面、対象URLまたは送信先ホスト、発生時刻とタイムゾーン、直前の操作を記録します。公開ページ、WordPressログイン、管理画面、記事保存、外部アプリ、APIのどれで発生したかも残します。
スクリーンショットやHARへ、Authorization、Cookie、nonce、Application Password、APIトークンを含めません。サポートへ送る場合も、秘密部分を伏せ字にします。資格情報そのものではなく、認証方式、発生時刻、応答コードを共有します。
2．表示の種類を分ける
ブラウザが独自の小さなID・パスワード入力画面を出す場合は、サーバーやステージングのBasic認証が候補です。WordPressのロゴ付きログインフォームとは別の資格情報である場合があります。
記事保存や外部ツールだけ失敗する場合は、ブラウザのNetworkまたはツールのログで、失敗した/wp-json/などのURL、HTTP 401、応答JSONのエラーコードを確認します。公開ページ全体で出るなら、ホストやCDNを含む保護設定を優先します。
3．代替の管理経路とバックアップを確認する
認証設定を変える前に、ホスト管理画面、SFTP、バックアップなど、WordPressへ入れない場合でも戻せる経路を確認します。変更前の設定値を保存し、一つずつ試します。
401を返している場所を特定する
| 症状 | 主な候補 | 確認するもの |
|---|---|---|
| ブラウザのID・パスワード小窓 | Basic認証、ステージング保護 | WWW-Authenticateの方式とrealm、ホスト設定 |
| WordPressログイン画面で失敗 | 通常ユーザー、Cookie、リダイレクト | 実ステータス、ユーザー名、再設定経路 |
| 記事保存・エディターだけ401 | REST API、独自認証、セッション | 失敗endpoint、応答JSON、ログイン状態 |
| 外部投稿・同期ツールだけ401 | Application Password、API認証 | 送信先、ユーザー名、失効、最終利用 |
| 別サービスのAPIだけ401 | APIトークン、Bearer認証 | 送信先ドメイン、期限、対象環境 |
| CDN経由の特定パスだけ401 | オリジン認証、CDN・プロキシ設定 | 応答本文、WWW-Authenticate、両側ログ |
開発者ツールでは、Status 401、Request URL、Response、WWW-Authenticate、Server、CDN識別IDを一度確認します。Basic、Bearerなどの方式やrealmは手がかりですが、資格情報の値は記録しません。
Cloudflareを通っている場合、Cf-RayがあるだけではCloudflareが401を生成したと断定できません。配信元のBasic認証をCloudflareが中継している場合もあります。CDN・ホスト・WordPressの同時刻ログを照合します。
原因別の安全な直し方
1．サーバー・ステージングのBasic認証
ブラウザ小窓が出る場合は、ホスト管理画面のサイト保護、テスト環境、ディレクトリ保護を確認します。保護範囲、realm、利用する資格情報を確認し、WordPressユーザーのパスワードを何度も入力しません。
Apache公式の認証資料では、Basic認証をAuthType、AuthName、資格情報ファイル、Requireなどで構成します。.htaccessを丸ごと削除せず、ホストの仕様とバックアップを確認して、意図しないパスだけを修正します。
Basic認証の資格情報はHTTPSと組み合わせて扱います。HTTPへ戻して認証を通す方法は選びません。
2．WordPressの通常ログイン
WordPressの通常ログイン画面なら、ユーザー名またはメールアドレスと通常のアカウントパスワードを使います。Application Passwordは管理画面へログインするためのパスワードではありません。
パスワードを忘れた場合は、WordPress標準の再設定を利用します。Cookie、リダイレクト、ログインURL変更、二段階認証を含む切り分けは、WordPress管理画面にログインできないときの確認順で行ってください。
再設定メールが届かない場合は、認証設定を崩す前にWordPressからメールが届かないときの確認手順を使います。
3．REST APIのCookie・nonce・ログイン状態
WordPress REST API公式の認証資料では、管理画面内の標準認証はWordPressのCookieを使い、意図しない操作を防ぐためnonceを組み合わせます。nonceが送られない場合、ログイン中でも匿名利用者として扱われます。
ただし、WordPress標準のCookie認証でnonceが無効な場合は403になるため、「保存時の401は必ずnonce切れ」と断定しません。下書きを退避し、別タブでログイン状態を確認し、再ログイン後に一度保存します。NetworkのJSONエラーコードも確認してください。
保存時にJSONエラーも表示される場合は、WordPressのJSONレスポンスエラーを直す手順で、REST API、WAF、プラグインを分けます。nonceやCSRF対策、REST APIを全面停止しないでください。
4．Application Passwords
WordPress公式のApplication Passwords資料では、これは外部アプリやスクリプトのAPI認証用で、WordPressの主パスワードを第三者へ共有しないための個別資格情報です。管理画面への対話ログインには使えません。
HTTPS、WordPressのユーザー名、対象アプリ用のApplication Passwordを確認します。ユーザープロフィールで名前、最終利用、最終IP、失効状態を確認し、古い・不明・漏えい疑いのある一件だけを失効させます。新しい一件を生成したら、その連携先だけを更新します。
一つのApplication Passwordを複数サービスで共有しません。一連携につき一つにすると、問題が起きた資格情報だけを停止できます。
5．Authorizationヘッダーが途中で消える
外部ツールは正しい資格情報を送っているのに401になる場合、CDN、リバースプロキシ、CGI、WebサーバーでAuthorizationヘッダーがWordPressまで届いていないことがあります。クライアント側の送信記録と、配信元ログを同じ要求IDで照合します。
インターネット上の設定例を無条件にコピーせず、管理サーバーか共有ホストかを確認します。共有ホストでは、対象時刻、URL、認証方式を添えて提供元へ相談してください。資格情報をURLのクエリへ移して回避しないでください。
6．セキュリティプラグイン・独自認証
REST認証の必須化、Application Password無効化、ログイン保護などを追加するプラグイン、mu-plugin、独自コードを確認します。直前変更と同時刻のログが対象を示した場合だけ、その機能をテスト環境で一つずつ調整します。
WAFや全プラグインを停止したままにせず、検証後は防御を戻します。認証情報と防御の基本はWordPressセキュリティ設定の基本を参考にしてください。
7．外部APIのトークン・権限
Cloudflare、メール、分析、SNSなど別サービスのAPIだけ401なら、WordPressではなく送信先サービスのトークンを確認します。送信先ドメイン、認証方式、期限、失効、対象環境を公式管理画面で確認し、必要最小限の権限で再発行します。
認証自体は成功し、権限が足りない場合は403が適切ですが、実装によって401になる場合もあります。解決のためだけにWordPressユーザーを管理者へ昇格したり、APIトークンへ全権限を与えたりせず、必要な操作だけを許可します。
401対応でやってはいけないこと
- ログイン、保存、APIを連打し、自動再試行を続ける
- Authorization、Cookie、nonce、パスワード、トークンを公開する
- Application PasswordをWordPressログイン画面へ入力する
- WordPressの主パスワードを外部連携へ渡す
- Basic認証をHTTPで利用する
- 全ユーザー・全連携のパスワードを同時に変更する
- REST API、nonce、CSRF対策、WAFを全面停止する
.htaccessやサーバー認証設定を丸ごと削除する- ユーザーを管理者へ昇格し、APIトークンへ全権限を与える
- 公開ページの401を正常な200応答へ見せかける
認証設定の変更前には、WordPressのバックアップを安全に取る手順で復元方法を確認し、元の値を記録します。
復旧後の確認と再発防止
- 公開ページ、wp-login、wp-adminが意図した応答を返す
- 記事保存、画像アップロード、予約投稿が一度ずつ成功する
- REST APIと外部連携が必要な権限だけで動く
- 失効した古い資格情報では接続できない
- Basic認証やWAFの必要な保護が有効である
- AuthorizationやCookieがログへ平文で残っていない
- 資格情報ごとに名前、用途、管理者、更新日を記録した
- 401、403、429が繰り返されていない
公開ページが意図せず401を返し続けると、検索にも影響します。GoogleのHTTPステータス公式資料では、429以外の4xxを返すURLの内容は検索に利用されず、継続すれば既存URLもインデックスから外れると説明されています。会員ページやステージングの意図的な保護とは分け、公開URLだけは早めに200へ戻します。
サポートへ伝える情報
- 401が出たURLまたはAPIの送信先
- 発生時刻とタイムゾーン
- ブラウザ小窓、WordPress画面、API応答のどれか
- WWW-Authenticateの方式とrealm
- 公開画面、ログイン、保存、外部連携のどこで出るか
- Server、CDN識別ID、応答JSONのエラーコード
- 直前の認証・プラグイン・CDN変更
- 資格情報を伏せたログ
- 実施済みの確認と結果
「401を直してください」だけでなく、「7月21日15時、外部投稿ツールからwp-jsonへの要求だけ401。WWW-AuthenticateはBasic。通常の管理画面は正常。Application Passwordは最終利用なし」のように伝えると、調査対象を絞れます。
よくある質問
401は「権限がない」という意味ですか？
仕様上は、有効な認証情報がない、または送った資格情報が拒否された状態です。認証済みでも権限が足りない場合は403が基本です。ただし実装による違いがあるため、本文とログも確認します。
WordPressのパスワードを変えれば直りますか？
Basic認証、Application Password、外部APIトークンが原因なら、WordPressの通常パスワードを変えても直りません。まず401を返した場所と認証方式を特定します。
Application Passwordで管理画面へ入れますか？
入れません。Application PasswordはREST APIなど、アプリやスクリプトのプログラム認証用です。管理画面では通常のWordPressユーザーのパスワードを使います。
WWW-Authenticateがない401はどうしますか？
RFC上は401に必要ですが、独自実装や中継で欠落している可能性があります。応答本文、CDN・配信元ログ、失敗したURLを確認し、提供元へ問い合わせます。
キャッシュ削除で直りますか？
古いログインセッションの切り分けには役立つ場合がありますが、資格情報の失効、Authorizationヘッダーの欠落、権限不足はキャッシュ全消去では直りません。発行元を先に確認します。
401から429へ変わりました
認証試行を繰り返したため、回数制限が追加された可能性があります。操作を止め、Retry-Afterと制限ログを確認してください。詳しくはWordPressの429 Too Many Requestsを直す手順へ進みます。
まとめ
WordPressの401 Unauthorizedは、対象へ必要な有効な認証情報がない、または送った資格情報が拒否された状態です。まず試行を止め、URL、時刻、応答本文、WWW-Authenticateを確認し、Basic認証、通常ログイン、REST API、Application Password、外部トークンを分けます。
全パスワードを変えるのではなく、失敗した認証方式の資格情報だけを安全に修正することが復旧の近道です。秘密情報を伏せた記録をそろえ、自分で発行元を確認できない場合はホストや連携サービスへ相談してください。