linux网络故障排查时，连接被拒绝与连接超时应该先区分什么

先看失败类型：是收到拒绝，还是一直等不到回应

一次 Linux网络故障往往从很简单的报错开始：业务访问接口失败，ssh 登录不上，curl 提示连接失败，监控显示端口不可用。此时不要急着重启服务，也不要先改防火墙。第一步应把现象拆开：客户端到底是收到了“拒绝”，还是发出连接请求后一直没有回应。

在 TCP 场景下，Connection refused 通常表示目标地址可达，并且对端返回了 RST，说明该端口没有进程监听，或者有策略主动拒绝连接；Connection timed out 通常表示 SYN 发出后没有完成三次握手，可能是链路不通、路由错误、防火墙丢弃、目标主机不可达，或者回程路径有问题。排查顺序建议是：先在客户端确认目标 IP、端口和路由；再到服务端确认端口监听；随后检查本机防火墙和访问控制；最后看服务状态、应用日志和抓包结果。这个顺序能避免把链路问题误判成服务问题，也能避免把服务未监听误判成网络不通。

连接被拒绝与连接超时的判别依据

Linux服务器连接被拒绝和 Linux服务器连接超时的根本差异，不在报错文字本身，而在 TCP 握手过程。

现象	TCP 层表现	常见原因	优先检查点
`Connection refused`	客户端发出 SYN，对端返回 RST	服务未监听、监听地址不对、防火墙 reject、端口映射错误	服务端 `ss`、服务状态、防火墙 reject 规则
`Connection timed out`	客户端发出 SYN 后长时间无响应，反复重传	路由不通、防火墙 drop、目标主机不可达、回程路由异常	客户端路由、服务端抓包、防火墙 drop、网关与回程
`No route to host`	本机路由或中间网络直接返回不可达	路由缺失、网关不可达、ICMP 不可达	`ip route get`、网关连通性
应用读超时	TCP 已连接，但应用没有及时返回数据	应用卡死、后端慢、代理超时	应用日志、连接状态、后端依赖

需要注意，ping 不能作为唯一依据。ICMP 被禁用时，ping 失败不代表 TCP 端口不可用；ping 成功也不代表业务端口已经监听。排查端口类问题，应优先使用 TCP 工具验证。

先从客户端排除外部因素

客户端侧的目标是确认三件事：访问的 IP 是否正确，端口是否正确，数据包是否有路由可走。DNS、端口写错、访问了旧 IP，这类问题很常见，但容易被误认为服务器异常。

可以先在客户端执行：

getent hosts example.com
ip route get SERVER_IP
nc -vz -w 3 SERVER_IP PORT
curl -v --connect-timeout 3 http://SERVER_IP:PORT/

将 SERVER_IP 和 PORT 替换为实际目标。结果可以这样理解：

nc 很快返回 succeeded：TCP 端口可连接，问题可能在应用协议、认证、代理或后端。
nc 返回 Connection refused：对端主动拒绝，优先查服务端是否监听该端口。
nc 等待数秒后超时：优先查链路、路由、防火墙 drop 或回程路径。
ip route get 没有合理出口：客户端本机路由或网关配置有问题。

如果是域名访问失败，还要确认解析结果是否符合预期：

dig +short example.com

同一个故障，建议至少从两个位置验证：故障客户端、同网段另一台主机，必要时再从服务端本机反向验证。这样可以区分“单个客户端问题”和“服务端对所有来源不可用”。

在服务端确认端口是否真的监听

当客户端看到 Connection refused 时，服务端监听状态是第一检查项。不要只看服务进程是否存在，进程存在不等于端口已经监听。

在服务端执行：

ss -ltnp

如果只想看指定端口：

ss -ltnp 'sport = :PORT'

重点看两列：Local Address:Port 和 Process。

常见判断如下：

0.0.0.0:PORT：监听所有 IPv4 地址，远端理论上可以访问，后续查防火墙和路由。
127.0.0.1:PORT：只监听本机回环地址，远端访问会失败。
SERVER_IP:PORT：只监听指定网卡地址，需确认客户端访问的就是该地址。
[::]:PORT：监听 IPv6，是否同时接受 IPv4 取决于系统和应用配置。
查不到端口：服务未启动、启动失败、配置端口不一致，或应用还没完成监听。

可以在服务端本机分别访问回环地址和服务器地址：

curl -v --connect-timeout 3 http://127.0.0.1:PORT/
curl -v --connect-timeout 3 http://SERVER_IP:PORT/

如果 127.0.0.1 可访问，但 SERVER_IP 不可访问，多半是监听地址或本机防火墙问题。如果服务端本机访问正常，而远端超时，则更可能是入站策略、链路或回程路由问题。

检查服务状态与启动日志

端口没有监听时，再看服务状态。不同发行版和应用名称不同，命令中的 SERVICE_NAME 需要替换为实际服务，例如 nginx、sshd、mysql、redis 等。

systemctl status SERVICE_NAME --no-pager
journalctl -u SERVICE_NAME -n 100 --no-pager

如果服务刚改过配置，应先做语法检查，再 reload 或 restart。以 Nginx 为例：

nginx -t
systemctl reload nginx

不要在未确认配置正确时直接重启关键服务。对 SSH、防火墙、远程管理类服务尤其要谨慎，错误配置可能导致远程连接中断。

几类常见问题值得重点看：

端口被其他进程占用，日志中可能出现 Address already in use。
应用配置只绑定 127.0.0.1，例如数据库、缓存服务常见。
服务启动失败，但进程管理器反复重启，表面看服务“在运行”，实际端口不断消失。
容器内服务监听正常，但宿主机没有发布端口，远端访问宿主机端口会失败。

防火墙要区分 reject 和 drop

防火墙策略是 Linux服务器连接被拒绝与连接超时之间最容易混淆的点。主动 reject 可能让客户端看到 Connection refused；静默 drop 更容易表现为 Connection timed out。

常见检查命令如下，具体使用哪一个取决于系统启用的防火墙组件：

nft list ruleset
iptables -S
firewall-cmd --state
firewall-cmd --list-all
ufw status verbose

如果服务器使用 firewalld，可以查看当前区域和端口：

firewall-cmd --get-active-zones
firewall-cmd --list-ports
firewall-cmd --list-services

临时放行端口前，应确认变更窗口和来源范围。不要为了排障直接开放所有来源、所有端口。较安全的做法是先按来源 IP 放行，再验证，再决定是否持久化。

例如使用 firewalld 临时放行指定 TCP 端口：

firewall-cmd --add-port=PORT/tcp

验证无误后再持久化：

firewall-cmd --runtime-to-permanent

如果使用 UFW，可以按来源限制：

ufw allow from CLIENT_IP to any port PORT proto tcp

涉及防火墙修改时，建议保留当前规则输出，便于回滚：

nft list ruleset > /root/nft-rules-backup.txt
iptables-save > /root/iptables-backup.txt

这类备份不会改变现有策略，只是保存当前状态。

路由与回程问题常表现为超时

如果客户端显示连接超时，而服务端确认进程已经监听，下一步要看数据包是否到达服务端，以及服务端是否能把响应包发回去。

服务端先看地址和路由：

ip addr
ip route
ip route get CLIENT_IP

ip route get CLIENT_IP 很有用，它能告诉你服务端访问该客户端时会走哪个出口、哪个源地址。如果回程走错网卡，客户端可能看不到 SYN-ACK，最终表现为超时。

多网卡服务器、策略路由、VPN、容器网络、NAT 环境中，回程异常更常见。此时不能只看入站链路，还要确认响应包是否按预期返回。若服务器启用了严格反向路径检查，也可能丢弃看似“来源异常”的数据包。可以查看：

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter

是否调整该项要结合网络拓扑判断，不建议在不了解影响范围时直接修改。

用抓包把争议落到数据包上

当命令结果互相矛盾时，抓包是最直接的证据。抓包前先确认网卡名称，不确定时可用 any：

tcpdump -ni any host CLIENT_IP and tcp port PORT

从服务端观察客户端连接时，常见结果解释如下：

抓包结果	说明	下一步
服务端完全看不到客户端 SYN	数据包没有到达服务端	查客户端路由、中间防火墙、网关、访问目标 IP 是否正确
看到 SYN，马上回 RST	服务端 TCP 栈或防火墙主动拒绝	查端口监听、防火墙 reject、应用绑定地址
看到 SYN，但没有 SYN-ACK	本机防火墙 drop、内核策略或抓包位置前后差异	查 nftables/iptables、rp_filter、安全策略
看到 SYN 和 SYN-ACK，但没有客户端 ACK	回程路径或客户端侧策略异常	查服务端回程路由、客户端防火墙、中间链路
三次握手完成，之后应用无响应	不是端口连通性问题	查应用日志、后端依赖、进程阻塞

客户端也可以抓包对照：

tcpdump -ni any host SERVER_IP and tcp port PORT

客户端看到 SYN 不断重传，而服务端完全看不到 SYN，问题在到达服务端之前。服务端看到 SYN-ACK 发出，而客户端看不到 SYN-ACK，问题在回程路径或中间策略。

修复时按故障类型处理，不要混合改动

定位到原因后，修复动作要尽量单一。一次只改一个变量，便于确认效果。

服务未监听或监听地址错误

先确认应用配置。不同服务配置文件不同，以下只是常见方向：

Nginx：检查 listen 指令是否为目标端口。
SSH：检查 /etc/ssh/sshd_config 中的 Port、ListenAddress。
MySQL/MariaDB：检查 bind-address 是否只绑定 127.0.0.1。
Redis：检查 bind、protected-mode 等配置，注意不要直接暴露到不可信网络。

修改后先做配置检查，再重载或重启。对 SSH 这类远程管理服务，建议保留一个已登录会话，确认新连接成功后再退出旧会话。

防火墙阻断

确认是防火墙导致后，优先添加精确规则，例如只允许业务来源 IP 或网段访问指定端口。避免使用“临时关闭防火墙”作为默认修复方式。若必须临时关闭验证，也要明确窗口、记录当前规则，并在验证后恢复。

路由或网关异常

如果 ip route get 显示出口不符合预期，应检查默认路由、静态路由、策略路由和网卡配置。临时路由可用于验证，但生产环境需要写入对应发行版的持久化网络配置。不同系统可能使用 NetworkManager、systemd-networkd、Netplan 或传统 network-scripts，修改前要先确认当前管理方式。

修复后的回归检查

故障修复后，不要只看一次连接成功。至少从客户端、服务端和日志三个角度回归。

客户端验证：

nc -vz -w 3 SERVER_IP PORT
curl -v --connect-timeout 3 http://SERVER_IP:PORT/

服务端验证：

ss -ltnp 'sport = :PORT'
journalctl -u SERVICE_NAME -n 50 --no-pager

如果改过防火墙，还要确认规则是否符合预期，并确认是否需要持久化：

firewall-cmd --list-all
ufw status verbose
nft list ruleset

如果故障曾表现为超时，建议短时间观察连接状态：

ss -ant state syn-recv
ss -ant state established

持续观察项可以包括：端口监听是否稳定、服务是否反复重启、连接数是否异常增长、防火墙日志是否持续命中拒绝规则、应用日志是否还有超时或后端错误。对于 Linux 网络故障排查来说，能把“拒绝”和“超时”先分清，后续定位就会从猜测变成按证据推进。

Linux运维网络故障端口排查防火墙服务监听

上一篇 日本名古屋云服务器和大阪云服务器面向关西用户，延迟与交付如何比较