ネットワークの基本：ss・curl・ping で調べる
「サーバーに繋がらない」というトラブルは、原因がネットワーク層にあるのか、DNS にあるのか、アプリケーション層にあるのかで対処が変わります。 むやみに再起動や設定変更を試す前に、段階的に状況を絞り込むのが鉄則です。 本記事では、その絞り込みに使うコマンド群を紹介します。
疎通確認：ping・traceroute
まず相手ホストまでパケットが届くかどうかを確認します。
ping
ICMP エコーリクエストを送り、相手が応答するかを確認する基本コマンドです。
ping google.com # 名前解決 + ICMP 疎通確認
ping -c 4 192.168.1.1 # 4回だけ送って終了（Linux のデフォルトは無限）
ping -i 0.5 example.com # 送信間隔を0.5秒にping が通らない場合、2つの可能性があります。ひとつは相手ホストまでの経路に問題がある場合、もうひとつは相手が ICMP を意図的にブロックしている場合です。後者は珍しくないため、ping が通らなくても即「繋がらない」とは判断できません。
traceroute / tracepath
パケットが相手に届くまでの経路（ルーター一覧）を表示します。どこでパケットが止まっているかを特定するのに使います。
traceroute google.com
tracepath google.com # traceroute がない環境でも使えることが多い* * * と表示されるホップは、そのルーターが ICMP タイムアウト応答を返していないだけで、必ずしもそこで止まっているわけではありません。その先のホップが正常に表示されていれば通過しています。
名前解決：dig・host
疎通が取れていても DNS が壊れていると名前でアクセスできません。
# dig: DNS の詳細な応答を確認する
dig google.com
dig google.com A # A レコード（IPv4）のみ
dig google.com AAAA # IPv6 アドレス
dig @8.8.8.8 example.com # 特定のDNSサーバーに問い合わせ（8.8.8.8 = Google）
# host: シンプルな名前解決確認
host google.com
host 8.8.8.8 # 逆引き（IP → ホスト名）dig の出力にある ANSWER SECTION が空、または NXDOMAIN が返ってきたら DNS 登録がない（もしくは問い合わせ先のサーバーに問題がある）ことを示しています。@8.8.8.8 のように別のDNSサーバーに問い合わせると、自社DNSの問題なのか外部から見ても同じなのかを切り分けられます。
ポートと接続状態：ss
ss（Socket Statistics）は、サーバーがどのポートで待ち受けているかや、現在の接続状態を確認するコマンドです。従来の netstat の後継にあたり、現在の Linux ディストリビューションでは ss が標準的に使われます。
# 待ち受けポートの確認（よく使う組み合わせ）
ss -tlnpオプションの意味:
| オプション | 意味 |
|---|---|
-t | TCP のみ表示 |
-l | LISTEN 状態のソケットのみ |
-n | ホスト名・サービス名を解決せず数値で表示 |
-p | プロセス名・PID を表示（root 権限が必要な場合あり） |
ss -tlnp
# State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
# LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))
# LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=5678,fd=6))「Nginx を起動したはずなのにアクセスできない」というとき、ss -tlnp で 80/443 ポートが LISTEN になっているか確認するのが最初のステップです。LISTEN していなければサービスが起動していない、または設定ミスで別ポートで待っている可能性があります。
UDP を確認したいときは -u に変えます。
ss -ulnp # UDP の待ち受け確認
ss -s # ソケット統計のサマリーHTTP の確認：curl
curl は HTTP/HTTPS を含む多プロトコルに対応した転送コマンドです。Web サーバーの応答をコマンドラインから手軽に確認できます。
よく使うオプション
# レスポンスヘッダだけ確認（-I: HEAD メソッドを送る）
curl -I https://example.com
# 詳細な通信ログを表示（TLS ハンドシェイク、ヘッダの送受信含む）
curl -v https://example.com
# リダイレクトを追従する
curl -L http://example.com
# ファイルをダウンロード
curl -o output.html https://example.com # ファイル名を指定
curl -O https://example.com/file.tar.gz # リモートのファイル名そのままで保存
# ステータスコードだけ取り出す
curl -o /dev/null -s -w "%{http_code}\n" https://example.com-I で確認できるレスポンスヘッダには、ステータスコード（200/301/404/502 など）、Content-Type、Server などが含まれており、アプリケーション層での問題の手がかりになります。
-v はトラブルシュート時に特に便利で、TLS 証明書の検証失敗や接続先のドメイン不一致なども可視化されます。
wget
curl の代わりに wget が使える環境もあります。再帰ダウンロードや -c（中断再開）が得意な一方、curl のほうがオプションが豊富で柔軟です。
wget https://example.com/file.tar.gz # ファイルをダウンロード
wget -c https://example.com/large.iso # 中断した続きからダウンロードIP アドレスとルーティング：ip コマンド
自分のマシンのネットワーク設定を確認するには ip コマンドを使います。ifconfig の後継です。
# インターフェース一覧と IP アドレスを表示
ip addr
ip addr show eth0 # 特定のインターフェースのみ
# ルーティングテーブルを確認
ip routeip route の出力にある default via の行が、デフォルトゲートウェイ（外部への出口）を示します。
default via 192.168.1.1 dev eth0 proto dhcp
192.168.1.0/24 dev eth0 proto kernel scope linkデフォルトゲートウェイが設定されていない場合、ローカルネットワーク外への通信が届きません。
切り分けの考え方
「繋がらない」を素直に信じず、次の順番で確認していくと原因を絞り込みやすくなります。
1. IP アドレスとインターフェースの確認
ip addr で自分の IP が正しく割り当てられているか。ip route でデフォルトゲートウェイが存在するか。
2. 疎通確認（L3）
ping でゲートウェイ、次に相手サーバーの IP アドレスに疎通を確認。IP 直打ちで通れば DNS ではなくルーティングの問題ではない。
3. 名前解決（DNS）
dig や host で名前解決が正しく機能しているか確認。IP 直打ちなら通るが名前で通らないなら、ここに原因がある。
4. ポートの確認（L4）
ss -tlnp で相手サーバー側のポートが LISTEN しているか、ファイアウォールで遮断されていないか。curl -v で接続できるか試す。
5. アプリケーション層の確認（L7） ポートには繋がるが期待の応答が返らない場合は、アプリケーション（Nginx や Node.js など）側のエラーログを確認する。
この順番を守ると「ネットワークは正常だがアプリが落ちていた」「DNS は通るが特定のポートがファイアウォールに弾かれていた」といった原因を無駄なく特定できます。
まとめ
| コマンド | 主な用途 |
|---|---|
ping | ICMP 疎通確認 |
traceroute / tracepath | 経路確認 |
dig / host | DNS 名前解決確認 |
ss -tlnp | 待ち受けポート確認 |
curl -I / -v | HTTP レスポンス確認 |
ip addr / ip route | IP・ルーティング確認 |
ネットワークのトラブルは「どの層で止まっているか」を段階的に絞り込むことが解決への近道です。コマンド自体はシンプルなので、実際にサーバーを触りながら使い方を覚えていくのが一番です。
次回（#8）はいよいよ SSH の実践編です。公開鍵認証の設定から鍵管理のコツまで、リモートサーバー操作の基盤となる知識を整理します。