第 5 章トラブルシュート編 — ネットワークの森

/ 00 · METHODOLOGY

切り分けの順序 ── 下から上へ

ネットワーク障害は「下の層」から「上の層」へ順番に確かめるのがコツ。物理的にケーブルが抜けているのに、TLS 証明書を疑っても無意味。

順	層	道具	確かめること
①	物理	目視	ケーブル抜けてない？Wi-Fi 繋がってる？
②	IP 到達性	`ping`	相手の IP まで届く？
③	ルーティング	`traceroute`	途中のルータで詰まってない？
④	DNS	`dig`	名前解決できる？
⑤	ポート	`nc`	そのポートで TCP セッションが張れる？
⑥	アプリ	`curl -v`	HTTP 応答が返る？
⑦	TLS	`openssl s_client`	証明書は有効？

「アプリが動かない」と言われたら、まずは TLS から疑わない。電源プラグから疑う。
── 経験豊富なエンジニアほど、下から始める。 — Operations Wisdom

/ 01 · PING

ping ── 届くかを聞く

ICMP を使って「そこにいる？」と聞く最初の道具。RTT（往復時間）とパケット損失率がわかる。

$ ping -c 4 google.com
PING google.com (142.250.207.46): 56 data bytes
64 bytes from 142.250.207.46: icmp_seq=0 ttl=117 time=8.42 ms
64 bytes from 142.250.207.46: icmp_seq=1 ttl=117 time=8.31 ms
...
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0.0% packet loss
round-trip min/avg/max = 8.31/8.45/8.61 ms

読み方

time＝RTT（往復時間、ミリ秒）。loss＝パケット損失率。日本国内なら 5-30 ms、米国なら 100-150 ms 程度。
応答なし＝ICMP がブロックされているか、相手が落ちている。最近のクラウドは ICMP をデフォルトで止めている場合が多いので、ping できない＝必ずしも障害ではない。

/ 02 · TRACEROUTE

traceroute ── どこで詰まるか

経由するルーターを 1 つずつ表示。途中で詰まっている地点を特定する。

$ traceroute google.com
 1  192.168.1.1 (自宅ルーター)        1.2 ms
 2  10.0.0.1 (ISP の入口)             8.5 ms
 3  ne.opt.example.com (バックボーン) 12 ms
 4  *  *  *                            ← この区間で詰まっている
 5  google.com (142.250.207.46)       8.4 ms

Windows では tracert、Linux/Mac では traceroute または mtr（推奨：リアルタイム連続計測でロス率も見える）。

/ 03 · DNS

nslookup / dig ── DNS を疑う

「ping は IP なら通るけど、ドメイン名だと通らない」── DNS の問題確定。

# シンプル
$ nslookup example.com
Server:  192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: example.com
Address: 93.184.216.34

# 詳しく見る（dig）
$ dig example.com +short
93.184.216.34

# 特定の DNS サーバに聞く（Cloudflare の 1.1.1.1）
$ dig @1.1.1.1 example.com

# レコード種類を指定
$ dig example.com MX     # メールサーバ
$ dig example.com TXT    # SPF 等
$ dig example.com NS     # 権威 DNS

DNS 変更が反映されない時

OS / ルーター / ISP の DNS キャッシュが残っている。
Mac: sudo dscacheutil -flushcache
Windows: ipconfig /flushdns
Linux: sudo systemctl restart systemd-resolved

/ 04 · NC / TELNET

nc / telnet ── ポート開通確認

ping は通るのにアプリが繋がらない → ポートが閉じている可能性。

# nc（netcat）でポート確認
$ nc -zv example.com 443
Connection to example.com 443 port [tcp/https] succeeded!

# 失敗時
$ nc -zv example.com 8080
nc: connectx to example.com port 8080 (tcp) failed: Connection refused
↑ アプリ未起動 or ポート閉鎖

# telnet（古典）
$ telnet example.com 443
Trying 93.184.216.34...
Connected to example.com.
↑ 接続できれば OK。Ctrl+] で抜ける

/ 05 · CURL

curl -v ── HTTP の中身を見る

ポートは開いているが 500 Internal Server Error が返る → アプリの問題。-v オプションで TLS ハンドシェイクから HTTP ヘッダまで丸見え。

$ curl -v https://example.com/api/health
*   Trying 93.184.216.34:443...
* Connected to example.com (93.184.216.34) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=example.com
*  start date: 2026-01-15
*  expire date: 2026-04-15  ← 期限切れ間近！
> GET /api/health HTTP/1.1
> Host: example.com
> User-Agent: curl/8.0.0
< HTTP/1.1 200 OK
< Content-Type: application/json
{"status":"ok"}

よく使うオプション

-I ヘッダだけ取得 / -L リダイレクト追従 / -X POST メソッド指定 / -d 'key=value' ボディ送信 / -H "Authorization: Bearer xxx" ヘッダ追加 / --resolve example.com:443:1.2.3.4 DNS を上書きして特定 IP で接続テスト。

/ 06 · OPENSSL

openssl s_client ── TLS 証明書を見る

「証明書エラー」が出る時の最終確認。証明書チェーン・期限・発行者・対象ドメインまで全て可視化できる。

$ openssl s_client -connect example.com:443 -servername example.com
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
---
Certificate chain
 0 s:CN = example.com
   i:C = US, O = Let's Encrypt, CN = R3
---
Server certificate
-----BEGIN CERTIFICATE-----
... (証明書本体) ...
-----END CERTIFICATE-----
subject=CN = example.com
issuer=C = US, O = Let's Encrypt, CN = R3
---
SSL handshake has read 5234 bytes and written 392 bytes
Verification: OK   ← 検証 OK

/ 07 · NETSTAT / SS

netstat / ss ── どのポートが開いてる？

自サーバで「ポート何番でリッスンしてる？」を確認。

# 古典：netstat
$ netstat -tulpn | grep LISTEN
tcp  0  0 0.0.0.0:22    0.0.0.0:*  LISTEN  1234/sshd
tcp  0  0 0.0.0.0:80    0.0.0.0:*  LISTEN  5678/nginx
tcp  0  0 0.0.0.0:443   0.0.0.0:*  LISTEN  5678/nginx

# 新世代：ss（速い）
$ ss -tulpn

# プロセス指定（PID）
$ lsof -i :443

/ 08 · WIRESHARK

Wireshark ── パケットを生で見る

上記すべてで原因不明 → ネットワーク上を流れる パケット 1 個ずつ を見る最後の手段。GUI ツール。

よく使うフィルタ：

フィルタ	意味
`http`	HTTP 通信のみ
`tcp.port == 443`	HTTPS のみ
`ip.addr == 93.184.216.34`	特定 IP の通信のみ
`dns`	DNS 通信のみ
`tcp.flags.reset == 1`	RST パケット（接続切断）

tcpdump ── CLI 版

サーバ上で GUI が使えない時は sudo tcpdump -i any -nn 'port 443' で同じことができる。出力を .pcap に保存して、後でローカルの Wireshark で開く流れも定番。

/ 09 · SCENARIOS

典型シナリオと対処手順

CASE 01

Web サイトが表示されない

① ブラウザ別で確認（キャッシュ問題）→ ② 別端末で確認（自分の Wi-Fi 問題）→ ③ ping 通る？ → ④ dig で DNS 確認 → ⑤ curl -v で詳細。

CASE 02

SSL 証明書エラー

① 期限切れ？（openssl s_client）② ドメイン名一致？ ③ 時計ずれ？（NTP）④ 中間証明書漏れ？

CASE 03

メールが届かない

① dig MX でメールサーバ確認 → ② SPF / DKIM / DMARC 設定確認 → ③ 受信側のスパムフォルダ → ④ Postmaster Tools で評価確認。

CASE 04

API が遅い

① curl -w "%{time_total}\n" で実測 → ② DNS / TLS / TTFB / 転送で切り分け → ③ サーバ側ログ・APM → ④ CDN 追加検討。

/ EPILOGUE

7 つの道具を、いつでも引き出せるように

TOOL 01–02

ping / traceroute

届くか・どこで詰まるか。最初に握る 2 つ。

TOOL 03

dig / nslookup

名前解決の真偽。設定変更のたびに叩く。

TOOL 04

nc / telnet

ポート開通。ファイアウォールの罠を見つける。

TOOL 05

curl -v

HTTP の中身。ほとんどの障害はここで決着がつく。

TOOL 06

openssl s_client

TLS 証明書。期限・チェーン・対象ドメイン。

TOOL 07

netstat / ss

自サーバの状態。「リッスンしているはずなのに」の確認。

TOOL 08

Wireshark / tcpdump

最後の手段、生パケット。ここまで来ると犯人は逃げ場がない。

これで「ネットワーク繋がらない」と相談されても、慌てず順番に潰せる。
── お疲れさまでした。森の出口です。 — End of vol. 01

トラブルシュート