ERR_CONNECTION_REFUSED: 它的含义以及如何完全修复它

ERR_CONNECTION_REFUSED 错误意味着您的浏览器向网络服务器发送了连接请求，该服务器主动拒绝了它——不是忽略它，而是明确拒绝了 TCP 握手。这是一种与超时 (ERR_CONNECTION_TIMED_OUT) 或 DNS 失败 (ERR_NAME_NOT_RESOLVED) 根本不同的故障模式，这种区别在诊断根本原因时至关重要。

实际上，当 Chrome 显示”无法访问此网站。ERR_CONNECTION_REFUSED”时，这意味着以下三种情况之一：目标服务器未在请求的端口上监听，防火墙或安全层向您的客户端发送了 TCP RST（重置）数据包，或者您的本地网络堆栈配置错误，在请求到达服务器之前就将其路由错误。确定这三个类别中哪一个适用于您的情况是找到解决方案的最快途径。

理解TCP级别的机制

大多数浏览器故障排除指南将ERR_CONNECTION_REFUSED视为模糊的”网络问题”。事实并非如此。在TCP层，连接被拒绝意味着服务器（或中介）发送了一个RST/ACK数据包来响应浏览器的SYN数据包。这是一个明确的拒绝，而不是无声的丢弃。

这个区别有一个实际的诊断含义：如果连接被防火墙无声地丢弃，你会看到ERR_CONNECTION_TIMED_OUT。连接被拒绝意味着有东西在主动响应——这意味着主机在网络级别是可达的，但目标端口上的服务不可用或被阻止。

常见的端口级别原因包括：

• Web服务器进程（Apache、Nginx、Node.js）已崩溃或停止
• 服务器在非标准端口上监听，而URL未指定该端口
• 基于主机的防火墙（iptables、ufw、Windows Defender防火墙）拒绝了端口80或443上的连接
• 反向代理（HAProxy、Nginx、Cloudflare）配置不正确，向上游返回RST数据包
• 代理后面的应用程序已崩溃，使代理没有后端可转发到

根本原因：结构化分解

客户端原因

服务器端原因

分步诊断和修复指南

第1步：确定问题是全局问题还是本地问题

在触及任何本地设置之前，请确定网站对所有人都无法访问还是仅对您无法访问。使用这些工具：

• downforeveryoneorjustme.com — 简单的上线/离线检查
• isitdownrightnow.com — 包括响应时间历史
• ping.pe — 同时从多个全球位置ping目标

如果外部节点可以访问该网站，但您的计算机无法访问，则问题是本地的。如果全球无法访问，则问题在服务器端，超出您的控制范围 — 请联系网站管理员或等待。

对于管理自己基础设施的服务器管理员，全球无法访问的网站需要立即调查Web服务器进程、防火墙规则和上游网络。如果您运行VPS Hosting环境，请首先检查服务器的进程列表和防火墙配置。

第2步：验证服务器是否实际在监听（对于服务器管理员）

如果您管理相关服务器，请SSH登录并运行以下命令以确认哪些端口正在监听：

sudo ss -tlnp | grep -E ':80|:443'

如果端口80或443的输出为空，则您的Web服务器进程未运行。重启它：

# For Nginx
sudo systemctl restart nginx

# For Apache
sudo systemctl restart apache2

# Check status
sudo systemctl status nginx

还要验证您的防火墙是否阻止了入站连接：

# Check iptables rules
sudo iptables -L INPUT -n -v

# If using ufw
sudo ufw status verbose

如果端口443被阻止，请允许它：

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw reload

对于运行Dedicated Servers的管理员，还要检查您的托管提供商的上游防火墙或安全组规则是否在网络边界处阻止了该端口 — 这与操作系统级防火墙分开。

第3步：重启路由器并清除本地网络状态

对于客户端问题，路由器重启会清除NAT表、DHCP租约和任何瞬时路由故障。拔掉路由器30秒，然后重新连接。当错误突然出现而没有任何配置更改时，这特别有效。

第4步：清除DNS缓存

指向旧IP地址或已停用IP地址的过期DNS缓存条目是客户端ERR_CONNECTION_REFUSED最常见的原因之一。缓存IP上的服务器可能不再运行目标网站。

• 在Windows上：

ipconfig /flushdns

• 在macOS上（Ventura、Sonoma和大多数现代版本）：

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

• 在Linux上（systemd-resolved）：

sudo systemd-resolve --flush-caches

清除后，验证域名现在解析到的IP：

nslookup example.com
# or
dig +short example.com

将其与网站的已知IP进行比较。如果不同，DNS传播可能仍在进行中。

第5步：清除浏览器缓存和Cookie

在Google Chrome中，导航到chrome://settings/clearBrowserData或使用键盘快捷键：

• Windows/Linux： Ctrl + Shift + Delete
• macOS： Cmd + Shift + Delete

将时间范围设置为所有时间，选中缓存的图片和文件和Cookie及其他网站数据，然后点击清除数据。完全重启Chrome（不仅仅是标签页）后再进行测试。

为了更快地测试而不清除数据，请打开无痕窗口（Ctrl + Shift + N）。如果网站在无痕模式下加载但在正常窗口中不加载，则缓存的资源或浏览器扩展是罪魁祸首。

第6步：审计并禁用代理设置

配置错误或已停用的代理服务器是导致所有网站同时出现ERR_CONNECTION_REFUSED的常见原因。Chrome默认使用系统代理设置。

• 在Windows上：

导航到设置 > 系统 > 代理，如果启用了”使用代理服务器”但您不知情，请禁用它。或者，从提升的命令提示符运行：

netsh winhttp reset proxy

• 在macOS上

转到系统设置 > 网络，选择您的活跃接口，点击详情，然后点击代理标签，取消选中所有活跃代理协议。

禁用代理后，测试网站。如果它加载，则您的代理配置是原因。要么正确重新配置它，要么完全删除它。

第7步：更改您的DNS解析器

您的ISP默认DNS解析器可能返回不正确的结果、经历中断或主动阻止某些域。切换到公共解析器可以消除这个变量。

推荐的公共DNS解析器：

• 在Windows上（通过PowerShell）：

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")

• 在macOS上：

转到系统设置 > 网络 > [您的接口] > 详情 > DNS，删除现有条目，并添加1.1.1.1和1.0.0.1。

• 在Linux上（systemd-resolved）：

编辑/etc/systemd/resolved.conf：

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

然后重启解析器：

sudo systemctl restart systemd-resolved

第8步：临时禁用防火墙和防病毒软件

某些防病毒产品和基于主机的防火墙通过本地代理拦截HTTPS流量，当其检查引擎失败或目标域在黑名单上时，可能会发送RST数据包。临时禁用它们（仅用于诊断目的）可以确认它们是否是原因。

如果禁用安全软件解决了错误，请为目标域添加特定异常，而不是让软件保持禁用状态。测试后立即重新启用它。

第9步：使用不同的浏览器和网络进行测试

在Firefox、Edge或Safari中测试URL。如果它在另一个浏览器中加载，则问题是Chrome特定的 — 可能是损坏的配置文件、故障扩展或Chrome特定的代理设置。尝试创建新的Chrome配置文件来隔离问题。

如果网站在所有浏览器中都失败，请切换到移动热点。如果它通过移动数据加载，则您的ISP或家庭路由器是问题的来源。

第10步：检查SSL/TLS配置问题（服务器管理员）

配置错误的SSL证书可能导致服务器崩溃或拒绝TLS连接，在某些边界情况下Chrome会将其报告为ERR_CONNECTION_REFUSED而不是证书错误。使用以下命令从命令行进行测试：

curl -vI https://yourdomain.com

在详细输出中查找TLS握手阶段。此处的失败表示证书或密码套件问题。您也可以使用以下方式进行测试：

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

如果您的SSL证书已过期或配置错误，更新或替换它可以解决问题。确保您的SSL Certificates有效、正确链接并安装在正确的服务器接口上。

ERR_CONNECTION_REFUSED 与类似浏览器错误的对比

了解此错误与相关错误的区别可防止误诊：

高级边界情况和陷阱

1) IPv6 与 IPv4 解析冲突：

如果域名解析为 IPv6 地址，但您的网络不能正确支持 IPv6，Chrome 可能会尝试 IPv6 连接被拒绝，然后无法快速回退到 IPv4。在网络适配器上临时禁用 IPv6 可以确认这一点。在 Linux 上，您可以使用 curl -4 https://example.com 强制使用 IPv4。

2) Cloudflare 或 CDN 缓存过期的源错误：

如果网站使用 Cloudflare，而源服务器宕机，Cloudflare 可能会在一段时间内提供缓存版本，然后开始返回 521（源拒绝连接）或 522 错误，Chrome 可能会根据错误如何代理而将其显示为 ERR_CONNECTION_REFUSED。

3) Localhost 开发环境：

开发人员在访问 localhost:3000 或类似地址时经常看到 ERR_CONNECTION_REFUSED。原因几乎总是开发服务器进程未运行、崩溃或绑定到 127.0.0.1 上的不同端口。运行 ss -tlnp | grep node（或相关进程）以确认实际监听的内容。

4) 电子邮件服务器端口冲突：

如果您在与 Web 应用程序相同的服务器上运行电子邮件托管，请确保 SMTP（25、587）、IMAP（993）和 HTTP/HTTPS（80、443）之间的端口冲突不会导致 Web 服务器无法绑定。

5) 共享托管限制：

在共享 Web 托管环境中，连接拒绝可能表示托管提供商的服务器过载、账户已被暂停或域名的 DNS 尚未指向正确的共享 IP。检查您的托管控制面板以了解账户状态和 DNS 配置。

实用决策矩阵：首先应用哪个修复

使用此清单进行有效分类：

• 错误同时出现在所有网站上 — 首先检查代理设置和 VPN/防火墙配置
• 错误仅出现在一个特定域上 — 检查网站是否全局宕机；然后刷新 DNS 缓存
• 错误仅在 Chrome 中出现，在其他浏览器中不出现 — 清除 Chrome 缓存、禁用扩展程序或创建新的 Chrome 配置文件
• 错误仅出现在您的网络上，不出现在移动数据上 — 重启路由器；检查 ISP 级别的 DNS 或防火墙
• 错误在服务器配置更改后出现 — 检查 Web 服务器进程状态、端口绑定和服务器上的防火墙规则
• 错误在负载下间歇性出现 — 调查服务器上的资源耗尽（文件描述符、内存、连接限制）
• 错误仅出现在 HTTPS 上，不出现在 HTTP 上 — 调查 SSL 证书有效性和 TLS 配置
• 错误在更改 DNS 设置后出现 — 恢复 DNS 更改并刷新缓存；验证新解析器是否可访问

常见问题

1) ERR_CONNECTION_REFUSED 和 ERR_CONNECTION_TIMED_OUT 有什么区别？

ERR_CONNECTION_REFUSED 表示服务器（或防火墙）主动发送了 TCP 重置数据包，立即拒绝连接。ERR_CONNECTION_TIMED_OUT 表示在超时期间内未收到响应——数据包被无声地丢弃。拒绝连接出现得更快，表示主动拒绝，而超时则表示路由或防火墙 DROP 规则。

2) ERR_CONNECTION_REFUSED 可能由过期的 SSL 证书引起吗？

间接地，可以。在某些服务器配置中，过期或配置错误的 SSL 证书会导致 Web 服务器进程在启动时失败或在处理 TLS 连接时崩溃，导致端口 443 上没有监听器。Chrome 随后报告 ERR_CONNECTION_REFUSED，因为没有任何东西在监听，尽管根本原因是证书问题。

3) 为什么 ERR_CONNECTION_REFUSED 仅在一个特定网站上出现？

如果错误仅限于单个域，最可能的原因是：目标服务器的 Web 服务已崩溃、服务器的防火墙阻止了你的 IP 范围、域的 DNS 记录指向没有运行服务的旧 IP 地址，或者网站已被关闭。使用 curl -v https://thatdomain.com 从不同的网络或服务器运行以隔离原因。

4) 如何修复 localhost 上的 ERR_CONNECTION_REFUSED？

应用服务器未运行或绑定到与你请求的端口不同的端口。使用 Linux/macOS 上的 ss -tlnp 或 Windows 上的 netstat -ano | findstr :PORT 确认正在监听的内容。启动应用服务器进程，并确保它绑定到预期端口上的 0.0.0.0 或 127.0.0.1。

5) 刷新 DNS 总是能修复 ERR_CONNECTION_REFUSED 吗？

仅当根本原因是指向服务不再运行的 IP 地址的过时 DNS 缓存条目时。如果服务器已关闭、防火墙阻止连接或代理配置错误，刷新 DNS 将无效。使用 dig 或 nslookup 在刷新前后验证 DNS 解析，以确认 DNS 是否确实是问题所在。