error_log不直接记录网卡阻塞，但通过errno 99（cannot assign requested address）、113（no route to host）、110（connection timed out）和104（connection reset by peer）等错误可间接定位接口阻塞根源，需结合ss、/proc/net/snmp、ethtool及tcpdump交叉验证。
error_log 本身不直接记录“网络接口阻塞”这类底层网卡或内核收发队列问题，但它会暴露因接口阻塞引发的上层连接行为异常，是诊断链路中断的关键线索入口。真正有价值的，是日志中反复出现的、与连接建立失败或传输中断强相关的 errno 编码和错误描述。
error_log 中可作为接口阻塞间接依据的典型报错
connect() failed (99: Cannot assign requested address)
表明本地 ephemeral 端口耗尽，常因net.ipv4.ip_local_port_range过窄或短连接并发过高导致。这不是网卡阻塞，但反映本地出口资源枯竭，系统已无法发起新连接——本质是网络栈出口被“堵住”。connect() failed (113: No route to host)
若集中出现在特定目标 IP（如某台后端机器），且ss -i显示大量retrans或rto异常，可能指向路由路径中某接口丢包严重或 MTU 不匹配，触发内核判定“不可达”。upstream timed out (110: Connection timed out)+while connecting to upstream
非单次超时，而是持续、批量出现，且ping基本通、telnet却极不稳定，需怀疑中间网络设备（如防火墙、负载均衡器）接口拥塞或限速，导致 SYN 包延迟或丢失。recv() failed (104: Connection reset by peer)大量突增，且伴随upstream_addr固定为某 IP:port
可能是该上游所在宿主机的接收队列溢出（rx queue full），内核被迫丢弃 TCP 包并回 RST；ethtool -S eth0 | grep rx_可验证rx_fifo_errors或rx_missed_errors是否飙升。
配合 error_log 必须做的三类交叉验证
-
查内核网络状态：
-
ss -s看total、TCP:行是否显示mem高或orphan突增 -
cat /proc/net/snmp | grep -A1 Tcp关注AttemptFails、EstabResets -
sar -n DEV 1观察rxpck/s、txpck/s和%ifutil，确认物理接口是否持续满载
-
-
检查网卡驱动与队列：
-
ethtool eth0确认Speed、Duplex正常，无Link detected: no -
cat /proc/interrupts | grep eth0看中断是否集中在单个 CPU，可能引发软中断瓶颈 -
ip link show eth0查txqueuelen，过小（如默认 1000）在高吞吐下易丢包
-
-
排除中间设备干扰：
- 在 Nginx 机器抓包：
tcpdump -i eth0 'host 上游IP and port 上游端口' -w block.pcap，看是否有大量重传、dup ACK 或零窗口通告 - 登录上游机器，执行
nstat -z | grep -i "retrans|listen"，确认其接收侧是否已饱和
- 在 Nginx 机器抓包：
注意一个关键边界error_log 不会写“eth0 RX dropped 12345”，也不会报“ring buffer overflow”。它只记录 socket 层调用失败的结果。所以看到 errno 99 或 113，你要做的不是修日志，而是顺着它去查 netstat -s、/proc/net/dev 和 dmesg | tail —— 那里才有接口级阻塞的实锤。
