502 和 504 到底有什么区别？

两者都是网关（反向代理）发出的，区别在「上游有没有回」：502 Bad Gateway 是网关收到了上游的响应，但响应本身无效或不符合预期；504 Gateway Timeout 是网关等上游等到超时，压根没拿到响应。所以 502 说明上游还活着但回错了，504 说明上游没在时限内回。

503 是不是就代表服务器挂了？

不一定。503 Service Unavailable 表示服务当前不可用，常见于过载、维护中、或后端全部不可用。服务器本身的进程和网络可能都还正常，只是应用层拒绝提供服务。所以看到 503 先查应用的负载和维护状态，而不是先去查服务器是否宕机。

5xx 是网站挂了还是网络问题？

5xx 是服务器侧产生的响应。能返回 5xx，说明网络是通的、服务器也在工作，只是它处理请求时出了问题。判断依据是全国节点是否一致：本文实测三个状态码在 59–60 个地区表现一致，这种情况下问题在源站；只有少数地区出 5xx 才要怀疑线路或 CDN 边缘节点。

拨测显示「节点成功」，页面却打不开，是什么情况？

「节点成功」只表示探针连上了服务器并拿到了 HTTP 响应，不代表响应是正常的。返回 502、503、504 都算成功拿到响应。所以看结果要同时看两个维度：成功/失败回答「连没连上」，状态码回答「服务器回了什么」。

只有部分地区返回 5xx，该怎么查？

先看返回 5xx 的节点是否集中在特定运营商或省份，再看这些节点解析到的响应 IP 是否落在 CDN 的地址段。集中在小范围通常是 CDN 某个边缘节点或某条线路的问题；全网一致则回到源站和应用本身。

怎么自己复现文中的测试？

打开宝塔拨测的网站测速页 https://t.bt.cn/http/ ，输入要测的地址发起拨测，结果页会给出各节点的 HTTP 状态码分布、响应时间和失败节点明细。

502、503、504 分别是谁的问题？三个状态码各做一次全国拨测，附三步定位

502、503、504 三个码长得像，责任方完全不同：502 是网关收到了上游的无效响应，504 是网关等上游等到超时，503 是服务自己说「暂时不可用」。三者的共同点是——它们都由服务器侧发出，所以能返回 5xx，就说明网络是通的、机器也在工作。

但仅凭「知道含义」不足以定位。真正有用的问题是：这次 5xx 是全网都在报，还是只有几个地区在报？本文用宝塔拨测（t.bt.cn）对三个状态码各做了一次全国 HTTP 拨测，用分布数据回答这个问题。

502、503、504 分别是谁的问题

状态码	直译	谁发出的	一句话判断
502 Bad Gateway	网关错误	反向代理（Nginx 等）	上游回了，但回的内容无效
503 Service Unavailable	服务不可用	应用本身或网关	服务主动拒绝，过载/维护/后端全挂
504 Gateway Timeout	网关超时	反向代理	上游没回，等到超时

关键区别在中间那一列。502 和 504 都是网关在替上游「传话」，区别是传到了一个坏答复（502）还是根本没等到答复（504）；503 则是服务明确表态「现在不接客」，它的后端可能是健康的，只是被限流、在重启、或在维护。

实测：同一个 5xx 在全国是什么样

对三个可复现的测试地址各发起一次网站测速（HTTP）拨测，采集时间 2026-10-27 14:39–14:42（北京时间）。三个目标的节点规模一致，状态码分布如下：

目标状态码	节点完成	返回到该状态码	成功率	覆盖地区
502	389	387	99%	59 个
503	390	389	99%	60 个
504	388	387	98.5%	60 个

三组数据呈现出同一个形态：几乎所有节点都返回了同一个状态码。以 502 为例，389 个成功节点里有 387 个拿到 502，另外各 1 个拿到 403 和 404——这两个是零星个例，不是趋势。

这个形态本身就是结论：当 5xx 在几十个地区同时、同码出现，问题在源站或应用，不在网络。 网络故障做不到让 59 个地区的探针整齐地收到同一个 502——线路不通会表现为连接失败、超时、丢包，而不是服务器礼貌地回一个状态码。

三者的耗时差异，比状态码本身更能说明位置

同一批目标的总耗时中位数差异明显：

状态码	总耗时中位数	p95	最快节点	最慢节点
502	535.7 ms	1505.2 ms	33.2 ms	6523.4 ms
503	249.7 ms	920.6 ms	16.5 ms	4452.7 ms
504	525.1 ms	1549.8 ms	32.7 ms	7172.1 ms

503 的中位数约为 502、504 的一半，这与三者的机制吻合：502 和 504 都要等上游（要么等到一个坏答复，要么等到超时），天然更慢；503 往往是服务器自己立刻拒绝，不用走完上游调用，天然更快。

这个规律可以用来反推：如果你看到一个 5xx 响应很快（几十到两三百毫秒），更可能是应用层直接拒绝（503 一类的过载/维护）；如果明显偏慢、接近网关的超时阈值，则更像上游没回（504）或上游半死不活（502）。

同时注意 p95 和最慢节点：502 的 p95 已达 1505.2 ms，最慢节点 6523.4 ms。5xx 场景下的长尾比正常响应更长，这也解释了为什么用户体感是「转很久然后报错」而不是「立刻报错」。

运营商之间的差异依然存在

即使所有节点都收到 502，耗时也不是全网一样。同一次 502 拨测按运营商分组：

分组	节点数	平均耗时
电信	134	804.8 ms
移动	117	699.1 ms
联通	95	624.1 ms
港澳台	7	441.9 ms
海外	39	351.6 ms

电信与海外之间的差距超过一倍。这说明状态码判断「是不是源站的问题」，运营商数据判断「慢在哪条线」，两件事要分开看——不能因为「全网都是 502」就认为线路没有差异，也不能因为「电信慢」就认为 502 是电信造成的。

三步定位：先看分布，再看耗时，最后看失败节点

第一步，看状态码是否全网一致。

几十个地区都是同一个 5xx → 源站或应用问题，去查 Nginx 错误日志和上游服务状态。
只有少数地区 5xx → 查这些节点是否集中在某运营商/省份，以及响应 IP 是否落在 CDN 段。

第二步，看耗时落在哪一档。

快（百毫秒级）→ 应用直接拒绝，查负载、限流、维护开关、后端进程是否存活。
慢（接近网关超时）→ 上游没回或回得极慢，查上游服务是否卡死、数据库是否慢查询。
长尾特别长 → 说明请求在超时边界上挣扎，用户会感到「卡很久才报错」。

第三步，看失败节点集中在哪。 本次 502 拨测有 4 个节点失败：湖北恩施电信域名解析超时、湖北武汉联通请求超时、陕西汉中移动请求超时、广西桂林电信任务超时。这些都是探针侧或链路侧的超时，不是目标返回了别的状态码。 少数节点失败不等于目标不可用，判断时要看失败原因的 message，而不是只看失败数。

三个常见误判

误判一：把「节点成功」当成「网站正常」。 成功只代表拿到了 HTTP 响应，502/503/504 都是成功的响应。必须同时看状态码。

误判二：看到 5xx 就去查 DNS 和防火墙。 5xx 恰恰证明网络和解析是通的——请求已经打到服务器并拿到了回应。这时候查 DNS 是浪费时间的。

误判三：用单个节点或单个地区的结果下结论。 本次 502 拨测里有 1 个节点返回 403、1 个返回 404，如果只看这两个节点，就会得出完全错误的结论。要看分布，不看个例。

怎么自己跑一次

打开宝塔拨测的网站测速页 t.bt.cn/http/，填入要测的地址发起拨测，结果页会给出各节点的 HTTP 状态码分布、成功率、响应时间与异常节点明细。判断顺序就按上面三步：先看状态码是否全网一致，再看耗时档位，最后看失败节点集中在哪里。

信息来源

状态码语义以宝塔官方文档《使用宝塔拨测》为准（该文档说明网站测速可查看「成功率、响应时间、状态码和异常节点」）。文中拨测数据为 2026-10-27 14:39–14:42（北京时间）对三个可复现测试地址的真实 HTTP 拨测结果，覆盖 59–60 个地区。拨测节点池与线路状况随时变化，上述数值仅代表采集时刻的情况。