HTTPの仕組みを図にした。前の話を覚えていない、という前提
HTTPは1往復で完結し、前のやり取りを覚えていません。ログイン状態が保てる理由と、ステータスコードの読み方を図で整理しました。

この記事の結論
- HTTPは1往復で完結する。前のやり取りとの関係は無い
- ログイン状態が保てるのは、別の仕組みで状態を持たせているから
- 番号の百の位を見れば、誰の問題かが分かる
- HTTPは1往復で完結する。前のやり取りとの関係は無い
- ログイン状態が保てるのは、別の仕組みで状態を持たせているから
- 番号の百の位を見れば、誰の問題かが分かる
エラーの切り分けで毎回使うのに、仕組みとして説明されることが少ないのがHTTPだ。図にすると、覚えることが驚くほど少ない。
やり取りは4段階
MDNはHTTPの流れをこう整理している。
- 接続を開く
- メッセージを送る
- 返ってきたものを読む
- 接続を閉じるか、再使用する
送るものと返るものの中身は、こうなっている。

前の話を覚えていない
ここが最も大事な性質になる。MDNの表現では、HTTPはステートレスであり、「同じコネクション上であっても、連続的に実行される2つのリクエスト間に関係性はありません」とされている。
つまりサーバーから見ると、1回目と2回目のリクエストは別人から来たのと区別がつかない。
ではログイン状態はどう保つのか
MDNはこう続ける。Cookieによってステートフルなセッションを実現でき、それぞれのリクエストが同じ状態を共有できるようになる。
つまり「毎回、自分が誰かを添えて送り直している」。覚えているのではなく、毎回申告している。ここが分かると、ログイン周りの不具合の見え方が変わる。
- ログインが切れる → 添えるものが送られていないか、期限が切れている
- 別のブラウザだと入れない → 添えるものがそのブラウザにしか無い
- 自分だけ表示が違う → 添えたものを見てサーバーが出し分けている
番号は百の位だけ見る
ステータスコードは数が多いが、分類は5つしかない。
| 範囲 | 意味 | 誰の問題か |
|---|---|---|
| 1xx | 情報。処理はまだ続く | — |
| 2xx | 成功 | — |
| 3xx | 場所が移った | — |
| 4xx | 送る側の問題 | こちら |
| 5xx | 受ける側の問題 | サーバー |
切り分けはここで半分終わる。4xxならこちらの送り方、5xxならサーバー側。404を見てサーバーの設定を疑うのは、たいてい遠回りになる。
よく出る番号の意味
- 301 / 302 … 移った。301は恒久、302は一時。どちらにするかで検索側の扱いが変わる
- 304 … 変わっていない。手元のものを使ってよい
- 401 / 403 … 401は「名乗っていない」、403は「名乗ったが権限が無い」
- 404 … 無い。意図して消した場合は410のほうが正確
- 502 / 504 … 間に入っているものが、奥から応答を得られていない
ヘッダーで何が変わるか
図の「付帯」の部分がヘッダーで、ここが挙動を大きく決める。
- Content-Type … 中身が何か。これを間違えると、HTMLがそのまま文字として出る
- Cache-Control … どれだけ手元に置いてよいか
- Content-Length … 中身の大きさ
表示が古いままのときは、ここを見ることになる。内容を直したのに変わらない場合、サーバーではなく手元か途中が古いものを返している。調べる順番は表示が遅い原因を、順番に調べた作業に書いた。
速さを見るときに効いてくる
1往復ごとに接続の手間がかかるので、往復の回数そのものが速さに効く。画像を10枚置けば、その数だけやり取りが発生する。
測り方はサイトが遅い原因を、推測ではなく測って特定したにまとめた。推測で減らしても、数字が動かないことが多い。
まとめ
- HTTPは「開く・送る・読む・閉じる」の4段階
- ステートレス。前のリクエストとの関係は無い
- ログイン状態は、毎回Cookieを添えて申告し直している
- 番号は百の位だけ見る。4xxはこちら、5xxはサーバー
- 401は名乗っていない、403は名乗ったが権限が無い
- 意図して消したものは404より410が正確
出典
- MDN「HTTP の概要」(流れ、ステートレス性、リクエストとレスポンスの構成、ステータスコードの分類)
図は本記事のために作成したもの。本記事は2026年10月13日時点の内容に基づく。
新しい記事が出たら、ブラウザの通知でお知らせします。
メールアドレスの登録は要りません。いつでも止められます。
関連記事
RELATED
テストが1つも無いコードに、どこからテストを足すか
全部にテストを書くのは無理です。移行で触る所だけに絞ったら、現実的な分量になりました。
Laravelへ移すとき、どこから手を付けるか決めた
全部を一度に移すと戻れなくなります。順番を決めたら、途中で止めても使える状態を保てました。
動くけれど危ないコードを、先に直す順番にした
エラーで止まるコードより、止まらずに動いてしまうSQLの連結のほうが優先度は上でした。