ネットワークトラブルシューティング: 接続問題の診断と修正

2026年3月31日 · 12分で読めます

ネットワーク接続の問題は、ITにおいて最もイライラする問題の一つです。エンタープライズインフラを管理するシステム管理者であれ、API呼び出しをデバッグする開発者であれ、ネットワーク問題を体系的に診断し解決する方法を理解することは不可欠なスキルです。

この包括的なガイドでは、実証済みのトラブルシューティング手法、必須の診断ツール、一般的なネットワーク問題に対する実践的な解決策を説明します。問題を迅速に特定し、ネットワークスタックの各層で何が起こっているかを理解し、効果的な修正を実装する方法を学びます。

ネットワークトラブルシューティングの体系的アプローチ

ネットワーク接続が失敗したとき、最悪なのは無作為に設定を変更し始めることです。効果的なトラブルシューティングは、OSIモデルに基づいた体系的なボトムアップアプローチに従います。物理層から始めて、ネットワーク層、トランスポート層、アプリケーション層へと進んでいきます。

各層での重要な質問は「この層は機能しているか?」です。はいの場合は上に進みます。いいえの場合は、問題領域を見つけたことになります。この方法論的アプローチは、何時間もの推測を省き、根本原因により早く到達できます。

7層トラブルシューティングフレームワーク

プロのネットワークエンジニアが従う基本的なトラブルシューティングシーケンスは次のとおりです:

1. 物理的接続 — ケーブルは接続されていますか? Wi-Fiは関連付けられていますか? リンクライトは点灯していますか?
2. データリンク層 — ネットワークインターフェースは起動していますか? 有効なMACアドレスを取得していますか?
3. ネットワーク層 — IPアドレスはありますか? ゲートウェイに到達できますか?
4. トランスポート層 — 正しいポートが開いていますか? ファイアウォールがトラフィックをブロックしていますか?
5. セッション/プレゼンテーション層 — 暗号化プロトコルは機能していますか? セッションは確立されていますか?
6. アプリケーション層 — 特定のサービスまたはアプリケーションは正しく応答していますか?

半分分割法

複雑なネットワークパスを扱う場合は、半分分割法を使用します。パスの中間点で接続性をテストします。機能する場合、問題は後半にあります。失敗する場合、問題は前半にあります。正確な障害点を特定するまで分割を続けます。

たとえば、リモートサーバーに到達できない場合、まずローカルゲートウェイをテストします。それが機能する場合は、中間ホップをテストします。このバイナリサーチアプローチは、トラブルシューティング時間を劇的に短縮します。

Ping: 接続性のテスト

Pingは最も基本的なネットワーク診断ツールです。ターゲットにICMPエコー要求パケットを送信し、応答時間を測定することで、ホストが到達可能かどうか、接続がどれだけ速いかを教えてくれます。

Pingを理解することは、単に応答を得られるかどうかを確認することを超えています。Ping結果のパターンは、ネットワークの動作、輻輳、パケット損失、ルーティングの問題を明らかにします。

必須のPingコマンド

# 基本的なpingテスト
ping google.com

# 特定の回数でping(スクリプトに便利)
ping -c 4 google.com

# タイムスタンプ付きping(問題が発生した時刻を追跡)
ping -D google.com

# 特定のパケットサイズでping(MTU問題をテスト)
ping -s 1472 -M do google.com

# 間隔を指定した連続ping
ping -i 0.5 192.168.1.1

# ストレステスト用のフラッドping(root権限が必要)
sudo ping -f -c 1000 192.168.1.1

# 特定の送信元アドレスでping
ping -I eth0 google.com

Ping結果の読み方

Ping出力を理解することは、正確な診断に不可欠です。各メトリックが何を示しているかは次のとおりです:

一般的なPingパターンとその意味

断続的なパケット損失: 時折パケットがドロップされる場合(5〜20%の損失)、これは通常、ネットワーク輻輳、故障しているネットワークインターフェース、またはワイヤレス干渉を示しています。帯域幅を大量に消費するアプリケーションやハードウェアの問題を確認してください。

遅延の増加: Ping時間が時間とともに徐々に増加する場合、ネットワーク輻輳またはルーティングループが発生している可能性があります。tracerouteを使用して、遅延が発生している場所を特定してください。

リクエストタイムアウト: 応答を受信できない完全な失敗は、通常、ファイアウォールがICMPをブロックしているか、ホストがダウンしているか、ルーティングの問題があることを意味します。DNS問題を除外するために、IPアドレスでpingしてみてください。

宛先ホスト到達不能: このエラーは、ローカルルーターが宛先へのルートを見つけられないことを意味します。ルーティングテーブルとデフォルトゲートウェイの設定を確認してください。

Traceroute: ネットワークパスのマッピング

Pingは宛先が到達可能かどうかを教えてくれますが、tracerouteはパケットがそこに到達するために取る正確なパスを示します。これは、ルート上のどこで問題が発生しているかを特定するのに非常に貴重です。

Tracerouteは、TTL(生存時間)値を段階的に増やしたパケットを送信することで機能します。パス上の各ルーターはTTLをデクリメントし、ゼロに達するとICMP時間超過メッセージを送り返し、その身元を明らかにします。

Tracerouteコマンドとオプション

# 基本的なtraceroute(Linux/Mac)
traceroute google.com

# Windows版
tracert google.com

# UDPの代わりにICMPを使用(成功する可能性が高い)
traceroute -I google.com

# 最大ホップ数を指定
traceroute -m 20 google.com

# TCP SYNパケットを使用(一部のファイアウォールをバイパス)
sudo traceroute -T -p 443 google.com

# 各ホップのAS番号を表示
traceroute -A google.com

# 同時プローブによる高速traceroute
traceroute -q 1 google.com

Traceroute出力の解釈

Traceroute出力の各行は、パス上のホップ(ルーター)を表します。ホップ番号、ホスト名/IP、および3つの往復時間測定値が表示されます。

アスタリスク(* * *): これらは、ルーターがタイムアウト期間内に応答しなかったことを示します。これはしばしば正常です。多くのルーターは、セキュリティ上の理由からtracerouteプローブに応答しないように設定されています。アスタリスクが表示されても、後のホップが応答する場合、パスは依然として機能しています。

突然の遅延増加: 特定のホップで20msから150msへのジャンプが見られる場合、そこに輻輳または長距離リンクが存在します。これがボトルネックです。

最後のタイムアウト: 最終宛先がアスタリスクを示しているが、以前のホップが機能している場合、宛先ホストまたはそのファイアウォールがプローブパケットをブロックしている可能性があります。既知の開いているポートでTCPベースのtracerouteを試してください。

高度なパス解析

より深い解析には、pingとtraceroute機能を組み合わせたMTR(My Traceroute)を使用します。MTRは継続的にパケットを送信し、各ホップでのパケット損失と遅延に関するリアルタイム統計を提供します。

# MTRをインストール
sudo apt-get install mtr  # Debian/Ubuntu
brew install mtr          # macOS

# レポートモードでMTRを実行
mtr --report --report-cycles 100 google.com

# TCPプローブを使用したMTR
mtr --tcp --port 443 google.com

DNSトラブルシューティングと解決

DNS問題は最も一般的なネットワーク問題の一つですが、しばしば接続問題として誤診断されます。IPアドレスにpingできるがドメイン名にはできない場合、DNSが原因です。

DNS解決のテスト

最初のステップは、DNSが全く機能しているかどうかを判断することです:

# 基本的なDNS解決をテスト
nslookup google.com

# 特定のDNSサーバーにクエリ
nslookup google.com 8.8.8.8

# digを使用した詳細なDNSクエリ
dig google.com

# 特定のレコードタイプをクエリ
dig google.com MX
dig google.com TXT

# DNS委任パスをトレース
dig +trace google.com

# 逆引きDNSルックアップ
dig -x 8.8.8.8

# DNS応答時間を確認
dig google.com | grep "Query time"

一般的なDNS問題と解決策

DNSサーバーが応答しない: /etc/resolv.conf(Linux)またはネットワーク設定(Windows/Mac)でDNSサーバー設定を確認してください。Google(8.8.8.8)やCloudflare(1.1.1.1)などのパブリックDNSサーバーへの切り替えを試してください。

古いDNSキャッシュ: システムまたはローカルDNSサーバーが古いレコードをキャッシュしている可能性があります。DNSキャッシュをフラッシュします:

# Linux(systemd-resolved)
sudo systemd-resolve --flush-caches

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

スプリットホライズンDNSの問題: 内部および外部DNSサーバーは、同じドメインに対して異なる結果を返す場合があります。dig @serverを使用して特定のDNSサーバーにクエリし、結果を比較してください。

DNSSEC検証の失敗: DNSSECが有効になっているが誤って設定されている場合、解決は失敗します。DNSSEC検証を無効にしてテストします:

dig +cd google.com

DNS伝播の問題

DNSレコードを更新しても、変更はすぐには有効になりません。DNS伝播は、TTL値とキャッシュ動作に応じて、数分から48時間かかる場合があります。

伝播状態を確認するには、異なる地理的地域のDNSサーバーにクエリします。当社のDNS伝播チェッカーは、このプロセスを自動化し、どのサーバーが更新されたレコードを持っているかを表示します。

一般的なネットワーク問題と解決策

最も頻繁に遭遇するネットワーク問題とその実証済みの解決策を見ていきましょう。

インターネット接続なし

これは最も一般的な苦情ですが、実際にはそれほど単純ではありません。次の診断シーケンスに従ってください:

1. 物理的接続を確認: ケーブルが接続されていること、Wi-Fiが接続されていること、ネットワークインターフェースライトがアクティブであることを確認します。
2. IP設定を確認: ipconfig(Windows)またはip addr(Linux)を実行して、有効なIPアドレスがあることを確認します。169.254.x.xが表示される場合、DHCPが失敗しました。
3. ゲートウェイ接続をテスト: デフォルトゲートウェイにpingします。これが失敗する場合、問題はローカルです。
4. 外部接続をテスト: 8.8.8.8のようなパブリックIPにpingします。これが機能するがドメイン名が解決されない場合、DNS問題です。
5. DNS解決を確認: nslookup google.comを使用してDNSが機能していることを確認します。

ネットワークパフォーマンスの低下

遅いネットワークには多くの潜在的な原因があります。ボトルネックを特定する方法は次のとおりです:

帯域幅をテスト: 速度テストツールを使用して実際のスループットを測定します。結果を期待される帯域幅と比較します。

輻輳を確認: netstat -sを実行して、パケット再送信統計を確認します。高い再送信率は、輻輳またはパケット損失を示しています。

帯域幅を消費しているものを特定: iftopやnethogsなどのツールを使用して、どのプロセスが帯域幅を消費しているかを確認します:

# iftopをインストールして実行
sudo apt-get install iftop
sudo iftop -i eth0

# nethogsをインストールして実行
sudo apt-get install nethogs
sudo nethogs eth0

デュプレックスミスマッチを確認: 接続の一方の端が全二重に設定され、もう一方が半二重に設定されている場合、パフォーマンスは悲惨なものになります。ethtool eth0で設定を確認してください。

断続的な接続

断続的な問題は、一貫して再現できないため、診断が最も困難です。それらを捕捉する方法は次のとおりです:

継続的な監視: ゲートウェイと外部ホストに同時に継続的なpingを実行します。結果をログに記録してパターンを特定します: