如何解决Xshell连接Linux服务器时出现“Connection refused”错误？

Question

Xshell连接Linux服务器时提示“Connection refused”，通常表示客户端成功到达目标IP，但目标端口（默认22）无服务响应。常见原因有四：① SSH服务未运行（执行 `systemctl status sshd` 检查，若未启动则 `sudo systemctl start sshd` 并设为开机自启）；② 防火墙拦截（CentOS/RHEL用 `firewall-cmd --list-ports` 查22端口，Ubuntu用 `ufw status`，必要时开放：`firewall-cmd --add-port=22/tcp --permanent && firewall-cmd --reload`）；③ SSH监听地址被限制（检查 `/etc/ssh/sshd_config` 中 `ListenAddress` 是否误配为127.0.0.1，应注释或改为 `0.0.0.0`）；④ 云服务器安全组未放行22端口（如阿里云、腾讯云需在控制台配置入方向规则）。建议按“服务→防火墙→配置→网络策略”顺序逐层排查，避免盲目重启。

Answer 1

```html

一、现象定位：从网络层确认“Connection refused”的本质

“Connection refused”是TCP三次握手阶段由目标主机主动返回的RST报文所致，表明客户端已成功路由至目标IP，但该IP上无进程在监听目标端口（默认22）。这与“Timeout”（网络不可达/防火墙静默丢包）有本质区别——前者是明确拒绝，后者是无声沉默。可通过本地诊断命令快速区分：

telnet 192.168.1.100 22    # 若返回 "Connection refused" → 服务层问题
nc -zv 192.168.1.100 22  # 同理，精准验证端口可达性
ping 192.168.1.100        # 排除ICMP层面基础连通性问题

二、服务层排查：SSH守护进程状态与生命周期管理

SSH服务未运行是最常见原因。需结合系统发行版差异执行精准检查：

系统类型	检查命令	启动命令	开机自启
CentOS/RHEL 7+	systemctl status sshd	sudo systemctl start sshd	sudo systemctl enable sshd
Ubuntu/Debian	systemctl status ssh	sudo systemctl start ssh	sudo systemctl enable ssh
Alpine Linux	rc-status | grep sshd	rc-service sshd start	rc-update add sshd default

三、主机防火墙策略：动态策略与持久化配置的协同验证

防火墙可能在运行时阻断22端口，且配置未持久化导致重启后复现。需分两步验证：

• 运行时状态检查：
  firewall-cmd --list-all（RHEL/CentOS）或 ufw status verbose（Ubuntu）
• 持久化开放操作（以RHEL为例）：
  sudo firewall-cmd --add-port=22/tcp --permanent && sudo firewall-cmd --reload

四、SSH服务配置深度解析：ListenAddress与BindAddress语义辨析

在/etc/ssh/sshd_config中，ListenAddress控制sshd绑定的具体IP地址。若误设为ListenAddress 127.0.0.1，则仅接受本地回环连接，外部请求必然被拒。正确做法是：

# ✅ 推荐：监听所有IPv4接口
ListenAddress 0.0.0.0
# ✅ 或注释掉该行（默认行为即监听全部）
# ListenAddress 127.0.0.1
# ⚠️ 禁止：多个ListenAddress混用时未覆盖全网段

修改后务必执行sudo systemctl restart sshd并验证ss -tlnp | grep :22输出是否含*:22或0.0.0.0:22。

五、云平台网络策略：安全组、网络ACL与NAT网关的三级过滤模型

现代云环境存在三层网络访问控制（按数据流向由外向内）：

1. 安全组（Security Group）：实例级有状态防火墙，必须显式放行入方向TCP 22；
2. 网络ACL（Network ACL）：子网级无状态规则，需同时配置入站与出站22端口；
3. NAT网关/公网IP绑定：确认ECS/EKS实例已分配弹性公网IP（EIP）或绑定NAT网关，且未启用“仅内网访问”模式。

六、综合诊断流程图：结构化排错路径

graph TD
    A[收到 Connection refused] --> B{能否 ping 通?}
    B -->|否| C[检查网络连通性/路由/NIC状态]
    B -->|是| D[执行 telnet IP 22]
    D -->|Connection refused| E[进入服务层诊断]
    D -->|Connected| F[检查Xshell配置/密钥认证]
    E --> G[① systemctl status ssh*]
    G --> H{服务是否active?}
    H -->|否| I[启动并enable服务]
    H -->|是| J[② 检查防火墙]
    J --> K{22端口是否开放?}
    K -->|否| L[配置firewall-cmd/ufw]
    K -->|是| M[③ 检查sshd_config ListenAddress]
    M --> N{是否绑定0.0.0.0?}
    N -->|否| O[修正配置并重启sshd]
    N -->|是| P[④ 登录云控制台检查安全组]

七、进阶避坑指南：5年+工程师易忽略的隐性陷阱

• SELinux处于enforcing模式时，可能阻止sshd绑定端口——执行sudo setsebool -P ssh_port_t 1并检查ausearch -m avc -ts recent日志；
• 某些定制化镜像禁用了root登录且未创建普通用户——检查PermitRootLogin与AllowUsers配置项；
• Docker容器化部署SSH时，宿主机22端口未映射（-p 22:22缺失）或容器内sshd未前台运行（缺少-D参数）；
• IPv6双栈环境下，若sshd_config中AddressFamily inet被强制设置，而客户端通过IPv6连接，亦会触发Connection refused。

八、验证闭环：从客户端到服务端的全链路可观测性验证

完成修复后，必须执行多维度验证：

1. 服务端执行：sudo ss -tlnp | grep ':22' 确认监听状态；
2. 服务端执行：sudo journalctl -u ssh* -n 50 --no-pager 检查启动日志异常；
3. 跳板机/同VPC内其他Linux节点执行：nc -zvw3 192.168.1.100 22 验证内网可达；
4. Xshell启用“Log session to file”后重连，分析日志中是否出现SSH-2.0-OpenSSH_*欢迎字符串；
5. 使用Wireshark在服务端抓包：tcpdump -i any port 22 and host <client_ip>，观察是否有SYN到达及是否返回SYN-ACK。

```