Guide de dépannage du proxy inverse pour l’envoi de grandes photos et vidéos
L’approche sûre consiste à traiter un test contrôlé de taille et de durée, qui identifie la couche défaillante avant toute modification des limites, de la mise en mémoire tampon ou des paramètres réseau, comme une séquence d’étapes observables plutôt que comme une seule commande.
Dans une application photo ou multimédia auto-hébergée derrière un ou plusieurs proxies, le risque concret est que les petits téléversements réussissent, mais que les grandes photos ou vidéos échouent, soient réinitialisées ou expirent via le proxy inverse. Notez l’identité actuelle et le point de récupération, commencez par le test discriminant le moins invasif, interprétez les résultats avant de modifier une autre variable et arrêtez-vous si le stockage devient instable ou si la seule copie récupérable risquait d’être exposée. Le processus ci-dessous ne se termine qu’une fois que la charge de travail d’origine réussit ou que les éléments disponibles atteignent un seuil nécessitant une escalade.
Reproduire un téléversement avec une échelle de tailles
Utilisez un seul client, compte, réseau, nom d’hôte et type de fichier. Téléversez un petit fichier de contrôle, puis des fichiers de test de plus en plus volumineux, en notant le nombre exact d’octets, la durée, l’erreur du navigateur, le statut HTTP, les horodatages des journaux d’accès et d’erreur du proxy, les journaux de l’application et l’apparition éventuelle d’un objet partiel.
Testez le même fichier le plus volumineux via un point de terminaison direct et fiable de l’application, lorsqu’il est disponible. Si le test direct réussit et celui via le proxy échoue, le chemin du proxy est probablement en cause ; si les deux échouent à la même taille ou au même stade, examinez le comportement de l’application, du stockage ou du client avant de modifier la configuration du proxy.
Ne relevez pas toutes les limites de taille et de délai simultanément. Conservez la configuration actuelle et les relevés d’espace libre, et arrêtez les tests s’ils remplissent le volume de données de l’application ou exposent un point de terminaison backend non protégé.
Distinguer le rejet lié à la taille de l’échec lié à la durée
Un statut 413 ou un rejet immédiat à un seuil d’octets reproductible indique une règle de taille du corps de la requête dans la première couche qui renvoie ce statut. Un statut 408, 499, 502 ou 504, ou une réinitialisation de la connexion après une durée reproductible, pointe plutôt vers un délai d’expiration du client, du proxy, du serveur en amont, du tunnel ou de l’application.
Un cas de la communauté Traefik concernant un délai d’expiration lors d’un téléversement volumineux montre pourquoi la durée et l’ensemble du chemin entre le proxy et l’application sont importants : un téléversement volumineux peut échouer via un tunnel alors que les photos ordinaires et la navigation fonctionnent. Considérez ce cas comme une signature diagnostique, et non comme une valeur de délai d’expiration universelle.
Recensez chaque saut susceptible d’imposer des limites : CDN ou tunnel, proxy en périphérie, proxy d’authentification, proxy de l’application, serveur applicatif, environnement d’exécution et point de terminaison de téléversement. La première couche qui consigne ou renvoie l’échec détermine le test suivant.
Vérifier la mise en mémoire tampon, le stockage temporaire et le transport
Observez les répertoires temporaires du proxy, les couches accessibles en écriture des conteneurs, les chemins de téléversement de l’application, la capacité du système de fichiers, la disponibilité des inodes et la mémoire pendant le téléversement du fichier contrôlé. La mise en mémoire tampon peut consommer du disque ou de la mémoire avant que l’application ne reçoive le corps de la requête ; un volume de bibliothèque final généreux ne prouve donc pas que le proxy dispose d’un espace de travail.
Un rapport concernant Nextcloud et Traefik sur un échec de téléversement volumineux à plusieurs niveaux illustre comment un même symptôme lié aux gros fichiers peut concerner les couches web, applicative et proxy. Appliquez cet enseignement multi-couche tout en reliant chaque modification au statut, à l’horodatage du journal et à la ressource qui échoue réellement.
Si les échecs varient sans suivre de seuil de taille ou de durée, comparez les chemins Ethernet, Wi-Fi, VPN et réseau local direct. Conservez un itinéraire stable et testez séparément la MTU, la perte de paquets et le comportement du tunnel, plutôt que d’augmenter les limites de l’application pour masquer les réinitialisations du transport.
Appliquer une correction adaptée et répéter le téléversement d’origine
Ne modifiez que la limite confirmée : une limite de taille du corps de la requête appliquée au périmètre concerné, le délai d’expiration précis de la requête ou de la réponse, le mode de mise en mémoire tampon ou l’allocation du stockage temporaire. Laissez inchangés l’authentification, TLS et les hôtes virtuels sans rapport, puis rechargez le proxy et vérifiez la configuration effective.
Le processus ZimaSpace pour le test du chemin direct par rapport au chemin via proxy montre comment la comparaison entre ces deux chemins permet d’isoler le chemin du proxy après un redémarrage. Appliquez ici la même limite, puis répétez exactement deux fois le téléversement du fichier volumineux et vérifiez sa taille finale, sa somme de contrôle lorsque cette option est disponible, le traitement des métadonnées et la suppression des fichiers temporaires.
Redémarrez le proxy une fois et répétez le téléversement depuis le chemin distant d’origine. Clôturez l’incident uniquement lorsque les petits et les gros fichiers réussissent sans nouvelle exposition ni pression sur le stockage ; annulez la modification si le changement de limite affecte d’autres hôtes et transmettez les éléments au niveau supérieur avec le statut, la durée, la couche et les informations sur les ressources lorsque aucun seuil reproductible n’est identifié.
Produits recommandés
Assistance et conseils
Plus à lire
Guide de stockage pour l’enregistrement de la télévision en direct : capacité, conservation et nettoyage
Mesurez les enregistrements réels, prévoyez une marge de sécurité, combinez les limites d’ancienneté et de capacité, et vérifiez que le programme admissible le plus...
Flux de récupération des métadonnées multimédias à domicile après la restauration d’une base de données
Protégez l’état restauré, vérifiez l’identité et les chemins des médias, puis corrigez les illustrations ou les correspondances manquantes dans une bibliothèque pilote avant d’appliquer...
Liste de contrôle de compatibilité du client Jellyfin pour l’audio, la vidéo et les sous-titres
Testez des fichiers représentatifs en ne faisant varier qu’un paramètre à la fois, puis consignez pour chaque client la lecture directe, le remuxage, la...
