Linuxのネットワークトラブルシューティング｜通信障害・Timeout・Packet Lossの原因調査

はじめに

Linuxで構築されたシステムでは、「通信できない」「接続に時間がかかる」「特定の宛先だけ通信できない」「ときどきTimeoutする」といったNetworkトラブルが発生することがあります。

Network障害が難しい理由は、原因がLinuxサーバ自身にあるとは限らないことです。NIC、IP Address、Routing、ARP / NDP、Firewall、TCP、DNS、Load Balancer、Network機器、Applicationなど、複数のLayerをまたいで原因を切り分ける必要があります。

そのため、「とりあえずping」「とりあえずtcpdump」ではなく、Link → IP → Route → Neighbor → TCP / Socket → DNS → Packetの順に確認すると、調査範囲を効率的に絞り込むことができます。

本記事では、Network障害を検知してから原因を特定し、暫定対処・恒久対処へつなげるまでの流れを実践的に解説します。

Network障害とは

Network障害では、症状によって疑うべきLayerが異なります。

重要なのは、Network障害＝NICやNetwork機器の障害ではないという点です。Linux上のRoute設定やApplicationのPort Listen状態、Firewall、DNSなどでも同様の症状が発生します。

Networkトラブルシューティングの全体像

Network障害を検知した場合は、通信経路を順番に確認し、どこに問題があるかを切り分けることが重要です。

Network障害の原因は、NICやIP Addressだけでなく、Routing、Neighbor、TCP、DNS、Application、Network機器など、さまざまなレイヤーに存在します。

闇雲にコマンドを実行するのではなく、次の流れで確認することで、問題箇所を効率よく絞り込めます。

Network調査では、どこまでは正常で、どこから先がおかしいのかを段階的に確認することが重要です。

まずNetwork全体の異常傾向を確認する

ip -s linkでInterface統計を確認する

ip -s link show では、Network Interfaceの状態とRX / TXの統計情報を確認できます。

まず state UP でInterfaceが有効になっていることを確認し、次に errors や dropped が増加していないかを確認します。
bytes・packets・errors・dropped は累積値のため、1回の値だけではなく、時間を空けて再実行して増加しているか確認することが重要です。

# ip -s link show <IF名>

ip -s link show コマンド表示例：

sar -n DEVで過去のTrafficを確認する

sar -n DEV では、Network InterfaceごとのTrafficを時系列で確認できます。rxpck/s・txpck/s でPacket数、rxkB/s・txkB/s でThroughput、%ifutil でInterfaceの帯域利用率を確認します。障害発生時刻にTrafficや帯域利用率が急増していないかを確認することで、Network負荷の切り分けに役立ちます。

# sar -n DEV
# sar -n DEV -f /var/log/sa/saXX

sar -n DEV コマンド表示例：

sar -n EDEVでError / Dropを確認する

sar -n EDEV では、Network InterfaceごとのErrorやPacket Dropを時系列で確認できます。sar -n DEV がTraffic量やThroughputの確認に向いているのに対し、sar -n EDEV は通信品質の異常を確認するための統計として利用します。

Network障害調査では、特に rxerr/s・txerr/s で送受信Error、rxdrop/s・txdrop/s でPacket Dropを確認します。障害発生時刻にこれらの値が増えている場合は、NIC、Driver、Buffer / Queue、Network機器、Virtualization Layerなどを含めて原因を切り分けます。

# sar -n EDEV
# sar -n EDEV -f /var/log/sa/saXX

sar -n EDEVコマンド出力例：

sar -n EDEV の値は、1回だけを見るのではなく障害発生時刻に増加しているか、通常時との差があるかを確認することが重要です。Error / Dropが見つかった場合は、ip -s link、ethtool -S、Kernel Logなどを併用して詳細を確認します。

ss -sでSocket全体を確認する

ss -s では、System全体のSocket利用状況をサマリで確認できます。特にTCPでは、estab で確立済みConnection数、timewait でTIME_WAIT状態のConnection数を確認します。これらが通常時と比べて急増していないかを確認することで、Connection数の増加や大量の短時間接続などを切り分けます。

ss -s は全体傾向を確認するコマンドなので、異常が見つかった場合は ss -tan や ss -lntp などで個々のSocketを深掘りします。

# ss -s

ss -s コマンド表示例：

Interface / IP Addressを確認する

ip linkでInterface状態を確認する

ip link show では、Network Interfaceの基本状態を確認します。まず UP と LOWER_UP を確認し、Interfaceが有効化され、下位LayerのLinkも確立していることを確認します。また、mtu や state が設計どおりかも確認します。

# ip link show eth0

ip link showコマンド表示例：

ethtoolでLink状態を確認する

ethtool では、NICのLink状態やSpeed、Duplexなどを確認できます。Physical NICではLinkが確立しているか、想定した通信速度やDuplexになっているかを確認します。Virtual Machineでは表示内容がVirtual NICやHypervisorに依存します。

# ethtool eth0

ethtool コマンド表示例：

ip addrでIP Addressを確認する

ip addr では、Interfaceに設定されているIP AddressやPrefix Lengthを確認できます。通信対象のInterfaceに、設計どおりのIP Addressが設定されているかを確認します。

# ip addr show eth0

ip addr show コマンド表示例：

Routing / Neighborを確認する

ip routeでRouting Tableを確認する

ip route では、Kernelが保持しているRouting Tableを確認できます。Default GatewayやDestination NetworkへのRouteが存在するか、想定したInterfaceやNext Hopが設定されているかを確認します。

# ip route

ip route コマンド表示例：

ip route getで実際に選択されるRouteを確認する

ip route get では、特定Destinationに対してKernelが実際に選択するRouteを確認できます。Routing Table全体を見るip routeに対して、障害調査ではDestinationごとの実際のNext Hop、Output Interface、Source IP Addressを確認できる点が有効です。

# ip route get 8.8.8.8

ip route get コマンド表示例：

ip neighborでNeighbor Tableを確認する

ip neighbor では、Neighbor Tableを確認できます。IPv4ではARP、IPv6ではNDPによってIP AddressとMAC Addressの対応を解決します。同一Subnet上の宛先、またはNext HopとなるGatewayのMAC Addressが解決できているか、Neighbor Stateに異常がないかを確認します。

# ip neighbor

ip neighbor コマンド表示例：

TCP / Socketまで原因を深掘りする

ssでLISTEN状態を確認する

ss -lntp では、TCP PortのLISTEN状態と、そのPortを使用しているProcessを確認できます。Applicationが起動していても、想定したIP Address / PortでLISTENしていなければConnectionを受け付けられません。

# ss -lntp

ss -lntp コマンド表示例：

TCP Connection Stateを確認する

ss -ant では、TCP Connectionの状態を確認できます。特定のStateが通常時より増えていないか、Connectionがどの段階で止まっているかを確認します。

# ss -ant

ss -ant コマンド表示例：

Connection RefusedとTimeoutを区別する

Connection Refusedでは、宛先Hostや経路上の機器などからTCP RSTが返されていることが多く、少なくともSYNに対する応答が返っている状態です。一方、Timeoutでは途中でPacketが破棄されているケースや、対向から応答が返っていないケース、Application処理が完了していないケースなどが考えられます。

Retransmissionを確認する

TcpRetransSegs は、再送されたTCP Segmentの累積数です。TCP再送が発生しているかを確認する際に使用します。累積値そのものではなく、障害発生中に値がどの程度増加しているかを確認することが重要です。

# nstat -az | grep TcpRetransSegs

nstat -az コマンド出力例：

DNSエラーを調査する

IP Addressでは通信できるのにHostnameでは通信できない場合は、DNSによる名前解決に問題が発生している可能性があります。DNSエラーでは、名前解決、DNS設定、DNS Serverへの経路、DNS Query / Response、DNS Server側の順に確認します。

① 名前解決できるか確認する

最初に、対象のHostnameを名前解決できるか確認します。DNS Serverへの問い合わせ結果を確認するには、digを使用します。

# dig <Host Name>

digコマンドの表示例：

名前解決に成功すると、ANSWER SECTIONにIP Addressが表示されます。

digでは名前解決できるのにApplicationから接続できない場合は、getentの結果や/etc/nsswitch.confの設定も確認します。

getentはName Service Switch（NSS）を使用して名前解決を行うため、/etc/nsswitch.confに定義された名前解決の設定も確認できます。

以下のコマンドを実行することで、/etc/nsswitch.conf の hosts に設定された名前解決の仕組みに従って、ホスト名の名前解決結果を確認できます。

# getent hosts <Host Name>

getentコマンド表示例：

続いてnsswitch.confの設定を確認します。

grep '^hosts:' /etc/nsswitch.conf

nsswitch.conf 表示例：

上記の例では、files（/etc/hosts）、dns、myhostname の順に名前解決を行うよう設定されています。

② DNS設定を確認する

名前解決に失敗している場合は、Clientが使用しているDNS Serverを確認します。

/etc/resolv.confの設定内容を確認し、nameserverに想定したDNS ServerのIP Addressが設定されているか確認します。また、searchなどのDomain設定も確認します。

# cat /etc/resolv.conf

resolv.conf 表示例：

上記の例では、corp.example.local がSearch Domainとして設定され、192.0.2.10 と 192.0.2.11 がDNS Serverとして設定されています。

Search Domainとは、ホスト名を省略して指定したときに、自動的に補完して名前解決を試みるDomainです。

③ DNS Serverへの経路を確認する

DNS Serverの設定を確認したら、DNS ServerへのRouteを確認します。

# ip route get <DNSサーバのIPアドレス>

ip route get コマンドの表示例：

実行結果から、DNS Serverへの通信で使用されるRoute、Output Interface、Next Hop、Source IP Addressを確認します。必要に応じてpingも使用しますが、ICMPが拒否されている環境もあるため、pingの失敗だけでDNS Serverと通信できないとは判断しません。

④ DNS Query / Responseを確認する

DNS Serverを指定してDNS Queryを送信します。

# dig @<DNSサーバのIPアドレス> example.com

digコマンドの出力例：

Packet単位で確認する場合は、tcpdumpでDNS QueryとResponseを確認します。

# tcpdump -ni any port 53

tcpdump表示例：

ClientからDNS Queryが送信されているか、DNS ServerからResponseが返っているかを確認します。Queryが出ていない場合はClient側、Queryは出ているがResponseがない場合はRoute、Firewall、DNS Server、ResponseにDNS Errorが含まれる場合はDNS Server側を確認します。

DNSではUDP Port 53が使用されることが多いですが、TCP Port 53が使用される場合もあります。FirewallやNetworkの設定を確認する場合は、UDP Port 53だけを前提にせずTCP Port 53も確認します。

⑤ DNS Server側を確認する

ClientからDNS Queryが送信され、DNS ServerからResponseも返っている場合は、DNS Server側を確認します。DNS Record、Zone、Forwarder、上位DNS Serverへの問い合わせ、DNS ServerのLogを確認します。

特定のHostnameだけNXDOMAINになる場合は、問い合わせているHostnameやDNS Recordを確認します。外部Domainへの問い合わせでSERVFAILが発生している場合は、Forwarderや上位DNS Serverへの問い合わせも確認します。

Packetから原因を追う

Interface、IP Address、Route、Neighbor、Socketまで確認しても原因が特定できない場合や、それまでの調査で立てた仮説をPacketレベルで検証したい場合はtcpdumpを利用します。

tcpdumpは、原因を探すための最初のコマンドではなく、ARP / NDP応答、TCP Handshake、RST、Retransmissionなど、それまでの調査で立てた仮説を確認するために使うと効果的です。「とりあえず全PacketをCaptureする」のではなく、何を確認したいのかを決めてから取得します。

ARPを確認する

ARP Requestは送信されているか、ARP Replyが返ってきているかを確認します。

# tcpdump -ni any arp

tcpdump コマンド出力例：

TCP 3-way Handshakeを確認する

# tcpdump -ni eth0 host 192.168.1.30 and port 443

tcpdumpコマンド表示例：

SYNは送信されているのにSYN / ACKが返ってこない場合は、Server側、途中のFirewall、Network機器などを確認します。

RST / Retransmissionを確認する

RSTが返っている場合はPort Listen状態やApplicationを確認します。同じSequence NumberのSegmentが再送されている場合はPacket LossやACK未達を疑います。

Application / OS / Network機器までEnd-to-Endで原因を追う

Linuxサーバ上でip、ss、ping、traceroute、tcpdumpなどを確認しても明確な異常が見つからない場合は、調査範囲をApplication、Firewall、Load Balancer、Virtualization基盤、Network機器まで広げます。

Network障害では、実際にはNetworkそのものではなく、Application側の処理遅延やConnection枯渇が原因になっているケースもあります。そのため、LinuxサーバのNetworkだけを見て調査を終わらせず、通信経路全体を確認することが重要です。

Applicationを確認する

まず、通信先となるApplicationが正常に動作しているかを確認します。

• Application Processが起動しているか
• 対象PortをLISTENしているか
• Connection Poolが枯渇していないか
• Thread Poolが枯渇していないか
• Application内部の処理が遅延していないか
• Application LogにTimeoutやConnection Errorが出ていないか

Processが起動していることだけでは、Applicationが正常とは限りません。

たとえば、Web ApplicationがTCP PortをLISTENしていてTCP Connectionも正常に確立できていても、Thread PoolやConnection Poolが枯渇していればRequest処理が開始できず、Responseが返るまで長時間待たされることがあります。

このような場合、利用者から見ると「Networkが遅い」「通信がTimeoutした」ように見えます。そのため、Network障害を調査するときは、TCP Connectionが確立できているかだけでなく、その後Applicationが正常にRequestを処理できているかまで確認します。

ss -lntp

特定Portを確認する場合は、次のように絞り込みます。

ss -lntp | grep :8080

ss -lntp コマンド表示例：

Application Logでは、次のようなKeywordを確認します。

timeout
connection refused
connection reset
connection pool
thread pool
too many connections

Firewallを確認する

Host Firewallによって通信が遮断されていないか確認します。firewalldを利用している場合は、次のCommandで現在の設定を確認できます。

firewall-cmd --list-all

nftablesを利用している場合は、Rule全体を確認します。

nft list ruleset

確認するポイントは、対象IP Address、Port、Protocolに対する通信が許可されているかです。また、Linuxサーバ自身のFirewallだけではなく、通信経路上にNetwork FirewallやSecurity Applianceが存在する場合は、それらのRuleも確認する必要があります。

TCPのSYN Packetは送信されているのにResponseが返ってこない場合などは、途中のFirewallでPacketがDropされている可能性も考えます。

Load Balancer / Reverse Proxyを確認する

Applicationの前段にLoad BalancerやReverse Proxyが存在する場合は、その機器やSoftwareも調査対象になります。

• Health Checkが成功しているか
• Backend Serverが正常として認識されているか
• BackendへのConnectionが確立できているか
• Connection数が上限に達していないか
• Idle Timeoutが短すぎないか
• Connect TimeoutやResponse Timeoutが発生していないか
• 特定BackendにTrafficが偏っていないか

たとえば、ClientからLoad Balancerまでは正常でも、Load BalancerからBackend Serverへの通信でTimeoutしているケースがあります。この場合、Client側から見ると単純なResponse Timeoutに見えるため、Load BalancerのAccess LogやError Log、Backend Connectionの状態も合わせて確認します。

Reverse ProxyとしてApache HTTP ServerやNginxを使用している場合も同様です。

どの区間で通信が止まっているのかを切り分けることが重要です。

Network機器 / Virtualization / Cloudを確認する

Linuxサーバ側で問題が確認できない場合は、通信経路上のNetwork機器やVirtualization基盤まで調査範囲を広げます。

• L2 Switch
• L3 Switch
• Router
• Firewall
• Load Balancer
• Physical NIC
• Hypervisor
• Virtual Switch
• Cloud Network
• VPN / Dedicated Line

たとえばVirtual Machineでは、Guest OS上のeth0にErrorやDropが発生していなくても、Hypervisor側のVirtual SwitchやPhysical NICでPacket Dropが発生している可能性があります。

Guest OSだけを確認して「Networkに問題なし」と判断しないことが重要です。Network機器では、InterfaceのError、Drop、Discard、CRC Error、帯域使用率などを確認します。

Cloud環境であれば、Security Group、Network ACL、Route Table、Load Balancer、NAT Gatewayなども調査対象になります。

OS / Kernel Logを確認する

Network InterfaceやDriver、Kernel内部で異常が発生していないか、OS / Kernel Logも確認します。

journalctl -k

Network関連のMessageに絞る場合は、次のように確認できます。

dmesg -T | grep -i -E "link|eth|net|nic"

特に確認したいのは、次のようなMessageです。

link down
link up
NIC reset
TX timeout
driver error
firmware error
NETDEV WATCHDOG

たとえばNIC Driverで一時的なResetが発生すると、その間だけPacket送受信が止まり、Application側ではTimeoutとして観測されることがあります。tcpdumpでは通信断の結果しか見えないこともあるため、Kernel Logと時刻を突き合わせて確認します。

Network障害時の暫定対処

Network障害によるサービス影響が継続している場合は、原因調査と並行して暫定対処を検討します。

ただし、Network障害では再起動やRoute変更を実施すると、障害発生時の状態が変化してEvidenceを失うことがあります。可能な限り、次の情報を取得してから対処します。

ip addr
ip route
ip neighbor
ss
ethtool
journalctl
tcpdump
Application Log

特に再起動やNetwork設定変更を行う場合は、実施前後の状態を記録しておくことが重要です。

Application / Serviceを再起動する

Application ProcessやNetwork Connectionが異常な状態になっている場合、Service再起動によって復旧することがあります。

systemctl restart <service>

ただし、「再起動したら直った」で調査を終了すると、根本原因が分からなくなる可能性があります。再起動前に、Process状態、Connection数、Thread数、Logなどを取得しておきます。

また、再起動によって既存Connectionが切断されるため、サービス影響も考慮して実施します。

Routeを修正する

誤ったRouteが設定されている場合は、正しいRouteへ修正します。Routeを変更する場合は、設計上の正しいNext HopやInterfaceを確認してから実施します。

ip route add 192.168.100.0/24 via 192.168.1.254 dev eth0

上記は、一時的にip routeで設定変更するコマンドです。OS再起動やNetworkManager再接続によって消える場合があります。そのため、復旧後はNetworkManagerなどの恒久設定を変更します。

Neighbor Cacheを再解決する

ARPやNDPによるNeighbor情報が不正な状態になっている場合は、Neighbor Cacheを削除して再解決させることで復旧することがあります。

特定Entryを削除する場合は次のように実行します。

ip neigh del 192.168.1.1 dev eth0

削除後、次回通信時にARPまたはNDPによってMAC Addressが再解決されます。

ただし、Neighbor Cacheそのものが重要なEvidenceになるケースがあります。たとえばFAILED、INCOMPLETE、STALEなどのStateが確認できることがあるため、削除する前に必ず状態を記録しておきます。

冗長系・別経路へ切り替える

Network機器、回線、特定Nodeなどに障害が発生していることが明確な場合は、正常系へTrafficを切り替えることでサービスを復旧できる場合があります。

• Standby回線へ切り替える
• 冗長Router / Firewallへ切り替える
• 問題のあるBackend ServerをLoad Balancerから切り離す
• 別Availability ZoneへTrafficを迂回する
• 問題のあるNodeをClusterから切り離す
• 別Network経路へRoutingを変更する

この場合も、切り替え前に障害経路の状態を取得しておくことが重要です。復旧を優先しつつ、後から原因分析できるEvidenceを可能な限り残します。

Network障害の恒久対処

障害復旧後は、同じ問題が再発しないように恒久対処を実施します。単純に障害箇所だけを修正するのではなく、Routing、Timeout、Connection、Firewall、DNS、Capacity、監視まで含めてNetwork全体を見直します。

Routing設計を見直す

Static RouteやDefault Routeが適切か確認します。特に複数NICや複数Gatewayを持つServerでは、想定外のInterfaceからPacketが送信されることがあります。

• Static Route
• Default Route
• Redundant Route
• Policy Routing
• Asymmetric Routing

障害時にも正常な経路へ切り替えられる設計になっているか確認します。

Timeout / Retry設計を見直す

Network障害が発生した際に、Applicationが過剰にRetryすると、障害をさらに悪化させることがあります。

このようなRetry Stormを防ぐため、次の設定を見直します。

• Connect Timeout
• Read Timeout
• Retry回数
• Retry Interval
• Exponential Backoff

Network側だけでなくApplication側の設計も重要です。

Connection設計を見直す

Connection数やPool Sizeが適切か確認します。

• Connection Pool
• KeepAlive
• Backend Connection数
• Application Thread数
• File Descriptor上限
• Load Balancer Connection上限

Application、OS、Load Balancer、Backendそれぞれの上限値が整合している必要があります。たとえばApplicationが10,000 Connectionを生成できても、Load Balancer側のConnection上限が5,000であれば、そこでBottle Neckになります。

Firewall / Load Balancer設計を見直す

FirewallやLoad Balancerでは、単純なPort許可だけでなくTimeoutやSession管理も確認します。

• Port / Protocol
• Session Table容量
• Idle Timeout
• Connect Timeout
• Health Check
• Backend Server数
• Redundancy

長時間Connectionを維持するApplicationでは、Load BalancerやFirewallのIdle TimeoutによってConnectionが切断されることがあります。Application側のKeepAlive設定とNetwork機器側のTimeout設定を合わせて確認します。

DNS設計を見直す

DNS障害がService全体に影響する構成になっていないか確認します。

• 複数DNS Serverの利用
• DNS ServerまでのNetwork経路
• TTL
• DNS Cache
• Resolver Timeout
• Retry設定

DNS Serverそのものを冗長化していても、同じNetwork経路上に配置されている場合、Network障害によって両方へ到達できなくなることがあります。Server冗長化だけでなく、Network経路も含めた冗長化を検討します。

CapacityとNetwork品質を継続監視する

Network障害は完全な通信断だけではありません。Packet DropやRetransmissionの増加によって、徐々にPerformanceが悪化するケースもあります。

• Network帯域使用率
• Packet Drop
• Packet Error
• TCP Retransmission
• Connection数
• Connection Error
• NIC Error / Drop
• Firewall Session数
• Load Balancer Connection数

正常時のBaselineを把握しておくと、障害時に「通常と何が違うのか」を判断しやすくなります。

Network障害では、Application、OS、NIC、Virtualization、Network機器を個別に見るのではなく、End-to-Endの通信経路として確認することが重要です。

まとめ

LinuxのNetworkトラブルシューティングでは、いきなりPacket Captureから始めるのではなく、通信経路をLayerごとに確認していくことが重要です。

1. Interface / Link：ip link、ethtool、ip -s linkでNICとLink状態を確認し、sar -n DEV / EDEVでTraffic、Error、Dropの推移を確認する。
2. IP Address：ip addrでIP AddressとPrefix Lengthを確認する。
3. Routing：ip routeとip route getで実際の経路、Output Interface、Next Hopを確認する。
4. Neighbor：ip neighborで同一Subnet上の宛先やNext HopのMAC Address、Neighbor Stateを確認する。
5. TCP / Socket：ssでLISTEN状態やConnection State、nstatでRetransmissionを確認する。
6. DNS：dig、getent、resolv.conf、ip route get、tcpdumpで名前解決とDNS Query / Responseを確認する。
7. Packet：tcpdumpでARP / NDP、TCP Handshake、RST、Retransmissionを確認し、これまでの仮説をPacketレベルで検証する。
8. Application / Network機器：Linuxだけで原因が見つからない場合は調査範囲を広げる。

Network障害では、初動確認 → Link / IP → Route / Neighbor → TCP / Socket → DNS → Packet → Application / Network機器 → 暫定対処 → 恒久対処の順に確認することで、「どこまでは正常で、どこから先がおかしいのか」を効率的に特定できます。

個々のコマンドを暗記するよりも、通信が成立するまでの流れを理解し、その流れに沿って調査することが、Networkトラブルシューティングでは最も重要です。