服务器联网10分钟就死机，多数情况下是系统配置问题而非硬件故障，重点排查网卡驱动、内核参数和网络协议栈。
作为常年和服务器打交道的运维,遇到"一联网就死机、断网就安静"的这种怪病，第一反应确实容易怀疑硬件，但行业共识认为，这类带明显触发条件（联网才死机）的故障，八成以上都出在操作系统和软件配置层面，纯硬件损坏导致的比例并不高，下面用具体场景一步步拆解，帮你把问题定位到根上。
服务器死机是怎么回事：先从故障触发条件找线索
死机分两种：一种是无差别死机，开机就卡、不操作也卡，这种确实优先怀疑CPU、内存、主板电容等硬件，另一种就是你说的这种平时好好的，一联网跑流量就死，断网就恢复正常，这种有明确触发条件的故障，排查思路完全不同。
联网死机的典型特征：
- 网卡一收到数据包,系统负载就飙升。
- 内部服务（Nginx、MySQL）压力不大，但只要外部流量一进来就卡死。
- 拔掉网线或断开网络连接,服务器又能稳定运行很长时间。
- 死机时屏幕或日志会出现网络相关的报错信息。
遇到这种情况,先把CPU、内存、硬盘的硬件故障怀疑往后放一放，硬件的损坏通常是不可逆的，不会给你"拔线就好、插线就坏"这么规律的表现。
服务器死机排查步骤：先查配置再查硬件
节奏上,先花80%的精力在系统配置上，因为这类问题九成都能在配置和驱动层面找到答案。
第一步：检查网卡驱动和固件版本
网卡驱动和内核模块不匹配,是导致"联网死机"的头号原因，尤其是使用Realtek、Intel I219、以及市面上常见的板载2.5G网卡型号，驱动问题非常普遍。
排查路径：
- 查看当前网卡型号：
lspci | grep -i ethernet - 查看当前使用的驱动版本：
ethtool -i eth0 - 对比网卡厂商官网的驱动支持列表,看是否存在已知的兼容性问题。
实操建议：如果用的是主流发行版（Ubuntu、CentOS、Debian），优先安装官方内核自带的驱动模块，不要自己去网卡官网下载源码编译，编译安装虽然性能好，但一旦内核升级，驱动模块不匹配就会引发中断风暴（IRQ storm），这在行业里是相当常见的死机诱因。
第二步：看内核日志和系统消息
死机前系统会留下痕迹,登录服务器后（如果还能登录），马上执行：
dmesg -T | tail -50 journalctl -k -f
重点观察有没有以下关键词：
watchdog: BUG: soft lockup说明某个CPU核心被锁死kernel: INFO: task blocked for more than 120 seconds进程被网卡中断卡住eth0: Detected Hardware Unit Hang网卡硬件单元挂起NMI watchdog硬锁死，这往往是驱动或硬件协同问题
出现以上任意一种,都和网卡驱动、中断处理机制有直接关系，此时先把网卡的多队列（RSS）关闭试试：ethtool -L eth0 combined 1，将队列数降到1后再观察是否复现死机，不少案例证实，问题就出在多队列与CPU自动调频（cpufreq）之间的调度冲突上。
第三步：检查内存和交换分区配置
联网服务跑起来后,内存压力会骤增，如果系统配置了较小的swap或错误的swappiness参数，内存回收机制可能在网络高负载时产生死锁。
执行以下命令看内存状态：
free -h cat /proc/sys/vm/swappiness
如果free显示可用内存很少，而swappiness高于60，那么网络流量增大时系统会频繁进行内存换页，极端情况下导致卡死，建议调整为10左右：
sysctl -w vm.swappiness=10 echo 'vm.swappiness=10' >> /etc/sysctl.conf
再看硬件健康状态
排除配置问题后,硬件排查集中在网卡和PCIe通道上：
- 用
smartctl -a /dev/sda查硬盘健康状态，排除磁盘坏道干扰。 - 用
ethtool -S eth0查看网卡错误计数，重点看crc_errors、rx_errors、tx_timeout这三项，如果tx_timeout持续增加，说明网卡芯片过热或供电不稳。 - 使用
mcelog --daemon记录机器检查异常（Machine Check Exception）事件，这是CPU和内存硬件层面的权威日志来源。
硬件层面的死机通常不做修复,直接更换部件，但在此之前，务必备份好系统日志和配置，作为售后维修时的判断依据。
系统和网络侧的隐性配置坑
排查完上述步骤,另一个常见死机场景藏在TCP/IP协议栈和防火墙规则里。
SYN洪水攻击防护与半连接队列溢出
服务器联网后,如果对外提供服务（尤其Web服务），那么在遭遇较大规模连接请求时，系统默认的半连接队列很容易被打满，内核参数net.ipv4.tcp_max_syn_backlog设置过小，加上net.core.somaxconn默认值太低，就可能导致系统在大量网络连接涌入时直接假死。
调整路径：
sysctl -w net.core.somaxconn=1024 sysctl -w net.ipv4.tcp_max_syn_backlog=4096
这个操作称为"优化内核网络参数"，但注意，参数的调整需结合业务实际并发量，不能盲目设置过大，否则反而增加内存开销，诱发其他问题。
网卡节能模式和中断合并（Coalesce）
联网死机的另一大根源就是网卡的节能机制,服务器网卡默认开启了电源管理节能（如ethtool --set-eee、ASPM链路节能），当网络流量从低负载突然升高时，网卡从休眠状态唤醒不及时，导致驱动超时触发看门狗复位，表现为死机或断网重启。
排查和关闭方法：
ethtool --show-eee eth0 ethtool --set-eee eth0 eee off
同时进入BIOS,关闭ASPM（Active State Power Management）和CPU的C-States低功耗状态，很多企业服务器在机房长期运行，电源策略设为"省电模式"而不自知，这个问题直接影响网卡的实时响应能力。
把"硬件故障"帽子的最后一道测试用iperf3压测
如果你已经做完上面所有排查仍未定位问题,用iperf3做一次网络压力测试，能帮你区分是网卡/交换机链路问题还是主机系统问题，方法：
- 找一台同网段的电脑作为服务端：
iperf3 -s - 在故障服务器上运行：
iperf3 -c <对端IP> -t 300 -i 10
如果在压测过程死机,抓取dmesg输出看是否与TCP卸载（TSO/GRO）相关，临时的验证手段是关掉TSO：
ethtool -K eth0 tso off gso off gro off
关闭后如果死机不再复现,那问题的根源基本锁定在网卡卸载引擎与内核协议的兼容性上。
按照不同场景定制的解决思路
新买的二手服务器或组装机频繁死机
这种情况在深圳机房的朋友那里很常见,尤其是购买渠道不明的机器，多半是机房内的供电波动和网卡发热导致的不稳定，拿万用表测一下服务器电源电压是否稳定，必要时加装稳压模块。
物理机托管机房，一上业务就死
关注防火墙规则数量,如果你配置了iptables或nftables规则，怀疑规则引擎处理吞吐量不足导致CPU软中断满载：
top -c # 查看si（软中断）百分比
如果si占比超过30%，说明网络数据包处理已耗尽CPU资源，死机只是时间问题，对策是简化防火墙链规则，或升级dpdk / 硬加速网卡。
虚拟机平台上的虚机联网即死
宿主机网卡的虚拟化队列（virtio）配置不当是最常见原因，把虚拟网卡的队列数从多队列改为单队列，并关闭宿主机侧的TCP校验和卸载，通常能解决大多数"开机正常、联网死机"的虚机问题。
Q：服务器死机问题排查的常见疑问
Q：反复死机后重启，数据会丢吗？
取决于死机时是否有未落盘的数据，一般Web服务无大碍，但如果正在写数据库，MySQL的redo log未同步则可能丢少量数据，建议配置定期备份，并用fsck检查文件系统完整性。
Q：排查服务器死机问题大概要花多少钱？
系统排查的费用如果请外包运维工程师现场处理，按二线城市行情大概在300到800元/次，一线城市贵一些，这里建议先自己按上文步骤排查一轮，因为动手改配置的成本为零，硬件更换费用另算，一块普通Intel服务器网卡大约在200至500元区间。
Q：如果所有配置都查过了仍然死机，还要不要考虑硬件？
需要考虑硬件，但此时可以缩小到主板供电模块和网卡金手指氧化这两类问题上，拔下网卡，用橡皮擦清洁金手指后重新插紧，能解决相当一部分偶发性死机问题。
回到最初的问题：服务器联网10分钟就死机，硬件故障和系统配置这两个方向上，建议把系统配置问题作为优先排查对象，尤其是网卡驱动、内核网络参数、节能策略这三类配置项，发生频率远高于物理损坏，按本文列出的步骤逐项排查，多数情况能在不更换任何配件的情况下解决问题。