先に結論
405はURLが存在しないのではなく、そのリソースが受け付けないHTTP methodで要求された時の応答です。Allowヘッダーを保存し、ブラウザー・CDN／WAF・reverse proxy・アプリrouteのどこでmethodが拒否されたかを同じURLの成功要求と比較します。
URLとmethodをセットで記録する
- 完全なURL、HTTP method、発生時刻、status、response header、request IDを保存する。
Allowヘッダーがあるか、値が実際の仕様と合うかを確認する。- 同じURLへGET／HEADなど許可済みmethodを送り、リソース自体が存在するか確認する。
- CDN／WAF、reverse proxy、アプリのどこに405記録があるかを時刻で追う。
- 直前のroute、framework、proxy、WAF、デプロイ変更を差分化する。
結論：同じURLでGETは成功しPOSTだけ405ならmethod・route側、OPTIONSだけ405ならpreflight経路を優先します。全methodが404ならURL・デプロイを先に確認します。
失敗するmethodから原因候補を絞る
| 観測 | 優先候補 | 次の確認 |
|---|---|---|
| GET成功・POST失敗 | POST route未登録 | route表、handler、公開先environment |
| OPTIONSだけ405 | preflight route・proxy | OPTIONSとCORS headerを確認 |
| 本番だけ405 | CDN／WAF・proxy差分 | 本番route、method allowlist、cache |
| デプロイ直後 | 古いinstance・route漏れ | version、region、target、rolling状態 |
| 全methodで404 | URL・rewrite | 404・移行経路を確認 |
| 認証前だけ失敗 | gateway認証・redirect | 401と認証経路を確認 |
最初に405を返した層を特定する
- edgeのrequest IDとstatusを確認し、通過していれば次のproxyへ進む。
- WAF・API gatewayのmethod allowlistと拒否ruleを確認する。
- reverse proxyのlocation、rewrite、upstreamへ渡したmethodを確認する。
- アプリのroute一覧と実際に稼働中のversionを照合する。
- 405応答のAllowと、公開API仕様・route実装の差を修正する。
一部instanceだけ古いrouteでないか確認する
rolling deploymentや複数regionでは、同じURL・methodでも接続先により成功と405が混在します。request ID、instance、version、regionを記録し、全targetへrouteが反映済みかを確認します。cache purgeだけで隠さず、旧versionを安全に切り離せるかを判断します。
避ける操作
- 原因未確認でWAFやgatewayの全methodを許可する。
- POST／PUT／DELETEをGETへ置き換え、状態変更をquery stringで実行する。
- OPTIONSの405を消すためCORSを全origin・全header許可へ広げる。
- 405を404や200へ置換し、API仕様と実装のずれを隠す。
- 本番だけに手動routeを追加し、構成管理との差分を残す。
公式情報
よくある質問
405と404の違いは何ですか？
405はサーバーがmethodを理解している一方、その対象リソースでは許可していない応答です。404は対象リソースが見つからない、または存在を明かさない応答です。まず同じURLでGETなど別methodが成功するかを確認します。
405応答には何を含めるべきですか？
RFC 9110では、405を返すサーバーは対象リソースで現在サポートするmethodをAllowヘッダーで示す必要があります。実際のroute設定とAllowが一致するか確認します。
OPTIONSの405はCORSエラーですか？
ブラウザーのpreflightがOPTIONSで405になるとCORS失敗として見えることがあります。ただし原因はCORS headerだけでなく、OPTIONS routeやproxy・WAFでのmethod拒否です。各層のログで応答主体を特定します。