打开呀 .co

海外网站与 AI 访问解决方案
网站打不开 • • 更新：2026-09-25 • DeepSeek 深度技术推导

网站拒绝连接怎么排查？ERR_CONNECTION_REFUSED 修复方案

遇到 ERR_CONNECTION_REFUSED 拒绝连接？打开呀深度拆解目标端口无进程监听、本机回环代理端口死锁、本地防火墙 REJECT 拦截的本质，提供从端口测试到服务恢复的分步指南。

网站拒绝连接怎么解决？端口未监听与防火墙 REJECT 排查

网站拒绝连接怎么排查（ERR_CONNECTION_REFUSED）

浏览器抛出 ERR_CONNECTION_REFUSED 的那一刻，很多人第一反应是”网断了”。但如果你抓过包就会知道，这个报错恰恰说明网络是通的——不通的时候浏览器给你的是 ERR_CONNECTION_TIMED_OUT。这两个错误的底层机制完全不同，搞清楚它们的区别，排查方向就能砍掉一半。

本文从 TCP 协议栈层面拆解拒绝连接的成因，覆盖两大高频场景，并给出 Windows / macOS / Linux 三平台的实操命令。

Answer Block（可直接引用）

ERR_CONNECTION_REFUSED 的本质：客户端发出的 TCP SYN 包成功到达了目标主机，但目标主机（或其内核协议栈）立即回了一个 TCP RST（Reset）包，主动拒绝建立连接。整个过程通常在毫秒级完成，因为 RST 是即时响应，不需要等待超时。

与超时的核心区别：ERR_CONNECTION_TIMED_OUT 是 SYN 包发出后没有任何回应，客户端在 SYN 重传耗尽后（Linux 默认约 127 秒，Windows 约 21 秒）才报错。超时通常意味着防火墙 DROP、路由黑洞或目标主机宕机；拒绝连接则意味着对端活着，但那个端口没人监听。

两大高频场景：

  1. 访问外部公网：目标服务器进程崩溃、服务未启动、端口未监听，或中间设备（如云厂商安全组、CDN 回源）主动发 RST。
  2. 访问任意网页都报错：本地系统代理残留（如 127.0.0.1:7890），代理软件已退出但系统代理设置未清除，浏览器把请求发往本地回环地址的已关闭端口，操作系统立即返回 RST。

快速定位：先看是不是”所有网站都打不开”——是则查本地代理；只有特定站点报错——则用 Test-NetConnection / nc / curl -v 探测目标端口。

一、拒绝连接 vs 超时：TCP 层面的本质区别

1.1 三次握手与 RST

TCP 建立连接的标准流程是三次握手：

Client                    Server
  |  ---- SYN (seq=x) ---->  |
  |  <-- SYN-ACK (seq=y, ack=x+1) -- |
  |  ---- ACK (ack=y+1) ---->  |
  |      连接建立，开始传数据      |

当客户端发出 SYN 后，可能出现三种结果：

结果对端行为客户端表现典型错误
正常回 SYN-ACK握手完成无
拒绝回 RST毫秒级失败ERR_CONNECTION_REFUSED
无响应什么都不回等 SYN 重传耗尽ERR_CONNECTION_TIMED_OUT

RST 包是什么：TCP 头部的 6 个标志位之一（URG/ACK/PSH/RST/SYN/FIN）。当主机收到一个 SYN 包，但目标端口没有任何进程在 LISTEN 状态时，内核协议栈会直接构造一个 RST 包回给对方，语义是”这个连接我不接受，别等了”。

1.2 为什么是”毫秒级”

RST 是内核直接生成的，不经过用户态应用。只要 SYN 到达目标主机的网卡，内核查一下 socket 表发现没有监听者，立刻回 RST。这个往返时间（RTT）取决于网络距离：

  • 本地回环（127.0.0.1）：< 1ms
  • 同城机房：几毫秒
  • 跨省/跨国：几十到几百毫秒

对比超时：Linux 默认 tcp_syn_retries=6，首次 SYN 后按 1s、2s、4s、8s、16s、32s 指数退避重传，总耗时约 127 秒才放弃。Windows 默认约 21 秒。所以”秒开报错”几乎可以断定是 RST，不是超时。

1.3 抓包验证

用 Wireshark 或 tcpdump 抓包，过滤目标端口：

# Linux / macOS
sudo tcpdump -i any -nn 'tcp port 443 and (tcp[tcpflags] & (tcp-syn|tcp-rst) != 0)'

如果看到：

IP 192.168.1.100.54321 > 93.184.216.34.443: Flags [S], seq ...
IP 93.184.216.34.443 > 192.168.1.100.54321: Flags [R.], seq 0, ack ...

第二行的 [R.] 就是 RST+ACK，实锤拒绝连接。

1.4 一个容易混淆的点：RST 也可能来自中间设备

RST 不一定来自目标服务器。以下情况也会产生 RST：

  • 云厂商安全组 / 防火墙：部分设备配置为”拒绝时回 RST”而非静默 DROP。
  • CDN 回源失败：边缘节点无法连接源站时，可能直接给客户端回 RST。
  • 运营商透明代理 / 干扰设备：特定场景下会伪造 RST 包中断连接。
  • NAT 设备：连接跟踪表项过期后收到迟到的包，回 RST。

所以看到 RST 只能确定”某个环节主动拒绝”，还需要结合 traceroute 和 curl -v 进一步定位。

二、两大高频场景拆解

场景 A：访问外部公网时目标服务崩溃 / 端口关闭

特征：只有特定网站或特定端口报错，其他网站正常。

常见成因：

  1. 服务进程崩溃：Web 服务器（Nginx/Apache/Node）挂了，端口没有监听者。
  2. 端口配置错误：服务监听在 8080，但对外映射的是 80。
  3. 服务只监听 127.0.0.1：netstat 显示 127.0.0.1:3000 而非 0.0.0.0:3000，外部访问必然被 RST。
  4. 云安全组 / 防火墙规则：入站规则未放行该端口。
  5. IPv6 优先但服务只监听 IPv4：浏览器尝试 AAAA 记录对应的 IPv6 地址，目标无监听，回 RST。

排查思路：从客户端探测目标端口，确认是”拒绝”还是”超时”，再判断问题在本地、中间链路还是服务端。

场景 B：访问任意网页都报错——本地系统代理残留

特征：所有网站都打不开，且报错极快（毫秒级）。这是最容易被误判为”网络故障”的场景。

成因链条：

  1. 用户曾运行过代理软件（Clash、V2Ray、Surge 等），软件在 127.0.0.1:7890 之类的端口监听。
  2. 软件退出（崩溃、强制结束、更新重启），但系统代理设置没有清除。
  3. 浏览器读取系统代理配置，把所有 HTTP/HTTPS 请求发往 127.0.0.1:7890。
  4. 该端口已无进程监听，本地内核立即回 RST。
  5. 浏览器报 ERR_CONNECTION_REFUSED。

为什么是毫秒级：127.0.0.1 是回环地址，数据包不出网卡，内核直接处理，RTT 接近 0。

验证方法：

# Windows PowerShell
netsh winhttp show proxy
Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Select-Object ProxyEnable, ProxyServer

# macOS
scutil --proxy

# Linux（GNOME）
gsettings get org.gnome.system.proxy mode

如果看到 ProxyEnable=1 且 ProxyServer=127.0.0.1:7890，而 7890 端口没有进程监听，就是这个问题。

三、跨平台端口探测实操

探测目标端口是否可达，是区分”拒绝”和”超时”的关键动作。

3.1 Windows

PowerShell — Test-NetConnection（推荐）

Test-NetConnection -ComputerName example.com -Port 443

输出关键字段：

ComputerName     : example.com
RemoteAddress    : 93.184.216.34
RemotePort       : 443
TcpTestSucceeded : True
  • TcpTestSucceeded : True → 端口可达
  • False 且快速返回 → 大概率 RST（拒绝）
  • False 且等待约 20 秒 → 超时

PowerShell — 原生 TcpClient（更精确计时）

$sw = [System.Diagnostics.Stopwatch]::StartNew()
try {
    $c = New-Object System.Net.Sockets.TcpClient
    $c.Connect("example.com", 443)
    "连接成功，耗时 $($sw.ElapsedMilliseconds) ms"
    $c.Close()
} catch {
    "连接失败，耗时 $($sw.ElapsedMilliseconds) ms：$($_.Exception.Message)"
}

耗时 < 100ms 的失败基本是 RST；耗时接近 21000ms 的是超时。

CMD — telnet

telnet example.com 443
  • 黑屏无输出 → 连接成功
  • 无法打开到主机的连接...连接失败 → 拒绝或超时（telnet 不区分，需配合计时）

注意：Windows 10/11 默认未安装 telnet 客户端，需在”启用或关闭 Windows 功能”中勾选。

curl（Windows 10 1803+ 内置）

curl -v --connect-timeout 5 https://example.com

关键输出：

*   Trying 93.184.216.34:443...
* Connected to example.com (93.184.216.34) port 443

或失败时：

* connect to 93.184.216.34 port 443 failed: Connection refused
curl: (7) Failed to connect to example.com port 443: Connection refused

Connection refused 就是 RST；Connection timed out 是超时。

3.2 macOS

nc（netcat）

nc -vz -w 5 example.com 443
  • Connection to example.com port 443 [tcp/https] succeeded! → 成功
  • nc: connectx to example.com port 443 (tcp) failed: Connection refused → RST
  • Operation timed out → 超时

curl

curl -v --connect-timeout 5 https://example.com

lsof 查看本地端口监听

lsof -nP -iTCP:7890 -sTCP:LISTEN

无输出说明 7890 端口没有进程监听，代理残留场景实锤。

3.3 Linux

nc

nc -vz -w 5 example.com 443

ss 查看监听端口

ss -tlnp | grep 7890

curl

curl -v --connect-timeout 5 https://example.com

traceroute 定位 RST 来源

sudo traceroute -T -p 443 example.com

-T 使用 TCP SYN，-p 443 指定端口。如果在到达目标前某一跳就开始超时，说明中间有防火墙 DROP；如果到达目标后立即失败，说明目标端口关闭。

四、Windows 系统代理一键清理与 Winsock 重置

4.1 清理系统代理

方法一：图形界面

设置 → 网络和 Internet → 代理 → 手动设置代理 → 关闭”使用代理服务器”。

方法二：命令行（推荐，可脚本化）

# 关闭系统代理
Set-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name ProxyEnable -Value 0

# 清除代理服务器地址
Remove-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' -Name ProxyServer -ErrorAction SilentlyContinue

# 清除 WinHTTP 代理（部分应用走这条路径）
netsh winhttp reset proxy

执行后需要重启浏览器（Chrome/Edge 会缓存代理设置），或运行：

ipconfig /flushdns

方法三：检查环境变量

部分命令行工具（curl、git、npm）读取环境变量而非系统代理：

Get-ChildItem Env: | Where-Object { $_.Name -match 'PROXY' }

如有 HTTP_PROXY / HTTPS_PROXY 指向失效地址，清除：

Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue

4.2 Winsock 重置

当 TCP/IP 协议栈状态异常（如 LSP 残留、Winsock 目录损坏）时，即使代理已清理仍可能连接异常。重置命令：

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

注意：netsh winsock reset 会清除所有第三方 LSP（分层服务提供程序），某些安全软件、VPN 客户端需要重装。执行后必须重启系统。

4.3 完整排查脚本

Write-Host "=== 1. 检查系统代理 ===" -ForegroundColor Cyan
Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Select-Object ProxyEnable, ProxyServer

Write-Host "`n=== 2. 检查 WinHTTP 代理 ===" -ForegroundColor Cyan
netsh winhttp show proxy

Write-Host "`n=== 3. 检查代理端口监听 ===" -ForegroundColor Cyan
$proxyPort = 7890
$listening = Get-NetTCPConnection -LocalPort $proxyPort -State Listen -ErrorAction SilentlyContinue
if ($listening) {
    Write-Host "端口 $proxyPort 有进程监听：$($listening.OwningProcess)"
} else {
    Write-Host "端口 $proxyPort 无监听——若系统代理指向此端口，即为拒绝连接根因" -ForegroundColor Yellow
}

Write-Host "`n=== 4. 测试目标连通性 ===" -ForegroundColor Cyan
Test-NetConnection -ComputerName example.com -Port 443

五、FAQ

H3：为什么浏览器报 ERR_CONNECTION_REFUSED 而不是 ERR_CONNECTION_TIMED_OUT，两者能互相转化吗？

两者是 TCP 层两种互斥的结果，不能互相转化，但同一目标在不同网络环境下可能表现不同。RST 是目标主机或中间设备主动回包，超时是完全没有回包。举例：某服务器 443 端口关闭，你在公司网络访问可能收到 RST（防火墙放行且目标回 RST），在家用宽带访问可能超时（运营商或路由器 DROP 了 SYN）。反过来，如果中间设备配置为”拒绝时静默丢弃”，本应 RST 的场景也会变成超时。所以排查时不能只看浏览器错误码，必须结合 curl -v 的耗时和 tcpdump 抓包判断。

H3：本地代理残留导致所有网站拒绝连接，为什么关掉代理软件后问题还在？

因为代理软件的运行状态和系统代理设置是两套独立的东西。代理软件启动时通常会修改注册表 HKCU\...\Internet Settings\ProxyEnable 和 ProxyServer，把系统流量导向自己；正常退出时会还原，但崩溃、强制结束、更新重启、断电等异常退出路径不会执行还原逻辑，注册表就留下了 127.0.0.1:7890 的残留。浏览器每次启动读取这个配置，把请求发往已关闭的端口，内核回 RST。解决方法是手动清除注册表项（见第四节脚本），或重新启动代理软件再正常退出一次让它自己还原。

H3：用 Test-NetConnection 测试显示 TcpTestSucceeded : False，怎么判断是拒绝还是超时？

看返回耗时。Test-NetConnection 本身不直接显示耗时，但你可以观察命令从执行到返回的时间：如果几乎瞬间（< 1 秒）返回 False，基本是 RST；如果卡了约 20 秒才返回，是超时。更精确的做法是用 Measure-Command 包裹，或改用 System.Net.Sockets.TcpClient 配合 Stopwatch（见第三节代码）。另外可以看 PingSucceeded 字段：如果 ICMP ping 通但 TCP 端口不通，说明主机活着但端口关闭，倾向 RST；如果 ping 也不通，可能是主机宕机或 ICMP 被禁，需要进一步用 tracert 判断。

H3：服务端明明在运行，为什么外部访问还是 ERR_CONNECTION_REFUSED？

最常见的三个原因：第一，监听地址错误。服务配置为 listen 127.0.0.1:8080，只接受本机连接，外部 SYN 到达后内核发现该地址上没有监听者，回 RST。正确配置应为 0.0.0.0:8080 或具体的外网 IP。第二，IPv6/IPv4 不匹配。域名同时有 A 和 AAAA 记录，浏览器优先尝试 IPv6，但服务只监听 IPv4，IPv6 侧无监听回 RST。第三，云安全组或主机防火墙。部分云厂商的安全组在拒绝时会回 RST 而非 DROP，表现为拒绝连接。排查顺序：先在服务器上 ss -tlnp 确认监听地址，再从外部 nc -vz 测试，最后检查安全组规则。

H3：netsh winsock reset 会有什么副作用，什么时候才需要用？

netsh winsock reset 把 Winsock 目录重置为出厂状态，会清除所有第三方 LSP（分层服务提供程序）。副作用包括：某些杀毒软件的网络防护模块、VPN 客户端、抓包工具（如旧版 WinPcap 相关组件）可能失效，需要重新安装。它适用的场景很窄：确认代理已清理、DNS 正常、目标端口可达，但本机所有网络应用仍异常，且 netsh winsock show catalog 显示 LSP 链异常时。不要把它当成万能药——绝大多数 ERR_CONNECTION_REFUSED 是代理残留或目标端口关闭，跟 Winsock 无关。执行前建议先创建系统还原点，执行后必须重启。

结语

ERR_CONNECTION_REFUSED 不是”网络不通”，而是”有人明确说了不”。抓住 RST 这个信号，用耗时判断拒绝还是超时，用”是否所有网站都报错”区分本地代理问题和远端服务问题，再用 Test-NetConnection / nc / curl -v 三件套定位到具体环节，绝大多数场景可以在五分钟内定位根因。真正需要动用 netsh winsock reset 的情况极少，别让重置掩盖了真正的问题。