After I set up PeerTube, I routinely used the Pagoda Panel (with its built-in Nginx) to configure the reverse proxy (as mentioned earlier, when setting up 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: Building a PeerTube-Based Private Video Sharing Platform (Part 1)), but after configuring it, I found a problem: all other accesses were normal (configuration, uploading videos, etc.), but when playing videos, Safari and Chrome on iPhone seemed to be able to play them, but they were obviously much slower, buffering for a long time, while browsers on Mac (Chrome, Safari) just kept buffering and finally reported the following error:

This left me a bit confused. Why did the iPhone seem to work (albeit very slowly), but the Mac failed completely? I searched foreign forums for a long time using “HLS.js error: networkError – fatal: false – fragLoadError” and found various suggestions, but none of them were relevant to my current environment. There are only a few options on PeerTube, and none of them even seem remotely related. The problem shouldn't be related to PeerTube, so could it be related to Nginx? But I have configured countless reverse proxies on Pagoda Panel and never encountered any issues. What could be the reason?

I checked the videos stored on PeerTube, and they have all been transcoded into HLS:

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

proxy_buffering

This is mainly to achieve asynchronous communication between the response data of the proxied server (application) and the client's request. Generally speaking, when Nginx acts as a reverse proxy for an application, it is highly likely in the same local area network as the application. Compared to the client, the network quality between Nginx and the application is more trustworthy. Therefore, after the client request reaches Nginx and is forwarded by Nginx to the application, Nginx will first place the response from the proxied server (application) into 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 full, the data will be written to a temp_file. If this feature is turned off, Nginx will directly return the response packet received from the application to the client.

proxy_cache

This is mainly to cache the response data obtained from the proxied server (application) onto Nginx according to preset rules. When a client request reaches Nginx, Nginx will directly return the cached response data (if any) to the client, without needing to fetch it from the proxied server (application) every time. This saves the resources of the proxied server and also improves the speed at which the client obtains the response. If this feature is turned off, every time Nginx receives a request from a client, it will forward it to the application and then directly send the response data returned by the application back to the client.

`proxy_buffering` defaults to `on`, and `proxy_cache` theoretically defaults to `off`. Both features are related to how Nginx responds to client requests when acting as a reverse proxy. If both features are enabled at the same time and coexist with streaming media like HLS, will there be any “compatibility” issues? To verify this, I first tried to turn off `proxy_buffering`:

proxy_buffering off;   

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

proxy_cache off;

However, so far I have only found that this setting is related to streaming media with HLS enabled, whereas the links generated by the COS I built with MinIOhttps://*.xxx.mp4play fine in the browser without this setting. Maybe it is only related to streaming media? If you encounter similar problems when using Nginx as a reverse proxy for streaming media in the future, you can try this solution.