在我搭建好peertube以后，惯例使用宝塔面板（自带的nginx）配置反向代理（前文提到过，搭建peertube docker的时候就要使用-e参数指定用来访问peertube的域名、是否使用https以及使用的端口，具体步骤参见：docker系列 搭建基于peertube的私人视频分享平台(上)），但是配置好以后发现一个问题：所有其他访问都正常（配置、上传视频等），但是在播放视频的时候，iphone上的safari和chrome貌似可以播放，但是明显慢了很多，要转半天圈，而mac上的浏览器（chrome、safari）播放直接转圈，最后报错如下：

这让我有点懵了，为啥iphone貌似可以（虽然很慢），但是mac上却完全不行？用“HLS.js error: networkError – fatal: false – fragLoadError”去国外论坛上搜索了半天，各种建议，但是和我眼下的环境却完全不搭边。peertube上就那么几个选项，连看起来可能有关的都没有，问题应该和peertube无关，那难道还会和nginx有关？但是我在宝塔上配置无数的反向代理，都没遇到过问题，能是啥原因呢？

看了下peertube上存放的视频，都已经被转码成HLS：

难道是HLS方式的NGINX反向代理配置上有啥特殊之处？又是一通搜索，验证，最终发现还真是，这与nginx的2个参数有关：proxy_buffering(缓冲)和proxy_cache(缓存)。

proxy_buffering

主要是实现被代理的服务器（应用）的响应数据和客户端的请求异步。一般来说nginx作为应用的反向代理时，大概率是和应用在一个内网里，相对于访问客户端而言，nginx和应用之间的网络质量更值得信任，所以客户端请求达到nginx，被并nginx转发到应用之后，nginx会先将来自被代理的服务器（应用）的响应放在自身的"buffer"里，然后根据"proxy_busy_buffer_size"设置的值来决定什么时候开始把响应数据返回给客户端。在此过程中，如果所有的buffer被写满， 数据将会写入到temp_file中。该功能如果关闭，nginx收到应用发回的响应包会直接返回给客户端。

proxy_cache

主要是实现将从被代理的服务器（应用）上获取到的响应数据根据预设规则缓存到nginx上， 当客户端请求到达nginx时，nginx会把缓存的响应数据（如果有的话）直接返回给客户端，而不需要每次都重新向被代理服务器（应用）去取，这样既节省了被代理服务器的资源，同时也提高了客户端获取效应的速度。该功能如果关闭，nginx每次收到客户端发来的请求，都会转发给应用，然后把应用返回的响应数据直接发回给客户端。

proxy_buffering默认为on，proxy_cache默认理论上为off。这2个功能都和nginx作为反向代理时对客户端请求的响应方式有关。如果2个功能同时打开，和HLS这类流媒体同时存在，是否会有啥“兼容性”问题？为了验证这个问题，先尝试关闭proxy_buffering：

proxy_buffering off;   

加在反向代理所在的location部分，如下：

结果没用。然后在加上关闭proxy_cache：

proxy_cache off;

问题解决。。。这个就奇了怪了，理论上，proxy_buffering on应该是proxy_cache生效的前置条件，proxy_buffering都off了，为啥要必须显式指定proxy_cache off？

不过，目前我只发现这个设置和启用HLS的流媒体有关系，而我用minio搭建的COS生成的链接https://*.xxx.mp4不加这个设置在浏览器里播放也没有关系，可能只是和流媒体有关？大家以后遇到类似的流媒体用nginx做反向代理遇到了问题可以试试这个解决方法。