「あれ…？さっきまで普通に繋がってたのに、突然Webサイトが表示されなくなった！」
「社内のLinuxサーバーに接続できないんだけど！？」
「なんか全体的にインターネットが遅い気がする…」
ある日突然、あなたのLinuxサーバーやデスクトップPCがそんな状態になって、スマホで慌てて「linux 疎通確認」なんて検索して、このページにたどり着いてくれたんじゃないでしょうか。
わかります、わかります！私も全く同じ経験があります。
仕事や作業がまったく進まないし、「もしかして、サーバーが落ちた…？」「ネットワーク設定を壊しちゃった…？」って、もうパニックになっちゃいますよね😥
でも、大丈夫です！
その焦る気持ち、よーくわかります。でも、闇雲に設定ファイル（ifcfgとか）を書き換えるのは、絶対に待ってください！
ネットワークトラブルの解決は、まず「問題がどこで発生しているのか？」を特定する「切り分け（疎通確認）」が、なによりも大事なんです。
この記事は、そんな「ネットワーク地獄」に陥ってしまったあなたを救うための、基本的なトラブルシューティングコマンドを徹底的に解説する「完全ガイド」です🕵️♀️✨
Linux環境で絶対に知っておくべき4つの基本コマンド、「ping」「traceroute」「nslookup（とdig）」「nc（netcat）」について、その役割と具体的な使い方、出力結果の読み方まで、私と一緒に、一つずつ冷静に確認していきましょうね🥰
この記事を最後まで読めば、あなたはLinuxの基本的なネットワーク問題を自信を持って切り分け、原因を特定するための技術を身につけることができるはずですよ！
まずは、今回紹介する4つのコマンドが、それぞれネットワークのどの部分を確認するためのものなのか、その役割分担を見てみましょう。
4つの疎通確認コマンドの使い分け早見表
| コマンド | 主な目的 (確認するレイヤー) | 確認できること | 主なユースケース |
|---|---|---|---|
| ping | 生存確認 (L3: ネットワーク層) | 相手のIPアドレスまで到達可能か？ 応答速度(遅延)はどれくらいか？ |
「サーバーが落ちていないか？」 「ネットワークが遅くないか？」 |
| nslookup / dig | 名前解決 (L7: アプリケーション層/DNS) | ドメイン名からIPアドレスを正しく引けるか？ | 「Webサイトのドメインが見つからない」 「DNS設定は正しいか？」 |
| traceroute | 経路確認 (L3: ネットワーク層) | 相手に到達するまでにどのルーターを経由しているか？ ネットワークのどこで遅延やパケットロスが発生しているか？ |
「特定のサイトだけ遅い」 「社内からインターネットに出ているか？」 |
| nc (netcat) | ポート（サービス）確認 (L4: トランスポート層) | 相手の特定のポート（サービス）が応答するか？ ファイアウォールでブロックされていないか？ |
「pingは通るのにWeb(80)が見れない」 「SSH(22)ポートが開いているか？」 |
ネットワークトラブルシューティングの基本フロー
ネットワークが繋がらない時、私たちが一番知りたいのって「問題は”自分自身”にあるのか？」「”相手”にあるのか？」「それともその”途中”にあるのか？」ってことですよね。
これを「レイヤー（階層）」っていう考え方で切り分けるのが、トラブルシューティングの基本中の基本なんです。
（OSI参照モデルとか難しい話をしだすとキリがないので、ここでは割愛しますね😅）
大まかには、以下の流れで確認を進めていくのが一番効率的なんです！
- レイヤー1/2 (物理/データリンク): 自分の状態確認
そもそも自分のPC/サーバーのネットワーク設定は正しいか？（ip aコマンドでIPアドレス、サブネットマスクを確認します）
LANケーブルは抜けていないか？ Wi-Fiは接続されているか？（意外とこれが原因だったりします…）
（※IPアドレスの設定なんかは、別記事の「Linuxネットワーク設定ガイド」で詳しく解説していますよ！） - レイヤー7 (アプリケーション層): 名前解決の確認 (nslookup / dig)
「google.com」みたいなドメイン名から、IPアドレス「172.217.25.142」を正しく引けているか（名前解決できているか）を確認します。
これが失敗しちゃうと、PCはどこにアクセスすればよいか分からないので、通信が始まらないんですね。 - レイヤー3 (ネットワーク層): 相手への到達確認 (ping)
名前解決でゲットしたIPアドレス（または最初から分かってるIP）に対して、「もしもーし！」って声をかけ、応答（疎通）があるか確認します。
ここで応答があれば、少なくとも相手までの基本的なネットワーク経路は生きているってことになります！ - レイヤー3 (ネットワーク層): 経路の特定 (traceroute)
もしpingが失敗する、あるいはpingの応答がすっごく遅い（遅延している）場合…
自分から相手までの「途中」のどこに問題があるのかを、このコマンドで追跡します。 - レイヤー4 (トランスポート層): サービスの確認 (nc)
pingは成功する（＝相手サーバーは生きている）のに、特定のサービス（Webサイト、SSH、メールなど）に接続できないっていう最悪のケース…！
相手サーバーの「目的のポート（サービスの窓口）」が開いているか、ファイアウォールでブロックされていないかを確認します。
この流れに沿って、各コマンドの詳細を見ていきましょう！
① ping – ネットワークの「もしもし」【linux ping】
pingは、ネットワークトラブルシューティングで、最も基本となるコマンドです。
指定したホスト（IPアドレスまたはドメイン名）に対して、ICMPっていうプロトコルの「ECHO_REQUEST」パケット（「生きてますか？」っていう信号）を送信して、相手から「ECHO_RESPONSE」（「生きてますよ」っていう返事）が返ってくるかを確認するんです。
これによって、「相手ホストがネットワーク上で稼働しているか」そして「相手までのネットワーク遅延（応答時間）はどれくらいか」を、いっぺんに測定できちゃうんですね。
pingの基本的な使い方
最も基本的な使い方は、pingに続けて、確認したい相手のIPアドレスかホスト名を入力するだけです。カンタンですよね！
# GoogleのDNSサーバー (8.8.8.8) にpingを打つ
ping 8.8.8.8
# google.com にpingを打つ (自動的に名前解決されます)
ping google.com
⚠️（重要）Linux版 ping の注意点⚠️
Windowsのpingはデフォルトで4回実行すると自動的に停止してくれますが、Linuxのpingは、[Ctrl] + [C] を押して手動で停止するまで、無限にパケットを送り続けます！
これを知らずに実行しちゃうと、意図せずネットワークに負荷をかけちゃう可能性があるので、通常は「回数指定」のオプションを付けて実行するのがマナーですよ。
pingの出力結果の徹底解説
じゃあ、回数を指定して ping google.com を実行した場合の典型的な出力例を見てみましょう！
# -c 4 オプションで4回実行
$ ping -c 4 google.com
PING google.com (142.250.206.238) 56(84) bytes of data.
64 bytes from nrt12s54-in-f14.1e100.net (142.250.206.238): icmp_seq=1 ttl=116 time=5.20 ms
64 bytes from nrt12s54-in-f14.1e100.net (142.250.206.238): icmp_seq=2 ttl=116 time=5.15 ms
64 bytes from nrt12s54-in-f14.1e100.net (142.250.206.238): icmp_seq=3 ttl=116 time=5.09 ms
64 bytes from nrt12s54-in-f14.1e100.net (142.250.206.238): icmp_seq=4 ttl=116 time=5.12 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 5.090/5.140/5.201/0.041 ms
この出力から、すっごく多くの情報が読み取れますよ！😮
PING google.com (142.250.206.238)
google.comの名前解決が行われて、IPアドレスが142.250.206.238であることが分かります。64 bytes from ...
相手（nrt12s54-in-f14.1e100.net）から64バイトの応答があったことを示します。
これが表示されれば、疎通確認は成功です！ やったー！🎉icmp_seq=1
送信したパケットのシーケンス番号（1番目のパケット）です。ttl=116
TTL (Time To Live) の値です。
これはパケットがネットワーク上で生存できる「寿命」みたいなもので、ルーターを1つ経由する（1ホップする）ごとに通常1ずつ減少します。
（ちなみに、OSごとに初期値が違うので、この値から相手のOSをある程度推測することもできたりします…すごいですよね！）time=5.20 ms
RTT (Round Trip Time) と呼ばれ、パケットを送信してから応答が返ってくるまでの往復時間（ミリ秒）です。
これがネットワークの「遅延（レイテンシ）」であり、この値が小さいほど応答が速く、ネットワーク品質が高いと言えます。
目安として、国内の良好な接続であれば数ms〜数十ms、海外サーバーだと100msを超えることもありますよ。
【統計情報（まとめ）】
4 packets transmitted, 4 received, 0% packet loss
「4回送信し、4回受信し、パケットロス（途中で消失したパケット）は0%でした」という意味です。
ここが「0% packet loss」であれば、ネットワークは安定しています！
もし「50% packet loss」みたいに表示されたら、ネットワークが不安定であるか、経路が混雑していることを示しています…😥rtt min/avg/max/mdev = 5.090/5.140/5.201/0.041 ms
応答時間（RTT）の最小/平均/最大/標準偏差です。
特に「avg (平均)」と「max (最大)」に注目して、平均と最大の差が大きすぎないか（＝応答時間が安定しているか）を確認します。
よく使うpingコマンドのオプション
pingコマンドはたくさんのオプションを持っていて、状況に応じて使い分けることで、もっと詳しい調査が可能になるんです。
| オプション | 説明 | 主な使用例 |
|---|---|---|
| -c [回数] | 実行する回数を指定します。 | ping -c 5 google.com （5回実行して停止） |
| -i [秒数] | パケットを送信する間隔（秒）を指定します。 | ping -i 3 8.8.8.8 （3秒に1回送信）（高頻度で送ると負荷になるため注意） |
| -s [サイズ] | 送信するパケットのサイズ（バイト）を指定します。 | ping -s 1500 8.8.8.8 （大きいパケットを送り、経路のMTU問題などを調査） |
| -W [秒数] | 応答を待つタイムアウト時間（秒）を指定します。 | ping -c 1 -W 2 192.168.1.1 （2秒待っても応答がなければタイムアウトとみなす） |
| -I [IF名] | 送信元のネットワークインターフェース（例: eth0）を指定します。 | ping -I eth1 8.8.8.8 （複数のNICがあるサーバーで、eth1から送信） |
| -n | IPアドレスからホスト名を逆引き（名前解決）しない。 | ping -n 8.8.8.8 （DNSに頼らず、IPアドレスだけで確認したい場合に高速） |
pingでよく見るエラーと対処法
疎通確認が成功すれば良いんですが、問題がある場合は以下のようなイヤ～なエラーが表示されます…
エラー1: Destination Host Unreachable (宛先ホスト到達不可)
$ ping -c 4 192.168.1.99
PING 192.168.1.99 (192.168.1.99) 56(84) bytes of data.
From 192.168.1.10 icmp_seq=1 Destination Host Unreachable
...
- 意味:
「宛先（192.168.1.99）に到達できませんでした」っていうエラーです。
From 192.168.1.10 ...と表示されている場合、192.168.1.10（この場合は自分自身または直近のルーター）が、「その宛先への行き方（ルーティング）が分からない」あるいは「ARP要求に応答がない」と判断したことを意味します。 - 考えられる原因:
- 宛先ホスト（192.168.1.99）の電源が落ちている、またはネットワークに接続されていない。
- 自分自身のIP設定やサブネットマスク、デフォルトゲートウェイの設定が間違っている。（
ip aやip rコマンドで確認しましょう！） - 途中のルーターや、自分自身のファイアウォール（iptables, firewalldなど）がICMPをブロックしている。
- （同一セグメントの場合）ARPテーブルに問題がある。
エラー2: Request timed out (または応答が何もない)
$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
(応答が何も返ってこない...)
...
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3000ms
- 意味:
パケットは送信（transmitted）したものの、相手からの応答（received）がタイムアウト時間内に返ってこなかったことを示します。
結果として「100% packet loss」になっちゃいます。絶望的…。 - 考えられる原因:
- 宛先ホスト（8.8.8.8）が、ICMP（ping）に応答しないよう設定されている（セキュリティ上の理由でpingを拒否するサーバーは多いんです）。
- 自分、相手、または経路上のファイアウォールが、ICMPパケット（行きまたは帰り）をブロックしている。
- ネットワーク経路が極端に混雑している、または経路の途中で障害が発生している。
- （pingは成功するけどパケットロスが数%ある場合）ネットワークが不安定。
エラー3: Name or service not known (名前またはサービスが不明)
$ ping -c 4 google-invalid.com
ping: google-invalid.com: Name or service not known
- 意味:
これはping（レイヤー3）の問題じゃなくて、その前段階である「名前解決」が失敗したことを示します。 - 考えられる原因:
- 入力したドメイン名（
google-invalid.com）がそもそも存在しない。 - ドメイン名は存在するけど、自分のLinuxマシンが設定しているDNSサーバー（
/etc/resolv.confに書かれている）が、その名前解決に失敗した。 - DNSサーバー自体に到達できない（ネットワーク設定の問題）。
- 入力したドメイン名（
このエラーが出ちゃった場合は、次に解説する nslookup や dig コマンドで、名前解決の詳細を調査する必要がありそうですね！
② nslookup (と dig) – アドレスを尋ねる【linux 名前解決 コマンド】
pingでホスト名を指定したときに Name or service not known と出ちゃった場合や、そもそも「ドメイン名（google.com）に対応するIPアドレスは何か？」を調べたい場合に使うのが、linux 名前解決 コマンドである nslookup や dig です。
私たちがWebサイトにアクセスする時、「google.com」っていう名前を使いますけど、コンピューターは「142.250.206.238」といったIPアドレスで通信してるんですよね。
この「ドメイン名」と「IPアドレス」を相互に変換する仕組みをDNS (Domain Name System) と呼んで、この変換作業を「名前解決」と呼ぶんです。
nslookupコマンドの基本的な使い方
nslookup (Name Server Lookup) は、古くから使われている名前解決ツールです。
# google.com のIPアドレス (Aレコード) を調べる
$ nslookup google.com
Server: 192.168.1.1 # ← 自分が問い合わせたDNSサーバー
Address: 192.168.1.1#53 # ← そのDNSサーバーのIPとポート(53)
Non-authoritative answer: # ← (権威のない回答 = キャッシュされた情報かも)
Name: google.com
Address: 142.250.206.238 # ← google.com のIPアドレス (Aレコード)
Name: google.com
Address: 2404:6800:4004:82a::200e # ← IPv6アドレス (AAAAレコード)
この結果から、google.com には 142.250.206.238 というIPアドレスが割り当てられていることが分かりました！
もしpingが失敗していた場合、ここで取得したIPアドレス 142.250.206.238 に対して ping を実行してみる（ping 142.250.206.238）ことで、問題が名前解決にあったのか、ネットワーク経路にあるのかを切り分けることができるんです！
別のDNSサーバーを指定して確認する
nslookup は、デフォルトで /etc/resolv.conf に設定されたDNSサーバー（さっきの例だと 192.168.1.1）に問い合わせます。
もし、社内のDNSサーバーの調子が悪そうだな…？って感じた場合は、Googleが提供しているパブリックDNSサーバー（8.8.8.8）なんかを指定して、名前解決ができるか試すことができますよ。
# 8.8.8.8 (Google DNS) を使って名前解決する
$ nslookup google.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: google.com
Address: 142.250.206.238
...
これで名前解決ができれば、問題はデフォルトのDNSサーバー（192.168.1.1）にある可能性が高い！って判断できますね。
(推奨) より高機能なdigコマンドの使い方
nslookup は便利なんですけど、今ではちょっと古くて動作が曖昧なところもあるので、非推奨（deprecated）とされることもあるんです…
その代わり、もっと詳細で正確な情報が得られる dig (Domain Information Groper) コマンドの使用が、今は推奨されています！
（dig コマンドは bind-utils や dnsutils といったパッケージに含まれていることが多いので、もし入ってなかったらインストールしてみてくださいね）
▼ digの基本的な使い方
dig は nslookup よりも、すっごく詳細な情報（デバッグ情報）を表示してくれます。
# digで google.com を引く
$ dig google.com
...
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 142.250.206.238
;; Query time: 10 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
...
私たちが注目すべきなのは ANSWER SECTION（回答セクション）です！
google.com の A レコードは 142.250.206.238 ですよ、って教えてくれていますね。
▼ dig +trace (最も重要なオプション)
dig の最も強力な機能が、この +trace オプションです！
これは、名前解決の「過程」を、インターネットの根幹であるルートサーバー（.）から順番に追跡して表示してくれる、すごい機能なんです。
$ dig +trace google.com
...
. 518400 IN NS a.root-servers.net.
... (ルートサーバー一覧)
;; Received 239 bytes from 192.168.1.1#53(192.168.1.1) in 10 ms
com. 172800 IN NS a.gtld-servers.net.
... (.comサーバー一覧)
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 50 ms
google.com. 172800 IN NS ns1.google.com.
... (google.comサーバー一覧)
;; Received 1170 bytes from 192.5.6.30#53(a.gtld-servers.net) in 80 ms
google.com. 300 IN A 142.250.206.238
;; Received 55 bytes from 216.239.32.10#53(ns1.google.com) in 20 ms
この出力は、
- まずローカルDNS(192.168.1.1)に「ルートサーバーはどこ？」と聞く。
- ルートサーバー(a.root-servers.net)に「.comはどこ？」と聞く。
- .comサーバー(a.gtld-servers.net)に「google.comはどこ？」と聞く。
- google.comサーバー(ns1.google.com)に「google.comのAレコードは？」と聞いて、
142.250.206.238という最終回答を得る。
っていう流れを全部見せてくれています。
dig +trace が最後まで成功すれば、少なくともインターネットへの経路とDNSの仕組み自体は正常に動いていることが確認できます！勝利は目前です💪
名前解決が失敗する時のチェックポイント
/etc/resolv.confの確認
cat /etc/resolv.confを実行して、nameserverに設定されているDNSサーバーのIPアドレスが正しいか確認します。- ファイアウォールの確認
DNSの通信は通常、UDP 53番ポート（たまにTCP 53番ポート）を使います。
firewalldやiptablesの設定で、このポート（特にOutbound）が閉じられていないか確認しましょう。 - DNSサーバー自体の障害
dig @8.8.8.8 google.comみたいに、パブリックDNSを指定して実行し、名前解決できるか試します。
これで成功するなら、デフォルトのDNSサーバー（社内DNSやルーターとか）に問題がある可能性が濃厚です…。
③ traceroute – 経路を追跡する【linux traceroute】
ping は「相手に届くか（Yes/No）」しかわかんないんですよね…。
もし ping がタイムアウトしたり、応答がすっごく遅かったりする場合、自分と相手の「間」にあるネットワーク経路の、どこに問題があるのかを特定する必要があります。
このために使うのが traceroute（Windowsでは tracert）コマンドです！
traceroute は、宛先に到達するまでに経由するルーター（ホップ）のリストと、各ルーターまでの応答時間をぜんぶ表示してくれます。
tracerouteの基本的な使い方
traceroute も ping と同じで、IPアドレスかホスト名を指定します。
# google.com までの経路を追跡
$ traceroute google.com
traceroute to google.com (142.250.206.238), 30 hops max, 60 byte packets
1 my-router (192.168.1.1) 0.350 ms 0.300 ms 0.280 ms
2 isp-gateway.local (10.0.0.1) 2.500 ms 2.480 ms 2.510 ms
3 isp-area-router.tokyo (123.45.67.1) 5.100 ms 5.200 ms 5.150 ms
4 * * *
5 some-isp-backbone (198.51.100.1) 8.200 ms 8.150 ms 8.300 ms
6 jgao.com (203.0.113.1) 10.500 ms 10.400 ms 10.300 ms
7 108.170.250.193 (108.170.250.193) 11.000 ms 10.900 ms 11.100 ms
8 142.251.50.149 (142.251.50.149) 11.200 ms 11.150 ms 11.180 ms
9 nrt12s54-in-f14.1e100.net (142.250.206.238) 5.200 ms 5.150 ms 5.180 ms
tracerouteの出力結果の読み方
1 ... 192.168.1.1 ... 0.350 ms ...
1ホップ目は192.168.1.1（自宅やオフィスのルーター）で、応答時間は約0.3ms。2 ... 10.0.0.1 ... 2.500 ms ...
2ホップ目は10.0.0.1（プロバイダのゲートウェイ）。4 * * *
4ホップ目のルーターから応答がありませんでした（3回試行してすべてタイムアウト）。
これは、そのルーターが「Time Exceeded」メッセージを返さない設定になっているか、ICMPをブロックしていることを意味します。
この時点で通信が途絶えているとは限りません！ 次のホップ（5）に応答があるので、パケットはちゃんと通過していることがわかりますね。9 ... 142.250.206.238 ... 5.200 ms
9ホップ目で最終的な宛先であるgoogle.com(142.250.206.238) に到達しました！
tracerouteで見るべきポイントと実践
traceroute の真価は、遅延やパケットロスの「発生場所」を特定することにあります！
▼ 社内ネットワークから出ているか？
1ホップ目や2ホップ目（社内ルーターやファイアウォール）で応答が * * * となって、それ以降もずっと * * * が続く場合、そのルーターの設定ミスやファイアウォールでブロックされている可能性がすっごく高いです。
▼ どこで遅延が発生しているか？
（例）
5 ... 8.150 ms 6 ... 150.500 ms 7 ... 151.000 ms
上記みたいに、5ホップ目から6ホップ目の間で応答時間が 8ms から 150ms へと急激に増加した場合、5と6の「間」（多くの場合、ISP間や国際回線）に遅延の原因があると推測できます。
▼ どこで通信が止まっているか？
（例）
5 ... 8.150 ms
6 * * *
7 * * *
8 * * *
... (最後まで * * * が続く)
この場合、5ホップ目のルーターは通過しましたが、6ホップ目のルーター（またはそれ以降）が応答を返さず、最終的に宛先にも到達していません…。
6ホップ目のルーターで障害が発生しているか、そこでパケットが破棄（ルーティングミスやFW）されている可能性が高いです。
tracerouteの主要オプション（ICMP/UDP/TCP）
traceroute は、どのプロトコル（通信方式）を使って経路を調べるかを選べるんです。これ、ファイアウォール対策としてすっごく重要なんですよ！
- デフォルト (UDP)
Linuxのtracerouteは、デフォルトでUDPパケットを（通常では使われない）ハイポート番号宛に送信します。
（traceroute google.com） -I(ICMP)
Windowsのtracertと同じ、ICMP ECHO（pingと同じ）パケットを使います。
ファイアウォールがUDPをブロックしていても、ICMP（ping）は許可している場合、こちらで経路が見えることがありますよ。
（traceroute -I google.com）-T(TCP)
TCP SYNパケット（Webアクセスなどの「接続要求」）を使います。
多くのファイアウォールは、Webサーバー（TCP 80, 443）へのアクセスは許可していますよね。
ICMPやUDPがブロックされていても、TCPを使えば経路を追跡できる可能性が最も高い、強力なオプションです！
（traceroute -T -p 80 google.com←TCPの80番ポートを使って追跡）-n
ping同様、IPアドレスからホスト名を逆引き（名前解決）しません。
名前解決による遅延がなくなるので、追跡が高速になります！
もし traceroute で * * * が続いちゃう場合は、まず -I を試して、ダメなら -T -p 80 や -T -p 443 を試してみるのが定石ですね！
④ nc (netcat) – ポートに接続する【linux nc コマンド】
ping が通り（L3はOK）、nslookup も成功（DNSはOK）、traceroute でも宛先に到達している…。
でも、Webサイト（HTTPS: 443番ポート）にだけ接続できない！！
もう、なんで！？ってパニックになっちゃいますよね😭
この「ネットワーク層は生きているけど、特定のサービス（アプリケーション層）が応答しない」っていう状況で大活躍するのが nc (netcat) です！
nc は、その多機能さから「TCP/IPのスイスアーミーナイフ」なんて呼ばれてる、すごいヤツなんです。
ping や traceroute がICMP（レイヤー3）で動作するのに対して、nc は TCP や UDP（レイヤー4）で動作して、特定のポート番号（サービスの窓口）が「開いているか」「閉じているか」を確認できるんです！
ncの基本：ポートスキャン（疎通確認）
linux nc コマンド の最も基本的な使い方は、ポートスキャンです。
nc -zv [ホスト名 or IP] [ポート番号]
-z: ゼロI/Oモード。接続できたらすぐに切断する（スキャン目的）。-v: 詳細表示 (Verbose)。
（例1）Webサーバー (HTTPS: 443番) の疎通確認
# google.com の 443番ポート (HTTPS) が開いているか確認
$ nc -zv google.com 443
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connected to 142.250.206.238:443.
Ncat: 0 bytes sent, 0 bytes received in 0.05 seconds.
Connected to ... または succeeded! と表示されれば、接続成功です！🎉
これは、相手のサーバー（google.com）までのネットワーク経路が確立していて、かつ相手が443番ポートでサービス（HTTPS）を待機させていることを意味します。
（例2）SSH (22番) が閉じている（Refused）場合
# google.com の 22番ポート (SSH) を確認 (通常は閉じている)
$ nc -zv google.com 22
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connection refused.
「Connection refused (接続拒否)」
これは非常に重要な応答です！
「相手（google.com）までは到達したけど、相手が『22番ポートは使っていません』と明確に拒否した」ことを意味します。
ファイアウォールでブロックされているんじゃなくて、相手OSが「そのポートは開いてないよ」と応答している状態なんです。
（例3）ファイアウォールでブロックされている（Timeout）場合
# (仮に) 81番ポートがFWでブロックされている場合
$ nc -zv example.com 81
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connection timed out.
「Connection timed out (タイムアウト)」
nc がパケット（TCP SYN）を送信したけど、相手から succeeded (SYN/ACK) も refused (RST) も返ってこず、応答がない状態です…
これは、途中のファイアウォール（自分側、経路、相手側）が、そのパケットを黙って破棄（Drop または Reject）していることを示します。
pingは通るのに nc がタイムアウトする場合、ほぼ確実にファイアウォールが原因です！
linux nc コマンドの応用：簡易サーバー/クライアント
nc の真価は、それ自身が簡易的なサーバーやクライアントとして動作できることなんです！
これは、ファイアウォールの通過テストに最適ですよ！
シナリオ: サーバーA (192.168.1.10) から サーバーB (192.168.1.20) の 12345番ポートが、ファイアウォールを通過できるかテストしたい！
手順1: サーバーB（受け手）で待機 (Listen) サーバーを起動
サーバーBで、-l (Listen) と -p (Port) を使って 12345番ポートで待機します。
[Server B] $ nc -l -p 12345
# (カーソルが点滅し、接続を待機する)
手順2: サーバーA（送り手）で接続
サーバーAから、サーバーBの 12345番ポートに nc で接続します。
[Server A] $ nc 192.168.1.20 12345
# (接続が成功すると、カーソルが点滅する)
手順3: 通信テスト
この状態で、サーバーAでキーボードから文字を打ち、Enterを押します。
[Server A] $ nc 192.168.1.20 12345
Hello Server B
すると、サーバーBの画面に、その文字がリアルタイムで表示されます！
[Server B] $ nc -l -p 12345
Hello Server B
これが成功すれば、サーバーAからサーバーBへのTCP 12345番ポートの通信は、双方向で確立していることが完全に証明されます！
もしサーバーAで Connection timed out や Connection refused が出れば、ファイアウォール設定やルーティングを見直す必要がありますね。
ケーススタディ：Webサイトに繋がらない時のトラブルシューティング実践
最後に、これまで学んだ4つのコマンドを使って、「社内のLinuxサーバーから https://example.com に接続できない」という典型的な問題を切り分ける実践的な手順を見ていきましょう！
（あなたが今まさに直面している状況かもしれません…！冷静にいきましょうね！）
手順1: 名前解決の確認 (dig / nslookup)
まず、example.com という名前がIPアドレスに変換できるか確認します。
$ dig example.com
- 失敗 (
status: SERVFAILや応答なし )
問題: DNSに問題があります。
次のアクション:cat /etc/resolv.confでDNSサーバー設定を確認。dig @8.8.8.8 example.comでパブリックDNSなら引けるか確認。nc -zv [DNSサーバーIP] 53でDNSサーバーの53番ポート（UDP/TCP）がブロックされていないか確認。
- 成功 (
ANSWER SECTIONにIPアドレス (例: 93.184.216.34) が表示される )
状況: 名前解決は正常です！ IPアドレス93.184.216.34を控えて次へ進みましょう！
手順2: 生存確認 (ping)
次に、そのIPアドレスまでネットワーク的に到達できるか確認します。
$ ping -c 4 93.184.216.34
- 失敗 (
100% packet lossまたはDestination Host Unreachable)
問題: 相手に到達できないか、相手がICMP（ping）を拒否しています。
次のアクション: 手順3のtracerouteで経路を調査します。 - 成功 (
0% packet loss)
状況: レイヤー3（ネットワーク層）での疎通はOK。サーバーは生きています！
次のアクション: 問題はレイヤー4（ポート）かそれ以上にあるみたいです…。手順4のncへ進みます。
手順3: 経路確認 (traceroute)
ping が失敗した場合、どこで止まっているか確認します。
# まずは -n (名前解決なし) で高速に実行
$ traceroute -n 93.184.216.34
- （結果1）社内ルーター（例: 192.168.1.1）以降、すべて
* * *
問題: デフォルトゲートウェイの設定ミス、または社内のファイアウォールが外部への通信（ICMP）をブロックしています。
次のアクション:ip rでルーティングテーブルを確認。ファイアウォール設定を確認します。 - （結果2）途中のISP（例: 5ホップ目）から先がすべて
* * *
問題: 5ホップ目のルーターか、その先で障害が発生しているか、パケットが破棄されています。
次のアクション:traceroute -T -p 443 -n 93.184.216.34のように、TCP 443番（HTTPS）で追跡を試みます（ICMPだけブロックされている可能性があるためです！）。 - （結果3）TCPでも失敗
問題: 経路上の深刻な障害、または相手側がこちらからのアクセスをIPレベルでブロックしている可能性があります…。
手順4: ポート（サービス）の確認 (nc)
ping は成功したのに https://example.com (HTTPS) に繋がらない場合、目的のポートが開いているか確認します。HTTPSのポート番号は 443 ですよね。
$ nc -zv 93.184.216.34 443
- 失敗 (
Connection timed out)
問題: これがおそらく原因です！
ping（ICMP）は許可されているけど、TCP 443番ポートへの通信が、自分、経路、または相手のファイアウォールでブロックされています。
次のアクション:firewalldやiptablesのOUTPUT（送信）ルール、社内ネットワークのファイアウォール設定を確認して、TCP 443番ポートへの通信を許可します。 - 失敗 (
Connection refused)
問題: 相手の93.184.216.34サーバーに到達はしたけど、そのサーバーが443番ポートでサービスを動かしていない（Webサーバーが起動していない）ことを意味します。
次のアクション: 相手側のサーバー管理者に連絡します。（これはこちらのネットワークの問題じゃないですね！） - 成功 (
Connected to ...)
状況: ネットワーク（L3）もポート（L4）も問題ありません。
問題: アプリケーション層（L7）に問題がある可能性が高いです…。
次のアクション:curl -v https://example.comなどを実行して、SSL/TLS証明書の問題、プロキシ設定の問題、Webサーバー側のアプリケーションエラー（500エラーなど）がないかを確認します。
まとめ
Linuxにおけるネットワークの疎通確認は、問題の切り分け（トラブルシューティング）の基本中の基本です！
今回解説した4つのコマンドの役割を、もう一度おさらいしますね。
✅ nslookup / dig:
繋がらない原因が「名前解決」か否かを切り分けます。
✅ ping:
生存確認（レイヤー3）。相手サーバーがネットワーク的に生きているかを確認します。
✅ traceroute:
経路確認（レイヤー3）。ping が失敗したり遅かったりする場合に、ネットワークの「どこ」に問題があるかを追跡します。
✅ nc:
ポート（サービス）確認（レイヤー4）。ping は通るのにサービスに繋がらない時、ファイアウォールや目的のサービス（ポート）が応答するかを確認します。
ネットワークトラブルに遭遇すると本当に焦っちゃいますが、慌てずにこの4つのコマンドを基本フローに沿って使いこなし、問題を論理的に特定していけば、必ず解決の糸口は見つかりますから！💪✨
コメント