Commencez par vérifier si l'écran blanc affecte un seul fichier ou tous les fichiers, puis examinez les panneaux Réseau et Console du navigateur ainsi que les journaux de Collabora et de la plateforme de stockage. Un écran blanc est un symptôme, pas un diagnostic : l'éditeur a peut-être chargé alors que la connexion au document, l'autorisation WOPI ou les ressources intégrées ont échoué.
Ouvrez un document fonctionnel dans la même application, puis essayez d'ouvrir le fichier problématique dans un autre navigateur compatible ou dans une fenêtre de navigation privée. Ne modifiez pas le fichier original pendant le diagnostic. Un seul fichier défectueux indique un problème de format, de contenu ou d'autorisations ; des défaillances généralisées indiquent un problème de services partagés ou de modifications du réseau.
| Ce que vous observez | Vérification suivante la plus utile | Compromis |
|---|---|---|
| Un document est vierge | Essayez un autre fichier du même format ; examinez les journaux de fichiers et WOPI de l’application de stockage. | Isolation rapide, mais n'exclut pas un problème d'analyse ou d'autorisation spécifique au fichier. |
| Tous les documents échouent dans un seul navigateur | Fenêtre de navigation privée, autre navigateur, extensions et console du navigateur. | Peu risquée et rapide, mais une solution de contournement via navigateur ne résout pas un problème de serveur. |
| Tous les utilisateurs et navigateurs échouent | Requêtes réseau, proxy inverse, politique d'hôte WOPI et journaux du serveur. | Plus utile pour le diagnostic, mais les modifications peuvent affecter tous les utilisateurs ; il est donc conseillé de noter d’abord les paramètres actuels. |
La navigation privée est un test, pas une solution. Si le problème est résolu, désactivez les extensions une par une ou effacez les données de site pour l'origine concernée uniquement après avoir vérifié qu'aucun travail n'est désynchronisé. L'effacement de toutes les données de navigation peut déconnecter les utilisateurs et supprimer des données de site non pertinentes.
Dans Chrome ou Chromium, ouvrez les outils de développement ( F12 ou Ctrl+Maj+I ), sélectionnez Réseau , activez l'option « Conserver le journal » et rechargez la page. Filtrez les requêtes WS (WebSocket) et examinez les erreurs ; la documentation réseau des outils de développement Chrome explique les filtres de requêtes et les détails d'état. Consultez la console pour détecter les erreurs CSP, de certificat, de contenu mixte ou JavaScript.
Interpréter les preuves plutôt que d'appliquer une recette générique par procuration :
/browser/les chemins de l'éditeur : vérifiez si le proxy inverse transfère les chemins Collabora actuels vers le serveur en amont approprié./hosting/discoverypoint de terminaison accessible prouve uniquement un accès HTTP de base ; il ne garantit pas le bon fonctionnement de la connexion de l'éditeur.Pour les requêtes WebSocket, l'objectif est d'établir une liaison réussie ; le statut affiché dépend de la version HTTP et du chemin du proxy, il ne faut donc pas considérer un seul numéro de statut attendu comme universel.
Les instructions de dépannage actuelles de Nextcloud indiquent que le navigateur de l'utilisateur doit accéder aux deux serveurs via HTTP(S), Nextcloud doit accéder à Collabora et Collabora doit accéder à Nextcloud. Elles exigent également l'utilisation du même protocole sur les deux services. Testez l'adresse publique de Collabora depuis un navigateur à l' https://office.example.com/hosting/discoveryadresse indiquée https://office.example.com/hosting/capabilities. Depuis l'hôte Nextcloud, utilisez :
curl -fsS https://office.example.com/hosting/discovery -o /dev/null
curl -fsS https://office.example.com/hosting/capabilities -o /dev/null
Remplacez le nom d'hôte d'exemple par votre URL Collabora réelle. Ces vérifications permettent de s'assurer de l'accessibilité HTTP, et non de la réussite de l'édition. Si le serveur réussit mais que le navigateur échoue, vérifiez le DNS public, le protocole TLS, le pare-feu ou le proxy. Le guide de dépannage de Nextcloud Office répertorie ces vérifications de connexion et recommande de consulter les journaux des deux applications.
Si les ressources de l'éditeur statique renvoient une erreur 404 ou si la connexion en direct renvoie une erreur 502, comparez les routes de votre proxy inverse avec les paramètres de proxy officiels de Collabora . Assurez-vous que le proxy envoie les chemins Collabora requis au serveur en amont approprié et qu'il prend en charge la connexion WebSocket utilisée par le navigateur. Conservez les informations d'hôte externe et HTTPS attendues par votre déploiement. Ne copiez pas une configuration pour un autre proxy, préfixe d'URL ou version de Collabora sans en vérifier les hypothèses. Un nom d'hôte Collabora dédié est souvent plus facile à déboguer ; le routage basé sur les chemins exige une gestion cohérente des préfixes.
WOPI est le protocole utilisé par Collabora pour récupérer et enregistrer un document via la plateforme de stockage. L'hôte WOPI correspond généralement au nom d'hôte de Nextcloud ou d'un autre service de stockage, et non à celui de Collabora. Si les journaux indiquent une erreur No acceptable WOPI hosts found, ajoutez ou corrigez l'hôte de stockage exact dans la configuration WOPI de Collabora, puis vérifiez que la liste blanche des requêtes WOPI de la plateforme de stockage contient bien l'adresse du serveur Collabora. Nextcloud recommande de limiter les requêtes WOPI aux adresses IP attendues de Collabora et de configurer Collabora pour qu'il fasse confiance aux hôtes autorisés, conformément à ses instructions de configuration Office .
L'ajout d'un hôte de confiance spécifique est plus sûr que la désactivation de la validation des hôtes ou l'autorisation de domaines trop larges. Notez la configuration actuelle, modifiez uniquement l'entrée concernée et redémarrez ou rechargez les services uniquement lorsque votre déploiement l'exige. Si vous utilisez Docker, consultez la sortie récente de Collaboradocker logs --since=10m <collabora-container> ; remplacez l'espace réservé par le nom réel du conteneur. Pour les installations de packages ou de pods Kubernetes, utilisez plutôt les journaux de service ou de pod.
Rechargez le même document. Vérifiez que les ressources sont chargées, que la connexion est maintenue, que le contenu s'affiche et que les erreurs de la console cessent. Testez un deuxième document et un autre utilisateur si le problème est partagé. Enregistrez une modification de test sans conséquence et rouvrez-la pour vérifier la lecture et l'enregistrement.
Si l'écran reste blanc mais que les requêtes aboutissent, consultez les journaux du serveur pour détecter d'éventuelles erreurs de conversion de document ou des erreurs spécifiques aux fichiers, et comparez-les avec un autre fichier du même format. Si le problème est apparu immédiatement après une mise à jour de Collabora, du navigateur ou du proxy, effectuez une restauration contrôlée ou modifiez le proxy pour une version spécifique lors d'une fenêtre de maintenance, plutôt que de modifier plusieurs variables simultanément. Vider le cache du navigateur n'est utile que si des éléments indiquent la présence de ressources client obsolètes ; cela ne permet pas de résoudre les problèmes de routes bloquées ou de requêtes WOPI rejetées.
Installez le graphique Helm officiel de Collabora, configurez l'accès WOPI et l'affinité d'entrée, et vérifiez le déploiement sans erreurs de configuration courantes.
Utilisez les requêtes du navigateur, les journaux WOPI et les vérifications de proxy ciblées pour déterminer pourquoi Collabora ouvre un document vierge et choisissez une solution adaptée aux éléments de preuve.
Configurez correctement les dictionnaires Docker de CODE et les passages de documents étiquetés afin que l'anglais, le français et les autres langues prises en charge bénéficient d'une correction orthographique appropriée.
Ajustez le seuil d'inactivité par vue dans coolwsd et distinguez-le de l'assombrissement des onglets en arrière-plan, du déchargement des documents, de la sauvegarde automatique et de l'expiration de la connexion.
Interrompez les vérifications de mise à jour du code planifiées, examinez les services distants optionnels et utilisez les contrôles réseau sortants sans interrompre l'édition des documents.
Activez l'édition sécurisée de documents dans Seafile en configurant l'URL de découverte de Collabora, le protocole HTTPS et l'accès WOPI pour votre déploiement.
Testez le presse-papiers système, ajustez les autorisations du navigateur et identifiez les cas où une intégration Collabora intégrée nécessite une modification de la politique iframe.
Montez les fichiers de polices dans Docker et le système de Collabora afin que les polices personnalisées apparaissent dans l'éditeur et s'affichent correctement dans les documents.
Sauvegardez coolwsd.xml et ses sources de déploiement, restaurez-les en toute sécurité et vérifiez le code avant que les utilisateurs ne reprennent l'édition.
Autorisez l'origine exacte Nextcloud ou autre WOPI dans CODE, puis vérifiez la liste blanche des hôtes actifs et distinguez-la de la restriction d'adresse IP source de Nextcloud.
