服务器网络异常的核心排查思路是“先定位、后重启”：多数情况下问题不在系统本身，而是出在链路、路由或机房侧，按顺序检查五分钟内就能缩小故障范围。
很多朋友遇到服务器网络异常，第一反应就是重启或者重装系统，实际上骨干网络出问题的概率远低于本地配置，盲目重启不仅浪费时间，还可能把现场的诊断线索弄丢，下面这套流程，按故障概率从高到低排列,照着走一遍就行。
服务器ping不通什么原因？先分清故障边界
服务器ping不通，背后可能是四种完全不同的故障，一张表帮你快速对号入座,看看你踩的是哪一种。
| 故障现象 | 可能根源 | 排查方向 |
|---|---|---|
| 服务器完全ping不通 | 机房断网、网卡故障 | 工单联系机房 |
| 内网能ping通，外网不行 | 防火墙策略、安全组限制 | 检查入站规则 |
| ping有延迟和丢包 | 链路拥堵、被攻击 | 看带宽占用 |
| 域名ping不通、IP能通 | DNS解析问题 | 检查解析记录 |
先做“边界二分法”测试
打开命令行，依次执行下面三条指令,每一条都能砍掉一层故障可能。
ping 服务器内网网关：不通,问题在机房内部网络；ping 公网IP：通但延迟高,问题在中间链路；ping 域名：IP通域名不通,问题在DNS解析。
服务器本地网卡状态怎么看
执行 ip addr 查看网卡有没有 state UP 标记，有些时候服务器运行时间长了，网卡驱动或物理接口会进入异常状态，显示 DOWN 或者 no carrier,遇到这种就基本锁定问题了。
服务器网络异常怎么解决？三步定位法实操
如果服务器还能登录，网络却没响应，多数情况下是应用层或系统层的配置问题，按下面的顺序走一遍,比瞎猜靠谱得多。
第一步：确认服务端口是否真的在监听
很多朋友把服务启动了，但忘了端口根本没起来，用 netstat -tlnp 查看当前监听端口，确认目标服务的端口处于 LISTEN 状态，如果端口不在列表里，那就是服务本身的问题,跟网络无关。
第二步：用telnet测试端口连通性
在本机执行 telnet 服务器IP 端口号，比如测试web服务就是 telnet 你的IP 80。能通表示链路没问题，不通则可能是防火墙策略拦截了入站连接，这一步会直接帮你把故障从“网络问题”扭转到“安全策略问题”。
第三步：检查防火墙和安全组
服务器上的 firewalld 或 iptables，与云平台的安全组，两边都是独立生效的，任意一边拦了都连不上，先运行 systemctl status firewalld 看看防火墙状态，再检查入站规则里有没有放行对应端口，排查完别忘了看一眼云控制台的安全组入站规则,这一步经常被人忽略。
有个典型的场景：用户反馈网站时不时打不开，登录服务器看到大量 TIME_WAIT 连接，最后发现是安全组规则把来自CDN节点的回源请求拦了。这类问题从服务器日志里看不出来，必须结合安全组策略一起查。
排完之后还得做一件事
如果你是通过修改防火墙规则解决的，建议顺手执行 firewall-cmd --reload 让规则彻底生效，别问为什么，问就是很多人改完不重载,白忙活半小时。
服务器网络延迟高怎么办？从链路逐段诊断
延迟高和ping不通是两回事ping不通是彻底断线，延迟高是数据包在路上的某一环被拖慢了，这个模块解决“连得上但很卡”的场景。
先用持续ping判断延迟是否稳定
执行 ping -t（Windows）或 ping 目标IP 持续10秒，观察延迟数字，如果延迟数值来回跳动超过50ms，多半是中间某台设备或者链路在排队。延迟稳定在同一个高值，则大概率是国际线路或跨网线路绕路导致的。
用tracert或MTR定位瓶颈节点
Windows下用 tracert 目标IP，Linux下用 mtr 目标IP，输出结果会列出每一跳的路由节点，延迟在哪一跳突然飙升，问题就出在哪一段链路，如果国内机房之间出现高延迟，常见原因是跨运营商访问移动用户访问电信机房，绕一圈的延迟自然下不来，行业共识认为，跨网高延迟多数属于BGP路由绕行问题,考虑用CDN或BGP多线机房缓解。
另一个容易被忽略的现象是本地网络误判，有用户反馈“服务器网络延迟高怎么办”，排查半天发现是笔记本连着Wi-Fi测试，无线信号本身就不稳定。测试链路质量务必用有线连接,否则ping出来的抖动数据没有参考价值。
别忽略网卡协商模式
登录服务器执行 ethtool eth0，查看 Speed 和 Duplex 字段，如果显示 10Mb/s 或者 Half，说明网卡和交换机协商出了问题，这种情况多见于老旧服务器或劣质网线，排查链路半天的延迟问题，最后发现是网线老化的情况并不少见。
服务器网络连接重置怎么解决？区分攻击与应用层问题
连接重置这个表现很迷惑人：网页偶尔能打开，刷新一下又报错，过一会儿又恢复，这类问题的排查方向往往不在网络硬件,而在系统资源或安全策略。
看连接状态判断是否被攻击
登录服务器执行 netstat -ant | awk '{print $6}' | sort | uniq -c 统计连接状态，如果大量出现 SYN_RECV 或 TIME_WAIT 状态，说明有大流量连接在占满系统资源。结合带宽监控看，如果入口带宽接近上限，基本就是被流量攻击打满了。
调整系统连接数限制
查看 /etc/sysctl.conf 里的 net.ipv4.tcp_max_syn_backlog 和 net.core.somaxconn 参数，这两个值太小，普通大促流量也会造成连接重置，调大后执行 sysctl -p 生效，注意，改之前先确认不是攻击行为，否则等于主动帮攻击者加资源。
防火墙与DDoS防护的误拦
另一个常见原因是防火墙本身的会话表溢出，部分低配硬件防火墙的会话数上限只有几万，流量稍微一冲，新连接就被直接重置，遇到这种情况，多数厂商的做法是开启云端DDoS高防，或直接在机房侧做流量清洗,单纯调服务器参数没用。
服务器网络异常怎么避免？日常运维的几个习惯
排查问题不如防住问题，养成下面几个习惯，后续“服务器网络异常”出现的频率会肉眼可见地下降。
- 重要服务器配置双网卡或备用链路,机房物理线路故障时自动切换；
- 定期执行
dmesg | grep eth检查网卡错误日志； - 给服务器配一套免费的监控告警，断网第一时间知道,而不是等用户投诉；
- 变更防火墙或路由配置前,先备份配置文件并记录操作日志。
Q&A：服务器网络异常相关问题
云服务器和物理服务器网络异常的排查顺序有区别吗？
有区别，云服务器要先查安全组和虚拟交换机状态，物理服务器要先查机房端口和物理链路，其余应用层排查步骤完全一致，云服务器的网络底层默认高可用，出问题先怀疑自己的安全组配置,物理服务器则更多关注硬件链路和机房线路质量。
服务器网络异常丢包严重怎么定位？
先明确丢包发生在本地网卡、中间路由还是服务端，本地用 ip -s link 查看网卡丢包统计，中间用MTR看每一跳丢包率，服务端看网卡和连接队列溢出。丢包集中在某一跳，问题就在那一跳前后的物理链路或设备上；丢包分散在各段,往往是源端带宽被打满。
网站时通时断是服务器网络问题还是域名解析问题？
如果直接访问服务器IP地址稳定，通过域名访问时通时断，问题指向DNS解析或CDN节点，执行 nslookup 域名 检查解析出的IP是否在多个节点之间跳动，如果是，说明运营商在DNS层做了调度或缓存，如果IP访问也不稳定，则回到链路和设备层面排查，多数时通时断的案例，最终定位到防火墙会话表溢出或本地网络波动,而非域名环节。