网络告警需分层定位，先验证连通性（ping 8.8.8.8）和DNS解析（nslookup google.com 8.8.8.8），再查接口、路由、防火墙、安全组及SELinux策略，结合日志与ss/dig命令精准排障。
网络告警不是孤立事件，而是系统通信链路某一层出现异常的信号。处理关键在于快速分层定位、避免盲目重启或改配置，优先确认“通不通”和“解析不解析”，再深入查“快不快”和“稳不稳”。
先验证基础连通性与DNS解析
这是90%网络告警的第一排查点。用两组命令快速切分问题域：
-
IP层是否通畅：执行
ping -c 3 8.8.8.8。能通 → 说明物理链路、网关、路由、防火墙OUTPUT方向基本正常；不通 → 检查网卡状态（ip link show）、默认路由（ip route | grep default）、本地iptables OUTPUT链（iptables -L OUTPUT -n | grep 53尤其注意UDP 53是否被DROP） -
DNS是否可用：执行
nslookup google.com 8.8.8.8。能解析 → 说明DNS服务本身可用，问题在本地/etc/resolv.conf配置或NetworkManager策略；不能解析但ping 8.8.8.8成功 → 高概率是本机防火墙阻断了UDP 53端口，或DNS服务器地址配置错误
检查网络接口与路由表状态
接口宕掉、地址丢失、路由错乱都会直接触发网络类告警，且常伴随“无网络连接”“网关不可达”等提示：
- 运行
ip addr show确认主网卡（如eth0、ens192）是否有有效IPv4地址、状态为UP、没有重复IP（DUPLICATE）标记 - 运行
ip route show查看是否存在默认路由（default via xxx），若缺失，需检查网络配置文件（如/etc/netplan/*.yaml或/etc/sysconfig/network-scripts/ifcfg-*）并重载网络服务 - 对虚拟化环境，还需确认VMware/Hyper-V侧网络适配器是否启用、端口组绑定正确，
ethtool eth0中link detected: yes是物理连通的硬指标
分析防火墙与安全策略影响
很多“网络不通”实际是策略拦截，而非故障。重点盯三处：
-
主机防火墙：CentOS/RHEL用
firewall-cmd --list-all，Ubuntu用ufw status verbose，查看是否误启了全局拒绝规则；传统iptables需重点检查INPUT/OUTPUT/FORWARD链中针对53（DNS）、22（SSH）、80/443（业务）端口的DROP规则 - 云平台安全组：阿里云/腾讯云/AWS控制台中，确认入方向（Inbound）是否放行了业务端口，出方向（Outbound）是否限制了DNS（UDP 53）或NTP（UDP 123）等基础协议
-
SELinux/AppArmor：若服务突然失联但端口监听正常，可临时设为宽容模式测试：
setenforce 0（SELinux）或aa-complain /usr/bin/nginx（AppArmor），确认是否策略拦截网络套接字创建
结合日志与实时连接追踪
当现象模糊（如“间歇性超时”“部分域名失败”），需借助日志和连接快照交叉印证：
- 查系统日志中的网络相关线索：
journalctl -u systemd-networkd --since "1 hour ago" | grep -i "link\|dhcp\|route"（NetworkManager环境则换为systemd-resolved） - 抓当前活跃连接：
ss -tulnp | grep ':80\|:443'看Web服务是否真在监听；netstat -tuln | grep ':53'看本地DNS服务（如dnsmasq）是否运行 - 对DNS类告警，用
dig @127.0.0.1 google.com +short测试本地解析器，再换公共DNS对比，可快速区分是上游DNS故障还是本机缓存/转发异常
