一、物理层。
排查目的：从最基础的物理层开始排查，物理层不通，上层排查就没有意义。
1、确认网卡、网线是等硬件是否正常工作。
举例：
下方是插好线，并且可以正常连接的网口。
看flag标志：UP表示网卡激活状态；RUNNING表示网卡有物理连接（还有一种命令查看是否有物理连接： ethtool +网口）；BROADCAST表示支持广播；MULTICAST表示支持组播。
2、检查网卡指示灯和交换机口是否正常。
3、ping 127.0.0.1。
操作系统在启动时，会默认创建一个虚拟网卡（lo），并分配给它 127.0.0.1 这个地址（这个网卡是纯软件模拟的，不需要任何物理硬件（网卡、网线）支持）。只要是运行着标准TCP/IP协议的操作系统（Windows、Linux、macOS等），ping 127.0.0.1 必须通。如果不通，说明操作系统底层的网络协议栈（TCP/IP 核心驱动）已经崩溃或损坏，之后只能重启服务器或者重装系统来解决问题了。
二、网络层。
排查目的：确认网关和外网的连通性，定位延迟、丢包和路由路径问题。
1、route -n查看所有路由信息。
只能存在一个默认网关。
2、ping 网关IP。
不能出现丢包或者延迟尖刺。
3、长时间测试。
如果网关正常，使用长时间测试，ping -c 300 <目标IP>，关注是否呀延时尖刺、丢包、延迟抖动是否大于1毫秒。
4、arp -n。
查看ARP表信息，arp -n查看出来的物理地址只能对应一个网口IP。
5、cpdump -i eno1 icmp 抓 ICMP 包。看包是再哪里被拦截。
判断标准：有来有回 = 路通；没回复 = 路不通
ping 网关IP排查验证实例1：
ping管理口网关路由存在尖刺延时，并且丢包，判断是没有唯一的默认路由，其他路由占用了流量，导致ssh登进去经常卡壳。
[root@rac1 ~]# ping 172.27.0.1
PING 172.27.0.1 (172.27.0.1) 56(84) bytes of data.
64 bytes from 172.27.0.1: icmp_seq=1 ttl=255 time=0.863 ms
64 bytes from 172.27.0.1: icmp_seq=2 ttl=255 time=0.919 ms
64 bytes from 172.27.0.1: icmp_seq=3 ttl=255 time=1523.11 ms ------延迟尖刺！！！
64 bytes from 172.27.0.1: icmp_seq=4 ttl=255 time=0.859 ms
64 bytes from 172.27.0.1: icmp_seq=5 ttl=255 time=2.05 ms
64 bytes from 172.27.0.1: icmp_seq=6 ttl=255 time=1862.832 ms ------又一个延迟尖刺！！！
64 bytes from 172.27.0.1: icmp_seq=7 ttl=255 time=0.865 ms
--- 172.27.0.1 ping statistics ---
14 packets transmitted, 14 received, 20% packet loss, time 100938ms ------20% packet loss存在丢包！！！！
rtt min/avg/max/mdev = 0.832/1.650/5.430/11111.310 ms -------延迟抖动>1ms 说明网络不稳！！！！
arp -n排查验证实例1：同一台服务器上，不同网口使用同一个IP。
命令：arp -n | grep 172.27.101.198，之后存在两个物理地址。
ether 14:18:77:70:ce:b1 C eno1 172.27.101.198
ether 14:18:77:70:ce:b2 C eno2 172.27.101.198
arp -n排查验证实例2：不同服务器上，不同网卡使用同一个IP，针对其他同事使用和你一样的IP情况。
命令：arping -I eno1 172.27.101.198，之后存在两个物理地址。
60 bytes from 14:18:77:70:ce:b1 (172.27.101.198): index=0 time=0.123 ms
60 bytes from 00:50:56:99:12:34 (172.27.101.198): index=1 time=0.145 ms
三、传输层
排查目的：确认服务器是否可达，定位中途的数据包情况。
1、tcpdump进行数据抓端口包处理。
判断标准：三次握手成功 = 门开了；收到 [R.] = 门锁着；无回复 = 有防火墙
2、确认监听状态。
[root@rac1 ~]# ss -tlnp | grep 22
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1876,fd=6))
分析：
a、LISTEN，说明端口有在被监听，并且0.0.0.0:22表示对所有访问者开放。
b、如果显示127.0.0.1:22表示任何网口显示这个也是只能自己监听自己，192.168.1.100:22表示在这个特定的网段才可以连接。
c、若是没有输出就表示服务没有启动，就不能ssh连接。
d、如果显示0.0.0.0表示服务正常，可能是防火墙的问题。
四、应用层
排查目的：应用层排障，目标就是确认“软件能不能正常干活”。不是看路通不通，而是看“业务逻辑对不对”。
应用层的排查是很灵活的，目前经验总结有
1、进程号 = 确认软件活着。
ps aux | grep <服务名> │ │ → 有进程 = 没崩；没进程 = 挂了，先重启
2、/var/log/messages = 系统级报错的总入口。
3、应用自己的日志（如 /var/log/secure、/var/log/nginx/error.log）= 定位具体根因。
应用层排障 = 日常看日志 + 查进程。
第1层（物理层）：网卡灯亮吗？网线插了吗？ ↓ 通了
第2层（网络层）：ping 网关通吗？路由表对吗？ ↓ 通了
第3层（传输层）：端口 LISTEN 吗？三次握手成功吗？ ↓ 通了
第4层（应用层）：应用进程在吗？日志报错吗？返回数据对吗？ ↓ 正常 ?
全部正常，问题不在这台服务器上！
