亚马逊云长期稳定号 亚马逊云服务器无法连接
你凌晨三点盯着终端里那行冷冰冰的 ssh: connect to host xxx.xxx.xxx.xxx port 22: Connection timed out，手边咖啡凉透，心跳比 ping 包还抖——别慌，这不是世界末日，只是 AWS 给你发了一张「故障排查体验券」，而且包邮，还带说明书（虽然说明书是英文的，还藏在文档第47页）。
先别删实例，它可能只是害羞了
很多人第一反应是：重启！重置！重装！甚至想格式化整个 VPC——冷静点朋友，EC2 不是前任，不用靠毁灭重建来疗伤。90% 的「连不上」问题，根本不在服务器肚子里，而在它和你之间那条看不见的数字小路。我们按「由外向内、由虚到实」的顺序，一层层剥洋葱（不辣眼，但可能让你恍然大悟到拍大腿）。
第一关：你的网络，真的能「看见」它吗？
打开浏览器，访问 https://checkip.amazonaws.com，记下你本机公网 IP。再登录 AWS 控制台，找到你的 EC2 实例 → 点击「安全组」→ 查看入站规则。重点来了：有没有一条规则，明确允许你的本机 IP（或 0.0.0.0/0，当然不推荐）访问端口 22（SSH）？
常见翻车现场：
❶ 写成了 2222 而不是 22（以为自己在搞个性化）；
❷ 源地址填了 192.168.1.100/32，结果你今天用的是公司 WiFi，IP 变成 10.20.30.40；
❸ 安全组绑错了——明明改了 A 组，却给实例绑着 B 组（AWS 控制台右上角那个「刷新」按钮，请多爱它几秒钟）。
顺手检查下：实例是否在「运行中」？状态检查（Status Checks）两个绿勾都亮着？如果「系统状态检查」失败，可能是底层宿主机抽风，重启实例往往立竿见影；如果是「实例状态检查」失败，大概率是你自己干的——比如把 sshd 服务 kill 了，或改了 /etc/ssh/sshd_config 却忘 reload。
第二关：密钥？不是「钥匙」，是「唯一身份证」
如果你用的是 PEM 密钥登录：
❶ 确保本地私钥文件权限是 600（macOS/Linux）：chmod 600 your-key.pem。Windows 用户用 PuTTY？请确认已正确转换为 .ppk 格式，且 PuTTY 配置里「Connection → SSH → Auth」路径指向它。
❷ 用户名别瞎猜！Amazon Linux 是 ec2-user，Ubuntu 是 ubuntu，CentOS 是 centos——控制台启动时页面下方小字写着呢，不是玄学。
输错密码？等等，EC2 默认根本没开密码登录！除非你手动改过 PasswordAuthentication yes 并设了密码。所以当你看到 Permission denied (publickey)，八成是密钥不对、用户名错、或者私钥根本没加载进 SSH agent。
第三关：VPC 和子网，不是地理概念，是逻辑牢笼
打开 VPC 控制台 → 找到你的子网 → 看「Route Table」。里面必须有一条指向 Internet Gateway（IGW）的路由：0.0.0.0/0 → igw-xxxxxx。没有？你的实例就是个局域网孤岛，连 AWS 自己的 DNS 都 ping 不通。
再查子网属性：「Auto-assign public IPv4 address」是否为 Yes？如果是 No，实例只有内网 IP（如 172.31.x.x），你在外网根本摸不到它。解决办法：要么编辑子网开启自动分配，要么手动关联一个弹性 IP（EIP）——注意，EIP 关联后要等 10 秒再试 SSH。
第四关：终端里的「超时」和「拒绝」，其实是两种方言
「Connection timed out」 = 你的请求石沉大海，没收到任何回应。原因：网络不通、安全组拦截、没公网 IP、路由表缺失——全是「连接前」的问题。
「Connection refused」 = 服务器收到了，但明确说「不约」。原因：sshd 服务没启动、端口监听错了（比如只监听 127.0.0.1）、防火墙（iptables/firewalld）挡路、SELinux 发疯。
怎么验证？用 telnet 或 nc：telnet your-ec2-ip 22 或 nc -zv your-ec2-ip 22。
如果显示 Connected to... —— 恭喜，网络层通畅，问题出在系统内部；
如果卡住 30 秒后报 Connection timed out —— 回头检查安全组和路由。
终极补刀：当所有配置都对，还是连不上…
亚马逊云长期稳定号 试试这个骚操作：停止实例 → 启动实例（不是重启！）。为什么？因为「停止/启动」会重新分配公有 IP（如果没绑定 EIP）、重置网络栈、甚至触发底层硬件迁移——有时候，就是那么玄学。
还有个隐藏彩蛋：检查实例的「用户数据（User Data）」。如果你写过脚本自动配置防火墙或禁用 SSH，而脚本某行执行失败导致半途而废……恭喜，你给自己挖了个温柔陷阱。
防坑口诀（建议抄在便利贴上贴显示器）
- 安全组管「能不能进」，网络 ACL 管「要不要拦」，路由表管「往哪走」——三者缺一不可；
- 「Public IP」和「Elastic IP」不是同义词，后者才永久；
- 改完 sshd_config 必须
sudo systemctl restart sshd（或service ssh restart）； - 本地 hosts 文件别乱加映射，DNS 解析失败时它会默默背锅；
- AWS 免费套餐的 t2/t3.micro 实例内存只有 1GB，跑个 Docker + Node.js 就可能 OOM 杀掉 sshd——
free -h看一眼，有时真相就在那里。
最后送你一句 AWS 老司机的真言
「连不上」从来不是服务器的问题，而是你和它之间，某处配置的沉默抗议。它不吵不闹，就静静躺在那里，等着你亲手解开那个被忽略的复选框、那行被注释掉的配置、那个权限为 644 的私钥文件。
下次再看到 ssh: connect to host... Connection refused，别急着砸键盘。泡杯茶，打开控制台，按本文顺序点三遍——大概率，5 分钟后，你会笑着输入 ls -la，然后对着满屏的 drwxr-xr-x 感慨：原来，云服务器也怕被误解，更怕你没看懂它的欲言又止。
