之前有提到，内部用了个网络上开源的网盘系统，最新峰峰他们突然反应好几次上传文件失败，出问题的时候有个比较明显的特征是文件体积较大。由于目前咱就是首席运维官，这个网盘也是亲自选型的，这种事就只好赤膊上阵了。

这个网盘的分发包，结构不是很合理，其存储用户上传的数据的目录跟主程序在一起，如下。

这种组织方法并不利于升级。老夫做了以下改进：
1. 把 conf 和 data 目录提升至与 app-root 平级；
2. 在 app-root 下创建 conf 和 data 软链接指向上层相对应的目录；
3. 将 app-root 改名为 app-root-vX，其中 X 为实际版本号；
4. 创建 app-root 软链接指向 app-root-vX。

这样做的最大的好处就是升级或者回滚都相对方便，勿需覆盖，数据除非应用自身做了大的更改，否则可以直接继承使用。

把源代码克隆到本地，安装 JDK、Maven，以及给 Visual Studio Code 安装插件，让工程可以顺利编译并打包。大体理了一下代码结构，找到了处理文件上传的类，查看可以插入调试信息的方式和位置。作者的信息记录，尤其是出错记录工作相当不到位，日志类竟然是和业务密切相关的，所以第一时间先补了个可以写任意调试内容的方法进去。

一开始，计划在不影响线上入口的情况下做测试，定位问题所在。思路是并行再运行一份服务（把程序复制了一份），但直接使用现有的数据，因为还考虑到了很有可能错误与现有数据相关。修改配置让服务监听到 8282 端口上，然后运行，报错，看信息是因为数据库已经被占用。看来不影响线上入口是不行了。于是把正本服务下线，再次执行副本，上传大文件竟然成功。这个结果表明，我大概率不用再去改源代码了，至少要改的地方可能要发生变化了。

那到底是什么导致的问题呢？突然想到，正本服务是经过 nginx 代理的（因为要让大家用得爽，消除对端口号的记忆），而副本服务是直接对监听端口进行访问的。此灵光一现之后，把副本服务停掉，重启正本服务，然大家分别使用带端口和无端口的 URL 进行访问测试，果然，只要不带端口，上传大文件就会失败。

机智的我，打开了搜索引擎，输入“nginx 反代 上传文件失败”，发现有很多相关的文章在说这个问题。查看后发现，重点在于一个名为 client_max_body_size 的配置（它可以作用于 http、server、location 等节），毫无疑问此处适用于我在 nginx 的配置文件中创建的 server 节。接下来为具体的值犯愁，1024m 还是 4096m？最后还是写作了 0，内部系统，让大家疯狂吧，先不做限制了。