Si je ne me trompe pas, c’est réservé à une route par défaut.
Pour une ip sur le LAN je lui aurait mis un /32 (255.255.255.255 pour tous les hôtes) 
Non je n’ai pas l’erreur de ta capture quand je suis sur les paramètres de NextcloudOffice, voici ce qu’indique la console de mon navigateur :
WebSocket connection to ‘wss://notes.mon-domaine.fr/cool/https%3A%2F%2Fnextcloud.mon-domaine.fr%2Fnextcloud%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F61141_ocvw1a4rl6i4%3Faccess_token%3DJzZhHV02XO1X6diP8iJT2hWH5ok2zTz9%26access_token_ttl%3D0%26permission%3Dedit/ws?WOPISrc=https%3A%2F%2Fnextcloud.mon-domaine.fr%2Fnextcloud%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F61141_ocvw1a4rl6i4&compat=/ws’ failed: WebSocket is closed before the connection is established.SocketBase.close @ notes.mon-domaine.fr/…81b/bundle.js:12414
Les commandes less /var/log/nginx/… ne remontent rien.
Bonjour et merci pour ton retour, mais malheureusement le /32 ne change rien.
Est-ce que le fichier /etc/hosts aurait été édité avec, par exemple :
IP PUBLIQUE nextcloud.domaine
?
Dans le /etc/hosts, j’ai :
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters— BEGIN PVE —
[IP LOCAL] YNH.[IP DNS] YNH
— END PVE —
127.0.0.1 mon-domaine
127.0.0.1 YNH
Mmh… Ce ne serait pas un conteneur LXC installé via les helpers scripts ?
J’ai installé YNH dans un conteneur LXC proxmox avec pour base une debian. Ensuite j’ai installé YNH conformément à la documentation.
Je ne sais pas ce qu’est “helpers script”, mais ce que je peux dire, c’est que cette instance de YNH a été faite dans proxmox le 01/09/2019 (avant il tournait sur un machine physique dédiée depuis le 21/11/2012) et que cette instance tourne sans problème dans son conteneur depuis.
Concernant NextcloudOffice/Collabora, je ne sais plus quand je l’ai installé, mais avant une certaine mise à jour faite en novembre, NextcloudOffice fonctionnait très bien 
.
Ce n’était qu’une simple question car ce type d’installation (via PVE helpers scripts) a déjà posé quelques soucis
Merci beaucoup, c’est parce que ton aide m’est précieuse que j’ai autant détaillé. Si ça peut t’aider .
EDIT: Et je te confirme que je n’ai jamais utilisé ton lien pour installer YNH. Je ne connaissais pas du tout.
As-tu des lignes “wsd” avec une mention d’erreur ERR dans le journal Webadmin>Outils>Services>Coolwsd après avoir tenté d’ouvrir un doc ?
Après une tentative d’ouverture d’un fichier, voici ce que j’ai dans les logs de coolwsd :
Jan 03 15:59:56 coolwsd[33709]: wsd-33709-33733 2026-01-03 15:59:56.018871 +0000 [ websrv_poll ] ERR #-1: No authorized hosts found matching the target host [nextcloud.mon-domaine.fr] in config| wsd/RequestVettingStation.cpp:96
Jan 03 15:59:56 coolwsd[33709]: wsd-33709-33733 2026-01-03 15:59:56.053393 +0000 [ websrv_poll ] ERR #23: No authorized hosts found matching the target host [nextcloud.mon-domaine.fr] in config| wsd/RequestVettingStation.cpp:262
Jan 03 15:59:56 coolwsd[33709]: wsd-33709-33733 2026-01-03 15:59:56.227589 +0000 [ websrv_poll ] WRN FileServerRequestHandler: File not found: Invalid URI request (hash): [/browser/278cb3481b/images/dark/lc_multipageview.svg].| wsd/FileServer.cpp:1175
Jan 03 15:59:56 coolwsd[33709]: wsd-33709-33733 2026-01-03 15:59:56.228729 +0000 [ websrv_poll ] ERR #23: No authorized hosts found matching the target host [nextcloud.mon-domaine.fr] in config| wsd/RequestVettingStation.cpp:262
Essaie ceci
nano /etc/coolwsd/coolwsd.xml
<host desc="Regex pattern of hostname to allow or deny." allow="true">https://nextcloud.mon-domaine.fr</host>
et
systemctl restart coolwsd
J’ai ajouter la ligne comme tu me l’as demandé, j’ai toujours l’erreur WOPI.
Voici les logs de coolwsd :
Jan 03 16:56:05 coolwsd[87815]: wsd-87815-87831 2026-01-03 16:56:05.109462 +0000 [ websrv_poll ] ERR #-1: No authorized hosts found matching the target host [nextcloud.mon-domaine.fr] in config| wsd/RequestVettingStation.cpp:96
Jan 03 16:56:05 coolwsd[87815]: wsd-87815-87831 2026-01-03 16:56:05.131065 +0000 [ websrv_poll ] ERR #23: No authorized hosts found matching the target host [nextcloud.mon-domaine.fr] in config| wsd/RequestVettingStation.cpp:262
Jan 03 16:56:05 coolwsd[87815]: wsd-87815-87831 2026-01-03 16:56:05.199992 +0000 [ websrv_poll ] WRN FileServerRequestHandler: File not found: Invalid URI request (hash): [/browser/278cb3481b/images/dark/lc_multipageview.svg].| wsd/FileServer.cpp:1175
Cela semble pareil non ?
Lorsque j’installe le plugin : “Collabora Online - Built-in CODE Server” et que dans les paramètres, NextcloudOffice je sélectionne : “Utiliser CODE - Collabora Online Development Edition intégré”, cela fonctionne correctement, je peux ouvrir mes documents.
Mais bon, ce n’est pas ce que je veux, même si ça reste auto-hébergé 
.
@otm33, j’ai trouvé la solution. chose étrange, la mise à jour avait modifié imperceptiblement le fichier /etc/coolwsd/coolwsd.xml dans la section que tu indiquais (<wopi desc="Allow/deny wopi storage." allow="true">)
Pour t’indiquer la subtilité, mon domaine ressemble à celui-ci : sousdomaine-rep.mondomaine.fr, et quand j’ai consulté le fichier j’avais : sousdomaine-rep.fr.domaine.fr.
je ne sais pas pourquoi, il y a eu un .fr après le sous domaine. Je l’ai donc retiré et relancé le service, et la tout fonctionne .
Encore merci pour ton aide, ça m’a permis de mieux comprendre comment tout ça s’articule,et de rétablir NextcloudOffice !
Encore merci ! 
je n’ai pas fait attention en copiant depuis le dépôt collabora: c’est ‘https’:// pas ‘scheme’… 
Franchement… 
si tu ne donnes pas les bonnes infos… C’est décourageant et du temps de perdu. Tu parles d’une “solution…”
Je ne comprends pas votre mécontentement, ça met peut-être en évidence l’existance d’un bug lors d’une mise à jours de collabora non ?
N’ayant jamais eu recours aux lignes de commande pour cette application, il est intéressant de ce demander comment elle est arrivée la non ? De plus votre aide a été très précieuse.
J’ajouterai que la modification était assez subtile, pour qu’elle échappe à ma vigilance. je vous prie de m’excuser si je ne l’ai pas vu avant. L’habitude de lecture fait que je l’ai vu uniquement en faisant une recherche complète de mon domaine et que celle-ci ne trouvait rien. J’en ai déduis qu’il y avait un soucis et j’ai corrigé le domaine. Je ne maîtrise pas tout ça aussi bien que vous.
Dans tous les cas merci.
Temps de perdu parce que je pensais ce paramètre assuré et fiable.
Ce paramètre vient d’une saisie de l’utilisateur à l’installation de collabora :
Tu devrais regarder ce fichier car il y a fort à parier que tu vas y retrouver la même erreur pour la valeur
nextcloud_domain :
cat /etc/yunohost/apps/collabora/settings.yml
Si tu laisses en l’état, la prochaine mise à jour va le reporter dans le coolwsd.xml et tu vas te retrouver avec la même problème.
La commande à passer
yunohost app setting collabora nextcloud_domain -v <la bonne adresse>
Bonne soirée.
En effet, le fichier settings.yml avait aussi l’erreur… Je l’ai corrigé grâce à votre commande.
Je vous prie d’excuser ma négligence…
Bonne soirée à vous également et meilleurs vœux.
Hello,
J’avais également un message d’erreur WOPI qui n’apparait plus quand j’utilise mon nom de domaine sans “https://” dans /etc/coolwsd/coolwsd.xml.
<host desc="Regex pattern of hostname to allow or deny." allow="true">mondomaine.fr</host>
Il faudrait donc utiliser un nom de domaine et pas un(e) URI.