Hello,
Je reprends ce cold case car j'ai exactement la même problématique.
Bon on commence par oublier ezconect.to : ce truc tente l'ouverture de port en automatique entre le NAS et la box ; on va éviter ce genre de bidouillle et tout faire à la main en maitrisant le geste NAT, OK ?
Etat des lieux :
Sur un NAS Asustor, on a :
_ installé jellyfin via l'App Central : on a donc un container docker
jellyfin/jellyfin:latest qui tourne gentiment.
Sur le LAN de la box c'est tout sympathique en http.
Et puis alors on se dit qu'on va le coller derrière son Reverse Proxy pour le faire accéder à sa communauté : et là c'est le drame : les videos freez toutes les 5 secondes .... pour celles qui veulent bien commencer à être lues !
Extrait de log lors de la tentative de lecture video :
[14:04:28] [WRN] [46] Jellyfin.Server.Middleware.ResponseTimeMiddleware: Slow HTTP Response from https://<mon domaine>/Sessions/Playing/Progress to <IP du client sur le WAN> in 0:00:00.7940373 with Status Code 204
J'aimerai donc exposer directement le jellyfin sans passer par le Reverse Proxy pour éliminer un potentiel goulet d'étranglement ; sans conviction car je ne pense pas que ce soit cela le ralentisseur.
Avec ca, ca semblait bien parti :
docker run -it --rm --name certbot -v "./etc/letsencrypt:/etc/letsencrypt" -v "./var/lib/letsencrypt:/var/lib/letsencrypt" certbot/certbot certonly
Mais il pose une question piège :
Input the webroot for <mon domaine>: (Enter 'c' to cancel):
Je tape donc c et reçois : Every requested domain must have a webroot when using the webroot plugin.
Je bloque là.
Et vous ? Votre NAS fait il du jellyfin sur le WAN de façon fluide ? Quelle est votre setup et votre architecure (derrière un RP, ...) ?
Les questions restantes à ce stade sont :
La box fibre optique pourait elle être la cause de ce ralentissement lan/wan ?
Où trouver un tuto pour disposer d'un certificat let's encrypt et savoir comment le faire reconnaitre par le container de l'ADM ?