OkHttp3错误异常: java.net.ProtocolException: unexpected end of stream竟是nginx惹的祸

一、问题

使用okhttp获取体检报告PDF时偶发报错；正常3次后就一直失败

报错内容如下：

二、解决过程

2.1 问题排查

通过看源码确认是请求响应的长度和实际响应body的长度不一致导致的；
网上有各种解决方案：

1. 比如服务端添加响应头：“Transfer-Encoding”：“chunked” 忽略响应长度校验;
2. 客户端通过okhttp的重试机制，失败后重试几次；

这些解决方案全部失败告终；

然后感觉是okhttp的问题，就通过postman测试了几次，postman请求不会报错;
但有一个小现象：
成功的响应时长：时长(3s) - 时短(625ms) 很不科学！

后来通过观察猜测，postman也有重试机制；

这时候我大概率猜到应该是服务端的问题；

站不住脚的猜测依据：

okhttp正常3次之后就报错
postman也有请求失败的重试机制
说明这个问题不单单是okhttp3自身导致的

为了再次验证和解决，我用Apache-Httpclient请求，现象依旧是正常几次之后，就开始报错；报错内容：

ApacheHttpClient的报错和okhttp的报错含义是类似的；依旧是响应长度不对导致的；
但是ApacheHttpClient在网上此问题的回答很多；

2.2 定位到nginx

搜索关键词
Truncated chunk (expected size: 81,920; actual size: 61,583)

看到了第一篇文章：
https://blog.csdn.net/weixin_30478757/article/details/98417848
答案：

终于定位到是nginx的问题，因为nginx处理chunked传输有问题。
所以最简单的处理方式是把nginx的缓存关闭。

这时候我就锁定了解决问题的方向——> nginx

立马查看Nginx的日志，果然在报错：

搜索关键词：
usr/local/nginx/proxy_temp

相关回答：
https://blog.csdn.net/wxb880114/article/details/116654001

答案：

根据答案修改nginx.conf的配置；

然后再次测试，问题解决！

三 问题总结

nginx配置：

• proxy_temp_file_write_size 24k; #设定缓存文件夹大小，大于这个值，将从upstream服务器传
  而获取的体检报告基本都在100k以上；

问题就出在proxy_temp_file_write_size上，当nginx服务器传输的文件超过参数设置的大小时，Nginx会先将文件写入临时目录(缺省时默认为Nginx安装目下/proxy_temp目录)，缺省Nginx是以nobody身份启动的，用ls -al 命令查看proxy_temp目录 nobody是proxy_temp目录的所有者，怪了那为什么没权限呢？查看proxy_temp的父目录既Nginx安装目录。发现nobody竞然没权限

解决方案有多种，大家根据自己需求变通使用：

• 设置proxy_temp目录的权限，然后重启nginx;
• 修改nginx配置的用户权限，不推荐使用root用户，root权限过大，存在风险；
• 增大proxy_temp_file_write_size的值，不让临时文件写入proxy_temp目录即可，记得重启nginx;

---

我的网站 https://www.lookhot.cn/#/