After I built peertube, I used the pagoda panel (built-in nginx) to configure the reverse proxy as usual (as mentioned above, when building peertube docker, you need to use the -e parameter to specify the domain name used to access peertube, whether to use https, and the port used. For specific steps, see:Docker series builds a private video sharing platform based on peertube (Part 1)), but after configuration, I found a problem: all other accesses are normal (configuration, uploading videos, etc.), but when playing videos, Safari and Chrome on iPhone seem to be able to play, but it is obviously much slower, and it takes a long time to play in circles, while the browsers (Chrome, Safari) on Mac play directly in circles, and finally report the following error:

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

I looked at the videos stored on peertube and found that they have all been transcoded into HLS:

Is there something special about the NGINX reverse proxy configuration for HLS? After another round of searching and verification, I finally found that it was indeed the case. It was related to two parameters of NGINX: proxy_buffering and proxy_cache.

proxy_buffering

The main purpose is to achieve asynchronous response data of the proxied server (application) and client request. Generally speaking, when nginx is used as a reverse proxy for an application, it is most likely in the same intranet as the application. Compared with accessing the client, the network quality between nginx and the application is more trustworthy. Therefore, after the client request reaches nginx and is forwarded to the application by nginx, nginx will first put the response from the proxied server (application) in its own "buffer", and then decide when to start returning the response data to the client based on the value set by "proxy_busy_buffer_size". During this process, if all buffers are filled, the data will be written to temp_file. If this function is turned off, nginx will directly return the response packet sent back by the application to the client.

proxy_cache

The main function is to cache the response data obtained from the proxied server (application) to nginx according to the preset rules. When the client request reaches nginx, nginx will return the cached response data (if any) directly to the client, without having to fetch it from the proxied server (application) every time. This saves the resources of the proxied server and increases the speed of the client obtaining the response. If this function is turned off, nginx will forward the request to the application every time it receives it from the client, and then send the response data returned by the application directly back to the client.

The default setting of proxy_buffering is on, and the default setting of proxy_cache is off in theory. Both of these functions are related to the way nginx responds to client requests when it is used as a reverse proxy. If both functions are turned on at the same time, and streaming media such as HLS coexists, will there be any "compatibility" issues? To verify this issue, try to turn off proxy_buffering first:

proxy_buffering off;   

Add it to the location part where the reverse proxy is located, as follows:

It didn't work. Then add the following to turn off proxy_cache:

proxy_cache off;

Problem solved... This is strange. In theory, proxy_buffering on should be a prerequisite for proxy_cache to take effect. If proxy_buffering is off, why do we have to explicitly specify proxy_cache off?

However, I have only found this setting to be relevant for HLS-enabled streaming, and the links generated by COS I built with miniohttps://*.xxx.mp4It doesn't matter if I play it in the browser without this setting. Maybe it's just related to the streaming media? If you encounter similar problems with streaming media using nginx as a reverse proxy in the future, you can try this solution.