服务器查看网络和运行时间，核心就一句话：运行时间用uptime或last reboot命令查看，网络状态用ping、ss和netstat命令排查，实时流量则靠iftop监控。这套组合拳能解决95%以上的日常运维诊断需求，下面我把每个工具的使用场景和输出结果拆开讲清楚，保证你看完就能上手操作。
运行时间：服务器“活了多久”一看便知
uptime：最直接的答案
登录服务器后,敲下uptime，系统会返回一行信息，包含当前时间、运行时长、登录用户数和负载均值，这是查看服务器运行时间最常用的命令。
输出格式大致长这样：
14:32:10 up 86 days, 4:02, 1 user, load average: 0.08, 0.03, 0.05重点看up后面的数字，86 days, 4:02代表这台机器已经连续运行了86天4小时2分钟，如果显示up 3 min，说明服务器刚经历过重启。load average则是1分钟、5分钟、15分钟的平均负载，数值超过CPU核心数就说明系统可能过载。
who -b：查看系统本次开机时间
uptime告诉你运行了多久，但如果你想知道具体的开机时刻，用who -b：
who -b
system boot 2026-10-02 09:15输出直接显示系统本次启动的日期和时间,适合需要精确记录重启节点的场景，配合date命令对照当前时间，能快速算出运行时长。
last reboot：回顾历史重启记录
想排查服务器是否频繁重启,用last reboot查看完整重启日志：
reboot system boot 3.10.0-1160.el7 Tue Oct 2 09:15 still running
reboot system boot 3.10.0-1160.el7 Mon Sep 10 22:40 - Tue Oct 2 09:15 (21+10:35)输出按时间倒序排列,列出每一次系统启动的时间点和运行时长，如果列表密集，说明服务器近期不稳定，需要结合系统日志排查硬件或内核问题。last reboot读到的是/var/log/wtmp文件，只要日志未被清理，记录就一直存在。
top命令里的运行时间线索
top命令第一行同样包含up时间和负载信息，当你需要同时观察系统资源占用和运行时长时，top是比uptime更全面的入口，进入top界面后，第一行右侧显示的up X days就是运行时间，按q退出。
网络连接状态：服务器“跟谁在说话”全掌握
ping：基础连通性检查
判断服务器网络是否在线,ping是第一个要用的工具，它通过发送ICMP报文测试目标主机的响应能力。
ping -c 4 baidu.com-c 4表示发送4个包后自动停止，重点关注两个数值：丢包率和响应时间，如果显示0% packet loss，说明网络链路通畅；如果出现100% packet loss，则可能是网络中断、防火墙拦截或DNS解析失败，响应时间（time=20.1 ms）在多轮测试中波动过大，则说明链路质量不佳。
ss与netstat：查看服务器所有网络连接
想了解服务器当前建立了哪些连接、正在监听哪些端口，用ss或netstat。ss是netstat的替代方案，输出更快、信息更全，多数现代Linux发行版默认推荐使用。
ss -tulnp这条命令展示所有TCP/UDP监听端口及对应进程，输出中State为LISTEN表示正在监听，Local Address:Port是服务器开放的端口，Process列显示占用该端口的进程名称和PID，排查端口冲突或确认服务是否正常启动时，这条命令是关键。
查看所有活跃连接用：
ss -tunap它会列出服务器所有TCP/UDP连接，包括远端地址和状态，当怀疑服务器被入侵扫描或出现异常外联时，ss -tunap的输出能直观展示每一个连接的去向，配合grep过滤特定IP或端口，比如ss -tunap | grep 22查看SSH连接情况。
排查网络连接状态的实战顺序
遇到服务器网络异常,推荐的排查路径是：
- 先用
ping测网关（如ping 192.168.1.1），网关通说明物理链路正常 - 再
ping公网IP（如ping 223.5.5.5，阿里DNS），公网通说明路由正常 - 接着
ping域名（如ping baidu.com），域名通说明DNS解析正常 - 然后
ss -tulnp查看本机服务端口是否在监听 - 最后
ss -tunap | grep ESTAB查看实际建立的业务连接
这套流程从底层到上层依次排除,能快速定位是哪一层出了问题，业内专家指出，多数网络故障根源在于防火墙规则或服务未启动，而非物理链路中断。
网络延迟与丢包：服务器响应慢怎么查
ping延迟基线测试
服务器响应慢,先测延迟，连续执行多次ping（建议
ping -c 100）收集数据，正常数据中心内网延迟应低于1ms，同城跨机房约2-5ms，跨省公网延迟在20-50ms区间属于正常范围，如果ping内网网关延迟都超过10ms，说明网卡或交换机可能存在异常。
traceroute：定位延迟瓶颈段
ping只能告诉你整体延迟，想知道延迟出在哪一跳，用traceroute：
traceroute -n 223.5.5.5输出按跳数列出每一跳路由IP及响应耗时,星号（）表示该节点未响应，不代表网络中断，只是该路由器禁用了ICMP响应，重点观察哪一跳的延迟突然大幅跳升，比如从第3跳的8ms直接升到第5跳的80ms，瓶颈大概率在那一段网络链路。
mtr：综合延迟和丢包的利器
mtr结合了ping和traceroute的功能，持续输出每一跳的丢包率和延迟变化，安装命令根据系统不同有所区别，CentOS用yum install mtr，Ubuntu用apt install mtr。
mtr -n 223.5.5.5运行后,界面左侧是跳数，中间是各节点延迟，右侧是丢包率，如果最后一跳丢包较高但前面节点都正常，通常是目标服务器自身限制；如果中间某一跳持续丢包且后续节点也受影响，说明骨干网或运营商线路存在问题。
实时流量监控：服务器“带宽跑哪里去了”
iftop：实时带宽占用排行
服务器带宽跑满但不知道是谁在用,iftop能直接给出答案，安装方式同样是yum install iftop或apt install iftop，安装后执行：
iftop -i eth0-i指定监控的网卡，界面会实时刷新，按流量大小排序展示每个连接的带宽占用，左边是源IP，右边是目标IP，中间是流量速率条，按T键可以切换显示累计流量，按P键暂停刷新，按q退出，当发现某个陌生IP持续占用大量带宽时，需要警惕服务器是否被用于对外发包攻击。
nload：整体的进/出流量视图
如果你只关心总带宽使用情况,而不需要看每个连接的明细，nload更直观，执行nload后，界面分上下两块，上半部分显示入站流量，下半部分是出站流量，各有当前值、峰值、平均值和总流量，按F2可以切换网卡，按q退出。
数据中心运维场景：常见问题快查
服务器重启后运行时间清零但服务正常
uptime显示运行时间从0开始，但业务进程都正常，这通常是内核更新后自动重启所致，排查方法：执行last reboot | head -5查看重启时间点，再对照系统日志journalctl --since "重启时间"确认是否有内核升级记录，云服务器厂商维护底层宿主机时也可能触发实例迁移，导致运行时间重置。
服务器网络连接数过高
执行ss -s查看系统级连接统计，输出中的established表示已建立的连接数，time wait表示等待超时的连接数，当time wait数量远超established时，说明有大量短连接频繁建立和断开，常见原因是Web服务配置了过短的keep-alive或存在连接池泄漏，在/etc/sysctl.conf中调整net.ipv4.tcp_tw_reuse参数可以缓解该问题。
服务器网络延迟高且丢包但业务正常
多数情况下属于运营商线路拥塞或国际链路质量问题,验证方法是更换DNS解析到一个不同线路的IP，比如将域名解析到其他云服务商的IP，再用mtr对比两条路径的延迟和丢包，若两条路径表现差异明显，建议使用CDN或BGP多线机房来优化访问路径。
常见问题解答
服务器运行时间显示几十天，需要主动重启吗？
不需要,Linux系统设计上支持长期运行，只要内核和业务进程稳定，uptime显示200天以上也属于正常状态，强制重启反而可能引发文件系统不一致或业务中断，只有当系统出现内存泄漏、内核异常告警或安全补丁更新时，才需要计划内重启。
服务器查看网络连接用什么命令最合适？
日常诊断优先用ss，它是netstat的现代替代品，输出速度快且信息完整，需要查看进程名称时用ss -tulnp，需要分析实时连接时用ss -tunap，只有处理老系统或脚本兼容需求时才使用netstat，流量分析场景则用iftop查看实时速率，用nload查看整体带宽。
服务器网络延迟高如何自查？
先ping网关确认内网是否正常，再traceroute公网目标定位延迟发生段，最后用mtr持续观察丢包率，若内网延迟正常但公网延迟高，联系IDC服务商获取网络质量报告，云服务器用户优先检查安全组规则是否限制了对端IP的访问，其次确认实例规格的带宽上限是否被占满。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/690321.html
