你像往常一样打开 FinalShell，输入服务器 IP，点击连接。几秒钟后，弹窗跳了出来——java.net.ConnectException: Connection refused: connect。

你愣了一下。明明昨天还能连上，怎么今天就“被拒绝”了？你没改过密码，没动过配置，服务器也没欠费——那到底是谁“拒绝”了你？

这个报错信息，是 SSH 连接失败中最令人困惑的一种。它不像“超时”那样让人怀疑网络不通，也不像“认证失败”那样让人立刻想到改密码。“Connection refused” 这个词，仿佛在说：服务器收到了你的请求，但它故意不理你。

这种感觉很糟糕。但别急，这篇文章会带你一步步拆解这个错误背后的真相，从端口到防火墙，从服务到配置，把所有可能的原因和解决方案讲清楚。

第一章：读懂“Connection refused”——它到底在说什么？

在动手排查之前，先搞清楚这个报错的真实含义。

Connection refused 是 TCP/IP 协议栈中一个非常明确的信号。它的意思是：你的电脑成功把连接请求发送到了目标服务器的 IP 和端口，但目标服务器上没有任何程序在该端口监听，或者监听程序拒绝了你的连接。

这和 Connection timed out（连接超时）有本质区别：

  • 超时：请求发出去了，但服务器根本没收到（被网络丢包、被防火墙拦截、路由不通）

  • 被拒绝：请求确实送到了服务器，但服务器上说“这个端口没人上班”或“我不接你的活儿”

换句话说，Connection refused 是一个比超时更有价值的信息——它告诉你网络是通的，问题出在服务器本身。你不需要去排查路由器、DNS 或本地网络，目标已经锁定在服务器端。

搞清楚这一点，排查的方向就清晰了。

第二章：三大元凶——谁在“拒绝”你？

Connection refused 的根源，99% 落在以下三个原因之一。

元凶一：SSH 服务根本没启动（最常见）

这是最普遍的原因。服务器虽然开机了，但 SSH 服务（sshd）没有运行。没有服务在监听 22 端口，自然就会返回“拒绝”。

常见场景：

  • 刚装好的 Linux 系统，默认没有安装 openssh-server

  • 服务器重启后，SSH 服务没有设置开机自启

  • SSH 服务被意外停止（系统更新、人为误操作、资源耗尽崩溃）

一句话判断：服务器上压根没人“接电话”。

元凶二：防火墙或安全组拦截了端口（最常见之一）

即使 SSH 服务正常运行，如果防火墙挡住了通往 22 端口的流量，结果同样是“拒绝”。

这里要注意两层防火墙：

  1. 服务器本地防火墙：如 Linux 的 firewalld、iptables、ufw

  2. 云平台安全组：如阿里云、腾讯云、AWS 的安全组规则

很多人在本地防火墙放行了端口，却忘了在云控制台的安全组里开放入站规则——结果还是连不上。

一句话判断：电话有人接了，但门卫不让你进。

元凶三：端口号对不上

SSH 默认端口是 22。但很多管理员出于安全考虑，会把 SSH 端口改成其他数字（如 2222、10022 等）。如果你在 FinalShell 里填的还是 22，而服务器实际监听的却是另一个端口——结果就是“拒绝”。

还有一种情况：SSH 服务虽然运行了，但只监听在 127.0.0.1（本地回环地址），而不是 0.0.0.0（所有网络接口）。这种情况下，只有服务器自己能连自己，外部机器一律被拒。

一句话判断：电话在响，但你打错了号码。

第三章：排查工具箱——一步步找出真凶

下面是一套标准化的排查流程，从易到难，逐层深入。

第一步：确认 FinalShell 里的配置没填错

在责怪服务器之前，先检查自己。

  • IP 地址：是否正确？服务器重启后内网 IP 可能变了

  • 端口号：填的是 22 还是自定义端口？

  • 用户名：是否填对？（root 还是普通用户）

这一步虽然基础，但往往被人忽略。先排除自己的问题，再去怪服务器。

第二步：用 Ping 测试网络连通性

在本地终端执行：

bash
ping <服务器IP>

  • 能 ping 通：网络层正常，问题在传输层或以上

  • ping 不通：可能是网络不通、路由问题、或服务器禁 ping——但这本身不是 Connection refused 的主因

第三步：用 Telnet 测试端口是否开放（关键一步）

bash
telnet <服务器IP> 22

  • 显示 Connected：端口是通的，问题不在防火墙，继续往下查

  • 显示 Connection refused：端口被拦了——防火墙或安全组是头号嫌疑犯

  • 显示 Connection timed out：请求根本没到达服务器，可能是网络路由或上层防火墙的问题

这一步能帮你快速区分“端口被拒”和“端口不通”，让排查方向立刻清晰。

第四步：登录服务器检查 SSH 服务状态

如果 telnet 显示端口不通，就需要登录服务器（通过 VNC、云平台 Web 终端、或其他方式）进行内部检查。

检查 SSH 服务是否运行：

bash
systemctl status sshd

  • 显示 active (running)：服务正常

  • 显示 inactive (dead) 或 failed：服务未启动，执行 sudo systemctl start sshd

检查端口是否在监听：

bash
ss -tlnp | grep :22
# 或
netstat -tuln | grep :22[reference:29]

  • 正常应显示 0.0.0.0:22 或 *:22

  • 如果显示 127.0.0.1:22，说明只监听本地，外部无法访问

  • 如果没有任何输出，说明 SSH 服务没有正确绑定端口

检查 SSH 配置文件是否有语法错误：

bash
sudo sshd -t

这条命令会检查 /etc/ssh/sshd_config 的语法，如果有错误会直接报出来。

第五步：检查防火墙规则

检查 firewalld（CentOS/RHEL 系列）：

bash
sudo firewall-cmd --list-ports[reference:34]
sudo firewall-cmd --list-services

如果 22 端口不在列表中，执行：

bash
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload[reference:35]

或直接开放端口：

bash
sudo firewall-cmd --permanent --add-port=22/tcp
sudo firewall-cmd --reload[reference:36]

检查 UFW（Ubuntu/Debian 系列）：

bash
sudo ufw status[reference:37]

如果显示 active，执行：

bash
sudo ufw allow 22/tcp
sudo ufw reload[reference:38]

临时关闭测试（生产环境慎用）：

bash
sudo ufw disable[reference:39]

检查 iptables：

bash
sudo iptables -L -n | grep :22[reference:40]

第六步：检查云平台安全组

这是很多人容易忽略的一步。

登录阿里云、腾讯云、华为云或 AWS 的控制台，找到对应实例的安全组。检查入方向规则中是否有一条允许 TCP:22（或你的自定义端口）从你的 IP（或 0.0.0.0/0）访问。

如果安全组没放行，服务器本地的 SSH 服务再正常也没用。

第四章：实战场景——不同情况下的解决方案

场景一：新装系统，第一次连接就报错

典型表现：刚买的新服务器、刚装好的虚拟机，FinalShell 第一次连接就 Connection refused。

最大嫌疑：SSH 服务未安装或未启动。

解决方案：

  1. 通过云平台 VNC 或虚拟机控制台登录服务器

  2. 安装 SSH 服务：

    bash
    # Ubuntu/Debian
sudo apt update
sudo apt install openssh-server -y[reference:45]

# CentOS/RHEL
sudo yum install openssh-server -y

  3. 启动并设置开机自启：

    bash
    sudo systemctl start sshd
sudo systemctl enable sshd[reference:46]

场景二：昨天还能连，今天突然报错

典型表现：之前一直正常使用，某天突然连不上，报 Connection refused。

最大嫌疑：SSH 服务崩溃、被停止、或防火墙规则被更改。

解决方案：

  1. 通过备用方式（VNC、其他已连接的会话）登录服务器

  2. 检查服务状态：systemctl status sshd

  3. 如果服务停止了，重启：sudo systemctl restart sshd

  4. 检查系统日志看看是否有异常：

    bash
    sudo tail -f /var/log/auth.log   # Ubuntu/Debian
sudo tail -f /var/log/secure     # CentOS/RHEL[reference:49]

场景三：改了 SSH 端口后连不上

典型表现：修改了 /etc/ssh/sshd_config 中的 Port 值，重启服务后 FinalShell 连不上了。

最大嫌疑：FinalShell 里填的端口没同步更新。

解决方案：

  1. 确认 sshd_config 中修改后的端口号

  2. 在 FinalShell 连接设置中，将端口号改为新端口

  3. 同时检查防火墙是否放行了新端口：

    bash
    sudo firewall-cmd --permanent --add-port=<新端口>/tcp
sudo firewall-cmd --reload

场景四：云服务器，所有配置都正常但就是连不上

典型表现：SSH 服务在运行，端口在监听，本地防火墙也放行了——但 FinalShell 还是报 Connection refused。

最大嫌疑：云平台安全组未放行端口。

解决方案：

  1. 登录云厂商控制台

  2. 找到实例 → 安全组 → 入方向规则

  3. 添加一条规则：允许 TCP 端口 22（或你的自定义端口），来源 IP 填你的公网 IP 或 0.0.0.0/0

  4. 保存后重试连接

💡 特别注意：有些云平台默认安全组只开放了 80 和 443 端口，22 端口需要手动添加。

第五章：一个容易被忽略的小细节——FinalShell 的加速功能

在排查 Connection refused 时，还有一个 FinalShell 特有的因素值得留意。

有用户反馈，在连接某些服务器时，开启智能加速或双边 TCP 加速后反而连不上，关闭加速后恢复正常。这可能是因为加速功能在某些网络环境下与服务器端的配置产生了冲突。

建议：如果上述所有排查步骤都无效，尝试在 FinalShell 的连接设置中暂时关闭加速功能再试一次。

“被拒绝”不是终点，而是排查的起点

Connection refused 这个错误信息，乍看之下让人沮丧——“被拒绝”这三个字带着一种主观的冷漠感。但从技术角度看，它其实是所有 SSH 连接错误中最“友善”的一个。

它不像 Connection timed out 那样让你无从下手——到底是网络断了？路由不通？还是防火墙默默丢弃了数据包？你根本不知道问题出在哪一环。

而 Connection refused 明确地告诉你：请求已经到了服务器，问题就在服务器端。你不需要排查本地网络、不需要怀疑 DNS、不需要检查路由器——目标已经锁定。

剩下的，就是按照本文的流程，一步步检查 SSH 服务是否运行、端口是否正确监听、防火墙和安全组是否放行。每一步都有明确的命令和预期结果，只要耐心排查，问题一定能找到。

下次再看到 Connection refused，别再慌了。它不是“拒绝你”，而是在告诉你——答案就在服务器那边，去找吧。

FinalShell声明：FinalShell站所有内容，资源，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。