Comece verificando se o navegador, o Nextcloud e o Collabora conseguem acessar os URLs corretos do servidor usando o mesmo esquema HTTP ou HTTPS. No Nextcloud, teste /hosting/capabilitiesos /hosting/discoveryendpoints do Collabora; se eles responderem, mas os documentos ainda falharem, verifique a rota WebSocket do proxy reverso e a lista de permissões WOPI.
A mensagem "Bem, isto é embaraçoso" é uma falha genérica na abertura de documentos, não um diagnóstico em si. A causa pode ser uma URL inacessível, uma incompatibilidade de TLS ou DNS, um proxy que bloqueia atualizações do WebSocket ou um host WOPI no qual o Collabora ou o Nextcloud não confiam. As verificações abaixo usam um exemplo típico com o Nextcloud em `http://localhost:8080` https://cloud.example.come o Collabora em `http:// localhost https://office.example.com:8080`; substitua ambos os nomes pelos seus nomes de host reais.
A partir de um navegador na mesma rede que o usuário, abra estes URLs, alterando o nome do host do Collabora:
https://office.example.com/hosting/capabilitieshttps://office.example.com/hosting/discoveryEles devem retornar dados do endpoint do Collabora em vez de um aviso de certificado do navegador, uma página 404 ou um erro de proxy reverso. O endpoint de descoberta normalmente retorna XML. Você também pode testar a partir do host do Nextcloud ou do contêiner do aplicativo:
curl -fsS https://office.example.com/hosting/capabilities
curl -fsS https://office.example.com/hosting/discoveryUma falha no navegador indica problemas com DNS público ou de rede local (LAN), firewall, certificado ou roteamento de proxy. Se o navegador funcionar corretamente, mas o Nextcloud falhar na linha de comando, significa que a rota no servidor é diferente; o navegador do usuário e o servidor Nextcloud precisam de caminhos distintos para acessar o Collabora. O manual de administração atual do Nextcloud recomenda testar ambos os endpoints a partir de ambos os locais e confirmar se o Collabora também consegue acessar o Nextcloud via HTTP(S).
No Nextcloud, acesse Configurações → Administração → Office e confirme se o campo do servidor Collabora Online contém o URL público ou acessível do Collabora. Use-o https://se o serviço estiver configurado para HTTPS. A documentação do Nextcloud indica que o URL configurado deve usar o mesmo protocolo da instalação do Collabora e recomenda o uso de HTTPS.
Agora verifique o caminho de retorno. A partir do host ou contêiner do Collabora, solicite o endpoint de status do Nextcloud:
curl -fsS https://cloud.example.com/status.phpA resposta deve ser acessível a partir do Collabora, e não apenas do seu computador. Se algum dos servidores estiver em um contêiner Docker, teste a partir do contêiner ou namespace de rede relevante: um nome de host que é resolvido no host pode não ser resolvido dentro de um contêiner. Para um servidor CODE integrado, o Nextcloud deve ser capaz de se acessar usando o mesmo nome de host que os usuários usam no navegador. Se o DNS dividido ou a resolução de nomes local impedirem isso, corrija o DNS ou o mapeamento de host em vez de inserir o nome de host localhostpara um serviço remoto.
Se a URL de descoberta carregar, mas a janela do editor permanecer em branco, girar indefinidamente ou desconectar, verifique o proxy à frente do Collabora. A edição utiliza uma conexão WebSocket persistente: o proxy deve encaminhar /cool/…/wso endpoint atual do Collabora para o serviço Collabora e repassar os cabeçalhos de atualização HTTP/1.1. Consulte o exemplo de proxy atual do Collabora para o seu software e versão de proxy; não copie e cole uma configuração antiga sem alterações.
Instalações mais antigas ainda podem usar caminhos como /lool. O guia de migração da Collabora documenta a mudança de loolpara coole de loleafletpara browser. Um proxy mantido nas rotas antigas pode retornar erros 404 mesmo quando o domínio base abre. Após editar um arquivo de proxy, valide sua sintaxe com o comando de teste do servidor, recarregue-o e, em seguida, teste novamente a URL de descoberta e abra um documento.
Verifique os registros de acesso e de erros no mesmo horário da tentativa falha. Um erro 404 /browsersugere /coolroteamento de caminho; uma falha na atualização do WebSocket sugere ausência de tratamento de atualização ou um tempo limite excedido; um erro 502 geralmente significa que o proxy não consegue alcançar o servidor upstream da Collabora. Essas são pistas, não diagnósticos definitivos, portanto, compare-as com o próprio registro da Collabora.
WOPI (Web Application Open Platform Interface) é o protocolo que o Nextcloud e o Collabora usam para trocar solicitações de acesso a documentos. Se o log do Collabora reportar “Nenhum host WOPI aceitável encontrado” ou um host WOPI não autorizado, confirme se o Collabora foi configurado para confiar no nome do host do Nextcloud — e não no seu próprio nome de host do Collabora. Com a imagem do Docker, inspecione a configuração de inicialização e os logs do contêiner:
docker ps
docker logs --tail=100 CONTAINER_NAMESubstitua CONTAINER_NAMEpelo nome real do contêiner Collabora. Para uma instalação de pacote nativo, inspecione o log de serviço com sudo journalctl -u coolwsd --since "15 minutes ago". Siga as instruções de configuração do host WOPI para o seu método de instalação; evite regras de permissão com curingas genéricos.
Existe também uma lista de permissões WOPI separada no Nextcloud Office. Ela restringe quais endereços IP do servidor Collabora podem solicitar arquivos do Nextcloud. Adicione o endereço IP de origem que o Nextcloud realmente vê para o Collabora, que pode ser diferente quando a rede Docker ou um proxy reverso estão envolvidos. Não insira 0.0.0.0ou desative a restrição apenas para silenciar um erro: o Nextcloud recomenda limitar as solicitações WOPI aos endereços esperados do servidor Collabora.
Repita o teste a partir do navegador do usuário e do servidor Nextcloud: os endpoints de descoberta e de recursos devem responder, o Nextcloud deve acessar a URL do Collabora configurada e o Collabora deve acessar o endpoint de status do Nextcloud. Em seguida, abra um pequeno documento de teste. Se o problema persistir, registre o carimbo de data/hora, a ação afetada no documento, o status HTTP ou WebSocket no log do proxy e as entradas correspondentes nos logs do Nextcloud e do Collabora. Essas evidências ajudam a distinguir uma falha no caminho da rede de um problema de autorização WOPI.
Permita a origem exata do Nextcloud ou de outro servidor WOPI no código e, em seguida, verifique a lista de permissões do host ativo e diferencie-a da restrição de IP de origem do Nextcloud.
Analise as conexões do navegador, WOPI e WebSocket do Collabora para descobrir por que um documento não abre e, em seguida, aplique a correção que corresponde à sua configuração do Nextcloud.
Implante réplicas do Collabora CODE com o Helm, mantenha cada documento em um único pod por meio da afinidade WOPI e verifique o ingress, o posicionamento do nó e a edição do Nextcloud.
Rastreie uma falha no handshake de socket do navegador para o coolwsd e, em seguida, associe a rota do proxy reverso à sua versão do Collabora, incluindo a alteração CODE 26.04 do Apache.
Rastreie falhas na validação WOPI do Collabora devido a chaves incompatíveis, dados de descoberta desatualizados, desvio de relógio ou alterações de URL de proxy, sem comprometer a validação.
Redefina o zoom do navegador, teste uma sessão limpa e identifique quando um menu de tamanho malformado precisa de uma atualização do servidor Collabora.
Implante o Collabora CODE com Docker, conecte-o com segurança ao Nextcloud Office e verifique a edição de documentos com verificações práticas de WOPI e proxy.
Aumente temporariamente o nível de privilégios do coolwsd para depuração, capture uma falha de abertura e use a sequência de logs para separar problemas relacionados a WebSocket, WOPI, proxy e contêiner.
Configure o login de administrador do Collabora Online para Docker ou Linux, reinicie o serviço correto e verifique a nova senha sem expô-la.
Antes de alterar as configurações do Collabora ou reiniciar o serviço, verifique se a carga da CPU provém de documentos ativos, processos de trabalho ociosos ou da capacidade do servidor.
