ERR_CONNECTION_REFUSED是什么意思？被拒绝、干等、被掐断，Chrome三种连不上是三种病

上个月表弟在家庭群里@我，说家里的Jellyfin打不开了，Chrome给他甩一行绿字：ERR_CONNECTION_REFUSED。隔了俩礼拜，我去我妈家想开NAS的管理页，报的又是另一串：ERR_CONNECTION_TIMED_OUT。两回都是「网页打不开」，病根差了十万八千里——头一回是Docker容器挂了端口没人听，第二回是我IP敲错了一位，敲到一个压根没人用的地址上。

这两回折腾完我才意识到，Chrome报错那行小字其实是份病历本。同是连不上，被拒绝、干等、被掐断，方向完全不一样，无脑重启路由器是最浪费时间的动作。

先看清楚这一步卡在哪：门牌找到了，卡在敲门口

Chrome的报错分好几层，看到ERR_CONNECTION开头，有个好消息：问路那步已经过了。网址变成IP是DNS干的活，那一步失败报的是「服务器DNS地址找不到」或者NXDOMAIN这种字样，我上一篇刚写过怎么分诊。都报到ERR_CONNECTION了，说明门牌号已经攥在手里，卡的是下一步——拿着门牌去敲门。

敲门在TCP里叫三次握手，一句话就能说明白：你敲一下门（SYN），里面回一声「请进」（SYN+ACK），你再应一句「收到」（ACK），这三步全走完，连接才算建好，才开始传网页内容。TCP和UDP那篇讲过这套流程，这里只要记住一点：ERR_CONNECTION全家桶，全是卡在敲门口或刚进门那一下，网页内容一个字节都还没传。

同样是敲门失败，失败的样子有三种，对应三个不同的报错词。把它们分开，排查方向就定了一半。

报错小字在哪看？Chrome和Edge都一样，页面正中央一行大字底下有行小字，再往下还有个「重新加载」按钮。多数人盯着大字「无法访问此网站」就慌了，值钱的信息全在那行小字里。实在看不清，按F12打开开发者工具切到Console标签页，报错原文会原样躺在那里，复制下来搜都方便。还有个更土的分法不用读字：秒报错的多半是被拒绝，转圈半天才死心的是干等，聊到一半断的是被掐——报错的速度本身就是个分诊信号。

REFUSED被拒绝：门口有人，冲你喊「这家没开门」

这是三个里最「痛快」的一种，报错来得飞快，一两秒就甩你脸上。翻译成人话：你的敲门声送到了那台机器，机器也活着，但那个端口上没有任何程序在听，系统直接回你一个RST包——相当于门里有人冲你喊，这儿没你要找的服务，走错门了。

这个报错的含金量其实很高：网是通的，IP是对的，机器也活着，三个前提全确认了，只剩「端口上没程序」这一个嫌疑。所以排查方向是服务端，别去动路由器。我家踩过的坑就三种来路：

表弟那回就是头一种。他Jellyfin是host网络跑的，前一晚NAS更新完容器没爬起来，端口空了一整夜。SSH进去看一眼容器状态的事，开SSH那篇里有现成命令。顺手说一句，容器类服务挂掉还有个高频帮凶是内存被挤爆，升级容器那篇提过重启不等于修复的老坑，这里一样适用。

还有一种被拒绝容易冤到路由器头上：从外面访问自家路由器或光猫的后台。这些管理页默认只对内网开着，你拿流量去敲它的公网地址，多数设备直接回一个拒绝——这不是坏了，是人家故意不开门。想从外面管家里设备，正路是走远程管理App或者VPN回家，硬敲管理端口既敲不开也不该敲开。

TIMED_OUT干等：门敲出去了，里头一点动静没有

这种最磨人。点开网页转圈，转上二十来秒才死心，报ERR_CONNECTION_TIMED_OUT。机理上是你敲门的那一下发出去就石沉大海，没人应答也没人拒绝，Chrome干等到超时窗口耗尽自己放弃。

它冤就冤在分不清两种完全不同的情况：一种是门牌本身敲错了，另一种是有人把你的敲门声半路扔了。表现一模一样，都是干等。

门牌敲错在家用环境特别常见。网段里没人用的IP，比如192.168.31.99，敲过去连ARP都找不到对象；设备关机了、NAS断电了，同一个下场。我妈家那回就是我把31.10手滑敲成31.1，那个地址上是路由器，管理端口压根没开，白等二十秒。

被半路扔包的典型是防火墙的DROP策略——不吭声地丢，比拒绝还让人摸不着头脑。家用场景里最有名的一个：运营商把家宽的80和445入站方向封了，你从外面访问家里这些端口，就是干等。这不是你机器的错，SMB那篇讲445被封时提过这个机制。还有种更根本的：你家压根没公网IP，地址是100.64开头的运营商大院门牌，公网IP那篇教过怎么自查，这种情况下从外面敲什么都是白敲。

分辨两种情况的土办法就一招：换个网络再敲一次。手机关WiFi用流量访问，流量能通家里不通，是路径上的事；两边都干等，回头查门牌本身。再进阶一点可以换端口对照：同一台机器上别的端口响应麻利，就某一个端口干等，八成是这个端口被针对性丢了包，而不是机器不在——运营商封端口、防火墙按端口放行，都是这种「挑着扔」的表现。

还有一个特别容易忽视的干等制造者：自己电脑上残留的代理。加速器、抓包工具退出了没把系统代理还回去，浏览器拿着一个早就不工作的代理地址去敲门，包发出去就没了下文。这种通常的表现是「有的网站干等、微信却正常」，代理和SOCKS5那篇有三层清理办法，排TCP问题前值得先花十秒看一眼代理开关。

RESET和空回应：门开了，聊两句被轰出来

第三种跟前面俩都不一样，连接明明建好了，网页内容传到一半，突然杀出一个RST把线掐断，Chrome报ERR_CONNECTION_RESET。好比门开了你刚坐下说两句，被人拎着领子轰出去。病根基本都在对面：服务进程传着传着当场崩了、防火墙策略半路掐线、设备过载重启，你自己这边没什么可修的。

它还有个孪生兄弟叫ERR_EMPTY_REPLY。我自己在本机起过一个测试服务做过实验：让它接受连接之后立刻断开，一个字节都不回，浏览器端看到的就是这种报错——门开了，探头看了一眼，啥也没说。跟RESET的区别就一句话：一个是聊着聊着被轰，一个是开门看一眼就关门。两种都指向对面服务的问题，要么等它缓过来，要么去修它。

四步走完，别跳步

我的顺序习惯是：先分范围，再读小字，然后换网络对照，动服务端放在末位。表弟那回要是先做第二步，看见REFUSED直接去看容器，五分钟就完事，实际是他重启了三遍路由器、把光猫也重启了一遍，折腾一晚上。

记住一句就够：被拒绝查端口，干等查门牌和路，被掐断看对面。下次Chrome再甩你一行绿字，先念一遍这句，动手的方向就错不了。