Nginx 反向代理腾讯云 COS 的一个坑

有一个朋友开发的手机 app，把大量文件都保存在腾讯云 COS 上，然后通过 CDN 分发。

最近有一个特殊的需求，希望通过 CVM 来提供部分 COS 文件的访问。因为服务器用的是 Nginx ，所以事情也很简单：

1、 到COS的管理页面上查询一下内网访问域名。

[1484825458649_3261_1484825459080.png]

2、 给 nginx 增加一个标准的 upstream 配置，上游指向腾讯云 COS 的内网域名。

[1484813547389_3855_1484813547588.png]

照理说，配置好域名解析就可以开始工作了。但是一开始工作就出现很奇怪的现象：下载开始很快，随后变得很慢，最终有很大概率失败。

首先排除网络原因的可能性。登录服务器用 wget 通过访问本机 localhost 验证：

[1484813930798_5463_1484813931314.png]

现象就是前面都下载的飞快，到了最后一部分就突然下载不动了。

打开 nginx 的 error_log，发现了 upstream timed out (Connection timed out) 错误。

[1484814414771_1344_1484814415286.png]

再排除 COS 有问题的可能性：

[1484814076223_5459_1484814076670.png]

现在问题就很诡异了：上游没有问题，经过反向代理后文件的前面一大部分也都没有问题，就是最后一小截文件要等待很久很久，并且发生了 upstream timed out 超时。

通过肥龙找到了熟悉nginx的ares同学协助抓包，才定位到了这个问题：

[1484814697293_4399_1484814697615.png]

这里的 UA 是 wget，wget 默认使用的是 http1.0 协议。当前服务器使用的 nginx 是1.0.15这个比较古老的稳定版，还不支持 proxy_http_version 1.1这样的参数（要到1.1.4版本以后才支持）。所以也是采用http1.0协议代理了请求。

照理说 innercos 服务接到这样的请求应该按照 http1.0 的方式返回数据，但是我们看到服务器返回了 HTTP/1.1 200 OK 。也就是说不管客户端支持什么 http 版本 cos 服务总是用 http1.1协议来工作。

http1.1有一个重要的特性是 keep-alive，也就是说 http 数据传输完毕后 TCP 连接继续保持一段时间不断开，可以给后续的 http 请求重用。而 http1.0的客户端原则上并不知道 http1.1的这套原理。所以对于这个老版本的 Nginx 来讲，它收到完整的数据以后，看到 TCP 链接一直没有断开，以为 upstream 还有话说，就一直挂在那里，等上游继续送数据，直到上游连接超时，才在 error_log 里面记录一个 timed out 错误，然后断开下游的连接。

把 proxy_buffering 关掉让上下游直接对上话可以绕过这个问题，但是有附带的损失。更好的办法是把nginx升级到1.1.4以上的版本，并且开启proxy_http_version 1.1 。

[1484815794488_9876_1484815794718.png]

[1484815588114_2842_1484815588750.png]

[1484815731831_2769_1484815732738.png]

至此圆满解决。

总结一下，腾讯云COS的后台服务假设客户端都支持http1.1协议，对http1.0协议没有做很好的兼容，而腾讯云CVM提供的带Nginx的系统镜像里面的Nginx版本又有点儿老旧了，proxy还只能工作在http1.0上，导致了这个问题的出现。

续集

这样做还有可能带来的一个副作用是，媒体文件用Safari浏览器播放的时候会变成“实时广播”模式

[1501488462066_9017_1501488462439.jpg]

也就是说不显示总长度，不显示进度条，无法前进后退，只能顺序播放。

正常的媒体问题件应该是这样的：

[1501488520918_1970_1501488521110.jpg]

这个问题在Stack Overflow上有网友分析过：

It appears that Safari doesn`t trust a server when it says it can provide partial content: Safari (or technically Quicktime I think) requests bytes 0-1 of a file with a range header like this:

Range: bytes=0-1

as its first request to the file. If the server returns the whole file - it treats the file as a 'stream', which has no beginning or end.

看起来safari并不信任服务器送出的内容是一个文件，自己要先请求一下文件的头两个字节看看。如果头两个字节不能正确返回，就断定服务器在进行“实时广播”。

在这种回源访问方式下，由于COS本身是支持分段下载的，所以nginx回源到COS服务器的时候，服务器总是会返回一个Content-Range: bytes 0-xxxx/xxxx 表示整个文件是作为一个大分段返回的。而Nginx发现用户请求的是头两个字节，字节也要返回一个Content-Range: bytes 0-1/xxxx 的http头部。此时nginx发现源服务器输出了同名的http头，就采取了一个最简单的处理策略：把两个头部合并一下，返回了这样一个自相矛盾的http头部：

Content-Range: bytes 0-xxxx/xxxx，bytes 0-1/xxxx

这样在safari浏览器看起来当然是一个“乱来”的服务器，于是safari果断决定吧这个服务器当成是直播服务，进入“实时广播”模式。

解决的方案也很简单，在nginx配置文件中吧来自源服务器的Content-Range头部隐藏掉：

proxy_hide_header Content-Range;