【入門編】HTTP/1.1ステータスコード4xx(Client Error)の発生条件とデバッグ手法 – HTTPプロトコル・通信規格実践ガイド

エンジニアとして現場に出ると、必ずと言っていいほど直面するのが「4xx」という数字です。Webブラウザに「404 Not Found」と表示されて頭を抱えた経験、誰しも一度はありますよね。

HTTPステータスコードの「400番台」は、一言で言えば「クライアント（あなたやブラウザ）からのお願いの仕方が間違っていますよ」という、サーバーからの丁寧な（時に冷徹な）お断りのサインです。

今日は、郵便配達に例えながら、この4xxエラーの正体と、現場でプロがどうやって原因を突き止めているのか、その「捜査手法」を紐解いていきましょう。

—

ネットワークの世界を、郵便局に例えてみましょう。

200番台は「手紙が届いて返事がもらえた」状態ですが、4xxエラーは「手紙の宛先が間違っている」「封筒の書き方がおかしい」「そんな荷物は受け取れない」といった、送り手側の不備を指します。

—

では、実際にエラーが起きたとき、インフラエンジニアはどうやって犯人を特定しているのでしょうか。重要なのは「どこで止まっているか」を見極めることです。

ChromeやEdgeを使っているなら、`F12`キーを押して「ネットワーク」タブを開いてみてください。ここでリクエストの内容（ヘッダー情報）が見れます。

ここが腕の見せ所です。Linuxサーバーであれば、NginxやApacheのログを確認します。

Nginxのアクセスログを末尾からリアルタイムで監視するコマンド
tail -f /var/log/nginx/access.log

ログには以下のように記録されます。

192.168.1.1 – – [10/Oct/2023:10:00:00] “GET /secret-page HTTP/1.1” 403 150 “-” “Mozilla/5.0…”
最後の「403」がステータスコードです。

—

ブラウザが勝手に特殊な記号を送っていたり、サーバーが許容していない巨大なデータを送ろうとすると発生します。

デバッグ: 送信しているデータ量を減らしてみる、またはURLに含まれる特殊文字（`%`や`&`など）を正しく変換（エンコード）しているか確認しましょう。

ファイルはあるけれど、サーバーの設定で「誰にも見せない」ようになっている場合です。

デバッグ: ファイルのアクセス権限（パーミッション）が `644` や `755` になっているか確認しましょう。Webサーバーユーザー（www-dataなど）がそのファイルを読み取れるかが鍵です。

これは少しマニアックですが、クライアントが「サーバーへ特定の動作（Expectヘッダー）」を要求したものの、サーバーが「その要求には応えられない」と拒否した時に起きます。

デバッグ: リクエストヘッダーに `Expect: 100-continue` が含まれていないか確認してください。古いプロキシサーバーなどがこの要求を処理できず、エラーを返すことがよくあります。

—

4xxエラーは、システムが壊れたわけではありません。「会話が噛み合っていないだけ」です。

インフラエンジニアにとって、ログを確認する作業は、まさに迷路を解くようなもの。「なぜエラーが出たのか」を紐解いていくと、ネットワークの仕組みが手に取るように分かってきます。

もし次に4xxエラーに出会ったら、「あ、郵便局員さんが困っているんだな。書き方を直してあげよう」と、一歩引いて冷静にリクエストを見直してみてください。きっと、解決の糸口はすぐそこに見つかるはずですよ！

—
執筆者より:
ネットワークの世界は、ルール（プロトコル）を知れば知るほど面白くなります。これからも一緒に、一歩ずつ技術の深淵を覗いていきましょう！