记录一次由yum update引起的http服务ERR_CONTENT_LENGTH

背景

为了安装docker compose，在Centos服务器上执行了sudo yum update

没错，这才是第一步！！！

可没想到，这一步刚刚执行完成，业务就反馈XXX页面打不开了，异常出奇的一致：

net::ERR_CONTENT_LENGTH_MISMATCH

更悲哀的是，这些服务都是因为人员变动后属于无人维护状态的服务，一时间尽不知道如何是好！

于是，就开启了漫长的问题排查与处理过程~~~

排查一：问搜索引擎，这是什么原因

作为一名java服务端开发人员，对这些Node服务，app.js完全不懂，但问题好像很简单，资源加载不出来而已嘛：）

直接搜索问题，看有没有思路

结果除了问题描述外基本都指向了nginx，排查nginx配置、proxy_temp目录权限等

代码没有变化，自己先验证下通过ip+port访问服务，是否正常？正常！无任何报错信息。

那么，域名->nginx.conf，这条路径应该就是主要排查点了

排查二：找运维同事查找域名对应的后端机器

服务无人维护，但有域名，那肯定是从域名入手，找机器，看配置。

然而，这一步很快就又走不通了~~~

域名直接指向了容器，而这个容器上一次部署时间是21年12月份，今天都2026年了，不涉及配置调整，也不涉及proxy_temp目录权限问题！！！

排查三：找前端同事协助

这没办法了，自己研究容易走弯路，找前端同事看一眼，没准问题很常见，一个node配置就解决？

或许是，或许，也不是~

前端同事看了眼错误，F12看了看资源响应，初步判断：gzip原因，zgip后Content-Length变化了，和这个net::ERR_CONTENT_LENGTH_MISMATCH错误的描述是能对应上的。

看到了希望：）

通过app.js中找到特殊路径gzip的逻辑，干掉它，重新部署服务，问题依旧存在！

那，难道是显式返回Content-Length原因？

配置为不返回Content-Length，问题依然存在！！！

于是，也开始了探索路径~

但，到这里，我们都没有想过yum update原因，认为更新一个库，不至于造成http服务响应资源异常吧，而且，通过ip+port访问也没问题啊？！！！

排查四：问AI吧

得，把上下文告诉它，看AI能不能协助解决这个问题。

这里的1、检查web服务状态，nginx日志，和我的方向一样，跳过

但，还有一个“同时检查系统日志”

这个确实没有操作过，来吧，直接上命令

哇哦哦哦哦哦哦哦哦哦哦哦哦~~~~~~

这，就定位了？

顺着这个错误继续问：

解决方案：

按照AI给的解决方案，应该去修改/etc/sysctl.conf配置文件，添加tcp_mem相关参数。

哦？难道yum update时，有对这个文件修改过？

ls -l确认一下，果然，/etc/sysctl.conf文件的修改时间与yum update执行完成的时间一致！

参考AI给的命令修改、应用：

# 编辑 sysctl 配置文件
vim /etc/sysctl.conf

# 添加以下内容：
# TCP Memory Tuning
net.ipv4.tcp_mem = 786432 1048576 1572864
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.somaxconn = 65535
fs.file-max = 2000000
net.core.netdev_max_backlog = 65535

# 应用配置
sysctl -p

问题消失，全部服务恢复正常！！！

记录一下，如遇类似问题，供参考：）