服务器网络怎么查？

一份全面且实用的服务器网络排查指南

在数字世界的底层，服务器如同永不疲倦的心脏，而网络便是将其生命力——数据——输送到四面八方的动脉血管，当业务流畅、访问如飞时，我们几乎感知不到它们的存在；可一旦出现延迟、丢包甚至服务中断，这错综复杂的网络世界瞬间便会化作一片亟待探索的迷雾之地。“服务器网络怎么查？”——这不仅是运维工程师的日常，更是每一位与服务器打交道的技术人必须掌握的核心技能，本文将摒弃空洞的理论，以实战为导向，带你深入这条“数据动脉”，一步步掌握从表象到根源的排查艺术。

第一章：征兆初现——明确问题与划定范围

排查的第一步永远不是盲目地输入命令，而是冷静地观察与分析，就像医生问诊，需要先了解症状。

1、症状收集：问题是什么？是用户反映“网站打不开”，还是监控系统报警“响应超时”？是特定地区用户无法访问，还是所有用户都遇到问题？是某个特定服务（如API接口）失败，还是整个服务器失联？准确的现象描述是定位问题的第一块基石。

2、划定范围：这是本地问题还是远程问题？快速在服务器本地执行ping 127.0.0.1（IPv4）或ping ::1（IPv6）， loopback 回环地址测试可以立刻验证服务器自身的TCP/IP协议栈是否工作正常，如果连自己都“ping不通”，那问题很可能出在系统内部，尝试 ping 服务器自身的局域网IP地址，这可以检查网络接口卡（NIC）和驱动的基本状态。

3、明确边界：问题出在服务器本身，还是网络链路上？尝试从服务器 ping 同一局域网下的另一台主机（比如网关），如果成功，说明局域网内部通信无虞；如果失败，则问题可能局限于服务器配置或本地交换机端口。

第二章：抽丝剥茧——本地服务器深度自查

如果初步判断问题可能出在服务器自身，那么就需要进行一场深入的“体检”。

1、接口状态确认（“网线插好了吗？”）

命令ip link show 或ifconfig（较老系统）

看什么首要确认目标网络接口（如eth0,ens192) 的状态是UP 而不是DOWN。LOWER_UP 则表示物理链路正常（相当于网线灯亮），如果状态不对，检查物理连接或使用ip link set eth0 up 尝试激活。

2、IP配置审查（“地址配置对了吗？”）

命令ip addr show 或ifconfig

看什么检查是否获取到了正确的IP地址、子网掩码（CIDR形式显示），如果是DHCP获取，看是否成功；如果是静态配置，核对是否输入错误，特别留意是否有重复的IP地址冲突。

3、路由表诊断（“路认识吗？”）

命令ip route show 或netstat -rn

看什么这是排查的重中之重，查看默认路由（default via ...）是否存在且指向正确的网关地址，检查是否有到特定网络的路由规则，是否存在多路径路由导致的选择异常。

4、本地端口与服务监听（“门开了吗？”）

命令netstat -tulnp 或ss -tulnp（更推荐，速度更快）

看什么确认你的服务进程（如Nginx, Tomcat, MySQL）是否正在预期的端口上监听（LISTEN 状态），Web服务器是否监听了0.0.0.0:80 或某个特定IP？如果只监听了127.0.0.1:3306，那么外部自然无法访问MySQL，防火墙很可能阻止了访问，但首先得确保服务本身“开了门”。

5、本地防火墙拦截（“保安让进吗？”）

这是最常见的问题根源之一，检查服务器本地的防火墙规则

FirewallD（CentOS/RHEL 7+）firewall-cmd --list-all

IPTablesiptables -L -n -v

UFW（Ubuntu）ufw status

* 查看是否放行了相应服务的端口，有时防火墙规则配置错误，甚至会拒绝来自局域网本身的访问。

第三章：顺藤摸瓜——网络链路追踪与性能分析

当服务器自查无误后，就需要走出服务器，沿着网络路径探寻了。

1、连通性测试基石：Ping

命令ping <目标IP或域名>

看什么能通吗？（有无回复）、延迟高吗？（time值）、稳定吗？（是否忽高忽低）、丢包吗？（packet loss），ping 网关、ping 公网DNS（如8.8.8.8）、ping 业务域名，逐级测试，在哪一跳开始失败，问题就可能出在哪一跳之后。注意：现代网络中，许多设备会禁ping（ICMP），ping不通不一定代表网络不通，但ping通了通常意味着底层网络是好的。

2、路径发现神器：Traceroute

命令traceroute <目标IP或域名> 或tracepath，Windows下是tracert

看什么它显示数据包到达目标所经过的每一跳（路由器），当网络不通或延迟很高时，traceroute 可以精准定位到故障发生的那一跳设备，某一跳之后全部显示为（超时），通常意味着问题就出在那台设备或链路上，它也能清晰展示网络路径是否符合预期，有无绕行。

3、DNS解析核查（“电话号码簿对吗？”）

命令nslookup <域名> 或dig <域名>

看什么服务访问通常是基于域名，检查域名是否能正确解析为预期的IP地址？解析速度是否过慢？DNS服务器（/etc/resolv.conf）配置是否正确？使用dig 可以看到更详细的解析过程，有助于判断是DNS服务器问题还是本地配置问题。

4、性能瓶颈探查：带宽与连接数

实时流量监控

命令iftop（查看实时网络带宽使用，哪个连接占用了最多流量）、nethogs（按进程查看流量）、ip -s link（查看接口统计信息，有无大量错误包、丢包）

连接数分析

命令ss -s（查看总连接统计）、netstat -an | grep :80 | wc -l（查看特定端口连接数）

看什么网络卡顿不一定是中断，可能是带宽被占满（iftop 看顶部的流量刻度），或者是服务器连接数过高达到极限（ss -s），也可能是网卡有大量的错误（RX/TX errors）。

第四章：高级武器库——综合工具与日志分析

对于复杂和深层问题，需要更强大的工具。

1、全能抓包分析：Tcpdump

命令tcpdump -i eth0 -w capture.pcap host <客户端IP> and port <服务端口>

怎么用当所有基础手段都无法定位时，抓包是终极真理，它记录网络上每一个数据包，你可以看到TCP三次握手是否完成？连接是否被重置（RST）？是否有应用层的数据交换？将抓取的pcap 文件下载到本地，用Wireshark 图形化工具进行深入分析，一切通信细节无所遁形。

2、日志——时代的目击者

查哪里

系统日志/var/log/messages，journalctl -u network.service（Systemd系统）

防火墙日志需要单独配置开启，记录被拒绝或丢弃的包。

服务自身日志如Nginx的access.log 和error.log，其中可能记录了连接超时、上游无法连接等关键错误信息。

看什么在出问题的时间点附近，日志中是否有异常记录？如 “Connection timed out”, “No route to host”, “Permission denied” 等，这些都是极佳的诊断线索。

面对服务器网络问题，切忌慌乱，请将上述过程内化为你的排查思维流程图：

1、现象定位：明确问题表现和范围。

2、本地自查：ip link ->ip addr ->ip route ->ss -tulnp ->防火墙规则，确保服务器自身“身强体健”。

3、链路追踪：ping 网关 ->ping 公网IP ->traceroute 目标 ->nslookup 域名，逐级向外，定位故障点。

4、性能剖析：iftop /nethogs 看流量，ss -s 看连接，ip -s 看错误。

5、深度挖掘：抓包 (tcpdump) 看真相，查日志找记录。

掌握这套方法论，你便能从容地面对大多数服务器网络问题，从一名被动的“救火队员”蜕变为主动的“系统侦探”，真正洞悉并驾驭那些在黑暗中奔腾的数据洪流，排查的关键在于大胆假设，小心求证，一步步缩小包围圈，最终精准命中问题根源。

文章摘自：https://idc.huochengrm.cn/fwq/13676.html