Commencez par vérifier la connexion entre Nginx et ONLYOFFICE Docs, puis consultez le journal d'erreurs correspondant à la réponse 502. Une erreur 502 Bad Gateway signifie qu'une passerelle n'a pas pu obtenir de réponse valide de son serveur en amont ; cela ne prouve pas, à lui seul, que la configuration publique de Nginx est en cause. Dans Docker, la solution habituelle consiste à rediriger Nginx vers le nom de service du serveur de documents sur son port interne 80 et à s'assurer que les deux conteneurs partagent le même réseau.
Un proxy inverse est un serveur qui reçoit une requête client et la transmet à un autre serveur. Dans une configuration courante, un serveur Nginx public gère le protocole HTTPS et redirige les requêtes vers ONLYOFFICE Docs via HTTP. ONLYOFFICE Docs exécute également son propre serveur Nginx en interne ; une page 502 peut donc être générée par le proxy externe ou par le conteneur du serveur de documents lui-même.
Commencez par identifier le serveur ayant émis la réponse. Comparez l'en-tête et l'horodatage du serveur de la page avec les journaux du proxy externe et du serveur de documents. Dans le cas d'une configuration Docker, vérifiez l'état du conteneur et les messages de démarrage récents.
docker ps --filter name=onlyoffice-documentserver
docker logs --tail 100 onlyoffice-documentserver
Si le conteneur redémarre ou vient de démarrer, consultez le journal avant de modifier les paramètres du proxy. ONLYOFFICE indique que le premier démarrage peut prendre une ou deux minutes, le temps que sa base de données s'initialise. Pour une installation Linux native, vérifiez ds-docserviceles journaux du serveur de documents ; ceux-ci se trouvent dans le répertoire ds-converterindiqué .systemctl status/var/log/onlyoffice/documentserver/
Utilisez les instructions de dépannage officielles ONLYOFFICE Linux correspondantes si un service est arrêté.
Effectuez vos tests depuis le conteneur Nginx ou l'hôte, et non pas seulement depuis votre ordinateur portable. Les conteneurs situés sur des réseaux Docker distincts ne peuvent pas se résoudre mutuellement par leur nom de service, même s'ils sont tous deux en cours d'exécution. Si Nginx et ONLYOFFICE partagent un réseau Docker défini par l'utilisateur, utilisez le nom du service Compose ou un nom de conteneur résolvable, ainsi que le port d'écoute du conteneur. Le guide d'installation officiel de Docker indique le port 80 comme port d'écoute par défaut du serveur de documents ; un port hôte publié, tel que 8080:80, ne modifie pas le port interne.
Depuis le conteneur proxy, exécutez :
curl -I http://onlyoffice-documentserver:80/
Remplacez onlyoffice-documentserver`<nom_du_service>` par le nom réel de votre service Compose. Si la requête renvoie « Impossible de résoudre l'hôte », connectez les deux conteneurs au même réseau Docker ou corrigez le nom du service en amont. « Connexion refusée » signifie généralement que l'hôte cible a été résolu, mais qu'aucun service n'accepte de connexions sur ce port, que le conteneur n'est pas prêt ou que le port utilisé est incorrect. S'il s'agit d'une installation native, testez plutôt l'adresse locale et le port configuré, par exemple : `<adresse_locale>` curl -I http://127.0.0.1/.
Le guide Docker d'ONLYOFFICE couvre le port par défaut, les mappages de ports, le délai de démarrage et les journaux de conteneurs : installation et vérification de Docker .
Dans l'hôte virtuel HTTPS du nom d'hôte ONLYOFFICE, indiquez proxy_passle chemin vers le serveur en amont accessible. Cet exemple suppose un réseau Docker partagé et le nom de service indiqué ci-dessus ; modifiez-le en fonction de votre déploiement.
location / {
proxy_pass http://onlyoffice-documentserver:80;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
Ne configurez pas de proxy conteneurisé pour une adresse IP publique, 127.0.0.1:8080sauf si le serveur de documents écoute dans le même conteneur ou si l'adresse IP de l'hôte est configurée et accessible. « À l'intérieur d'un conteneur » 127.0.0.1signifie que le serveur de documents est lui-même accessible. Évitez également d'envoyer des requêtes HTTPS au serveur en amont lorsque le point de terminaison du serveur de documents utilise HTTP.
Le protocole et l'hôte transmis indiquent à ONLYOFFICE l'URL publique utilisée par le client, et les en-têtes de mise à niveau autorisent les connexions WebSocket nécessaires à la communication avec l'éditeur en direct. ONLYOFFICE fournit des exemples mis à jour pour l'exécution de Docs derrière un proxy , notamment sa configuration Nginx HTTPS vers HTTP . Comparez-vous à cet exemple complet si votre environnement comporte plusieurs sauts de proxy ou utilise un préfixe de chemin d'URL.
Avant d'appliquer les modifications, validez la configuration nginx -t, puis rechargez Nginx en utilisant la méthode appropriée à votre hôte ou conteneur. Ne redémarrez pas tous les services simultanément ; un rechargement progressif permet de vérifier plus facilement si la correction apportée par le correctif en amont a modifié le résultat.
Si le proxy externe peut accéder à la page d'accueil du serveur de documents mais /healthcheckrenvoie une erreur 502, le problème se situe probablement au sein du serveur de documents plutôt que dans le serveur Nginx public. Consultez les journaux du conteneur et les journaux de service internes du serveur de documents. Pour les installations Linux natives, examinez les commandes d'état du service et le répertoire de journaux mentionnés ci-dessus. Si /welcome/la commande répond mais que le test d'intégrité échoue, considérez ces deux événements comme des signaux distincts : une page d'accueil statique ne garantit pas le bon fonctionnement du service de documents et de ses dépendances.
Ne tentez pas de résoudre ce problème en désactivant JWT. La validation par jeton Web JSON (JWT) authentifie les requêtes d'intégration ; une erreur de JWT provoque généralement une erreur d'autorisation, et non une impossibilité de se connecter au serveur en amont. Vérifiez les paramètres JWT uniquement si le proxy répond mais que l'intégration signale une erreur d'autorisation ou de jeton.
Enfin, vérifiez que Nginx achemine bien le nom d'hôte correct vers l'hôte virtuel approprié. Une faute de frappe dans le nom d'hôte server_name, le nom DNS en amont ou le port peut rediriger le trafic ailleurs ou entraîner l'utilisation d'une configuration obsolète par le proxy. Consultez le journal d'erreurs de Nginx pour rechercher des lignes telles que `<hostname>` host not found in upstream, connect() failed`<hostname>` ou `<hostname> upstream timed out` ; chacune fait référence à une couche différente.
Retestez le flux en amont depuis le réseau proxy, puis vérifiez le point de terminaison de santé publique et ouvrez un document via la plateforme connectée :
curl -I https://docs.example.com/healthcheck
Une réponse positive au test d'intégrité ne devrait plus renvoyer une erreur 502 ; un document devrait s'ouvrir et rester accessible pendant la modification. Si le test en amont réussit mais que la requête publique échoue toujours, examinez l'hôte virtuel Nginx sélectionné, sa configuration et ses journaux. Si la page d'accueil publique s'affiche correctement mais que le test d'intégrité renvoie toujours une erreur 502, poursuivez avec le diagnostic interne du service ONLYOFFICE.
Pour connaître le comportement des directives Nginx, consultez la documentation officielle du module proxy Nginx . Les commandes et les noms de service exacts peuvent varier selon le projet Docker Compose, la distribution Linux et la version d'ONLYOFFICE ; remplacez-les par vos noms réels et consultez les journaux du composant ayant généré la réponse.
Activez le suivi des modifications permanent pour tous les utilisateurs d'un document ONLYOFFICE, vérifiez que les modifications sont bien enregistrées et comprenez les limites de ce paramètre.
Déterminez si Nginx, le réseau Docker ou un service interne ONLYOFFICE renvoie une erreur 502, puis vérifiez le serveur en amont corrigé et effectuez un contrôle d'intégrité.
Diagnostiquez les échecs d'enregistrement ONLYOFFICE en vérifiant la route de rappel Nextcloud, les redirections proxy et les journaux de stockage, puis vérifiez que le fichier modifié est bien conservé.
Identifiez la cause des plantages de mémoire d'ONLYOFFICE, vérifiez les limites de Docker, dimensionnez correctement la RAM du VPS, ajoutez du swap en toute sécurité et vérifiez que les documents s'ouvrent et s'enregistrent correctement.
Distinguez les problèmes de téléchargement du navigateur des erreurs de conversion côté serveur et utilisez le journal ou le contrôle d'accès approprié pour que votre exportation PDF fonctionne.
Faites correspondre le secret JWT utilisé par ONLYOFFICE Docs et Nextcloud, appliquez-le en toute sécurité pour les installations Docker ou Linux et vérifiez la connexion sans affaiblir l'authentification.
Installez ONLYOFFICE Workspace Community sur Ubuntu 24.04 avec le script Docker officiel, vérifiez les exigences du serveur, ignorez Mail si nécessaire et vérifiez le portail en toute sécurité.
Configurez les secrets JWT correspondants pour ONLYOFFICE Docs et son connecteur, avec des étapes sécurisées pour les packages Linux, les déploiements Docker et la vérification.
Personnalisez l'éditeur ONLYOFFICE Docs intégré avec le logo et les couleurs de votre entreprise grâce à un thème et une configuration adaptés. Consultez les limites d'édition et les vérifications de déploiement.
Suivez les modifications dans Writer, conservez une source ODT modifiable et vérifiez le fichier DOCX exporté dans Word avant de le partager.
