サーバーのレスポンスが悪い、通信が途切れる、タイムアウトが発生する。
このようなとき、 本当にパケットロスが発生しているのかを Linuxサーバー上で正しく確認できていますか？
本記事では、 Linuxでパケットロスの有無を確認するための具体的な方法を、 切り分け手順として解説します。
目次
結論：パケットロスは「1つのコマンド」では判断できない
パケットロスの確認は、
- ping
- インターフェース統計
- TCP再送
複数の視点を組み合わせて判断する必要があります。
確認① ping による基本的なロス確認
ping -c 100 対象ホスト見るべきポイント
- packet loss が 0% か
- time が大きくばらついていないか
1〜2%でも継続的に発生していれば異常と判断します。
※ 一時的な 1 packet loss は必ずしも障害とは限りません。
確認② インターフェースのドロップ確認（ip -s link）
ip -s link注目すべき項目
- RX dropped
- TX dropped
- RX errors / TX errors
これらが増え続けている場合、
- NIC処理能力不足
- キュー溢れ
- ドライバ問題
が疑われます。
確認③ ethtool によるNICエラー確認
ethtool -S eth0よく見るカウンタ例
- rx_dropped
- tx_dropped
- rx_errors
- tx_errors
ここが増加している場合、OSより下のレイヤー （NIC / ケーブル / スイッチ）の問題を疑います。
確認④ netstat / ss によるTCP再送の確認
netstat -s | grep -i retransまたは
ss -s判断基準
- TCP retransmits が継続的に増加
- established は多いが throughput が出ない
→ パケットロスまたは遅延の可能性が高い
確認⑤ アプリケーション視点の確認
OSレベルで問題が見えない場合でも、
- APIタイムアウト
- DB接続再試行
が発生していることがあります。
この場合、 アプリケーションログの再送・timeout記録 も重要な判断材料です。
パケットロスが起きていると判断できる状態
- ping で packet loss が継続的に発生
- RX/TX dropped が増え続ける
- TCP retransmits が止まらない
これらが複合して確認できた場合、 パケットロスが発生している可能性が高いです。
よくある誤解
- ping が通るから問題ない
- CPU idle が高いからネットワークは健全
- NIC errors は無視してよい
パケットロスは CPU使用率や負荷に現れにくい障害です。
パケットロスが疑われた時の次のアクション
- NICドライバ・firmware確認
- MTU不一致の確認
- スイッチポートエラー確認
- 仮想環境ならvSwitch設定確認
まとめ
Linuxでパケットロスを確認するには、
- ping
- NIC統計
- TCP再送
を必ずセットで確認することが重要です。
「通信が遅い＝ネットワーク」と決めつけず、 数字で判断できる状態を作りましょう。