Linuxのネットワークコマンド9選｜IPアドレス・経路・DNS・ポートの確認方法

2026年7月26日

当ページのリンクには広告が含まれています。

ネットワーク初級編 28／全32記事

LinuxでIPアドレス、通信経路、DNS、待ち受けポートなどを確認する基本コマンドを、出力の読み方とともに学びます。

← 前の記事：Windowsで確認するネットワークコマンド初級編一覧次の記事：pingが通らないときの確認順序 →

Linuxのネットワークコマンド9選｜IPアドレス・経路・DNS・ポートの確認方法

Linuxサーバーで通信障害を調べるときは、勘に頼って設定を変更するのではなく、インターフェース、IPアドレス、ルーティング、DNS、待ち受けポートを順番に確認します。この記事では、初めに覚えたい9つのコマンドと、出力のどこを見ればよいかを解説します。

対象レベル Level 1・初級

想定読了時間 約25分

身につく成果 Linuxの通信状態を基本コマンドで確認できる

前提知識 IP・DNS・デフォルトゲートウェイ

演習環境 Linux端末または仮想マシン

Linuxでは、Windowsのipconfigやtracertに相当する確認を、 ip、ping、tracepath、ssなどのコマンドで行います。

大切なのはコマンド名を暗記することではありません。 何を確認したいのかを決め、その目的に合うコマンドを選ぶことです。

この記事を読み終えるとできること

LinuxのIPアドレスとリンク状態を確認できる
デフォルトゲートウェイと通信経路を確認できる
DNS名前解決とWeb通信を切り分けられる
サーバーの待ち受けポートを確認できる

Linuxでネットワークを確認するときの考え方

「Webサイトへ接続できない」「サーバーへSSH接続できない」という申告だけでは、原因箇所は分かりません。端末の設定からアプリケーションまで、確認対象を段階に分けます。

Linuxで通信障害を確認する基本の流れ

STEP 1 リンク
NICはUPか

STEP 2 アドレス
IPは正しいか

STEP 3 経路
Gatewayはあるか

STEP 4 名前解決
DNSは引けるか

STEP 5 サービス
ポートは開いているか

下の層から順番に確認するのが基本です。

インターフェースが停止しているのにDNSを調べても、問題は解決しません。先に「通信の土台」が正常かを確認すると、原因を効率よく絞り込めます。

この記事では確認コマンドを中心に扱います。

ip link setやnmcli connection modifyなどの変更コマンドは、稼働中の通信へ影響する可能性があります。初学者は、まず表示・確認系のコマンドから練習してください。

最初に覚えたいLinuxネットワークコマンド一覧

確認したいこと	基本コマンド	主な確認ポイント
IPアドレス	`ip addr`	IPv4・IPv6アドレス、プレフィックス長
インターフェース状態	`ip link`	UP・DOWN、MACアドレス
ルーティング	`ip route`	デフォルトゲートウェイ、送信インターフェース
ARP・近隣情報	`ip neigh`	IPアドレスとMACアドレスの対応
IP疎通	`ping`	応答、遅延、パケットロス
通信経路	`tracepath`	どの中継点まで到達するか
DNS	`resolvectl`／`dig`	利用中のDNS、名前解決結果
ポート・ソケット	`ss`	LISTEN状態、TCP・UDPポート
HTTP・HTTPS	`curl`	接続、TLS、HTTPステータス

Linuxディストリビューションや最小インストール環境によっては、 tracepath、dig、curlなどが入っていない場合があります。 command -v コマンド名で利用可否を確認できます。

1．ip addr：IPアドレスを確認する

IPアドレス確認

`ip addr show`

ネットワークインターフェースに設定されているIPv4・IPv6アドレスを確認します。 showは省略できるため、ip addrでも同じ目的で使えます。

$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
    inet 127.0.0.1/8 scope host lo
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    link/ether 00:50:56:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.25/24 brd 192.168.10.255 scope global dynamic ens160
    inet6 fe80::250:56ff:feaa:bbcc/64 scope link

確認する場所

ens160：インターフェース名
inet 192.168.10.25/24：IPv4アドレスとプレフィックス長
inet6：IPv6アドレス
scope global：そのインターフェースで通常の通信に使われるアドレス

見やすく表示するなら ip -br addr

-brはbriefの略で、情報を1行ずつ簡潔に表示します。複数のインターフェースがあるサーバーでは特に便利です。

$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens160           UP             192.168.10.25/24 fe80::250:56ff:feaa:bbcc/64
ens192           DOWN

loはループバックインターフェースです。 127.0.0.1は自分自身を表すため、通常のLAN接続に使うIPアドレスではありません。

2．ip link：インターフェースの状態を確認する

リンク状態確認

`ip link show`

インターフェースが有効か、物理・仮想リンクが利用可能か、MACアドレスは何かを確認します。

$ ip link show ens160
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT
    link/ether 00:50:56:aa:bb:cc brd ff:ff:ff:ff:ff:ff

確認する場所

UP：管理上、そのインターフェースが有効
LOWER_UP：下位のリンクも利用可能
state UP：現在の動作状態
link/ether：MACアドレス

IPアドレスが正しくても、インターフェースがDOWNなら通信できません。仮想マシンでは、仮想NICが接続解除されていないかも確認します。

UPが表示されていても、上位のスイッチ設定、VLAN、ケーブル、無線接続などが正常とは限りません。このコマンドだけで通信経路全体の正常性を判断しないようにしてください。

3．ip route：ルーティングを確認する

経路確認

`ip route show`

Linuxが宛先ネットワークごとに、どのゲートウェイ・インターフェースへパケットを送るか確認します。

$ ip route show
default via 192.168.10.1 dev ens160 proto dhcp src 192.168.10.25 metric 100
192.168.10.0/24 dev ens160 proto kernel scope link src 192.168.10.25 metric 100

確認する場所

default via 192.168.10.1：デフォルトゲートウェイ
dev ens160：パケットを送信するインターフェース
192.168.10.0/24：同じLANとして直接到達できるネットワーク
metric 100：同条件の経路間で使われる優先度の判断材料

特定の宛先へ使われる経路を確認する

ルーティングテーブル全体を眺めるだけでなく、実際に特定の宛先へどの経路が選ばれるか確認できます。

$ ip route get 8.8.8.8
8.8.8.8 via 192.168.10.1 dev ens160 src 192.168.10.25 uid 1000
    cache

この例では、8.8.8.8宛ての通信は、送信元IPアドレス192.168.10.25を使い、 ens160からゲートウェイ192.168.10.1へ送られます。

実務では ip route get が便利です。

NICが複数あるサーバーや経路が多い環境でも、Linuxカーネルが選ぶ実際の経路を宛先単位で確認できます。

4．ip neigh：ARP・近隣情報を確認する

近隣確認

`ip neigh show`

同じリンク上にいる相手について、IPアドレスとMACアドレスの対応を確認します。 IPv4では、ARPテーブルに相当する情報です。

$ ip neigh show
192.168.10.1 dev ens160 lladdr 00:11:22:33:44:55 REACHABLE
192.168.10.50 dev ens160 lladdr 00:11:22:aa:bb:cc STALE

代表的な状態

REACHABLE：最近、到達可能であることを確認できた
STALE：情報はあるが、最近の到達性確認は行われていない
DELAY／PROBE：到達性を再確認している途中
FAILED：近隣解決に失敗した

デフォルトゲートウェイへpingが通らない場合、ip neighでゲートウェイがFAILEDになっていないかを見ると、同一LAN内の接続やARP解決に問題がある可能性を考えられます。

5．ping：IPレベルの疎通を確認する

疎通確認

`ping -c 4 宛先`

ICMP Echo Requestを送り、相手からEcho Replyが返るか確認します。 Linuxのpingは停止するまで継続する環境が多いため、初学者は-c 4で4回に制限すると扱いやすくなります。

$ ping -c 4 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=0.612 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.571 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=0.588 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=64 time=0.603 ms

--- 192.168.10.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max/mdev = 0.571/0.593/0.612/0.016 ms

確認する場所

4 received：4回の応答を受信
0% packet loss：パケットロスなし
time=：応答にかかった時間
avg：平均往復時間

pingは順番を決めて実行する

ping -c 4 127.0.0.1 自分自身のTCP/IP機能を確認します。
ping -c 4 自分のIPアドレス 自分のインターフェースに設定されたアドレスを確認します。
ping -c 4 デフォルトゲートウェイ 同じLAN内のゲートウェイまで確認します。
ping -c 4 外部IPアドレス ルーティングを含む外部へのIP疎通を確認します。
ping -c 4 example.com DNS名前解決を含めて確認します。

pingに応答しないからといって、必ず相手が停止しているとは限りません。ファイアウォールや機器の方針でICMP応答を制限していても、HTTPやSSHなどのサービスは利用できる場合があります。

6．tracepath：通信経路を確認する

経路追跡

`tracepath 宛先`

宛先へ到達するまでに、どの中継点を通るかを確認します。ディストリビューションによってはtracerouteを使用します。

$ tracepath example.com
 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.10.1                      0.742ms
 2:  203.0.113.1                       4.981ms
 3:  198.51.100.10                     8.214ms
 4:  93.184.216.34                    12.623ms reached
     Resume: pmtu 1500 hops 4 back 4

確認する場所

1番目：多くの場合、自分のデフォルトゲートウェイ
途中のホップ：通信事業者や中継ネットワーク
reached：宛先へ到達
pmtu：経路上で確認されたPath MTU

途中に応答しない行があっても、その先や最終宛先まで到達していれば、中継機器が経路追跡用の応答を返していないだけの可能性があります。

7．resolvectl・dig：DNSを確認する

利用中のDNS設定を確認する

systemd-resolvedを使用している環境では、resolvectl statusでインターフェースごとのDNS設定を確認できます。

$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens160)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 192.168.10.53
       DNS Servers: 192.168.10.53 192.168.10.54
        DNS Domain: example.local

Current DNS ServerやDNS Serversに、想定したDNSサーバーが表示されているか確認します。

名前解決を実行する

$ resolvectl query example.com
example.com: 93.184.216.34

-- Information acquired via protocol DNS in 18.2ms.

digが導入されている場合は、DNS応答をより詳しく確認できます。

$ dig +short example.com
93.184.216.34

/etc/resolv.confも確認する

$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search example.local

nameserver 127.0.0.53と表示される環境では、ローカルのsystemd-resolvedスタブへ問い合わせています。実際の上流DNSサーバーはresolvectl statusで確認します。

IPアドレスでは通信できるが名前では通信できない場合

$ ping -c 2 93.184.216.34
# 応答あり

$ ping -c 2 example.com
ping: example.com: Temporary failure in name resolution

このようにIPアドレス指定では通信でき、ホスト名指定だけ失敗する場合は、 DNS設定やDNSサーバーへの到達性を優先して確認します。

8．ss：待ち受けポートを確認する

ソケット確認

`ss -tuln`

TCP・UDPの待ち受けソケットを数値表示で確認します。サーバー側で「サービスがポートを開いているか」を確認するときに使います。

$ ss -tuln
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port
tcp   LISTEN 0      128          0.0.0.0:22         0.0.0.0:*
tcp   LISTEN 0      511          0.0.0.0:80         0.0.0.0:*
tcp   LISTEN 0      511             [::]:443           [::]:*
udp   UNCONN 0      0            0.0.0.0:68         0.0.0.0:*

オプションの意味

-t：TCP
-u：UDP
-l：待ち受け中のみ
-n：ポート番号などを数値で表示

0.0.0.0:22は、IPv4のすべてのローカルアドレスでTCP 22番ポートを待ち受けていることを表します。 127.0.0.1:8080なら、同じサーバー自身からしか接続できません。

どのプロセスが使っているか確認する

$ sudo ss -tulnp
Netid State  Local Address:Port  Process
tcp   LISTEN 0.0.0.0:22          users:(("sshd",pid=812,fd=3))
tcp   LISTEN 0.0.0.0:80          users:(("nginx",pid=1042,fd=6))

ポートがLISTENしていても、OSのファイアウォール、クラウドのセキュリティルール、ネットワークACLなどで遮断されていれば、外部から接続できません。

9．curl：HTTP・HTTPS通信を確認する

アプリケーション確認

`curl -I URL`

WebサーバーへHTTPリクエストを送り、レスポンスヘッダーを確認します。 pingより上位の、DNS・TCP・TLS・HTTPを含む実際のWeb通信確認に役立ちます。

$ curl -I https://example.com/
HTTP/2 200
content-type: text/html
content-length: 1256
date: Sat, 25 Jul 2026 03:00:00 GMT

代表的なHTTPステータス

200：正常に応答
301／302：別のURLへ転送
403：アクセス拒否
404：対象ページが見つからない
500：サーバー内部でエラー

接続処理を詳しく見る

$ curl -v https://example.com/ -o /dev/null
* Host example.com:443 was resolved.
* IPv4: 93.184.216.34
*   Trying 93.184.216.34:443...
* Connected to example.com (93.184.216.34) port 443
* SSL connection using TLSv1.3
> GET / HTTP/1.1
< HTTP/1.1 200 OK

-vでは、名前解決、接続先IPアドレス、TCP接続、TLS、HTTP応答のどこまで進んだかを確認できます。 -o /dev/nullは、本文を画面に表示せず破棄する指定です。

補助的に覚えておきたいコマンド

コマンド	用途	注意点
`hostname -I`	ホストに割り当てられたIPアドレスを簡潔に表示	複数のアドレスが並ぶことがある
`nmcli device status`	NetworkManager管理下のデバイス状態を確認	NetworkManagerを使わない環境では利用できない
`nmcli connection show --active`	有効な接続プロファイルを確認	インターフェース名と接続名は別の場合がある
`ethtool ens160`	リンク速度やDuplexなどを確認	物理NICやドライバーにより表示内容が異なる
`ip -s link`	送受信パケット数やエラー数を確認	増加傾向を比較して判断する

古い資料ではifconfig、route、arp、netstatが登場します。既存環境で使われることはありますが、初めて学ぶ場合は、まずipとssを中心に覚えると整理しやすくなります。

通信障害時のおすすめ確認順序

コマンドを1つずつ独立して覚えるより、確認順序とセットで覚えると現場で使いやすくなります。

インターフェースを確認する ip -br linkで対象NICがUPか確認します。
IPアドレスを確認する ip -br addrで想定したIPアドレスとプレフィックス長があるか確認します。
ルーティングを確認する ip routeとip route get 宛先でゲートウェイと送信NICを確認します。
同じLAN内を確認する ゲートウェイへpingし、必要に応じてip neighを確認します。
外部IPアドレスを確認する DNSを使わないIPアドレス指定で外部への疎通を確認します。
DNSを確認する resolvectl queryやdigでホスト名がIPアドレスへ変換されるか確認します。
経路を確認する 必要に応じてtracepathで、どの区間まで到達するか確認します。
アプリケーションを確認する サーバー側はss、クライアント側はcurlなどで実際のサービス通信を確認します。

「pingが通る＝サービスが正常」ではありません。

pingは主にIPレベルの到達性を確認します。Web障害なら最後にcurl、SSH障害ならTCP 22番への接続など、対象サービスまで確認します。

Windowsコマンドとの対応

確認内容	Windows	Linux
IPアドレス	`ipconfig /all`	`ip addr`
ルーティング	`route print`	`ip route`
ARP・近隣情報	`arp -a`	`ip neigh`
疎通	`ping`	`ping -c 4`
経路追跡	`tracert`	`tracepath`／`traceroute`
DNS問い合わせ	`nslookup`	`resolvectl query`／`dig`
接続・待ち受け	`netstat -ano`	`ss -tulnp`

Linuxネットワークコマンドのよくある勘違い

誤 ip addrにIPアドレスがあれば通信できる

IPアドレスがあっても、リンクがDOWN、ルーティングがない、ゲートウェイへ到達できない、DNSが失敗しているなどの理由で通信できない場合があります。

誤 pingが失敗したら相手サーバーは停止している

ICMPが遮断されているだけかもしれません。対象サービスがWebならcurl、待ち受け確認ならssなど、別の方法でも確認します。

誤 /etc/resolv.confだけ見れば実際のDNSサーバーが分かる

systemd-resolved環境では、ローカルスタブのアドレスだけが表示されることがあります。実際の上流DNSはresolvectl statusで確認します。

誤 80番ポートがLISTENなら外部から必ず接続できる

LISTENはサーバー内部の待ち受け状態です。OSファイアウォール、ネットワーク機器、クラウド側ルールなどによる遮断は別に確認します。

正コマンド結果を組み合わせて原因を絞る

1つの出力だけで断定せず、リンク、アドレス、経路、名前解決、サービスの順に証拠を集めることが重要です。

理解度チェック

次の5問に答え、Linuxネットワークコマンドの役割を確認しましょう。

問題1．IPアドレスとプレフィックス長を確認する基本コマンドはどれですか。

ip addr
ip neigh
ss -tuln
curl -I

解答を見る

正解：A

ip addrで各インターフェースのIPv4・IPv6アドレスを確認できます。

問題2．特定の宛先へ、どのゲートウェイとインターフェースが使われるか確認するコマンドはどれですか。

ip link get 宛先
ip route get 宛先
ip neigh get 宛先
ss get 宛先

解答を見る

正解：B

ip route getは、指定した宛先に対してLinuxが選ぶ経路を表示します。

問題3．サーバーがTCP 443番ポートで待ち受けているか確認するのに適したコマンドはどれですか。

ss -tuln
ip addr
tracepath
hostname -I

解答を見る

正解：A

ss -tulnでTCP・UDPの待ち受けポートを確認できます。

問題4．IPアドレス指定のpingは成功し、ホスト名指定だけ失敗しました。最初に疑うべき機能は何ですか。

解答を見る

正解：DNS名前解決

IP通信そのものはできている可能性が高いため、DNSサーバー設定や名前解決結果を確認します。

問題5．pingに応答しない場合、「相手サーバーが停止している」と断定してよいですか。

解答を見る

正解：断定できません。

ICMPが遮断されている可能性があります。対象サービスに応じてcurlやTCP接続なども確認します。

実践演習：Webサイトへ接続できない原因を考えよう

Linuxサーバーからhttps://example.com/へ接続できないという申告がありました。次のコマンド結果から、最初に確認すべき問題を考えてください。

確認結果1：インターフェースとIPアドレス

$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens160           UP             192.168.10.25/24

確認結果2：ルーティング

$ ip route
192.168.10.0/24 dev ens160 proto kernel scope link src 192.168.10.25

確認結果3：疎通

$ ping -c 2 192.168.10.1
ping: connect: Network is unreachable

課題1．不足している可能性が高い設定は何ですか。

ここに自分の回答を書いてみましょう。

解答を見る

解答：デフォルトルートまたはデフォルトゲートウェイ

ip routeにdefault via ...がありません。同一ネットワーク外へ送る経路がないため、外部サイトへ通信できません。

課題2．デフォルトルートが追加された後、次にどの順番で確認しますか。

確認コマンドを3つ以上、順番に書いてみましょう。

解答例を見る

ip routeまたはip route get 93.184.216.34
ping -c 4 デフォルトゲートウェイ
ping -c 4 外部IPアドレス
resolvectl query example.comまたはdig +short example.com
curl -I https://example.com/

追加演習：DNS障害を見分ける

$ ping -c 2 93.184.216.34
2 packets transmitted, 2 received, 0% packet loss

$ resolvectl query example.com
example.com: resolve call failed: All attempts to contact name servers failed

課題3．この結果から、どの部分に問題があると考えられますか。

原因候補と、次に確認するコマンドを書いてみましょう。

解答例を見る

外部IPアドレスへの疎通は成功しているため、基本的なIP通信とルーティングは動作している可能性が高いです。 DNSサーバー設定、DNSサーバーへの到達性、DNSサービスの状態を確認します。

次の確認例はresolvectl status、cat /etc/resolv.conf、設定されたDNSサーバーへのpingまたはDNS問い合わせです。

自分の言葉で説明する課題

「LinuxサーバーからWebサイトへ接続できないとき、どの順番で確認しますか？」と質問されました。 1分程度で説明してください。

まず＿＿＿＿＿＿を確認し、次に＿＿＿＿＿＿、＿＿＿＿＿＿、＿＿＿＿＿＿の順で確認する。

説明例を見る

まずip linkとip addrでインターフェースとIPアドレスを確認します。次にip routeでデフォルトゲートウェイを確認し、ゲートウェイ、外部IPアドレスの順にpingします。 IPアドレスでは通信できるのにホスト名で失敗する場合はDNSを調べ、最後にcurlでHTTP・HTTPSの実通信を確認します。サーバー側の障害ならssで対象ポートが待ち受けているかも確認します。