直接查看访问日志最高效，404请求记录在/var/log/nginx/access.log中，可用awk '$9==404{print$7}' | sort | uniq -c | sort -nr | head -20按频次排序定位高频死链，并结合$1、$7、$9、$11字段及root/alias配置验证路径合理性。
直接看访问日志是最高效的方式——404 请求会原样记录在 /var/log/nginx/access.log 里，每条记录都包含请求路径、状态码、来源 IP 和时间戳。你不需要猜，日志会告诉你哪些链接已经失效。
快速定位死链的常用命令
用以下命令能立刻筛出所有 404 请求，并按路径频次排序：
-
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
（输出访问次数最多的前 20 个 404 路径） -
grep ' 404 ' /var/log/nginx/access.log | grep -E '\.(html|js|css|png|jpg|svg)' | tail -10
（查最近 10 条带常见资源后缀的 404） -
awk '$9 == 404 && $7 ~ /^\/api\// {print $0}' /var/log/nginx/access.log
（专门抓 API 类 404，方便区分前端路由还是后端接口问题）
关键字段含义要认得
一条典型的 access.log 记录长这样：
- $1：客户端 IP（可判断是否是爬虫或内部测试）
- $7：请求 URI（即出问题的具体路径，重点看它）
- $9：HTTP 状态码（确认是 404，不是 301 或 502）
- $11：Referer（上一页地址，能帮你发现是哪个页面里的链接坏了）
结合配置验证路径是否合理
拿到一个 404 路径后，别急着改代码，先确认 Nginx 是否本该处理它：
- 检查
root或alias指向的目录下，是否存在对应文件（注意大小写和扩展名） - 如果是 SPA 应用，确认该路径是否应由前端路由接管——那它就不该真实存在物理文件，而是靠
try_files $uri $uri/ /index.html回退 - 如果路径含
/api/或/v1/，说明应走反向代理，检查location /api/块是否配置了proxy_pass，且后端服务确实监听并响应了该路径
日常预防建议
死链不是修一次就完事，得让它“冒出来”才好及时处理：
- 加个定时任务，每天凌晨跑一次 top 10 404 路径分析，发邮件提醒自己
- 前端构建时开启
html-webpack-plugin的minify.removeEmptyAttributes，减少空 href 或 src - 上线新版本后，用
linkchecker工具扫一遍全站，提前发现跳转断裂点
