Linuxネットワーク疎通・接続障害の確認手順｜ip・ping・ss・curl・nc
Linuxで通信できないときに、NIC・IPアドレス・ルーティング・ICMP疎通・TCPポート・待受状態・HTTP/TLSの順で原因を切り分ける確認手順を整理します。
このページの目的
「ネットワークがつながらない」を一括りにせず、ローカルNIC、経路、IP疎通、TCPポート、サーバー待受、アプリケーション応答のどこで止まっているかを順番に分けます。
最初にやること
ip -br addrとip routeで自ホストの状態を確認し、接続先IPが分かる場合はip route get 接続先IPでカーネルが選ぶ経路を確認します。
関連する接続障害ガイド
名前解決できない原因を切り分ける
IPでは到達できるのにホスト名で失敗する場合は、getent・resolvectl・digでDNS経路を確認します。
DNSを確認 → SSHSSH接続できない原因を切り分ける
22番ポート、sshd、認証のどこで失敗しているかをSSH固有の観点で確認します。
SSHを確認 →最短の確認順
最初からFirewallやサービス設定を変更せず、自ホスト → 経路 → IP → TCPポート → サーバー待受 → アプリの順で、どこまで正常かを記録します。
203.0.113.10はドキュメント用の例です。実環境では対象ホストのIPへ置き換えてください。接続確認は許可された対象に対して実施してください。エラー表示から確認範囲を絞る
| 症状・表示 | まず疑う範囲 | 最初の確認 |
|---|---|---|
Network is unreachable | ローカル経路・NIC・ルーティング | ip -br addr / ip route get |
No route to host | 経路、途中の拒否、到達不能応答など | ip route get / ping / 経路確認 |
Connection refused | 到達先でポート未待受、明示的拒否 | クライアントのncとサーバーのss -lntp |
Connection timed out | 経路途中のdrop、FW、Security Group、到達不能など | ip route / nc / FW・クラウド設定 |
Could not resolve host等 | DNS・名前解決 | DNS名前解決ガイド |
| HTTP 4xx / 5xx | ネットワーク到達後のアプリケーション側 | curl -vとアプリ・Proxyログ |
1. NICとIPアドレスを確認する
ip -br addrでインターフェースの状態とIPアドレスを一覧し、想定したNICに想定したアドレスが付いているかを確認します。インターフェースがDOWN、IP未設定、別VRF・namespace内などの場合は、この段階で調査対象を分けます。
2. ルーティングを確認する
ip route showはルーティングテーブルを表示します。ip route getは指定した宛先に対して、カーネルが選ぶ経路・出力インターフェース・送信元アドレスなどを確認するのに向いています。
ip ruleやテーブル別ルートも確認します。3. IP疎通を確認する
pingはICMP Echoを使った疎通確認です。応答があればIPレベルの往復経路を確認する材料になりますが、pingが失敗しただけで対象ホストが停止しているとは断定できません。ICMPをFirewallやクラウド側で許可していない構成もあります。
可能なら同一セグメントのGateway、接続先IPなどを段階的に確認し、「どこから失敗するか」を分けます。
4. TCPポートへ接続できるか確認する
IP疎通だけでは、目的のTCPポートへ接続できるかは分かりません。対象プロトコルに合わせてポート接続を確認します。
ncは実装差があります：ディストリビューションやnetcat実装によってオプションが異なる場合があります。利用環境のnc -hやman pageを確認してください。5. サーバー側で待受状態を確認する
ssで対象ポートがLISTENしているか、どのアドレスにbindしているかを確認します。127.0.0.1:PORTだけで待ち受けている場合、外部ホストからは接続できません。
0.0.0.0:PORT：全IPv4アドレスで待受する構成の一例127.0.0.1:PORT：IPv4 loopbackのみ[::]:PORT：IPv6側の待受。IPv4も受けるかは環境・設定により異なる
6. HTTP・TLSまで到達しているか確認する
curl -vでは名前解決、接続、TLS、HTTP応答のどこまで進んだかを確認できます。--resolveは指定したホスト名・ポートを特定IPへ向けて接続するため、DNS経路を切り離した比較にも使えます。
curl -vの出力にはURL、ヘッダー、認証情報などの機密情報が含まれる可能性があります。外部へ共有する前に必ずマスクしてください。7. 経路途中を確認する
経路確認コマンドは「最後に表示されたHopが障害点」と単純には判断できません。途中装置がTTL超過応答を返さない場合や、実通信と異なる経路を通る場合もあります。ルーティング・Firewall情報と合わせて判断します。
8. Firewall・クラウド・コンテナなどの環境差
- ホストFirewall：nftables / firewalld / iptables互換層など、環境の管理方式を確認する。
- クラウド：Security Group、Network ACL、Firewall Rule、Route Table、Load Balancerなどを確認する。
- コンテナ/Kubernetes：hostとPod/Containerのnetwork namespace、Service、NetworkPolicy、CNIを分けて確認する。
- Proxy/VPN：HTTP(S)_PROXY、PAC、VPNルート、split tunnelなどで実際の接続経路が変わる場合がある。
確認結果から次へ進む
| 確認結果 | 次の調査 |
|---|---|
| NIC/IPが想定と違う | ネットワーク設定、DHCP、NetworkManager/systemd-networkd、クラウドNIC設定など |
ip route getで経路がない/想定外 | route、policy routing、VPN、VRF、クラウドルート |
| pingだけ失敗・TCPは成功 | ICMP制御の可能性。目的ポートの実通信を基準に判断 |
TCPがrefused | サーバーのss -lntp、サービス状態、bindアドレスを確認 |
| TCPがtimeout | 経路、FW、Security Group、Network ACL、LBなどを確認 |
| IPでは接続できるが名前で失敗 | DNS名前解決を確認 |
| 22/TCPまでは到達するがSSH失敗 | SSH固有の切り分けへ |
| HTTP応答が4xx/5xx | Proxy/Web/Appの設定とログを確認 |
既存環境でよく使われる旧来コマンドとの読み替え
ip・ss など現在一般的なツールを優先します。一方、既存の運用手順や長期稼働環境では ifconfig・netstat・route が残っていることがあります。旧来コマンドを見つけたら削除前提にせず、まず同じ確認を現行コマンドへ読み替えます。| 確認したいこと | 現在の確認例 | 既存環境で見かける例 |
|---|---|---|
| IPアドレス・NIC | ip -br addrip link | ifconfig -a |
| ルーティング | ip routeip route get 192.0.2.10 | route -n |
| TCP/UDP待受 | ss -lntup | netstat -lntup |
ifconfig・netstat・routeはnet-tools系の既存手順で見かけます。利用できるからといって誤りではありませんが、出力項目や対応機能は完全な1対1ではありません。新旧コマンドの結果を比較し、環境の標準ツールに合わせて手順を更新してください。
nft、firewall-cmd、iptablesのどれを使うかは環境によります。iptablesコマンドがnftables互換バックエンドを利用している構成もあるため、コマンド名だけで実装方式を決めつけません。