405 Method Not Allowedの深淵：プロトコルスタックから紐解くAPI設計の美学
APIの設計において、405 Method Not Allowed は単なる「エラー」ではありません。それは、クライアントとサーバーの間で交わされる「リソースに対する契約」が破られたことを示す、極めて重要なプロトコル上のシグナルです。
多くのエンジニアはこれを「メソッドを間違えただけ」と軽視しますが、ネットワークスペシャリストの視点から見れば、これはリバースプロキシ、アプリケーション層、そしてOSのカーネルに至るまで、スタック全体の整合性を問う試金石と言えます。
パケットが語る405の真実
HTTP/1.1の仕様（RFC 9110）において、405 Method Not Allowed は「リクエストされたメソッドは、リクエストされたリソースに対して知られているが、そのメソッドは許可されていない」場合に発生します。
ここで注目すべきは、サーバー側が送信する必須ヘッダーである Allow です。
HTTP/1.1 405 Method Not Allowed
Date: Mon, 20 May 2024 10:00:00 GMT
Allow: GET, HEAD, OPTIONS
Content-Length: 0
Connection: keep-aliveこの Allow ヘッダーが欠落している実装は、プロトコルに対する敬意を欠いています。クライアントが次にどのメソッドを試すべきか、その「航路」を提示しないからです。
パフォーマンスとセキュリティの交差点：TLSハンドシェイクとRTT
405 が返される際、すでに TCP 3-way handshake が完了し、TLS 1.3 の ClientHello / ServerHello も終了しています。つまり、貴重なRTT（Round Trip Time）を浪費した後に「お断り」をしているわけです。
高負荷な環境において、無効なメソッドによるリクエストが大量に押し寄せると、TCP ACK や TLS の暗号化・復号処理がCPUリソースを食いつぶします。これを防ぐには、アプリケーション層に到達する前の「境界」で遮断するのが鉄則です。
Nginxによる高速なメソッドフィルタリング
リバースプロキシの段階で不必要なメソッドを 405 で即座に返すことで、バックエンド（Node.jsやPython等）のプロセス生成コストを排除します。
# Nginx設定ファイル: 許可外のメソッドをエッジで即座に拒絶する
location /api/resource {
# GET, POST, OPTIONS 以外は処理せず即座に405を返す
limit_except GET POST OPTIONS {
deny all;
}
}TCPバッファチューニングとヘッダー圧縮
大規模なトラフィックを扱う場合、HTTP/2 または HTTP/3 の採用は必須です。HPACK や QPACK によるヘッダー圧縮は、Allow ヘッダーのような頻出する文字列を動的テーブルにインデックス化し、バイト数を削減します。
また、405 を返すような不正なリクエストが攻撃目的（メソッドの列挙による脆弱性スキャンなど）である場合、TCP の受信バッファを枯渇させる Slowloris 攻撃の標的にならないよう、カーネルパラメータを調整しておく必要があります。
# /etc/sysctl.conf: 接続の信頼性を高めるためのチューニング
# 半開接続のキューサイズを増やし、攻撃による溢れを防ぐ
net.ipv4.tcp_max_syn_backlog = 4096
# 接続終了後のTIME_WAIT状態のソケットを再利用可能にする
net.ipv4.tcp_tw_reuse = 1セキュリティの観点：メソッドの列挙と脆弱性
攻撃者は OPTIONS メソッドを使用して、そのエンドポイントがどのメソッドを許容しているかを執拗に探ります。もし、管理用URLに対して OPTIONS を許可し、Allow: GET, POST, DELETE などと返せば、それは「攻撃のメニュー表」を渡しているのと同じです。
設計時には、以下の原則を守ってください。
1. 最小権限の原則: 許可が必要ない限り、OPTIONS へのレスポンスには最小限のメソッドのみを記述する。
2. 隠蔽: 405 を返す際に、サーバーの種類やバージョンを特定できる Server ヘッダーを proxy_hide_header 等で確実に削除する。
3. ログ記録: 頻発する 405 は、不正なスキャンや、クライアントサイドのバグの兆候です。fail2ban 等のツールで、異常な回数の 405 を発生させるIPを一時的に DROP する設定を検討してください。
結論：プロトコルは嘘をつかない
405 Method Not Allowed は、単なるエラーコードではありません。それは、クライアントに対して「このリソースが何者であるか」を正しく伝え、かつシステム全体のリソースを不当なアクセスから守るための防波堤です。
プロトコルスタックの深層まで理解し、単に「動く」コードを書くのではなく、「ネットワーク上で美しく振る舞う」設計を心がけてください。その小さな気配りが、結果としてシステムの堅牢性と圧倒的なパフォーマンスを支えるのです。
コメント