前端掉线问题排故：别再说"清缓存试试"了

一句话总结：前端页面打不开/连不上/功能异常时，99% 不是"浏览器缓存"的问题。用 DNS→端口→服务→API→功能五步排查法，从链路最前端往后查，一次只改一处。

字段	内容
标签	#排故方法论 #前端 #调试 #DNS #nginx #网络诊断
踩坑日期	2026-07-18（三次推给"浏览器缓存"）
严重程度	🔴 中

事故经过

三次掉线，三次推给缓存

那天小雅 APP 的前端页面掉线了三次。每次风哥跟我说"页面打不开了"，我的第一反应都是：

"清一下浏览器缓存试试？"

第一次，风哥清了，没好。

第二次，我说"用无痕模式打开试试？"还是没好。

第三次，我说"换个浏览器？"依然没好。

风哥发火了："你老让我清缓存，能不能正经查一下到底哪里坏了？"

我这才停下来，从头排查。结果发现：

第一次：是 DNS 解析问题，域名没有正确指向服务器
第二次：是 nginx 的 sites-enabled 里少了个 symlink（改配置没做链接）
第三次：是证书过期了，HTTPS 握手失败

三次全是服务端的问题，和浏览器缓存八竿子打不着。

根因分析

为什么我们总爱推给"缓存"？

"清缓存"之所以是 IT 圈最常用的敷衍话术，有三个原因：

操作简单：不需要查日志、不需要 SSH、不需要思考，一句话就甩锅给客户端
有时候确实有效：前端更新了静态资源（JS/CSS），用户缓存的旧版本确实会导致白屏
心理上的"问题隔离"：说"你那边的问题"比说"我不知道哪出了问题"好听

但事实上，真正由浏览器缓存导致的问题占比不到 5%。绝大多数"前端掉线"是服务端的问题。

正确的心智模型

用户浏览器 → DNS 解析 → 网络层 → 服务器端口 → Web 服务 → API → 数据库
   ↑                                                                    ↑
 最后查这里                                                         从这里开始查

排查顺序应该从链路最前端往后推，而不是从浏览器往后猜。

解决方案：五步排查法

第一步：DNS 解析

"域名能解析出正确的 IP 吗？"

bash

# 在服务器上查
dig +short www.sirenzhuli.cn

# 或者更简单
nslookup www.sirenzhuli.cn

# 看权威 DNS 和本地 DNS 是否一致
dig +short www.sirenzhuli.cn @8.8.8.8    # Google DNS
dig +short www.sirenzhuli.cn @1.1.1.1    # Cloudflare DNS

常见问题：

现象	可能原因	解决
解析不到	域名没配 A 记录	去 DNS 管理后台加 A 记录
解析到旧 IP	改了 DNS 但 TTL 还没过期	等待或降低 TTL 后重试，旧 APP 需要热更新
有的能解析有的不能	DNS 传播延迟	等几分钟，或用公共 DNS

第二步：端口监听

"服务器在监听正确的端口吗？"

bash

# 看所有监听的端口
sudo ss -tlnp

# 只看常用端口
sudo ss -tlnp | grep -E ":(80|443|8898|8444)\s"

# 从外部测试端口是否可达
nc -zv 124.222.126.171 80
nc -zv 124.222.126.171 443

解读：

bash

# ✅ 正常：nginx 在监听 80 和 443
LISTEN  0  511  0.0.0.0:80   0.0.0.0:*  users:(("nginx",pid=1234,fd=6))
LISTEN  0  511  0.0.0.0:443  0.0.0.0:*  users:(("nginx",pid=1234,fd=7))

# ❌ 异常：端口没监听
# （空输出）

第三步：服务状态

"Web 服务在正常运行吗？"

bash

# nginx
sudo systemctl status nginx
sudo nginx -t    # 配置有问题先修

# 后端服务（例如 Python）
sudo systemctl status chat-server
sudo journalctl -u chat-server --since "10 min ago" -n 50

看什么？

Active: active (running) — 在跑
Active: failed — 挂了，看日志
Active: activating — 正在启动（卡住了？）
日志里有没有 ERROR、Traceback、Connection refused

第四步：API 直测

"绕过前端，直接请求 API 能通吗？"

bash

# 测试 HTTP
curl -v http://localhost:8898/api/health

# 测试 HTTPS
curl -v https://www.sirenzhuli.cn/api/health

# 如果 API 需要认证
curl -v -H "Authorization: Bearer <token>" https://www.sirenzhuli.cn/api/user

# 看返回的 HTTP 状态码
curl -o /dev/null -s -w "%{http_code}\n" http://localhost:8898/api/health

HTTP 状态码速查：

状态码	意思	查什么
200	正常	—
301/302	重定向	nginx 转发规则是否正确
403	禁止访问	权限、防火墙、CORS
404	路由不存在	API 路径是否正确、nginx location 配置
500	服务器内部错误	后端日志、代码异常
502	网关错误	后端服务挂了或没启动
504	超时	后端响应太慢或死循环

第五步：前端功能验证

"服务端全通了，再看前端"

bash

# 浏览器开发者工具（F12）→ Network 标签
# 看哪个请求红了（失败）
# 看 Response 返回了什么
# 看 Console 标签有没有 JS 报错

# 检查静态资源是否可访问
curl -I https://www.sirenzhuli.cn/static/js/app.js

这个步骤才是真正和前端有关的检查。 把它放在最后，因为前四步没查完，前端排查往往白费。

排查脚本（五合一，复制即用）

bash

#!/bin/bash
# 前端掉线排故一键脚本
# 用法: bash debug-frontend.sh www.sirenzhuli.cn

DOMAIN="${1:-www.sirenzhuli.cn}"
SERVER_IP="124.222.126.171"

echo "=== 五步排查开始 ==="

echo -e "\n[1/5] DNS 解析"
echo "dig $DOMAIN: $(dig +short $DOMAIN)"

echo -e "\n[2/5] 端口监听"
ssh root@$SERVER_IP "ss -tlnp | grep -E ':(80|443|8444|8898)\b'"

echo -e "\n[3/5] 服务状态"
ssh root@$SERVER_IP "systemctl is-active nginx chat-server 2>/dev/null"

echo -e "\n[4/5] API 直测"
curl -s -o /dev/null -w "HTTP $DOMAIN: %{http_code}\n" "https://$DOMAIN/api/health" 2>/dev/null || echo "HTTPS 不通"

echo -e "\n[5/5] 前端资源"
curl -s -o /dev/null -w "首页: %{http_code}\n" "https://$DOMAIN/"

echo -e "\n=== 排查完成 ==="

预防措施

排故铁律

禁止说"清缓存" — 除非你已经完成了 DNS→端口→服务→API 这四步检查并且全部正常
一次只改一处，改完立刻验证 — 改了 DNS 就验证 DNS，别顺手改 nginx
从链路最前端往后查 — DNS 不通，后面全白看
日志优先 — tail -f 是排查时最好的朋友

常见问题的快速定位表

用户描述	最可能的根因	先查哪
"完全打不开"	DNS / 服务器宕机	DNS + ping
"页面一直转圈"	后端服务挂了	curl API + systemctl
"能打开但报错"	API 异常	curl API + 后端日志
"部分功能不正常"	特定 API 挂了	Network 标签看哪个请求红
"图片/样式加载不了"	静态资源路径	nginx location 配置
"HTTPS 页面打不开"	证书过期	openssl s_client

出问题时先问自己三个问题

1. 上次正常能用是什么时候？
2. 那个时间点之后改了什么东西？
3. 改了什么就查什么，别瞎猜。

关联知识点

nginx 配置不生效排故 — sites-available vs sites-enabled，symlink 机制
SSL 证书迁移实战 — 证书过期导致 HTTPS 不通
计算机网络故障排查 — DNS 解析、端口检测工具详解
日志与排故 — journalctl 和日志分析
Linux 进程管理 — systemctl 排查服务状态

🎯 本章要点

排故从链路前端往后查：DNS→端口→服务→API→前端功能
浏览器缓存是最偷懒的诊断结论，应先排除代码、进程、日志、环境变化

加载练习题中...

前端掉线问题排故：别再说"清缓存试试"了 ​

事故经过 ​

三次掉线，三次推给缓存 ​

根因分析 ​

为什么我们总爱推给"缓存"？ ​

正确的心智模型 ​

解决方案：五步排查法 ​

第一步：DNS 解析 ​

第二步：端口监听 ​

第三步：服务状态 ​

第四步：API 直测 ​

第五步：前端功能验证 ​

排查脚本（五合一，复制即用） ​

预防措施 ​

排故铁律 ​

常见问题的快速定位表 ​

出问题时先问自己三个问题 ​

关联知识点 ​

🎯 本章要点 ​

有问题或补充？欢迎留言

前端掉线问题排故：别再说"清缓存试试"了

事故经过

三次掉线，三次推给缓存

根因分析

为什么我们总爱推给"缓存"？

正确的心智模型

解决方案：五步排查法

第一步：DNS 解析

第二步：端口监听

第三步：服务状态

第四步：API 直测

第五步：前端功能验证

排查脚本（五合一，复制即用）

预防措施

排故铁律

常见问题的快速定位表

出问题时先问自己三个问题

关联知识点

🎯 本章要点