HTTP 405 Method Not Allowed：意味と解決方法

このエラーの意味と見分け方

• ブラウザ、API クライアント、監視ツール、チェッカーが 405 Method Not Allowed を受け取る。
• ある HTTP メソッドは失敗する一方、同じルートに対する別のメソッドは動作する場合がある。
• 問題はサイト全体ではなく、1 つの URL、ルートパターン、クライアント、デプロイに限定される場合がある。
• レスポンスに、許可されているメソッドを列挙した Allow ヘッダーが含まれる場合がある。
• その他のヘッダーから、リダイレクト、キャッシュ、認証、プロキシ、CDN、サーバーの状況が分かる場合がある。
• HTTP レスポンスを受信できているため、DNS 名前解決と TLS ネゴシエーションはすでに成功している可能性があります。ただし、これはアプリケーションやルートが正しく設定されていることを意味しません。

可能性の高い順の主な原因

主な原因

1. そのメソッドがルートでサポートされていない。 エンドポイントが GET は受け付けても POST を拒否したり、POST は受け付けても PUT や PATCH などの更新用メソッドを拒否したりする場合があります。
2. ルーティングまたは Web サーバーのルールがメソッドを拒否している。 ルート、バーチャルホスト、サーバーポリシーによって、リクエストが意図したハンドラーに渡されない場合があります。
3. リバースプロキシ、CDN、WAF が先にレスポンスを返している。 中間層がメソッド制限を適用したり、オリジンとは異なる方法でリクエストをルーティングしたりする場合があります。
4. リクエストがアプリケーションの契約に一致していない。 パス、末尾のスラッシュ、コンテンツタイプ、ホスト、認証状態、その他のリクエスト詳細によって、別のルートや検証ルールが選択される場合があります。
5. 最近のデプロイまたは設定変更によって不整合が生じた。 アプリケーションのルート、プロキシルール、許可メソッド、キャッシュ動作の間に不整合が生じている可能性があります。
6. 意図的なポリシーまたはエンドポイント設計。 リソースによっては、安全でない、サポート対象外、または文書化されたインターフェースの範囲外のメソッドを意図的に拒否します。

ステータスコードだけでは、どのレイヤーまたはルールがレスポンスの原因になったかを特定できません。システムを変更する前に、メソッド、ヘッダー、ログ、最近の変更を確認してください。

修正方法

訪問者または API 利用者の場合

1. 正確な URL と、クライアントが意図したメソッドを送信しているかを確認します。ブラウザのアドレスバーからのリクエストは通常 GET を使用しますが、API クライアントは POST、PUT、PATCH、DELETE などのメソッドを使用する場合があります。
2. レスポンスヘッダーで Allow ヘッダー、およびリダイレクト、認証、キャッシュ、プロキシに関する情報を確認します。サイトまたは API のドキュメントでサポートされていると明記されていない限り、別のメソッドを有効な回避策として扱わないでください。
3. エンドポイントにアカウントが必要な場合は、通常の手順でサインインして再試行します。サポートへの問い合わせに認証情報を含めないでください。
4. サービスがレート制限、タイムアウト、過負荷の兆候も示している場合は、繰り返し再試行しないでください。
5. 問題が解決しない場合は、URL、メソッド、タイムスタンプ、ステータスコード、関連するサニタイズ済みヘッダーをサイト管理者に送信します。パスワード、Cookie、認証トークン、API シークレットは共有しないでください。

サイトを所有または管理している場合

1. 最小限の再現条件を記録します。 正確なメソッド、URL、ホスト、リクエストパス、ステータス、関連するレスポンスヘッダーを記録します。リクエストボディに秘密情報や個人データが含まれていない場合に限り、保存してください。
2. レスポンスが意図したものか確認します。 リクエストをルートまたは API の契約と比較します。そのリソースが対象のメソッドをサポートする設計か、また Allow ヘッダーが受け付けるメソッドを示しているかを確認します。
3. レスポンスを返したレイヤーを特定します。 レスポンスヘッダー、リクエスト ID、タイムスタンプを使い、レスポンスがアプリケーション、Web サーバー、リバースプロキシ、CDN、WAF のどこから返されたかを特定します。プロキシが生成したレスポンスは、オリジンに到達していない可能性があります。
4. 該当するログを調べます。 特定したレイヤーと、利用できる場合は上流レイヤーで、同じタイムスタンプ、パス、メソッド、リクエスト ID を検索します。ルートの不一致、メソッドフィルター、上流リクエストの拒否、最近のポリシー変更を確認します。
5. 最近の変更を比較します。 デプロイ、ルート定義、Web サーバーのルール、プロキシまたは CDN の動作、認証設定、WAF ポリシーを確認します。同じルートで失敗するメソッドと、既知のサポート対象メソッドを比較します。
6. 権限のある最小限の修正を適用します。 メソッドをサポートすべきルートまたはルールだけを更新します。エラーを消すために、認証、WAF 保護、メソッド制限を広範囲に無効化しないでください。
7. 安全に再テストします。 可能な場合は非本番環境で同じリクエストを繰り返し、その後、承認された変更手順に従って影響を受けた本番ルートをテストします。サポート対象外のメソッドが引き続き拒否され、関連ルートが意図したステータスコードを返すことを確認します。
8. キャッシュと中間層を確認します。 クライアントや場所によって動作が異なる場合は、プロキシまたは CDN がレスポンスをキャッシュしていないか、別のルールを適用していないかを確認します。キャッシュの動作をパージまたは変更する場合は、サービスの通常の運用手順に従ってください。

予防と修正確認

• 重要な Web ルートと API エンドポイントでサポートするメソッドを定義し、文書化します。
• アプリケーション、サーバー、プロキシ、CDN、WAF を変更した後、重要なルートで代表的なメソッドをテストします。
• すべての 4xx レスポンスを 1 つのグループとして扱わず、ルートとメソッドごとのステータスコード率を監視します。
• ルーティング、メソッド制限、認証、プロキシ設定をバージョン管理します。
• 中間層とオリジンのレイヤー間で障害を照合できるよう、リクエスト ID とログを十分な期間保持します。
• 意図的な 405 レスポンスを文書化し、サポートチームと監視チームが想定された動作とリグレッションを区別できるようにします。
• 広範囲にメソッドを許可することは避け、各リソースとアプリケーションの契約に必要なメソッドだけを許可します。

よくある質問