Static Route のトラブルシューティング｜静的ルートを設定したのに届かないときの切り分け手順

静的ルート（Static Route）を追加したのに通信できない場合、原因はおおむね「その経路が実際には選ばれていない」「ネクストホップに届いていない」「行きは届いて戻りの経路がない」「途中の機器が転送・許可していない」「再起動で消えた」のどれかです。この記事では、Linux を中心に、どの経路が使われているかを確かめるコマンド、よくある原因を起きやすい順に並べた確認と修正、Windows とクラウド（AWS）での注意点を扱います。ルーティングテーブルの基本的な見方と編集方法は別記事の範囲とし、ここでは「設定したはずなのに動かない」状態からの切り分けに絞ります。

まず症状を 3 つに分ける

いきなり設定を変える前に、どこで止まっているかを分けると調べる場所が絞れます。

1. 送信元のホストで、宛先への経路が期待どおりに選ばれていない
2. 経路は選ばれているが、ネクストホップ（次のルーター）から先に進まない
3. 宛先まで届いているのに応答が返ってこない

1 は送信元の設定だけで確認できます。2 と 3 は、経路上の機器でパケットを観察して判断します。traceroute（Windows は tracert）でどこまで進むかを見ると、おおよその位置が分かります。

どの経路が選ばれているかを確認する

Linux では、ip route get で「その宛先に送るとき、実際にどの経路・どのインターフェース・どの送信元アドレスが使われるか」を表示できます。経路表を目で追うより確実性が高い方法です。

# 宛先 10.20.5.10 に送るときに選ばれる経路
ip route get 10.20.5.10

# 経路表全体（main テーブル）
ip route show

# ポリシールーティングを使っている場合はルールと他のテーブルも確認
ip rule show
ip route show table all

ip route get の結果が、追加した静的ルートの via（ネクストホップ）と dev（インターフェース）になっていなければ、その経路は使われていません。原因は次の節の 1 から順に疑います。

よくある原因を起きやすい順に確認する

1. もっと具体的な経路、または同じ宛先の別経路が優先されている

経路の選択は「宛先に一致する経路のうち、プレフィックス長がいちばん長いもの」が優先されます（最長一致）。10.20.0.0/16 を追加しても、どこかに 10.20.5.0/24 の経路があれば、10.20.5.10 宛てはそちらが使われます。VPN クライアントやコンテナのブリッジ、クラウドのエージェントが自動で経路を追加していることもあります。

同じプレフィックスの経路が複数ある場合は、メトリック（metric）の小さいものが優先されます。ip route show で同じ宛先の行が複数ないか、メトリックがどうなっているかを確認し、不要な経路を削除するか、メトリックを調整します。

2. ネクストホップが直接つながっていない

静的ルートのネクストホップは、通常そのホストから直接届く（同じセグメントにある）アドレスでなければなりません。ゲートウェイの IP アドレスを 1 文字間違えた、別セグメントのルーターを指定した、という場合、追加の時点でエラーになるか、追加できても通信できません。エラーの文言は iproute2 の版によって異なり、「Nexthop has invalid gateway」や「Network is unreachable」といった表示になります。

# ネクストホップへの経路が直接接続（via なし）になっているか
ip route get 192.168.1.254

# ネクストホップの MAC アドレスが解決できているか
ip neigh show 192.168.1.254

ip neigh の状態が FAILED や INCOMPLETE のままなら、ネクストホップの機器が応答していないか、ケーブル・VLAN・アドレスの設定に問題があります。

3. 戻りの経路がない（片方向だけ届く）

意外に多いのがこのケースです。送信元から宛先へは静的ルートで届いても、宛先側のホストやその先のルーターが送信元のネットワークへの経路を知らなければ、応答はデフォルトゲートウェイなど別の方向に送られて消えます。宛先側で tcpdump を使うと、要求が届いているのに応答が別のインターフェースへ出ていく様子を確認できます。

# 宛先ホストで、送信元からの ICMP が届いているか
sudo tcpdump -ni any icmp and host 192.168.1.20

修正は、宛先側（またはその上流のルーター）に送信元ネットワークへの静的ルートを追加するか、経路の途中で NAT して戻りを自動的に解決させるかのどちらかです。経路を増やす場合は両方向の対応表を作っておくと、追加漏れを防げます。

4. 経路上の Linux ルーターが転送していない

Linux をルーターとして使っている場合、IP 転送が無効だとパケットは転送されません。また、行きと戻りで別のインターフェースを通る非対称な経路では、リバースパスフィルター（rp_filter）が厳格モードだとパケットが破棄されることがあります。

# 1 なら転送有効
sysctl net.ipv4.ip_forward

# rp_filter の値（0=無効、1=厳格、2=緩い）。all とインターフェース別の大きい方が使われる
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter

設定を変える場合は /etc/sysctl.d/ 配下のファイルに書いて sudo sysctl --system で反映します。rp_filter を緩める前に、本当に非対称経路が必要な構成かを見直すほうが、セキュリティ上は望ましい対応です。

5. ファイアウォールが転送や応答を止めている

経路が正しくても、途中のルーターやホストのファイアウォールで転送（iptables の FORWARD チェーン、nftables の forward フック）が拒否されていれば通信できません。宛先ホスト側でも、送信元ネットワークからの接続を許可しているかを確認します。ICMP だけ許可されていない環境では、ping が失敗しても TCP は通ることがあるので、実際に使うポートで nc -vz 10.20.5.10 443 のように確認すると判断を誤りにくくなります。

6. 再起動やネットワーク再起動で消えた

ip route add で追加した経路は一時的なもので、再起動すると消えます。また、インターフェースのアドレスが外れたりリンクが落ちたりすると、そのインターフェースに結び付いた経路も無効になることがあります。恒久的に設定するには、使っているネットワーク管理の仕組みに書きます。

Ubuntu（netplan）の例です。適用前に設定ファイルをバックアップし、リモート接続の場合は netplan try で自動切り戻し付きで試すと、設定ミスで接続を失う事態を避けやすくなります。

# /etc/netplan/ 配下の設定ファイル（インターフェース名とアドレスは環境に合わせる）
network:
  version: 2
  ethernets:
    eth0:
      routes:
        - to: 10.20.0.0/16
          via: 192.168.1.254

NetworkManager を使う環境（RHEL 系など）では、接続プロファイルに経路を追加します。

sudo nmcli connection modify eth0 +ipv4.routes "10.20.0.0/16 192.168.1.254"
sudo nmcli connection up eth0

Windows での確認と恒久設定

Windows では route print で経路表を表示し、PowerShell の Find-NetRoute -RemoteIPAddress 10.20.5.10 で、その宛先に選ばれる経路を確認できます。route add で追加した経路は再起動で消えるため、残したい場合は -p を付けます。

route -p add 10.20.0.0 mask 255.255.0.0 192.168.1.254

Windows Defender ファイアウォールは既定で ICMP の受信を許可していない場合があるため、ping の失敗だけで経路の問題と判断しないよう注意してください。

クラウド（AWS）で静的ルートが効かないとき

AWS の VPC では、OS の経路表に加えて、サブネットに関連付けられたルートテーブルが通信先を決めます（2026年10月現在）。確認する点は次のとおりです。

• 対象のサブネットに、意図したルートテーブルが関連付けられているか（メインのルートテーブルが使われていないか）
• 経路のターゲット（インターネットゲートウェイ、NAT ゲートウェイ、Transit Gateway、ENI など）が正しく、状態が有効か
• EC2 インスタンスをルーターや NAT として使う場合、そのインスタンスで送信元/送信先チェックを無効にしているか。有効のままだと、自分宛てでないパケットは破棄されます
• セキュリティグループとネットワーク ACL で、両方向の通信が許可されているか

コンソールの表記は変わることがあるため、項目名は目的から探してください。VPC の到達性を調べる機能（Reachability Analyzer）を使うと、どの設定で止まっているかを確認しやすくなります。

まとめ

• まず ip route get（Windows は Find-NetRoute）で、その宛先に実際に選ばれる経路を確認する
• 最長一致とメトリックにより、追加した経路より別の経路が優先されていないかを見る
• ネクストホップが直接届くか、ip neigh で MAC アドレスが解決できているかを確認する
• 片方向だけ届く場合は、宛先側の戻りの経路を疑う
• Linux ルーターの IP 転送と rp_filter、ファイアウォールの転送許可を確認する
• 一時的な ip route add は再起動で消えるため、netplan や NetworkManager で恒久化する

• tracerouteで経路を調査する方法
• Linuxのネットワーク設定ファイルの書き方