获课：xingkeit.top/17321/

排错实录：云计算环境 Linux 网络不通的全套排查与解决指南

在云计算时代，基础设施的弹性伸缩让我们习惯了资源的随取随用。然而，当你在云控制台上点击“启动”，一台崭新的 Linux 实例亮起运行绿灯，当你满怀信心地通过 SSH 准备大干一场时，屏幕上却赫然跳出那句令人绝望的提示：“Connection timed out”。

网络不通，是云上运维最常见、也最让人抓狂的“盲盒”。与本地物理机不同，云环境的网络链路被虚拟化层切割得极其复杂。经过无数次在深夜与“断网”搏斗的经历，我总结了一套从下到上、从内到外的云原生 Linux 网络排错指南。没有一行代码，只有纯粹的底层逻辑与排查路径。

一、 先问“安全”而非“系统”：云平台控制台排雷

很多人遇到网络不通，第一时间就登录系统查网卡、改路由，这其实是犯了云上排错的大忌。云环境的底层基石是虚拟化，而虚拟化网络的第一道关卡，往往不在操作系统内，而在云平台的控制台里。

1. 安全组规则核查
安全组相当于云服务器的“虚拟防火墙”，且是状态无关的白名单机制。第一步必须确认：入站规则是否放行了你所需的端口（如 SSH 的 22 端口或 Web 的 80 端口）？放行的源 IP 是否限制过死（比如只允许特定 IP 访问，而你现在正用另一个 IP 连接）？很多看似玄学的“超时”，仅仅是因为安全组少配了一条规则。

2. 弹性公网 IP（EIP）与网卡绑定状态
如果安全组没问题，接着看公网入口。云服务器通常通过绑定弹性公网 IP 来上网。要检查 EIP 是否成功绑定到主网卡，状态是否为“正常”。此外，要确认 EIP 的带宽包是否被限速到 0，或者因欠费被停用。

3. VPC 路由表与 NAT 网关
如果实例没有公网 IP，而是通过 NAT 网关访问外网，此时要检查 VPC 的路由表配置。确保指向 0.0.0.0/0 的默认路由正确指向了 NAT 网关。任何路由表的配置错误，都会让数据包在虚拟私有云里“有去无回”。

二、 探秘虚拟边界：操作系统网络接口排障

排除了云平台层面的限制后，我们终于可以登录系统（通常通过 VNC 控制台直接登录）。在 Linux 系统中，网络接口的配置是第二道关。

1. 网卡状态与 IP 分配
首先确认网卡是否处于 UP 状态，以及是否成功获取到了私有 IP 地址。在云环境中，IP 通常由云平台的 DHCP 服务静态分配。如果发现系统内网卡没有 IP，可能是 DHCP 租约过期或网络管理服务卡死，重启网络服务通常能解决。

2. MTU（最大传输单元）不匹配的隐性杀手
这是一个非常隐蔽的坑。云厂商为了提高网络性能，某些实例默认会开启巨型帧，MTU 值可能被设置为 9000。但如果对端的网络设备（如 VPN 网关或物理防火墙）只支持标准的 1500，数据包就会被静默丢弃。表现就是：小数据能通，大数据卡死或 SSH 登录后敲击命令极度延迟。将网卡的 MTU 强制降回 1500，往往能立竿见影。

三、 穿越系统防火墙：iptables 与 firewalld 的博弈

云平台的安全组管的是外部流量，而 Linux 内部的防火墙管的是系统大门。两者互不干涉。

1. 默认策略的“一刀切”
很多操作系统镜像默认开启了 firewalld 或 iptables。在排错时，必须检查 INPUT 链的默认策略是否被设置为了 DROP。如果是，即使云安全组放行了，数据包依然会在进入系统的一瞬间被内核丢弃。临时关闭内部防火墙进行连通性测试，是快速隔离问题的有效手段。

2. 规则冲突与残留
有时候，之前的业务配置了大量复杂的 NAT 或转发规则，业务下线后规则未清理，导致新业务网络冲突。清空默认链规则，只保留最基本的 ACCEPT 策略，可以排除这类历史遗留问题。

四、 循迹数据流向：路由表与 DNS 解析

网络通了，不代表业务能跑起来。数据包能不能找到正确的路，以及能不能认得出对方的门牌号，是接下来的关键。

1. 路由表与默认网关
使用命令查看系统路由表，确认是否存在指向 0.0.0.0 的默认路由，且网关地址是否与云平台 VPC 子网网关一致。如果实例有多块网卡，很容易出现路由从网卡 A 进、却从网卡 B 出的“非对称路由”问题，这会导致回包全部被丢弃。必要时需要配置基于策略的路由（Policy Routing）来规范流向。

2. DNS 解析的“最后一公里”
当发现能 ping 通公网 IP（如 114.114.114.114），却无法访问域名时，问题 100% 出在 DNS。检查 /etc/resolv.conf 文件，确认是否配置了有效的 DNS 服务器。在云上，最佳实践是使用云厂商提供的内网 DNS 地址，它能解析云内部服务，且速度极快。如果该文件为空或被覆盖，网络表现就是“看似连着网，实际啥也打不开”。

五、 警惕内核级拦截：TCP Wrappers 与 SELinux

如果你一路排查到这里，网络配置全对，防火墙全开，但某个特定服务（比如 SSHD）就是死活连不上，那就得向更深层的系统内核机制要答案了。

1. TCP Wrappers 的黑白名单
老旧的 Linux 系统可能仍保留着 /etc/hosts.allow 和 /etc/hosts.deny 机制。这是一个应用层的访问控制，如果 deny 文件里写了 ALL: ALL，那么不管网络层怎么放行，服务端应用都会拒绝连接。

2. SELinux 的强制访问控制
这是排错的终极黑洞。SELinux 是一种内核级的 MAC（强制访问控制）机制。如果策略配置不当，比如 Web 服务进程试图访问一个非标准端口或没有正确标签的文件，SELinux 会直接在内核态拦截，且可能在普通日志里不露声色。将 SELinux 临时设置为 Permissive（宽容模式），如果服务立刻恢复，那你就得去钻研 SELinux 的策略日志了。

结语

在云计算环境中排查 Linux 网络故障，如同在错综复杂的迷宫中寻找出口。它的难点不在于命令有多复杂，而在于链路有多长。从云控制台的安全组、VPC 路由，到系统内的网卡驱动、MTU 配置，再到内部防火墙、路由策略，最后到 SELinux 这种内核级拦截。

每一次成功的排错，都是对系统全链路认知的一次重塑。不要急于敲击命令，而是要在脑海中构建出数据包从源到目的地的完整流转图。顺藤摸瓜，逐层验证，才能真正在这个云原生时代，掌控属于你的网络主导权。