Se um documento do Collabora Online Development Edition (CODE) abrir normalmente, as edições funcionarem e, em seguida, o editor se desconectar após aproximadamente 10 minutos, comece verificando o caminho do WebSocket entre o navegador e o CODE. Um limite de 600 segundos que se repete sugere muito mais um problema com um proxy reverso, controlador de entrada, balanceador de carga ou firewall do que com os temporizadores de inatividade padrão documentados pelo CODE.
Essa distinção é importante porque alterar primeiro as configurações de inatividade do próprio CODE pode mascarar o problema real sem corrigir a conexão que transporta o tráfego de edição. O modelo de configuração atual do Collabora documenta um tempo limite de inatividade de 15 minutos por visualização e um tempo limite de inatividade de uma hora para documentos, e não um limite de 10 minutos para sessões de edição. Consulte o modelo coolwsd.xml original . Se os usuários estiverem digitando ativamente quando a desconexão ocorrer, uma configuração do CODE que limite apenas a inatividade é uma explicação ainda mais frágil.
Verificado: o exemplo de Nginx publicado pela Collabora usa cabeçalhos de atualização do WebSocket e um parâmetro `long` proxy_read_timeout 36000spara o WebSocket principal. A própria documentação do Nginx informa que as conexões WebSocket por proxy são fechadas quando nenhum dado é recebido dentro do tempo limite de leitura configurado, cujo proxy_read_timeoutvalor padrão genérico é de 60 segundos. Consulte o manual do SDK Online da Collabora e a documentação do proxy WebSocket do Nginx .
Dependente do ambiente: um tempo limite de 600 segundos pode ser introduzido por uma camada de proxy diferente, mesmo quando o host Nginx à frente do CODE parece correto. Isso geralmente ocorre com o Kubernetes Ingress, HAProxy, um balanceador de carga na nuvem, um WAF ou um proxy reverso upstream. O tempo limite exato e a chave de configuração dependem desse componente.
Apenas pelo sintoma: "desconexões após 10 minutos" não comprovam que o Nginx seja o componente responsável. Capture a conexão WebSocket com falha e correlacione seu registro de data e hora com os logs do proxy e do CODE antes de alterar várias camadas simultaneamente.
Ação: reproduza a falha com as ferramentas de desenvolvedor do navegador abertas e registre a duração exata da solicitação WebSocket.
Abra um documento, depois abra as ferramentas de desenvolvedor do navegador e acesse o painel Rede. Filtre o tráfego WebSocket. O tráfego de edição de código normalmente inclui um WebSocket no /cool/caminho especificado. Mantenha o documento aberto mesmo após a falha.
Quando a sessão for desconectada, inspecione a requisição WebSocket. As informações mais úteis são a duração, o momento do fechamento, o status HTTP durante a atualização inicial e se o navegador reporta algum erro de rede. Uma conexão inicial limpa 101 Switching Protocolsseguida de um fechamento por volta de 600 segundos indica a existência de uma política de tempo de vida da conexão ou de inatividade em algum ponto do caminho.
Se o WebSocket nunca for atualizado com sucesso, isso não é um problema de "tempo limite de 10 minutos"; corrija primeiro o roteamento e os cabeçalhos do WebSocket. Se o WebSocket permanecer conectado enquanto o editor exibe um erro de armazenamento ou de salvamento, investigue o caminho WOPI/storage.
Ação: anote a hora de início e a hora de desconexão e, em seguida, compare esses registros de data e hora com os logs de acesso/erro do proxy reverso e os logs do contêiner ou serviço CODE.
Para o Nginx, o importante é que o endereço do WebSocket passe os cabeçalhos de atualização e tenha um tempo limite de leitura suficientemente longo. O manual do SDK da Collabora mostra esse padrão para o WebSocket principal:
location ~ ^/cool/(.*)/ws$ {
proxy_pass https://127.0.0.1:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_read_timeout 36000s;
}Se o TLS for encerrado no Nginx e o CODE estiver intencionalmente servindo HTTP puro por trás dele, o esquema upstream pode ser http://diferente. Não copie o esquema cegamente: ele deve corresponder à configuração da sua instância do CODE.
Um equívoco comum é que `setTimeout` proxy_connect_timeoutcontrola o tempo de vida de uma sessão de edição já estabelecida. Não controla; ele se aplica durante o estabelecimento da conexão com o servidor upstream. A configuração mais diretamente relevante para um WebSocket proxy estabelecido, com períodos sem dados upstream, é `setTimeout` proxy_read_timeout. O Nginx documenta esse comportamento em sua referência do módulo de proxy HTTP .
Ação: localize o bloco Nginx real que corresponde ao URL do WebSocket CODE e confirme se o tempo limite está definido lá, e não apenas em um bloco não relacionado location.
Em outubro de 2026, as notas de lançamento da versão 26.04 do CODE, da Collabora, listam a versão 26.04.4.2, lançada em 24 de setembro de 2026. A série 26.04 introduziu uma URL WebSocket mais compacta. A Collabora observa que as configurações de proxy existentes podem precisar de atualizações; em versões posteriores da 26.04, o CODE pode recorrer à URL legada e emitir um aviso de auditoria quando o proxy não for atualizado. Os usuários do Apache2 foram especificamente instruídos a atualizar sua regra ProxyPass quando a versão 26.04 foi lançada. Consulte as notas de lançamento oficiais da 26.04 do CODE .
Isso não significa que toda desconexão a cada 10 minutos seja causada pela alteração do URL compacto. Significa que, na versão 26.04, você deve verificar suas regras de proxy reverso comparando-as com a documentação da versão que você está usando, principalmente se o problema surgiu após uma atualização.
Ação: verifique a versão do seu código nas informações "Sobre" do produto ou na tag da imagem do contêiner e compare sua configuração de proxy com as diretrizes de proxy atuais do Collabora. Não presuma que uma regra copiada de uma implantação anterior da versão 24.04 ainda seja ideal.
Se o Nginx for apenas uma camada à frente do CODE, estender seu tempo limite pode não ser suficiente. Para Kubernetes usando ingress-nginx, o projeto documenta anotações por Ingress chamadas `@Ingress` nginx.ingress.kubernetes.io/proxy-read-timeoute `@ nginx.ingress.kubernetes.io/proxy-send-timeoutWebSocket`. Suas diretrizes para WebSocket recomendam valores maiores que uma hora para conexões de longa duração. Consulte a referência oficial de anotações do Ingress-Nginx e as notas sobre WebSocket .
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"Para o HAProxy, o exemplo do SDK da Collabora usa um tempo limite de túnel longo para tráfego do tipo WebSocket. Para o Apache, o tempo limite genérico do proxy é controlado por `proxy_timeout` , mas o CODE 26.04 também exige atenção ao padrão atual do WebSocket ProxyPass. A própria documentação do mod_proxyProxyTimeout do Apache explica o que ` proxy_timeout` controla.ProxyTimeout
Ação: desenhe o caminho da conexão do navegador até o CODE e inspecione cada salto. Um limite de 600 segundos em qualquer salto ainda pode encerrar a sessão.
Após editar a configuração do Nginx, teste-a antes de recarregar:
sudo nginx -t
sudo systemctl reload nginxSe o Nginx estiver sendo executado em um contêiner, use o procedimento equivalente de validação e recarregamento específico para contêineres, em vez de presumir que ele systemctljá exista. O importante é validar a sintaxe antes de substituir a configuração em execução.
Ação: altere uma camada de cada vez, registre o valor anterior, valide a configuração e, em seguida, teste novamente o mesmo fluxo de trabalho do documento.
Não interrompa os testes quando o documento for reaberto. Mantenha a mesma sessão de edição conectada por um período bem maior do que o ponto de falha anterior. Para um sintoma que dura 10 minutos, uma janela de validação de 20 a 30 minutos é mais útil do que um teste rápido de dois minutos. Mantenha o painel de Rede aberto e faça edições ocasionais para que você possa distinguir a edição ativa de uma aba totalmente ociosa.
Um bom resultado apresenta três sinais: o WebSocket permanece estabelecido por mais de 10 minutos, o editor continua aceitando edições sem solicitar reconexão e nenhum tempo limite correspondente aparece nos logs intermediários ou do CODE.
Se a conexão ainda for fechada exatamente 10 minutos após você ter aumentado o tempo limite do proxy mais próximo, isso é uma evidência útil de que outro ponto de conexão ainda possui uma política de 600 segundos.
Ação: continue rastreando para fora até que o componente que emite o sinal de fechamento ou tempo limite seja identificado.
O modelo de configuração CODE original atualmente documenta per_view.idle_timeout_secsum intervalo de 900 segundos, ou 15 minutos. Sua descrição indica que a visualização é escurecida e as atualizações são interrompidas quando o usuário fica inativo. O idle_timeout_secspadrão em nível de documento é de 3600 segundos, ou uma hora, antes que um documento ocioso seja descarregado.
Vale a pena verificar esses valores para ver se o seu comportamento corresponde a eles, mas nenhum dos valores padrão explica exatamente uma desconexão de 600 segundos. Se alguém personalizou anteriormente coolwsd.xmlvariáveis de ambiente, valores do Helm ou parâmetros do contêiner, sua implantação pode ser diferente dos valores padrão.
Ação: inspecione a configuração efetiva do código somente depois de determinar se a falha é de nível de rede ou de nível de aplicação. Não aumente todos os valores ociosos como primeira resposta.
| Comportamento observado | A próxima verificação mais útil | O que não presumir |
|---|---|---|
| O WebSocket se fecha após aproximadamente 600 segundos enquanto o usuário estiver ativo. | Tempo limite de proxy, entrada, balanceador de carga ou firewall | Esse código tem um limite de edição integrado de 10 minutos. |
| O WebSocket nunca chega ao HTTP 101. | Atualizar cabeçalhos, roteamento, esquema upstream TLS, caminhos de proxy atuais do Ubuntu 26.04. | O simples fato de aumentar os tempos limite já ajudará. |
| A falha começou após a atualização para o CODE 26.04. | Compare as regras de procuração com as orientações atuais da seção 26.04. | Que uma configuração de proxy antiga do Ubuntu 24.04 seja automaticamente equivalente |
| Apenas as abas ociosas/em segundo plano são afetadas. | Comportamento ocioso por visualização do código, além de tempos limite de ociosidade intermediários. | As falhas em sessões ativas e em sessões ociosas têm a mesma causa. |
| O WebSocket permanece aberto, mas as gravações falham. | Registros WOPI/armazenamento e solicitações de salvamento | Que o tempo limite do WebSocket é a causa principal. |
Para uma sessão de edição do CODE que se desconecta após 10 minutos consecutivos, a sequência mais eficiente é: confirmar a falha do WebSocket, verificar a regra de proxy reverso correspondente, inspecionar todos os tempos limite intermediários, considerar as alterações no caminho do proxy do CODE 26.04, recarregar com segurança e testar além do limite anterior. Altere as configurações de inatividade do CODE somente quando o comportamento observado e a configuração efetiva realmente indicarem essa necessidade.
Se o tempo de falha não for repetível, ou se os registros do CODE mostrarem travamentos, encerramento de processos, sobrecarga de memória ou erros WOPI no mesmo instante, pare de tratá-lo como um simples caso de tempo limite excedido. Esses sintomas exigem um diagnóstico diferente.
O Microsoft Access é um aplicativo de banco de dados para Windows que permite armazenar registros relacionados, criar consultas, elaborar formulários de entrada de dados e gerar relatórios. Saiba como ele funciona e quando é adequado para você.
Aprenda como ajustar a altura e a largura das linhas de grade no Word 2010, alterar a frequência das linhas visíveis e definir o espaçamento horizontal e vertical da grade de desenho subjacente.
Aprenda como importar um arquivo PST para o Outlook 2010 ou exportar emails, contatos, calendário e tarefas. Siga os menus corretos e evite pastas ausentes ou duplicadas.
Recupere uma senha esquecida de um arquivo PST do Outlook seguindo os passos atuais do Kernel, incluindo como identificar o arquivo correto, fazer um backup e verificar as limitações da ferramenta.
Use o suplemento LiveWeb para inserir um site em um slide do PowerPoint, definir seu tamanho e comportamento de atualização e verificar a compatibilidade antes da apresentação.
Aprenda como criar e organizar contatos no Outlook 2010, criar um grupo de contatos e selecionar pessoas salvas na Agenda de Endereços ao endereçar um e-mail.
Crie um campo de Hiperlink no Access 2010 no Modo de Exibição de Design e, em seguida, adicione e teste links para sites, e-mails ou arquivos compartilhados com os detalhes de destino corretos.
Use o Inspetor de Documentos do Word para revisar detalhes do autor, comentários, alterações controladas, texto oculto e outros dados antes de compartilhar, e descubra o que a verificação pode não detectar.
Mova guias personalizadas da Faixa de Opções e comandos da Barra de Ferramentas de Acesso Rápido no Office 2010 com um arquivo .exportedUI e proteja as configurações já existentes no seu computador de destino.
Crie papel quadriculado imprimível no Excel ajustando as dimensões das células, definindo uma área de impressão, escolhendo papel A4 e ativando a impressão de linhas de grade no Excel para desktop.
