2026年5月24日

デフォルトゲートウェイが応答しない場合の原因と対処法

IPアドレス・ルーティング

デフォルトゲートウェイに ping が通らないとき、問題はほぼ「自分の端末からルーターまでの間」、つまり同じ LAN の中にあります。この記事では、まず症状と設定を確認して本当にゲートウェイの問題なのかを見極め、そのうえで起こりやすい順に原因を挙げて、それぞれの確認方法と直し方を説明します。家庭や事務所の PC だけでなく、VPS やクラウドのサーバーで起きた場合の注意点にも触れます。

まず症状を正しくつかむ

ゲートウェイの IP を確認する

最初に、自分の端末がどのアドレスをゲートウェイとして使っているかを確かめます。

# Linux
ip -4 addr show
ip route show default

rem Windows
ipconfig /all

Linux では default via 192.168.1.1 dev eth0 のような行の via の後ろ、Windows では「デフォルトゲートウェイ」の欄がそのアドレスです。この時点で、次の状態になっていないかを見ます。

ゲートウェイが表示されない：経路そのものがありません。DHCP の失敗か、固定 IP の設定漏れです。
自分の IP が 169.254 で始まる（Windows など）：DHCP サーバーからアドレスを受け取れず、OS が自動でリンクローカルアドレスを付けた状態です。
自分の IP とゲートウェイが別のネットワークにある：例えば自分が 192.168.0.10/24 でゲートウェイが 192.168.1.1 の場合、ゲートウェイには直接届きません。

ping の結果を見分ける

ping -c 4 192.168.1.1

表示が「タイムアウト（返事なし）」なのか「Destination Host Unreachable（到達不能）」なのかで、疑う場所が変わります。自分の IP から到達不能が返ってくる場合は、ゲートウェイの MAC アドレスを ARP で解決できていない、つまり L2（ケーブル・Wi-Fi・スイッチ）の段階で届いていない可能性が高いです。タイムアウトの場合は、届いてはいるが返事が来ない（ルーターが ICMP を返さない設定、ルーターの不調など）可能性も残ります。

ARP テーブルを見る

ping の結果よりも判断材料として確かなのが ARP（IPv6 では近隣探索）の状態です。

# Linux
ip neigh show 192.168.1.1

rem Windows
arp -a

ゲートウェイの IP に MAC アドレスが対応付けられ、Linux で REACHABLE や STALE と表示されていれば、L2 ではゲートウェイと通信できています。FAILED や INCOMPLETE、または一覧に出てこない場合は、ゲートウェイまでの物理的・論理的なつながりに問題があります。

この確認で、「ARP は解決できているのに ping だけ返らない」のか、「ARP から失敗している」のかが分かります。前者ならルーター側の ICMP の扱いを、後者なら下の原因 1〜4 を優先して疑います。

原因と対処（起こりやすい順）

1. ケーブル・Wi-Fi のリンクが切れている

もっとも多いのは物理的な接続の問題です。LAN ケーブルの抜けかけ、スイッチやハブの電源、Wi-Fi が別の SSID（ゲスト用など）につながっている、といったケースです。

確認：Linux では ip link show でインターフェースが state UP か、NO-CARRIER になっていないかを見ます。Windows では ipconfig で「メディアは接続されていません」と出ていないかを見ます。Wi-Fi なら、つながっている SSID 名を確かめます。

対処：ケーブルを挿し直す、別のポートやケーブルに替える、正しい SSID に接続し直す。ほかの端末も同じ症状なら、スイッチやルーター本体を疑います。

2. IP アドレスの取得失敗・設定ミス

DHCP で正しいアドレスを受け取れていない、固定 IP のサブネットマスクやゲートウェイが間違っている、というケースです。ルーターを交換したあとや、ネットワークのアドレス帯を変えたあとによく起こります。

確認：前の節で見た自分の IP・サブネットマスク・ゲートウェイが、ネットワークの設計と合っているかを見ます。

対処：DHCP ならアドレスを取り直します。

rem Windows
ipconfig /release
ipconfig /renew

# Linux（NetworkManager の場合。接続名は nmcli connection show で確認）
sudo nmcli connection down "接続名" && sudo nmcli connection up "接続名"

Linux はネットワーク管理の仕組み（NetworkManager、systemd-networkd、netplan など）によって手順が異なります。リモートからつないでいるサーバーでこの操作をすると接続が切れるので、コンソールから行ってください。固定 IP なら設定ファイルの値を見直します。

3. IP アドレスの重複

同じネットワークで、自分と同じ IP を別の機器が使っている、あるいはゲートウェイの IP を誰かが使っていると、通信が不安定になったり、まったく届かなくなったりします。

確認：Linux では iputils の arping で、同じ IP に複数の機器が応答しないかを見ます。

# eth0 から 192.168.1.1 に ARP を送り、応答する MAC アドレスを確認
sudo arping -I eth0 -c 4 192.168.1.1

返ってくる MAC アドレスが複数あれば重複しています。Windows でも、IP の重複を検出すると通知やイベントログに記録されることがあります。

対処：重複している機器を特定し、どちらかのアドレスを変えます。固定 IP は DHCP の払い出し範囲の外に割り当てるのが基本です。

4. 古い ARP キャッシュが残っている

ルーターを交換した直後などは、端末が以前のルーターの MAC アドレスを覚えたままになっていることがあります。

確認：ip neigh show や arp -a に表示されるゲートウェイの MAC アドレスが、現在のルーターのもの（本体ラベルや管理画面で確認）と一致しているかを見ます。

対処：ARP キャッシュを消して取り直させます。

# Linux
sudo ip neigh flush dev eth0

rem Windows（管理者として実行）
netsh interface ip delete arpcache

5. ルーターが ICMP に応答しない設定になっている

ARP は解決できていて、インターネットにも出られるのに、ゲートウェイへの ping だけ返らない場合はこれです。ルーターのセキュリティ設定で ping への応答を止めている機種や設定は珍しくありません。

確認：ゲートウェイの先、例えば外部の IP アドレス（1.1.1.1 など）へ ping し、traceroute -n や tracert -d で1ホップ目以降を通過しているかを見ます。ゲートウェイの先に進めているなら、ゲートウェイは転送の役目は果たしています。

対処：通信に支障がなければ、対処は不要です。ping で監視したい場合は、ルーターの管理画面で応答設定を確かめます（項目名は機種ごとに異なります）。

6. ルーター本体の不調

ルーターが高負荷やソフトウェアの不具合で固まっていると、つながっているすべての機器から応答がなくなります。

確認：ほかの端末からもゲートウェイに届かないか、ルーターのランプや管理画面の状態を見ます。

対処：再起動で直ることが多いですが、繰り返すならファームウェアの更新や機器の交換を検討します。再起動する前に、管理画面のログを確認しておくと原因の手がかりになります。

7. 端末側のファイアウォールや VPN・VLAN の設定

端末のファイアウォールが送信側の ICMP を止めている、VPN ソフトがすべての通信をトンネルに通す設定になっていてローカル LAN に出られない、スイッチのポートが別の VLAN に設定されている、といったケースです。

確認：VPN を一度切断して試す、ファイアウォールの送信ルールを確認する、同じスイッチの別ポートにつないで試します。VLAN はネットワーク管理者に確認するのが早道です。

VPS・クラウドのサーバーで起きた場合

クラウドの仮想ネットワークでは、ゲートウェイは物理的なルーターではなく、仮想ルーターとして提供されます。事業者によっては、このゲートウェイが ping に応答しない仕様になっていることがあります。そのため、ゲートウェイへの ping が返らないこと自体は異常とは限りません。外部への通信ができるか、ip route get 1.1.1.1 で想定どおりの経路が選ばれているかを確かめてください。

サーバーに SSH で入れない状態なら、事業者が提供するコンソール機能（シリアルコンソールや Web コンソールなど）からログインして、ここまでの確認を行います。設定ファイルを直す前にはバックアップを取り、同じ構成の検証環境があれば先にそちらで試してください。クラウドの機能名や提供状況は事業者・プランによって異なります（2026年10月現在）。

まとめ

まず自分の IP・サブネットマスク・ゲートウェイを確認し、経路がない、169.254 のアドレス、別ネットワーク、といった設定の問題を除外する
ping の結果よりも ARP テーブルが判断の決め手になる。ARP から失敗していれば L2 の問題を疑う
原因はリンク切れ、アドレスの取得失敗・設定ミス、IP 重複、古い ARP キャッシュ、ルーターの ICMP 無応答設定、ルーター不調、端末のファイアウォールや VPN・VLAN の順に多い
ゲートウェイの先に通信できているなら、ping が返らないだけで実害はないことがある
クラウドでは仮想ゲートウェイが ping に応答しないことがあるため、外部への疎通と経路で判断する