「つながらない」を順番に切り分ける——HTTPのエラー番号の読み方まで

Last updated at 2026-10-29Posted at 2026-10-29

「社内システムにつながらない」と連絡が来たとき、最初に何を確かめますか。

障害対応で時間を失うのは、原因が難しいときよりも、見る順番を間違えたときです。いきなりサーバーのログを開いたり、ファイアウォールの設定を疑ったりする前に、安く済む確認から順に潰していけば、たいていは早く片が付きます。

この記事では、「つながらない」を切り分ける順番と、最後に返ってきた HTTP のステータスコードの読み方までをまとめます。

安い確認から先に聞く

手を動かす前に、聞くだけで分かることがあります。

この4つで、調べる範囲が大きく狭まります。特に最後の「直前の変更」は、聞かないと出てこないのに、当たる確率が高い質問です。

聞き取りで絞れたら、コマンドで裏を取ります。

VPN の画面に「接続済み」と出ていても、宛先への経路がトンネルに向いていないことがあります。表示ではなく、経路表で確かめます。

ip -br addr show
ip route get <host>

トンネル用のインタフェースが上がっていて、宛先への経路がそちらへ向いているかを見ます。物理の NIC 側へ出ていれば、スプリットトンネルの対象から外れています。

次に名前です。

dig +short <host>
dig +trace <host>
resolvectl status | head -30

+trace はルートから順にたどるので、どの段階で切れているかが分かります。社内の名前なら、問い合わせ先が社内の DNS になっているかも見ます。VPN をつないだときに、社内 DNS を見るべきインタフェースが外の DNS を向いていることがあるからです。

ここでやりがちな間違いが、「ping が通らないから経路の障害だ」と決めつけることです。ICMP をポリシーで止めている環境は多く、ping の不通だけでは何も言えません。確かめるべきは、実際に使うポートへ TCP でつながるかです。

経路と取りこぼしを同時に見たいときは、traceroute と ping を兼ねたこれが便利です。

mtr -rwzbc 100 <host>

途中のホップだけで取りこぼしが出るのは、そのルーターが ICMP の返事を後回しにしているだけのことが多いです。最後のホップまで続いていなければ、問題ではありません。

TCP でつながって HTTP の返事が来たなら、通信そのものは届いています。ここからはステータスコードの出番です。

最初に見るのは1桁目です。

知らない番号でも、1桁目でおおよその扱いが決まります。文言(「Not Found」など)は省略や言い換えがありうるので、判定は数字で行います。

取り違えやすい組み合わせも押さえておくと、次に見る場所がずれません。

401 と 403: 401 は有効な認証情報が無い。403 は分かったうえで断っている(同じ認証情報で再試行しても変わらない)
502 と 504: 502 は後ろから不正な返事が来た(アプリが落ちているときの典型)。504 は後ろの返事が時間内に来なかった(重い処理やデータベースの詰まりを疑う)
404 と 410: 404 は見つからない、または理由を明かさない。410 は意図して恒久的に消した

まとめると、確かめる順番はこうなります。

この順番を毎回同じにしておくと、慌てているときでも抜けが出ません。調べた結果を、そのまま報告書の材料として残せるのも利点です。

この記事は生成AIで作成し、公開前に人が最終確認しています。掲載しているコマンドは、すべて公開済みの教材・記事に載っているものから引用しています。