코드 편집 세션이 10분에서 종료되는 것을 막으세요

CODE 문서가 약 10분 후에 연결이 끊어지는 문제가 발생한다면, 먼저 모든 리버스 프록시 또는 로드 밸런서를 통한 WebSocket 경로를 점검하십시오. 600초의 유휴 시간 초과는 흔히 구성 문제일 수 있지만, 시간만으로는 프록시가 원인이라고 단정할 수 없습니다. 설정을 변경하기 전에 어떤 구성 요소가 연결을 종료하는지 확인해야 합니다. 대부분의 배포 환경에서 실질적인 해결책은 Collabora WebSocket 업그레이드를 유지하고 프록시의 읽기 및 전송 시간 초과를 예상되는 최장 편집 세션 시간보다 길게 설정하는 것입니다.

먼저 연결이 끊기는 지점을 확인하십시오.

Collabora Online은 브라우저를 통해 CODE 서버에 연결하고, 문서 통합은 Nextcloud와 같은 호스트와의 WOPI 통신에도 의존합니다. Collabora의 역방향 프록시 지침과 Nextcloud의 최신 Office 예제에서는 문서 세션을 위한 별도의 WebSocket 경로를 안내합니다. 해당 경로가 없거나, 잘못된 상위 서버로 연결되거나, 유휴 시간 초과로 인해 연결이 끊어지면 페이지 자체는 계속 접속 가능하더라도 편집기의 연결이 끊어질 수 있습니다.

이는 검증된 아키텍처 요구 사항입니다. 그렇다고 해서 10분 간격으로 발생하는 장애가 모두 동일한 원인이라는 의미는 아닙니다. 클라우드 로드 밸런서, 인그레스 컨트롤러, 방화벽, VPN 또는 다른 프록시가 자체적인 제한을 둘 수 있습니다. 반복되는 장애 간격을 단서로 삼아 장애 발생 시점의 액세스 및 오류 로그를 확인하십시오.

1. 세션이 끊어지는 정확한 시간과, 타이핑 중인지 아니면 문서가 유휴 상태일 때만 발생하는지 기록하십시오.
2. /ws브라우저 개발자 도구에서 네트워크 패널을 열고 "WS"로 필터링한 다음 경로 가 로 끝나는 연결을 검사합니다 /cool/. 해당 연결의 상태를 기록하고 브라우저에서 오류가 보고되면 코드를 닫습니다.
3. 동일한 타임스탬프에서 리버스 프록시 또는 인그레스 로그, CODE 서버 로그, 그리고 WOPI 호스트 로그를 확인하십시오. 프록시 타임아웃, 업스트림 재설정, 비정상적인 WebSocket 종료 또는 WOPI 오류가 있는지 확인하십시오. 로그 문구는 제품 및 버전에 따라 다를 수 있으므로 하나의 메시지가 보편적이라고 가정하지 마십시오.

WebSocket 연결이 설정된 600초 임계값에서 종료되는 경우, 해당 임계값을 관리하는 프록시 또는 중간 서버를 수정하십시오. 연결이 다른 시간 간격에서 종료되거나 로그에 WOPI 또는 서버 오류가 표시되는 경우, 해당 오류를 기준으로 문제를 해결하십시오. Nextcloud의 문제 해결 문서에서는 양방향 연결을 확인하고 Nextcloud 및 Collabora 로그를 모두 검토할 것을 권장합니다.

프록시를 통해 웹소켓을 열어 두십시오.

프록시 파일을 편집하기 전에 활성화된 가상 호스트와 CODE에 대한 실제 업스트림 스키마 및 포트를 확인하십시오. 구성을 백업하고 다시 로드하기 전에 구문을 검증하십시오. 아래 예는 NGINX 리버스 프록시에 필요한 WebSocket 동작을 보여주는 것으로, 완전한 Collabora 가상 호스트는 아닙니다. 이 구성을 배포용 공식 구성에 병합하되, 다른 위치 블록, TLS 설정, URI 처리 및 보안 규칙은 유지하십시오.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

location ~ ^/cool/(.*)/ws$ {
    proxy_pass https://127.0.0.1:9980/cool/$1/ws;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_read_timeout 36000s;
    proxy_send_timeout 36000s;
}

` read` 및 Upgrade` Connectionsend` 헤더를 사용하면 HTTP 요청이 WebSocket으로 전환됩니다. 더 긴 읽기 및 전송 제한은 이 프록시가 기본 설정된 짧은 간격 후에 조용한 연결을 닫지 않도록 방지합니다. 이는 세션을 영구적으로 유지하라는 명령이 아닙니다. 설치 환경에 맞게 업스트림 주소와 TLS 검증을 조정하고, 예제를 작동시키기 위해 인증서 검사를 비활성화하지 마십시오.

Collabora의 공식 프록시 예제는 완벽하고 버전에 맞는 라우팅 구성을 위한 가장 신뢰할 수 있는 자료입니다. 현재 가이드에는 긴 프록시 타임아웃 설정이 포함되어 있으며, Nextcloud의 최신 Docker 예제에는 /cool/(.*)/wsWebSocket 매핑도 별도로 제공됩니다. 전체 가상 호스트를 이 작은 코드 조각으로 교체하는 대신, 이러한 완벽한 예제를 활용하십시오.

• Collabora Online 리버스 프록시 설정
• Nextcloud 35 Docker 설치 예시

NGINX의 경우 nginx -t테스트가 성공한 후에만 실행하고 다시 로드하십시오. Apache의 경우 다시 로드하기 전에 구성 테스트를 수행하십시오. CODE가 Kubernetes 인그레스 또는 클라우드 로드 밸런서 뒤에서 실행되는 경우, CODE 호스트의 NGINX 설정을 변경해도 인그레스 또는 공급자 에지에서 발생하는 타임아웃 시간 단축 문제는 해결되지 않습니다. 로그에서 지적하는 구성 요소를 업데이트하십시오.

CODE뿐만 아니라 모든 네트워크 홉을 확인하세요.

WebSocket 트래픽은 브라우저, CDN 또는 방화벽, 외부 로드 밸런싱, 인그레스, 호스트 프록시, 그리고 CODE 등 여러 중간 단계를 거칠 수 있습니다. 한 계층의 긴 타임아웃이 다음 계층의 짧은 타임아웃을 덮어쓸 수 없습니다. 각 계층의 유휴 또는 연결 타임아웃을 비교하고, 해당 플랫폼의 제한 및 정책 범위 내에서 WebSocket 경로의 타임아웃 제한을 예상 유휴 편집 기간보다 길게 설정하십시오.

문서의 유휴 언로드 설정과 프록시의 네트워크 타임아웃을 혼동하지 마십시오. 전자는 사용되지 않는 문서 프로세스가 언로드될 시점을 제어하는 ​​설정이며, 중간자가 이미 닫은 WebSocket 연결을 복구하는 기능은 아닙니다. 마찬가지로, 타임아웃 시간을 매우 길게 설정한다고 해서 잘못된 업그레이드 경로, 차단된 트래픽, 일치하지 않는 HTTP/HTTPS 구성 또는 CODE 프로세스 충돌 문제가 해결되는 것은 아닙니다. 변경 후에는 종료 시간이 변경되었는지 또는 로그에 기록된 원인이 사라졌는지 확인하십시오. 이렇게 하면 관련 없는 변경 사항을 추가하지 않고도 문제의 원인을 좁힐 수 있습니다.

사용자의 브라우저와 WOPI 호스트 모두 HTTPS를 통해 CODE 서비스에 연결할 수 있는지, 그리고 CODE가 WOPI 호스트에 연결할 수 있는지 확인하십시오. Nextcloud 통합의 경우, 문제 해결 설명서에서는 브라우저에서 공용 엔드포인트 /hosting/capabilities와 명령어를 사용하여 연결 상태를 확인한 다음, CODE 서버에서 Nextcloud 상태 엔드포인트를 확인하도록 권장합니다. 이러한 확인은 기본적인 연결 가능성을 확인하는 것이며, 웹소켓 연결이 10분 동안 유지된다는 것을 보장하는 것은 아닙니다./hosting/discoverycurl

시간 제한 세션을 통해 수리 결과를 확인하십시오.

1. 지원되는 유효성 검사 단계를 사용하여 프록시 또는 인그레스 구성을 다시 로드한 다음 새 문서 세션을 엽니다.
2. 이전 오류 발생 시간보다 문서를 더 오래 열어 두십시오. 편집 중에 한 번 테스트하고, 보고된 문제가 문서가 비어 있는 동안 발생하는 경우 문서가 비어 있는 상태에서 한 번 더 테스트하십시오.
3. /cool/.../ws브라우저의 네트워크 패널에서 연결이 유지되고 있는지, 그리고 문서가 WOPI 호스트를 통해 계속 저장되고 있는지 확인하십시오 .
4. 동일한 시간대의 로그를 검토하십시오. 테스트가 성공적이라는 것은 프록시 시간 초과 또는 예기치 않은 WebSocket 종료 오류가 발생하지 않고 문서를 다시 열었을 때 편집 내용이 유지됨을 의미합니다.

연결이 계속 끊어지면 기록된 실패 시간을 복원하고 각 홉의 로그와 비교하십시오. 진입점에서 600초 후에 연결이 끊어지면 해당 진입점의 문제일 가능성이 높고, 연결 끊김 시간이 다르거나 서버 측 오류가 발생하면 다른 원인이 있을 수 있습니다. "10분"이라는 시간 정보만으로는 정확한 원인을 파악할 수 없으며, 타임아웃 이름과 기본값은 프록시 제품 및 릴리스에 따라 다릅니다. 향후 업그레이드 시 현재 공식 예제와 비교하여 확인할 수 있도록 작동 중인 구성과 CODE 버전 및 프록시 제품을 문서화하여 보관하십시오.