HTTP 401 Unauthorizedエラーとは？原因と解決方法を徹底解説

401 Unauthorizedエラーとは？

401 Unauthorizedエラーは、リクエストされたリソースに対してサーバーが認証を要求しているが、リクエストに認証情報が含まれていないか、提供された認証情報が無効であることを示すHTTPステータスコードです。

HTTP仕様（RFC 9110、セクション15.5.2）では、「リクエストに対象リソースの有効な認証情報がない」と定義されています。401レスポンスを生成するサーバーは、使用する認証スキームを示すWWW-Authenticateヘッダーを含める必要があります。

簡単に言えば、サーバーはアクセスを許可する前に「あなたは誰ですか？」と尋ねています。身分証明を提供しなかったか、提供した身分証明が間違っていたということです。

401エラーの表示例

401エラーは、サーバー、ブラウザ、アプリケーションによって異なる表示になります。以下は最もよく見られるメッセージの一覧です。

• 401 Unauthorized — 標準的なHTTPレスポンスメッセージ

• HTTP Error 401 – Unauthorized — IISやASP.NETアプリケーションでよく見られる形式

• 401 Authorization Required — Nginxのデフォルトエラーページ

• Error 401 — ブラウザのアドレスバーに表示される短縮形

• Access Denied: Invalid credentials — カスタムアプリケーションのエラーページ

• Authentication Required — Basic/Digest認証時のブラウザポップアッププロンプト

• Invalid API Key — REST APIレスポンスでよく見られる形式

• Token Expired — JWTまたはOAuthトークンの更新が必要

サーバーが401を返すと、ほとんどのブラウザはユーザー名とパスワードを求めるログインポップアップを表示します。サーバーがトークンベース認証（APIなど）を使用している場合は、JSONレスポンスボディにエラーが表示されます。

401と403の違いとは？

401と403のステータスコードは、経験豊富な開発者でも頻繁に混同されます。違いはシンプルです。401は「あなたが誰か分からない」を意味し、403は「あなたが誰か分かるが、アクセスは許可されていない」を意味します。

実用的なルール：正しいユーザー名とパスワード（またはAPIキー）を提供すれば解決する場合、サーバーは401を返すべきです。ユーザーがすでに認証済みだが、そのリソースへのアクセス権がない場合、サーバーは403 Forbiddenを返すべきです。

401エラーの一般的な原因

401エラーが発生する原因は、一般ユーザー、API開発者、サーバー管理者のどの立場かによって異なります。以下は最も頻繁に見られる原因です。

• ユーザー名またはパスワードの間違い — 特にパスワードリセット後に最も基本的な原因

• 認証トークンの有効期限切れ — JWTトークン、OAuthアクセストークン、セッションCookieにはすべて有効期限があります

• Authorizationヘッダーの欠如 — リクエストに認証情報が一切含まれていない

• 無効なAPIキー — キーが取り消された、ローテーションされた、または誤ってコピーされた

• 認証スキームの不一致 — サーバーはBearerトークンを期待しているがBasic認証が送信された（またはその逆）

• クロックスキュー（時刻のずれ） — サーバーとクライアントの時刻が数分以上ずれるとJWT検証が失敗する

• CORSプリフライトによるヘッダー除去 — ブラウザがプリフライトOPTIONSリクエストからAuthorizationヘッダーを除去する

• 古いブラウザキャッシュ — ブラウザが新しいものを要求する代わりに、キャッシュされた期限切れのセッションCookieを送信する

• リバースプロキシの設定ミス — NginxやApacheがバックエンドに転送する前にAuthorizationヘッダーを除去してしまう

• レート制限または認証情報の失効 — ログイン失敗が多すぎてアカウントがロックされた

訪問者としての401エラーの解決方法

ウェブサイトにアクセスしようとして401エラーが表示された場合、問題はほぼ確実にログイン認証情報に関連しています。以下の手順を順番に実行してください。

1. ログイン認証情報を確認する

401エラーの最も一般的な原因は、単純に認証情報の間違いです。サイトにログインポップアップやフォームが表示された場合、ユーザー名とパスワードを再確認してください。

よくある間違い：Caps Lockがオンになっている、古いパスワードを使用している（特に最近リセットした後）、間違ったアカウントにログインしようとしている。パスワードマネージャーを使用している場合は、入力ミスを避けるために自動入力を使用してください。

2. ブラウザのキャッシュとCookieをクリアする

ブラウザが期限切れのセッションCookieやキャッシュされた認証トークンを送信している可能性があります。これらをクリアすることで、ブラウザがサーバーから新しい認証情報を要求するようになります。

Chrome:  Settings → Privacy → Clear browsing data → Cookies + Cached images
Firefox: Settings → Privacy → Clear Data → Cookies + Cache
Safari:  Settings → Privacy → Manage Website Data → Remove All
Edge:    Settings → Privacy → Clear browsing data → Cookies + Cache

クリア後、ブラウザを完全に閉じ（タブだけでなく）、再度開いてページにアクセスしてください。新しいログインプロンプトが表示されるはずです。

3. シークレットモードまたはプライベートモードで試す

シークレット（Chrome）またはプライベート（Firefox/Safari）ウィンドウでURLを開いてください。これにより、キャッシュされたすべてのCookie、拡張機能、保存された認証情報がバイパスされます。

シークレットモードではページが動作するが通常のブラウザでは動作しない場合、問題はキャッシュされたCookieか、認証を妨げるブラウザ拡張機能です。拡張機能を一つずつ無効にして原因を特定してください。

4. URLを確認する

正しいURLにアクセスしていることを確認してください。一部のサーバーは、パス自体が間違っている場合でも、認証が必要なパスに対して401を返します。アクセスするべきでない制限エリアにアクセスしようとしている可能性があります。

別のURLにページの公開バージョンがないか確認してください。例えば、example.com/admin/は401を返しますが、example.com/は公開アクセス可能な場合があります。

開発者としての401エラーの解決方法

APIを扱う開発者の場合、401エラーは通常、Authorizationヘッダー、トークンの形式、または認証情報のライフサイクルに関する問題です。以下は最も一般的な修正方法です。

5. Authorizationヘッダーを確認する

開発者が最もよく犯すミスは、Authorizationヘッダーの形式の誤りです。サーバーのWWW-Authenticateレスポンスヘッダーが、どの認証スキームが期待されているかを正確に示しています。

ヘッダーが要求される形式と一致していることを確認してください。最も一般的なスキームは、Bearer（トークン用）とBasic（Base64エンコードされたユーザー名:パスワード用）です。

# Bearer token authentication (most APIs)
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." https://api.example.com/data

# Basic authentication (username:password in Base64)
curl -u "username:password" https://api.example.com/data
# Equivalent to:
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

# Common mistakes that cause 401:
# Missing "Bearer " prefix:  Authorization: eyJhbGci...  ← WRONG
# Extra space:               Authorization: Bearer  eyJ... ← WRONG
# Wrong scheme:              Authorization: Basic eyJhbGci... ← WRONG

必ず401レスポンスのWWW-Authenticateヘッダーを確認してください。サーバーが何を期待しているかが正確に記載されています。DNS RobotのHTTPヘッダーツールを使用して、完全なレスポンスを検査できます。

6. APIキーの有効性を確認する

APIキーは、いくつかの理由で気づかないうちに機能しなくなることがあります。キーがローテーションされた、関連するアカウントがダウングレードされた、キーのレート制限に達した、またはアクセスしようとしているエンドポイントとは異なるスコープに設定されている場合です。

プロバイダーのダッシュボードでキーがまだ有効であることを確認してください。多くのAPI（Google、AWS、Stripe）では、コンソールから直接キーをテストできます。

# Test if your API key is valid
curl -I -H "Authorization: Bearer YOUR_API_KEY" https://api.example.com/me
# 200 = key is valid
# 401 = key is invalid or expired
# 403 = key is valid but lacks permission for this endpoint

# Check common API key issues:
# 1. Trailing whitespace in .env file:  API_KEY="abc123 " ← trailing space
# 2. Wrong environment:                 using test key on production
# 3. Missing prefix:                    some APIs need "sk_live_" prefix

7. トークンの有効期限切れとリフレッシュに対応する

JWTトークンとOAuthアクセストークンには有効期間が設定されており、通常は15分から24時間です。有効期限が切れると、新しいトークンを取得するまで、すべてのAPI呼び出しが401を返します。

修正方法は認証フローによって異なります。OAuth 2.0では、リフレッシュトークンを使用して再認証なしで新しいアクセストークンを取得できます。JWTベースのシステムでは、通常は新たなログインが必要です。

# Decode a JWT token to check its expiry (works on macOS and Linux)
echo "eyJhbGciOiJIUzI1NiIs..." | cut -d'.' -f2 | base64 -d 2>/dev/null | python3 -m json.tool
# Look for "exp" field — it's a Unix timestamp
# Compare with current time: date +%s

# OAuth 2.0 refresh token flow
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=YOUR_REFRESH_TOKEN" \
  -d "client_id=YOUR_CLIENT_ID"

8. CORSプリフライトの問題を修正する

ブラウザがAuthorizationヘッダーを含むクロスオリジンリクエストを送信する際、まずプリフライトOPTIONSリクエストを送信します。ブラウザはこのプリフライトからAuthorizationヘッダーを自動的に除去します。サーバーがOPTIONSリクエストに認証を要求している場合、実際のリクエストが送信される前に401が返されます。

修正方法：CORS対応のエンドポイントで、認証なしでOPTIONSリクエストを許可するようにサーバーを設定してください。

# Nginx — allow OPTIONS requests without auth
location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin *;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
        add_header Access-Control-Allow-Headers "Authorization, Content-Type";
        add_header Access-Control-Max-Age 86400;
        return 204;
    }

    # Normal auth for other methods
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

サイト管理者としての401エラーの解決方法

訪問者やユーザーから401エラーの報告がある場合、問題はサーバーの認証設定にあります。以下のチェック項目を順番に確認してください。

9. サーバーの認証設定を確認する

認証が必要なルートにのみ認証が有効になっていることを確認してください。よくある間違いは、特定のパスだけがログインを必要とするのに、ディレクトリ全体やサイト全体を保護してしまうことです。

Nginxではauth_basicディレクティブを確認してください。ApacheではAuthTypeとRequireディレクティブを確認してください。Node.js/Expressでは、ミドルウェアの順序を確認してください。認証ミドルウェアがルートハンドラーの前に配置されていると、すべてのリクエストがブロックされます。

# Nginx — WRONG: protects everything, including public pages
server {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # All pages now require login — including your homepage!
}

# Nginx — CORRECT: only protect admin routes
server {
    location / {
        # Public — no auth required
    }
    location /admin/ {
        auth_basic "Admin Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

10. .htaccessの認証ルールを確認する

Apacheサーバーでは、.htaccessファイルで特定のディレクトリのBasicまたはDigest認証を有効にできます。公開ディレクトリにAuthTypeディレクティブを含む.htaccessファイルが存在する場合、すべての訪問者に401ログインプロンプトが表示されます。

影響を受けているディレクトリとすべての親ディレクトリに.htaccessファイルがないか確認してください。Apacheはパス内のすべての.htaccessのルールを適用します。

# Find all .htaccess files with auth rules
find /var/www/html -name '.htaccess' -exec grep -l 'AuthType\|AuthUserFile\|Require valid-user' {} \;

# Example .htaccess that causes 401 for everyone:
# AuthType Basic
# AuthName "Restricted Area"
# AuthUserFile /etc/apache2/.htpasswd
# Require valid-user

# Fix: remove auth lines from public directories,
# or move them to the specific /admin/.htaccess only

11. リバースプロキシのヘッダー除去を修正する

アプリがNginx、Apache、またはロードバランサーの背後にある場合、プロキシがバックエンドにリクエストを転送する前にAuthorizationヘッダーを除去している可能性があります。これは最も厄介な401の原因の一つです。クライアントは正しい認証情報を送信しているのに、サーバーがそれを受信しないからです。

プロキシの設定で、Authorizationヘッダーが正しく転送されていることを確認してください。

# Nginx reverse proxy — pass Authorization header to backend
location /api/ {
    proxy_pass http://localhost:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Authorization $http_authorization;  # ← Critical!
    proxy_pass_header Authorization;                      # ← Also add this
}

# Apache reverse proxy
<Location /api/>
    ProxyPass http://localhost:3000/api/
    ProxyPassReverse http://localhost:3000/api/
    RequestHeader set Authorization "expr=%{HTTP:Authorization}"  # Pass auth header
</Location>

HTTPヘッダーを使った401エラーのデバッグ

401エラーを診断する最も速い方法は、レスポンスヘッダーを検査することです。サーバーのレスポンスに含まれるWWW-Authenticateヘッダーが、どの認証方法が必要かを正確に示しています。

DNS RobotのHTTPヘッダーツールまたはターミナルからcurlを使用して、完全なレスポンスを確認してください。

# Check the WWW-Authenticate header in the 401 response
curl -I https://api.example.com/protected-endpoint

# Typical 401 response headers:
# HTTP/1.1 401 Unauthorized
# WWW-Authenticate: Bearer realm="api", error="invalid_token"
# WWW-Authenticate: Basic realm="Admin Area"
# Content-Type: application/json

# The WWW-Authenticate header tells you:
# - The auth scheme (Bearer, Basic, Digest)
# - The realm (which area is protected)
# - The error reason (invalid_token, expired, etc.)

WWW-Authenticateヘッダーに特に注目してください。Bearerと表示されている場合はトークンが必要です。Basicの場合はユーザー名とパスワードが必要です。error=invalid_tokenが含まれている場合、トークンは存在するが形式が不正か期限切れです。この1つのヘッダーで、通常何が間違っているかが正確に分かります。

401エラーはSEOに影響するか？

公開ページで401エラーが発生すると、SEOに悪影響を与えます。Googlebotが401に遭遇すると、ページをクロールできず、最終的にインデックスから削除されます。

ただし、認証が必要なページ（管理パネル、ユーザーダッシュボード、APIエンドポイント）での401エラーは完全に正常です。Googleはこれらのページが保護されていることを想定しており、サイトにペナルティを課すことはありません。

問題が生じるのは、一般公開されるべきページで401エラーが表示される場合です。これは通常、認証ミドルウェアの設定ミス、またはCDN/リバースプロキシが公開ルートに誤って認証を要求している場合に発生します。

401エラーを防止する方法

予防は後のデバッグ作業を省きます。アプリケーションやウェブサイトでの401エラーを最小限に抑えるために、以下のプラクティスを実践してください。

• トークンの自動リフレッシュを実装する — リフレッシュトークンを使用して、有効期限が切れる前にサイレントに新しいアクセストークンを取得する

• 適切な認証スコープを設定する — 本当に認証が必要なルートのみを保護し、公開ページはオープンにする

• 明確なエラーメッセージを返す — ステータスコードだけでなく、役立つJSONエラーボディを401と一緒に返す

• 認証失敗を監視する — 401レスポンスの急増に対するアラートを設定する（認証情報の問題や攻撃を示す可能性がある）

• サーバーの時刻を同期する — NTPを使用してすべてのサーバーをUTCの数秒以内に保ち、JWTのクロックスキューによる拒否を防ぐ

• [HTTPヘッダーツール](/http-headers)でテストする — 公開ページが200を、保護されたページが期待通り401を返すことを定期的に確認する

• 認証スキームをドキュメント化する — 期待されるAuthorizationヘッダーの形式をAPIドキュメントで明確にする

• CORSプリフライトに対応する — APIエンドポイントでは常に認証なしでOPTIONSリクエストを許可する