Linuxでネットワークは正常なのに通信が遅い時の考え方

URLをコピーしました！

Linuxサーバーで通信遅延が発生した際、

pingは通る
パケットロスも見えない
NICエラーも出ていない

それでも、

「なぜか通信だけが遅い」

という状況に遭遇したことはないでしょうか。

本記事では、

「ネットワークが正常」とは何を意味するのか
それでも遅くなる理由
Linux視点での正しい切り分け順

を整理し、この記事だけで原因に辿り着ける思考法を解説します。

「ネットワークは正常」とは何を見て判断しているのか

多くの場合、「ネットワークは正常」という判断は、

ping疎通OK
packet loss 0%
NIC link up

といった疎通確認レベルで行われています。

しかし、これらが正常でも、

アプリケーション通信が速いとは限らない

のがLinux運用の落とし穴です。

ネットワークは正常なのに遅くなる代表的な原因

① サーバー側のI/O待ち・ブロック

通信処理は、以下の流れで進みます。

パケット受信
アプリケーション処理
ディスク・DBアクセス
レスポンス送信

この途中で、

ディスクI/O待ち
swapによるブロック

が発生すると、通信自体は遅く見えます。

pingが通るのは、

ICMP応答はCPU・I/Oをほぼ使わない

からです。

② コネクション数枯渇・待ち

ネットワーク機器が正常でも、

同時接続数が多すぎる
TIME_WAIT が溜まっている

と、通信は遅延します。

この場合、

ping → 問題なし
新規接続 → 遅い

という症状になります。

③ アプリケーション内部待ち

ネットワークは正常でも、

外部API待ち
DBロック待ち

が発生していると、結果的に

「通信が遅い」

と見えます。

これはネットワーク遅延ではなく、 処理待ち時間の問題です。

④ MTU・フラグメント問題

疎通はできているが、

大きなパケットだけ遅い
特定通信だけ遅延する

場合、MTU不一致が疑われます。

この場合も、

ping（小サイズ）OK
実通信が遅い

という現象になります。

Linuxでの実践的な切り分け順

Step1：ネットワークが「本当に」正常か確認

ip -s link

以下を確認します。

RX/TX error が増えていないか
dropped が増えていないか

ここで問題なければ、物理・NICレベルは概ね正常です。

Step2：vmstatでサーバー内部を疑う

vmstat 1

b（Blocked）が増えていないか
wa（I/O wait）が出ていないか

ここが怪しければ、 通信遅延の正体はI/O待ちです。

Step3：コネクション状態を確認

ss -ant

以下のような状態は要注意です。

ESTABLISHED が異常に多い
TIME_WAIT が大量

これはネットワーク正常でも遅くなる典型例です。

Step4：MTU問題の切り分け

ping -M do -s 1472 対向IP

通らない場合、

MTU不一致
フラグメント抑止

が原因の可能性があります。

どうなれば「解決」と判断できるのか

以下が揃えば解決です。

ネットワークエラーなし
b / wa が発生しない
新規接続が即時確立
アプリケーション応答が安定

重要なのは、

pingが通る = 通信が速い、ではない

という理解です。

まとめ

疎通確認だけでは通信品質は判断できない
通信遅延の多くはサーバー内部待ち
vmstat・ss・MTU確認が切り分けの鍵
「どこで待っているか」を見極めることが重要

ネットワークが正常に見えるときほど、 Linux内部の待ちを疑う視点が重要になります。