服务器 SSH 连接故障排查记录
2026年6月8日 server 16 分钟阅读 1 次阅读
📖 文章摘要
记录主机 SSH 超时故障完整排查流程，区分安全组与系统 ufw 双层防火墙，定位服务未自启根因并给出修复、巡检全套实操命令。
香港服务器 SSH 连接故障排查记录
故障现象
香港服务器（10.0.0.x）突然无法通过 SSH 连接，之前一直正常。
排查过程
第一步：确认网络层连通性
C:\> ping -n 3 10.0.0.x
正在 Ping 10.0.0.x 具有 32 字节的数据:
来自 10.0.0.x 的回复: 字节=32 时间=27ms TTL=43
来自 10.0.0.x 的回复: 字节=32 时间=27ms TTL=43
来自 10.0.0.x 的回复: 字节=32 时间=27ms TTL=43
10.0.0.x 的 Ping 统计信息:
数据包: 已发送 = 3，已接收 = 3，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 27ms，最长 = 27ms，平均 = 27ms
结论：ping 正常（27ms，0% 丢包），服务器在线，网络层可达。
排查经验：ping 是最基础的连通性检查。ping 通说明服务器在线、IP 可达，排除宕机、断网、IP 被封等可能。
第二步：测试 SSH 端口连通性
C:\> ssh -o ConnectTimeout=5 -p 2222 user@10.0.0.x echo "connected"
ssh: connect to host 10.0.0.x port 2222: Connection timed out
再测默认 22 端口：
C:\> ssh -o ConnectTimeout=5 -p 22 user@10.0.0.x echo "connected"
ssh: connect to host 10.0.0.x port 22: Connection timed out
用 PowerShell 确认 TCP 端口状态：
PS C:\> Test-NetConnection -ComputerName 10.0.0.x -Port 2222
ComputerName : 10.0.0.x
RemoteAddress : 10.0.0.x
RemotePort : 2222
TcpTestSucceeded : False
结论：ping 通但 TCP 端口不通，问题在端口级别的访问控制上，不是网络层问题。
排查经验：ping 通 + 端口不通 = 防火墙/安全组拦截。ping 通 + 端口通但连不上 = sshd 配置或认证问题。
第三步：排查 UCloud 安全组
在 UCloud 控制台查看安全组规则，结果如下：
策略 协议及端口 源地址 优先级
接受 TCP: 2894 0.0.0.0/0 高
接受 TCP: 80 0.0.0.0/0 高
接受 TCP: 443 0.0.0.0/0 高
接受 ICMP 0.0.0.0/0 高
状态：运行健康
结论：UCloud 安全组没有问题，2894 端口已正确放行。问题在服务器内部。
排查经验：云服务器有两层防火墙——外层是云平台安全组，内层是操作系统防火墙（iptables/ufw）。安全组没问题就往里查。
第四步：通过 VNC 登录服务器检查内部防火墙
SSH 连不上，通过 UCloud 控制台的 VNC 远程终端登录服务器。
4.1 检查 sshd 运行状态
ubuntu@web-server:~$ sudo systemctl status sshd
Unit sshhd.service could not be found.
ubuntu@web-server:~$ sudo ss -tlnp | grep 2222
LISTEN 0 128 0.0.0.0:2222 0.0.0.0:* users:(("sshd",pid=1591,fd=3))
LISTEN 0 128 [::]:2222 [::]:* users:(("sshd",pid=1591,fd=4))
结论：sshd 正常运行并监听 2222 端口，但不是通过 systemd 管理的（手动启动）。
4.2 检查 sshd 配置
ubuntu@web-server:~$ sudo grep -i "^Port" /etc/ssh/sshd_config
Port 2222
结论：sshd 配置正确，监听 2222 端口。
4.3 检查 iptables 规则（关键发现）
ubuntu@web-server:~$ sudo iptables -L INPUT -n | head -20
Chain INPUT (policy DROP)
target prot opt source destination
ufw-before-logging-input 0 -- 0.0.0.0/0 0.0.0.0/0
ufw-before-input 0 -- 0.0.0.0/0 0.0.0.0/0
ufw-after-input 0 -- 0.0.0.0/0 0.0.0.0/0
ufw-after-logging-input 0 -- 0.0.0.0/0 0.0.0.0/0
ufw-reject-input 0 -- 0.0.0.0/0 0.0.0.0/0
ufw-track-input 0 -- 0.0.0.0/0 0.0.0.0/0
关键发现：
policy DROP— INPUT 链默认策略是丢弃所有入站流量- ufw 相关链全部为空（计数器为 0）— ufw 链存在但没有加载任何规则
排查经验：
policy DROP+ 空规则 = 所有入站流量被拒绝policy ACCEPT+ 空规则 = 所有入站流量放行- 链存在但计数器为 0 = 规则没有被加载
4.4 检查 ufw 规则配置文件
ubuntu@web-server:~$ cat /etc/ufw/user.rules
### tuple ### allow tcp 22 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 22 -j ACCEPT
### tuple ### allow tcp 80 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 80 -j ACCEPT
### tuple ### allow tcp 443 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 443 -j ACCEPT
### tuple ### allow tcp 2894 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 2894 -j ACCEPT
结论：规则文件里有放行规则（包括 2894），但 iptables 里没加载。说明 ufw 服务没有正确启动。
4.5 检查 ufw 服务状态（根因确认）
ubuntu@web-server:~$ sudo systemctl is-enabled ufw
disabled
ubuntu@web-server:~$ sudo systemctl status ufw
○ ufw.service - Uncomplicated firewall
Loaded: loaded (/usr/lib/systemd/system/ufw.service; disabled; preset: enabled)
Active: inactive (dead)
Docs: man:ufw(8)
根因确认：
is-enabled返回disabled— ufw 没有设置开机自启status返回inactive (dead)— ufw 服务当前未运行- 规则文件存在但服务没启动 → 规则没有加载到 iptables → 所有入站连接被 DROP
排查经验：
ufw allow只是写入配置文件，必须配合systemctl enable ufw确保开机自启，否则重启后规则不会生效。
第五步：修复
ubuntu@web-server:~$ sudo ufw allow 2222/tcp
Rule added
Rule added (v6)
ubuntu@web-server:~$ sudo ufw allow 80/tcp
Skipping adding existing rule
Skipping adding existing rule (v6)
ubuntu@web-server:~$ sudo ufw allow 443/tcp
Skipping adding existing rule
Skipping adding existing rule (v6)
ubuntu@web-server:~$ sudo ufw reload
Firewall reloaded
ubuntu@web-server:~$ sudo systemctl enable ufw
Synchronizing state of ufw.service with SysV service script with
/usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable ufw
Created symlink /etc/systemd/system/multi-user.target.wants/ufw.service
→ /usr/lib/systemd/system/ufw.service.
ubuntu@web-server:~$ sudo systemctl start ufw
验证：
ubuntu@web-server:~$ sudo ufw status
Status: active
To Action From
-- ------ ----
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
2222/tcp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
2222/tcp (v6) ALLOW Anywhere (v6)
第六步：验证修复
从本地重新测试 SSH 连接：
C:\> ssh -o ConnectTimeout=5 -p 2222 user@10.0.0.x echo "connected"
connected
问题解决。
故障根因总结
ufw 防火墙的规则文件（/etc/ufw/user.rules）里有放行规则，但 ufw 服务没有设置开机自启（disabled），服务器重启后 ufw 没有启动，规则没有加载到 iptables 内存中，导致所有入站连接被丢弃。
排查思路框架
1. ping 服务器IP
├── 不通 → 服务器宕机 / IP被封 / 路由问题
└── 通 → 进入步骤2
2. 测试目标端口（ssh / Test-NetConnection / telnet）
├── 端口不通 → 进入步骤3（防火墙排查）
└── 端口通但连不上 → sshd配置问题 / 认证问题
3. 排查防火墙（两层）
├── 3a. 检查云平台安全组（控制台查看）
│ ├── 安全组未放行 → 添加规则
│ └── 安全组已放行 → 进入3b
└── 3b. 检查服务器内部防火墙
├── sudo iptables -L INPUT -n → 查看规则是否加载
├── sudo ufw status → 查看 ufw 规则
├── cat /etc/ufw/user.rules → 查看配置文件
└── sudo systemctl is-enabled ufw → 确认是否开机自启
4. 如果防火墙都没问题，检查 sshd 本身
├── sudo ss -tlnp | grep 端口
├── sudo systemctl status sshd
└── sudo tail -f /var/log/auth.log
关键命令速查
| 用途 | 命令 | 正常结果 |
|---|---|---|
| 测试网络连通 | ping -n 3 <IP> |
0% 丢包 |
| 测试端口连通 | ssh -o ConnectTimeout=5 -p <端口> user@IP |
connected |
| PowerShell测端口 | Test-NetConnection -ComputerName <IP> -Port <端口> |
TcpTestSucceeded: True |
| 查看sshd监听 | sudo ss -tlnp | grep <端口> |
有 LISTEN 记录 |
| 查看sshd状态 | sudo systemctl status sshd |
active (running) |
| 查看iptables规则 | sudo iptables -L INPUT -n |
有 ACCEPT 规则 |
| 查看ufw状态 | sudo ufw status |
Status: active，有 ALLOW 规则 |
| 检查ufw开机自启 | sudo systemctl is-enabled ufw |
enabled |
| 查看ufw配置文件 | cat /etc/ufw/user.rules |
有 allow 条目 |
| ufw放行端口 | sudo ufw allow <端口>/tcp |
Rule added |
| ufw重载规则 | sudo ufw reload |
Firewall reloaded |
| 设置ufw开机自启 | sudo systemctl enable ufw |
Created symlink... |
| 启动ufw服务 | sudo systemctl start ufw |
无报错 |
经验教训
- 云服务器有两层防火墙：安全组（云平台层面）+ 操作系统防火墙（iptables/ufw）。排查时两层都要查。
- ufw 配了规则不等于生效：
ufw allow只是写入配置文件，必须执行systemctl enable ufw确保开机自启，否则重启后规则不会加载到 iptables。 - 排查要查两层状态：不仅要看
ufw status（规则是否配置），还要看systemctl is-enabled ufw（服务是否开机自启），两者缺一不可。 - VNC 是救命稻口：SSH 连不上时，云平台控制台的 VNC/远程终端是唯一的远程访问途径，平时要熟悉怎么进入。
后续安排
- 确认 sshd 也设置开机自启：
sudo systemctl enable ssh，避免重启后 sshd 不启动 - 精简 ufw 规则：22 端口已禁用，可以
sudo ufw delete allow 22/tcp清掉多余规则 - 检查其他服务器：同批次购买的服务器可能有相同问题，逐一确认
systemctl is-enabled ufw和systemctl is-enabled ssh - 建立巡检习惯：定期通过 VNC 或 SSH 检查
ufw status和systemctl is-enabled ufw，确认防火墙状态正常 - 文档归档：将排查记录归入运维学习笔记，作为防火墙类故障的标准排查流程参考
最后更新：2026年7月9日CC BY-NC-SA 4.0
评论
暂无评论，来写第一条吧