服务器IPv4无法SSH但IPv6正常？常见原因与排查思路
最近入了一台 Clouduim 的低价 VPS，本来是打算拿来做点轻量级测试或者科学小玩具的，结果配置好系统后遇到了个怪事：通过 IPv6 地址可以顺畅地 SSH 登录，但死活连不上 IPv4。
这就很让人头大了。既然 IPv6 能通，说明机器本身是活着的，SSH 服务也是正常运行的，大概率不是“跑路”或者机器挂了。遇到这种情况别急着发工单（当然，如果是纯 Nat 机型除外），咱们可以按照以下几个思路自己排查一下，通常能解决大部分问题。
IPv4 无法连接时的排查思路导图
一、检查 SSH 服务监听地址
这是最基础的一步。SSH 服务默认情况下是监听在所有地址（0.0.0.0 和 ::）上的，但有些精简版的系统镜像或者被魔改过的配置，可能会把监听地址写死。
登录到机器上（既然 IPv6 能连，就先用 IPv6 登录），编辑配置文件：
sudo nano /etc/ssh/sshd_config
找到 #ListenAddress 0.0.0.0 这一行。
- 如果前面有
#号，去掉它，确保它监听 IPv4 的所有接口。 - 如果这就行被改成了具体的 IPv6 地址，或者只有
ListenAddress ::，那你需要增加一行ListenAddress 0.0.0.0来显式开启 IPv4 监听。
改完后别忘了重启 SSH 服务：
sudo systemctl restart sshd
二、防火墙策略（iptables/firewalld/UFW）之迷
很多“玩具鸡”为了防止被扫，可能预设了非常严格的防火墙规则。很多防火墙默认策略并不区分 IPv4 和 IPv6，但有时候规则并没有正确同步。
检查 iptables 防火墙规则列表
比如，你可能放行了 IPv6 的 SSH 端口（22），但 IPv4 的 INPUT 链却是 DROP 状态。
排查方法：
如果是 CentOS 7/8/Stream，查看 iptables：
sudo iptables -L -n -v
如果是 Ubuntu/Debian 查看UFW：
sudo ufw status verbose
解决思路： 直接放行 22 端口，或者允许已建立的连接。为了快速测试，可以尝试临时清空防火墙规则（生产环境慎用）：
# iptables 临时清空
sudo iptables -F
sudo ip6tables -F
清空后，再试着用 IPv4 连接一下。如果能连上，那就是防火墙规则的问题，你需要去添加正确的放行策略，而不是简单粗暴地清空。
三、网关与路由表配置问题
这一点在低价 VPS 上尤其常见。有些超售严重的机器或者 Nat 机型，IPv4 的网络配置可能会出现“虚接”。虽然系统里分配了 IPv4 地址，但路由表没指对路，或者默认网关压根就是坏的。
可以用以下命令检查：
ip route show
``}
看看有没有 `default via xxx.xxx.xxx.xxx dev eth0` 这样的记录。
如果路由表正常，试试 ping 一下网关：
```bash
ping -c 4 你的网关IP
如果 ping 不通网关，或者虽然能 ping 通网关但 ping 不通 8.8.8.8，那说明是底层网络层的问题，或者是 VPS 提供商的 Nat 映射出了故障。这步如果是 IPv6 正常而 IPv4 不通，大概率是提供商那边的问题了，这时候再发工单也不迟。
四、排查是否为 CN2 GIA 或线路分段阻断
还有一种情况是你的 SSH 能连上，但是握手瞬间就被断了。这通常是运营商那边的问题。比如某些线路对海外的 22 端口进行了干扰。
你可以尝试修改 SSH 端口（比如改成 2222），改完记得去防火墙放行新端口。换一个端口试试，有时候会有奇效。
总结
遇到 IPv4 挂了、IPv6 好着的情况，思路大概就是：
- 服务配置：查 sshd_config。
- 系统安全：查防火墙 chain。
- 网络层：查路由、网关和外部连通性。
- 外部干扰：改端口测试。
大部分情况下，这类问题都是防火墙误伤或者 SSH 配置疏忽导致的，自己动手丰衣足食，排查过程也是个熟悉 Linux 网络架构的好机会。如果以上都搞定了还不行，那可能就是这台“玩具鸡”本身的质量问题了，建议直接退款跑路。
评论已关闭