I am now trying to set up such a configuration, but I have a blank white page - (If I specify the wrong port (for example 9002), then an error appears 502 - it means the proxy is working. But why am I seeing a blank page?
That’s a great question!
I was going to respond with some more info about how it’s working for me, but then I took a closer look. Turns out I had left the old peertube folder on my FreeBSD server, and nginx was still serving the static content from there. That would have caused me quite a bit of trouble whenever the next video got around to being uploaded.
I removed the peertube directory, and now I am also seeing the blank white page!
But this should work. It looks like peertube has the config to support this kind of reverse proxy. So let’s see if anything can be done.
1st attempt at a workaround, this did not work.
I looked at the peertube error log and config, and noticed that it was using alias in a place where we want files to be proxied, so I replaced the line with try_files:
# Bypass PeerTube for performance reasons. Optional.
location ~ ^/client/(.*\.(js|css|png|svg|woff2|otf|ttf|woff|eot))$ {
add_header Cache-Control "public, max-age=31536000, immutable"; # Cache 1 year
#alias /var/www/peertube/peertube-latest/client/dist/$1; # <-- Won't proxy to peertube
try_files /var/www/peertube/peertube-latest/client/dist/$1 @api; # <-- Will proxy
}
That worked! Now the home page loads… except for thumbnails, which do not. Confusingly, in the network inspector the thumbnail URLs are returning ‹ 200 OK › status. So why aren’t they loading?
If I copy the URL and open it in a browser, it returns a full webpage that says « Error 404 » but in itself is not returning HTTP status code 404. So essentially we are getting a 404, just not a proper one. Maybe that’s a bug with Peertube.
Back in the peertube config, it looks like a rewrite directive is mangling the URL so that it can be fetched by nginx, but then fails to be found by the @api proxy… Maybe another bug?
# Bypass PeerTube for performance reasons. Optional.
location ~ ^/static/(thumbnails|avatars)/ {
if ($request_method = 'OPTIONS') {
add_header Access-Control-Allow-Origin '*';
add_header Access-Control-Allow-Methods 'GET, OPTIONS';
add_header Access-Control-Allow-Headers 'Range,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
add_header Access-Control-Max-Age 1728000; # Preflight request can be cached 20 days
add_header Content-Type 'text/plain charset=UTF-8';
add_header Content-Length 0;
return 204;
}
add_header Access-Control-Allow-Origin '*';
add_header Access-Control-Allow-Methods 'GET, OPTIONS';
add_header Access-Control-Allow-Headers 'Range,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
add_header Cache-Control "public, max-age=7200"; # Cache response 2 hours
#rewrite ^/static/(.*)$ /$1 break;
try_files $uri @api;
}
I commented out the rewrite line and now thumbnails load!
So close! But now when I click on a video and go to the watch page, the video fails to play. The network inspector shows that the video file and fragments list both return 404…
I spent the most time trying to figure out what was going on here. Initially I thought the rewrite statements in the /static/ section of the nginx config were messing up the request, just like they had for the thumbnails. But removing these did not help. Confusingly, nginx appeared to refuse to use the @api proxy, insisting on trying to open the file, and then returning 404 when the file wasn’t found.
Eventually I figured out that the Peertube process doesn’t (appear to) support sending the video file itself. Instead it sends a new request that’s supposed to have nginx grab the file from disk…
Here’s a screenshot of loading the site by the local Ubuntu IP address:
So Peertube is requesting to go back out and use nginx to grab the file there.
That’s as far as I’m able to troubleshoot. Maybe someone who actually knows what they’re doing can figure out a solution.
2nd attempt at a workaround, this does work for me.
So, I wish the above changes had worked. Since they do not, the only solution I can think of is to mirror the Peertube folder between the two servers. To do this I set /var/www/peertube up as an NFS mount that is shared from the FreeBSD/nginx to the Ubuntu/Peertube one. In my reasoning, that way the nginx caching can access the files fast, and hopefully webpage loading speed won’t be seriously affected.
Once the NFS share was configured, I undid the nginx config changes made in attempt #1 above.
# cat /etc/fstab
# /etc/fstab: static file system information.
# <file system> <mount point> <type> <options> <dump> <pass>
192.168.x.x:/mnt/main-pool/jail-share/peertube-storage /var/www/peertube nfs defaults 0 0
In my very basic testing this is noticeably slower, but at least it works at all.
Without NFS share:
With NFS share:
