云服务器连不上？八成是这个"低级错误"

EC2实例明明在跑，公网IP也对，访问就是超时。没报错，没线索，运维老手也得愣三秒。

最后发现：安全组（Security Group）的入站规则是空的。没开SSH，没开HTTP，啥都没开。AWS的默认策略——全部拒绝，除非显式放行——把流量挡得死死的。

这种事儿比想象中常见。因为太基础，反而容易被忽略。

一图看懂：EC2连不上的排查链

原文给了一张极简的排查逻辑图，核心就一层：安全组→入站规则→端口放行。看起来像是"废话"，但真踩过坑的人知道，这图能省半小时。

拆解一下这张图背后的设计：

AWS的安全组是"虚拟防火墙"，但它和物理防火墙的逻辑完全不同。传统防火墙是你配错了可能还通，AWS是你不配就绝对不通。这种"默认拒绝"的设计，本意是安全，副作用就是——忘了配规则，实例变孤岛。

原文提到的快速检查清单，第一条永远是安全组。不是网络ACL，不是路由表，不是IAM权限。顺序很重要：复杂系统里，80%的问题出在20%的基础配置上。

为什么"低级错误"最难防

有个反直觉的现象：越资深的工程师，越容易在这种地方翻车。

原因很实在。日常运维的注意力被高复杂度问题训练成了"默认模式"——看到超时先想DNS解析、想负载均衡、想证书链。大脑自动过滤掉"安全组没配"这种可能性，因为它"太基础了，不可能"。

原文的描述很精准：「一旦找到根因，你会想'这不可能'」。这种心理落差，本身就是运维工作的常态。

修复也简单：加一条入站规则，SSH立马通。不需要重启实例，不需要改其他配置。AWS的即时生效机制，在这里反而是双刃剑——配错了立刻暴露，配对了也立刻恢复，没有缓冲期让你反思。

AWS的"安全优先"设计哲学

这个案例背后有个产品设计的取舍：AWS把安全组的默认状态设为"全拒"，而不是"全通"或"继承模板"。

对比其他云厂商，有的提供"快速启动"模板，一键放通常用端口。AWS没有。它的假设是：用户应该知道自己在暴露什么。

这种设计抬高了新手门槛，但降低了误操作风险。原文提到的"日常操作中容易忽略"，其实是AWS有意为之的摩擦成本——让你每次开端口都手动确认。

代价就是：凌晨三点被告警叫醒，排查半小时发现是22端口没开。

一个可复用的检查清单

原文给出的极简清单，可以提炼成三句话：

第一，安全组入站规则有没有允许你的源IP？

第二，规则里的端口和协议是否匹配你的访问方式？

第三，如果用了网络ACL，别和安全组规则打架。

这三项覆盖了绝大多数"实例通但访问不通"的场景。原文强调"多数情况下问题在第一项"，数据没有，但经验上成立——入站规则为空或源IP写错，占这类故障的绝对大头。

这件事的行业意义

这个案例的价值不在于技术深度，而在于它揭示了云运维的一个结构性矛盾：平台层的安全设计越完善，用户层的配置失误成本越高。

AWS不会为你的安全组配置负责，但它提供了完善的审计日志和自动化工具（如Config规则）来帮你自查。原文没有提这些进阶工具，但"检查基础配置"这个建议，本质上是在说：自动化之前，先确保人工流程不翻车。

对于25-40岁的技术从业者，这个案例的启示很直接：在追逐Kubernetes、服务网格、可观测性这些高级话题之前，确保你的团队有张打印出来的"EC2连不上排查清单"，贴在显示器旁边。

高级故障的根因分析很酷，但凌晨三点能睡个好觉更酷。