网卡没起来先看ip addr中是否为UP状态；IP异常关注169.254.x.x和子网掩码错配；连不通远端用traceroute定位断点；Connection refused需查ss -tlnp和安全组规则。
网卡没起来？先看 ip addr 输出里有没有 UP 状态
新服务器通不了，八成连物理层都没过——网卡明明插着线，但操作系统根本没识别或没启用。别急着改 ip 或查防火墙，先确认网卡是不是真在工作。
- 执行
ip addr，找你的主网卡（比如eth0、ens3或enp0s3），看状态是不是UP；如果显示DOWN，说明网卡被禁用或驱动异常 - 常见坑：某些云平台（如阿里云/华为云）默认关闭多队列或使用
cloud-init延迟配置，导致首次启动后网卡未自动 up - 临时启用：运行
sudo ip link set eth0 up（替换为实际网卡名），再跑一遍ip addr确认 - 若仍为 DOWN，检查
dmesg | grep -i eth0是否有驱动加载失败、firmware 缺失等报错
IP 拿不到或拿错？警惕 169.254.x.x 和子网掩码错配
网卡 UP 了，但 ip addr 显示的是 169.254.x.x 这类链路本地地址，说明 DHCP 完全失败——不是“没连上”，而是“连上了却没要到地址”。
-
169.254.x.x是系统自动生成的 fallback 地址，意味着 DHCP 请求发出去没人应答，或响应被丢弃（常见于交换机 ACL、VLAN 隔离、DHCP 服务宕机） - 手动配静态 IP 时，务必核对三件事：
ip、netmask、default via（网关）必须同属一个广播域；子网掩码写成255.255.255.0却把服务器塞进10.0.2.0/24网段，等于直接断联 - 验证网关可达性：用
ping -c3 192.168.1.1（换成你的真实网关），不通就别试外网——先查交换机端口是否 up、网关本身是否响应 ARP
能 ping 通网关但连不上远端？traceroute 比 ping 更早暴露路由断点
ping 只告诉你“通”或“不通”，而 traceroute 能指出数据包在哪一跳开始消失——是本地策略路由错了？中间防火墙静默丢包？还是目标服务器开了反向路径过滤（rp_filter）？
- 执行
traceroute -n 8.8.8.8（加-n跳过 DNS 解析，避免干扰），观察哪一跳开始出现* * * - 若第一跳（通常是网关）就超时，问题在本地：检查
ip route是否存在错误的 default 路由，或网关 MAC 地址没解析出来（arp -n | grep 网关IP看有没有对应条目） - 若中途某跳起全超时，可能是该设备启用了 ICMP 限速、ACL 拒绝 traceroute 的 udp/TCP 探针，或策略路由把回程路径搞丢了
- 云环境特别注意：
traceroute在部分厂商（如 AWS）中可能因安全组默认禁止 ICMP/UDP 而失效，此时改用telnet 目标IP 端口或curl -v http://目标IP更可靠
连接被拒绝（Connection refused）？重点查 ss -tlnp 和安全组
“无法连接”不等于“网络不通”——TCP 握手能完成但服务不响应，十有八九是目标端口根本没监听，或被中间策略拦在最后一米。
- 登录服务器后，立刻执行
sudo ss -tlnp | grep :22（把 22 换成你要连的端口），确认服务进程真实在监听，且State是LISTEN；若无输出，说明 ssh/Web/数据库服务压根没起来 - 即使本地监听正常，云服务器还有一道关卡：安全组（Security Group）。它工作在虚拟交换机层面，优先级高于系统防火墙。必须确认入站规则明确放行了你的源 IP + 目标端口，哪怕只差一个 /32 也连不上
- 容易忽略的坑：
ss显示监听127.0.0.1:3306，但你试图从外部连0.0.0.0:3306——这是绑定地址写死了，得改 mysql 的bind-address或 redis 的bind配置项
真正卡住人的，往往不是某个命令不会敲，而是把“网络不通”当成单一问题去查。物理层、IP 层、传输层、应用层的线索可能同时存在，但日志和命令输出只会给你碎片。盯住 ip addr、ip route、ss -tlnp 这三个命令的原始输出，比任何“排查流程图”都管用。