很无语,就这么个问题反反复复排查了一个月?

事情要从测试妹妹开始

突然有个周四的下午,测试小妹妹蹦蹦跳跳的跑过来反馈,某些图片资源打不开了, Chrome直接访问图片的地址全是空白

第一次排查问题

接到问题之后,随机复制几个图片的 URL 到 Chrome 中测试, 发现确实都是白屏状态, 于是查看 NetWork,返回全是 200 状态码, 照理来说, 应该能正常访问才对。

这里很尴尬的是,因为测试服务器是测试自行部署的,没有部署一些监控和告警服务。

于是运维的同学开始登录服务器,导出了后端同学需要的所有日志文件给到后端的同学自己分析,然后下班了。

后端同事排查到凌晨三点,还是没有找到问题。

解决问题

第二天上班后,后端的同学跟运维说,"要不你重启一下测试服务器吧~"

测试小妹妹:"咦,好了耶!"

第二次出问题

一个月后,测试小妹妹又反馈了,图片又又又又又打不开了~

运维的同学表示,"不正常,一点都不正常!"

于是职业习惯性的在 shell 中敲了 df -h

???!!!

排查发现被后端的同事打测试的日志把磁盘打满了

直接把没用的日志删了,就正常了,你说气不气。

上次重启服务器,缓存文件没了空间多了,又挺了一个月,你说气不气。

问题原因追溯

非4xx/5xx, 说明服务器和浏览器都没有问题, 查了下 ERR_HTTP2_PROTOCOL_ERROR 的解释, 都在说 http2 的配置有问题, 但能确定的是, 测试服务器已经很久没有人登上去过了。

然后复制图片地址到 命令行中 curl, 发现了猫腻:

ok, 继续搜索 HTTP/2 stream 0 was not closed cleanly 相关的问题, 没找到答案。

运维小哥盲猜后给出了一个结论:

服务响应的 HTTP 请求头的 content-length 承诺的输出字节数 与 实际输出的内容长度 不一致,导致触发了 MITM 的安全策略。

然后磁盘被打满了,就是造成 没法按照 content-length 的要求完整输出本应该输出的内容长度 的原因。

测试小妹妹

"运维哥哥真厉害~"

故事的结束

今天的故事讲完了,如果你有兴趣,欢迎关注我的社交账号,交个朋友。

GithubGitee

相关推荐
biass20 分钟前
jenkins角色权限
运维·jenkins
tomorrow.hello22 分钟前
Jenkins Pipeline(二)
运维·jenkins
2501_9160137432 分钟前
iOS 多线程导致接口乱序?抓包还原 + 请求调度优化实战
websocket·网络协议·tcp/ip·http·网络安全·https·udp
做一个AC梦37 分钟前
Docker安装失败:Docker Desktop installation failed
运维·docker·容器
Shan120539 分钟前
浅谈Docker Kicks in的应用
运维·docker·容器
路长且阻1 小时前
网络协议(TCP/IP、HTTP、HTTPS)
网络协议·tcp/ip·http
吴free3 小时前
mac电脑wireshark快速实现http接口抓包
网络·测试工具·http·wireshark
Tipriest_3 小时前
Ubuntu常用的软件格式deb, rpm, dmg, AppImage等打包及使用方法
linux·运维·ubuntu
真智AI4 小时前
利用 Claude Opus 4 自动化 GitHub 工作流:从安装到实战详解
运维·自动化·github
胡斌附体4 小时前
linux测试端口是否可被外部访问
linux·运维·服务器·python·测试·端口测试·临时服务器