405 Method Not Allowed とは？原因と解決方法

405 Method Not Allowed エラーとは？

405 Method Not Allowed は、リクエストしたアドレスをサーバーは認識しているものの、リクエストで使われたメソッドを許可していないことを示す HTTP ステータスコードです。RFC 9110（セクション 15.5.6）では、そのメソッドが「オリジンサーバーには認識されているが、対象リソースではサポートされていない」状態と定義されています。

すべての HTTP リクエストにはメソッドがあります。ページを読むための GET、フォームを送信したり何かを作成したりする POST、更新するための PUT と PATCH、削除するための DELETE、許可されている操作を問い合わせる OPTIONS です。405 は、URL は存在するものの、その動詞（メソッド）では使えないという意味です。URL そのものが存在しなければ、代わりに 404 が返ります。

405 はページが見つからないことではなく、リクエストの送り方に関するエラーなので、ほとんどの場合はサイトの開発者が直すべきものです。訪問者がこのエラーに遭遇するのは、たいていフォームを送信した後や、古いリンクをたどったときです。

405 エラーの表示例

ステップ1：Allow ヘッダーを確認する

その URL でどのメソッドを受け付けるのかを、サーバーに問い合わせます。OPTIONS リクエストを送るか、失敗したリクエストをヘッダー付きで再送してください。

# この URL はどのメソッドを受け付けるか？
curl -i -X OPTIONS https://example.com/api/contact

# 失敗したリクエストを再送し、ステータスと Allow ヘッダーを確認する
curl -i -X POST https://example.com/api/contact -d 'name=test'
# HTTP/2 405
# allow: GET, HEAD

DNS Robot の HTTP ヘッダーチェックツールは、通常の GET リクエストに対して URL が返すステータスコードとヘッダーを表示します。API ではなく、ブラウザで開くページを確認するときに便利です。

すべてのサーバーがこのルールに従っているわけではありません。たとえば nginx 組み込みの 405 ページは Allow ヘッダーなしで送信されるため、nginx の場合は代わりに、どの location ブロックがその URL を処理しているかを確認する必要があります（解決策2）。

訪問者の方へ

• 前のページに戻って再読み込みしてから、フォームをもう一度送信します。古いキャッシュから読み込まれたフォームは、その後変更されたアドレスに送信してしまうことがあります。

• 送信後にページを更新しない。 フォーム送信の結果として表示されたページを更新すると、GET しか受け付けない URL に POST が再送されることがあります。

• アドレスを確認する。 入力ミスがないか確かめるか、サイトのトップページを開いてもう一度たどってください。

• 報告する。 サイトのフォームが毎回失敗する場合はサイト管理者が直す必要があるので、ページのアドレスを伝えましょう。

解決策1：正しい URL に正しいメソッドを送る

コードで最もよくある原因は、単純な食い違いです。エンドポイントが GET しか受け付けないのにフォームや fetch() 呼び出しが POST を使っている、あるいはリクエストが API の URL ではなくページの URL に送られている、といったケースです。コード内のメソッドを、Allow ヘッダーや API のドキュメントと照らし合わせてください。

// このエンドポイントは POST しか許可しないため、GET（fetch のデフォルト）では 405 が返る
const res = await fetch("/api/contact", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ name: "Ana" }),
})
if (res.status === 405) console.log("Allowed:", res.headers.get("allow"))

解決策2：nginx が静的ファイルへの POST に 405 を返す

nginx の静的ファイルハンドラーは GET と HEAD しか処理しません。.html ファイルへの POST や、リクエストをアプリケーションに渡さずにファイルを返す location への POST には、405 Not Allowed が返されます。これは、フォームの action が静的ページを指している場合や、アプリ用の location ブロックが一致しない場合によく起こります。

根本的な解決策は、適切な location ブロックで proxy_pass または fastcgi_pass を使い、POST をアプリケーション（PHP、Node、Python）に送ることです。どのブロックがその URL を処理しているかを確認してください。

# フォームの POST は静的ファイルハンドラーではなくアプリに届ける必要がある
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

# 変更後にテストして再読み込みする
# sudo nginx -t && sudo systemctl reload nginx

解決策3：IIS が PUT と DELETE をブロックする（WebDAV）

IIS を実行している Windows サーバーでは、WebDAV モジュールが PUT と DELETE の動詞を横取りするため、REST API（ASP.NET Web API など）はそれらに対して HTTP Error 405.0 を返します。WebDAV を使っていない場合は、web.config でサイトから削除してください。

<system.webServer>
  <modules>
    <remove name="WebDAVModule" />
  </modules>
  <handlers>
    <remove name="WebDAV" />
  </handlers>
</system.webServer>

IIS マネージャーで、サイトの 要求フィルター（Request Filtering）設定の HTTP 動詞 タブも確認してください。特定のメソッドを一律に拒否している場合があります（その場合、IIS は 405 ではなく 404.6 を返します）。

解決策4：ルートハンドラーにメソッドを追加する

ルートは存在するのに、使われたメソッドに対応するハンドラーがない場合、フレームワークは 405 を返します。

• Next.js（App Router）： route.ts は、エクスポートしているメソッドにしか応答しません。GET だけをエクスポートして POST をエクスポートしていなければ、POST には 405 が返ります。export async function POST(request: Request) { … } を追加してください。

• Flask： ルートはデフォルトで GET しか受け付けません。@app.route("/contact", methods=["GET", "POST"]) を使います。

• Django： クラスベースビューは、対応するハンドラーがないメソッドに 405 を返します（post() メソッドを追加します）。require_http_methods デコレーターも同様です。

• Express： デフォルトでは、一致しないメソッドは 405 ではなく 404 になります。API で 405 を返したい場合は、Allow ヘッダーを設定するキャッチオールハンドラーを追加してください。

解決策5：CORS プリフライト（OPTIONS）リクエストを処理する

ウェブページが JSON やカスタムヘッダーを使って別ドメインの API を呼び出すとき、ブラウザはまず OPTIONS プリフライトリクエストを送ります。API がその OPTIONS リクエストに 405 を返すと、本来のエンドポイントは正常に動くはずなのに、ブラウザは CORS エラーを報告して本来のリクエストを送りません。

それらのルートでは、API が OPTIONS に 204 または 200 で応答し、適切な Access-Control-Allow-Methods ヘッダーと Access-Control-Allow-Headers ヘッダーを返すようにします。ほとんどのフレームワークには、これを自動で行う CORS ミドルウェアがあります。たとえば DNS Robot 自身の DNS Lookup API はプリフライトに 204 と CORS ヘッダーで応答するので、どのサイトからでもブラウザから呼び出せます。

405 と 400、403、404、501 の違い

関連ガイド：400 Bad Request、403 Forbidden、401 Unauthorized。