企业官网建设流程全解析

1. 当服务器突然断网：基础连通性排查三板斧

凌晨三点，运维工程师小王的手机突然响起刺耳的警报声——监控系统显示生产环境的Web服务器无法访问外网。这种突发状况就像半夜家里的电路跳闸，需要快速定位问题根源。以下是每个Linux运维人员都应该掌握的"急救三板斧"：

第一斧：用ping验证基础连通性

# 先检查本地网卡是否正常（相当于检查自家电路总闸） ping 127.0.0.1 -c 3 # 再ping网关地址（检查楼道电表） ping 192.168.1.1 -c 3 # 最后测试外网连通性（检查小区变电站） ping 8.8.8.8 -c 3

如果本地回环测试失败，可能是TCP/IP协议栈出了问题；网关不通则要检查本地网络配置；外网不通但网关通，可能是NAT或防火墙问题。我遇到过最诡异的情况是服务器能ping通网关但无法上网，最后发现是有人误删了默认路由。

第二斧：ifconfig/ip addr查看网卡状态

ip addr show eth0 # 重点检查三项： # 1. 是否有正确的IP地址（好比检查水表是否安装） # 2. 网卡状态是否为UP（相当于水阀是否打开） # 3. 是否有异常的错误计数（类似水表异常读数）

某次故障排查时，发现RX errors计数不断增长，最终确认是机房网线接口氧化导致的物理层故障。ethtool工具可以获取更详细的网卡信息：

ethtool eth0 | grep -E 'Speed|Duplex|Link'

第三斧：路由表检查

route -n # 或使用现代命令 ip route show

曾经有台服务器突然无法访问特定网段，就是因为路由表中缺少了关键的路由条目。就像快递员找不到去某小区的路线，包裹自然无法送达。

2. 网络卡顿元凶追踪：路由分析与流量监控

当应用响应缓慢时，问题可能出在网络链路的任何一个环节。这时候需要像侦探一样层层排查：

2.1 用traceroute/mtr绘制网络路径图

# 基本用法（相当于绘制快递运输路线图） traceroute www.baidu.com # 更强大的实时监控工具 mtr --report www.baidu.com

mtr工具结合了ping和traceroute的功能，能直观显示每一跳的丢包率。有次我们发现到某云服务的延迟突然增加，用mtr定位到是运营商中间某个节点拥塞，及时切换了线路。

2.2 用iftop揪出带宽大胃王

iftop -nNP -i eth0 # -n 不解析域名（显示更快） # -P 显示端口号（定位具体应用） # -N 不解析端口服务名

这个界面会实时显示网络连接和流量排名，就像查看家里每个电器的用电量。曾经用这个工具发现过异常的加密流量，最终定位到被入侵的服务器。

2.3 高级技巧：TCP连接状态分析

ss -ntp # 等效于老旧的netstat -ntp # 显示所有TCP连接及关联进程

重点关注：

• 大量的TIME_WAIT状态：可能是连接未正确关闭
• SYN_SENT堆积：目标不可达或防火墙拦截
• ESTABLISHED连接数异常：可能是连接泄漏

3. 深度协议分析：tcpdump实战技巧

当常规手段无法定位问题时，就需要祭出抓包神器tcpdump了。这就像给网络流量安装监控摄像头：

3.1 基础抓包命令

tcpdump -i eth0 -w /tmp/dump.pcap # -i 指定网卡 # -w 保存到文件（建议always） # 按Ctrl+C停止抓包

3.2 智能过滤技巧

# 只抓取HTTP流量 tcpdump -i eth0 'tcp port 80' # 抓取特定IP的交互 tcpdump -i eth0 'host 192.168.1.100' # 组合条件 tcpdump -i eth0 'src 192.168.1.100 and dst port 3306'

3.3 经典故障案例分析案例一：某次MySQL连接时快时慢，通过抓包发现TCP窗口大小频繁调整，最终确认是网卡驱动bug。

案例二：HTTP请求偶尔超时，抓包显示服务端没有及时返回SYN+ACK，原来是应用线程池被耗尽。

案例三：DNS解析随机失败，抓包发现UDP响应被中间网络设备丢弃，改用TCP协议后解决。

4. 端口与服务排查：看不见的守门人

网络连通但服务不可用？可能是端口层面的问题：

4.1 快速端口检测

# telnet基本检测（检查门是否开着） telnet 192.168.1.100 80 # 更专业的nc命令 nc -zv 192.168.1.100 1-1024

4.2 服务监听检查

ss -ltnp # 显示所有监听端口及对应进程 # -l 只显示监听状态 # -t TCP协议 # -n 不解析服务名 # -p 显示进程信息

曾遇到Nginx无法访问的情况，ss命令显示端口确实在监听，最后发现是SELinux策略阻止了连接。

4.3 防火墙规则检查

iptables -L -n -v # 查看所有规则及匹配计数 nft list ruleset # 新式防火墙配置

记住防火墙规则是有顺序的，就像大楼的多道安检门，数据包可能在任意一道门被拦下。

5. DNS问题排查：网络世界的导航系统

域名解析问题往往最隐蔽，也最让人头疼：

5.1 基础诊断工具

nslookup www.baidu.com dig www.baidu.com +trace # +trace显示完整解析过程

5.2 常见问题处理

• 解析超时：检查DNS服务器配置
• 解析错误：检查hosts文件或DNS劫持
• 解析慢：更换公共DNS如8.8.8.8

5.3 高级技巧：DNS缓存检查

# 查看systemd-resolved缓存 systemd-resolve --statistics # 清空DNS缓存 systemd-resolve --flush-caches

6. 性能调优：从被动排查到主动预防

6.1 网络性能基准测试

# 测试带宽 iperf3 -c 192.168.1.100 # 测试延迟 ping -f -c 1000 192.168.1.1

6.2 内核参数调优

# 查看当前配置 sysctl -a | grep net.ipv4 # 临时修改 sysctl -w net.ipv4.tcp_tw_reuse=1 # 永久生效写入/etc/sysctl.conf

6.3 日常监控建议

# 使用sar记录历史数据 sar -n DEV 1 60 > /tmp/network.log # 关键指标： # rxpck/s：接收包速率 # txpck/s：发送包速率 # rxkB/s：接收吞吐量 # txkB/s：发送吞吐量

在实际运维中，我养成了保存典型故障案例和对应命令的习惯。当遇到新问题时，先回忆是否有类似场景，再根据症状选择合适的工具层层深入。网络问题排查就像破案，既需要系统的方法论，也需要丰富的实战经验。