Jitsi Meet에서 "연결이 끊어졌습니다"라는 오류 메시지 및 연결 끊김 문제 해결

Jitsi Meet 통화 중 "연결이 끊어졌습니다"라는 메시지가 표시되는 경우는 회의 신호 연결이 끊어지거나, WebRTC 미디어 트래픽이 비디오 브리지에 도달하지 못하거나, 로컬 네트워크 또는 브라우저 문제로 세션이 중단될 때입니다. 먼저 문제가 특정 참가자에게만 발생하는지 아니면 모든 참가자에게 발생하는지 확인하십시오. 이 차이를 통해 기기 및 네트워크 문제인지, 아니면 Jitsi 서버 문제인지 파악할 수 있습니다.

신속 환자 분류 체크리스트

당신이 관찰하는 것	첫 번째 확인	조사 가능성이 높은 지역
한 사람만 연결을 끊습니다	다른 네트워크 또는 장치에서 다시 연결	참가자의 Wi-Fi, VPN, 브라우저, 앱 또는 로컬 방화벽
여러 사람이 동시에 연결을 끊습니다.	그들이 동일한 Jitsi 호스트를 사용하는지 물어보세요.	서버, 리버스 프록시, 방화벽, 인터넷 연결 또는 서비스 장애
회의는 계속 진행되지만 오디오/비디오가 멈춥니다.	카메라를 잠시 껐다가 다시 켜고 오디오가 나오는지 확인하세요.	미디어 경로, 대역폭, UDP 필터링 또는 장치 부하
연결 끊김 현상은 특정 회사 또는 학교 네트워크에서만 발생합니다.	승인된 핫스팟을 사용하여 한 번 더 반복하십시오.	네트워크 정책, 프록시, VPN 또는 WebRTC 트래픽 차단
서버 또는 프록시 변경 후 문제가 발생합니다.	최근 구성 및 서비스 로그를 확인하십시오.	자체 호스팅 Jitsi 신호 처리, TLS, NAT 또는 방화벽 설정

여러 설정을 한 번에 변경하지 마십시오. 한 가지 설정만 변경하고, 가능하다면 같은 회의에 다시 참여한 후 증상이 어떻게 변하는지 확인하십시오.

먼저 어떤 연결이 실패했는지 확인하십시오.

Jitsi Meet는 실시간 오디오 및 비디오를 위해 WebRTC를 사용합니다. 회의가 원활하게 진행되려면 페이지 로딩뿐만 아니라 브라우저가 서버와 신호를 유지하고 Jitsi 비디오 브리지로 미디어 경로를 설정하는 등의 작업이 필요합니다. 때때로 미디어가 멈춘 상태에서도 참가자가 회의실에 계속 표시될 수 있으며, "연결이 끊어졌습니다"라는 메시지가 표시되면 세션 전체 또는 신호 전송에 문제가 발생했을 가능성이 있습니다. 이 메시지만으로는 정확한 원인을 파악할 수 없습니다.

연결이 끊긴 시간, 브라우저에 재연결 메시지가 표시되었는지 여부, 다른 참가자에게 영향을 미쳤는지 여부, 그리고 회의가 meet.jit.si에서 호스팅되었는지 아니면 비공개 Jitsi 도메인에서 호스팅되었는지 여부를 기록하십시오. 비공개 회의 URL, 회의실 이름, 액세스 토큰 또는 수정되지 않은 로그를 공개적으로 게시하지 마십시오.

브라우저를 사용하여 참가자를 확인합니다.

1. 다시 연결하고 회의 링크를 확인하세요.

화면에 재연결 옵션이 나타나면 해당 옵션을 사용하세요. 회의 연결이 복구되지 않으면 원래 초대 링크를 새 탭에서 다시 열고 회의에 참여하세요. 회의실 이름과 호스트 도메인이 초대에 포함된 내용과 일치하는지 확인하세요. 오타가 있거나 이전 링크를 사용하면 다른 회의실이나 호스트로 연결될 수 있습니다. 모든 참가자의 연결이 끊어진 경우, 잠시 기다린 후 회의 주최자에게 서비스가 여전히 사용 가능한지 문의한 다음, 다시 시도해 보세요.

2. 지원되는 최신 브라우저를 테스트하십시오.

브라우저를 업데이트하고 완전히 종료한 후 다시 회의를 시도해 보세요. 연결 끊김 현상이 반복되면 Jitsi에서 지원하는 다른 최신 브라우저를 사용해 보세요. Jitsi의 지원 브라우저 참조 페이지에는 브라우저 지원 및 플랫폼 관련 정보가 나와 있습니다. 지원 세부 정보는 변경될 수 있으므로 해당 페이지를 확인해 주세요. iPhone과 iPad에서는 여러 브라우저 브랜드가 동일한 기본 브라우저 엔진을 사용하므로 다른 브랜드를 사용해도 브라우저 엔진 문제인지 확실히 알 수 없을 수 있습니다.

정확한 비교를 위해 개인 정보 보호 모드를 사용하거나 스크립트 필터링, 추적기 차단 또는 네트워크 요청 수정 기능을 하는 확장 프로그램을 일시적으로 비활성화해 보세요. 이렇게 해서 통화 문제가 해결되면 확장 프로그램을 하나씩 다시 활성화하여 충돌 원인을 찾으세요. 보안 보호 기능을 영구적인 해결책으로 비활성화해 두지 마세요.

3. 네트워크 비교

Wi-Fi 액세스 포인트에 더 가까이 이동하고, 대용량 다운로드나 클라우드 백업을 일시 중지한 다음, 사용 권한이 있는 다른 네트워크에서 한 번 테스트해 보세요. 휴대폰 핫스팟을 사용하면 가정이나 직장 네트워크 문제와 브라우저 또는 서버 문제를 구분하는 데 도움이 될 수 있습니다. Jitsi가 다른 네트워크에서는 작동하지만 원래 네트워크에서는 반복적으로 연결이 끊긴다면, 네트워크 관리자에게 테스트 시간을 알려주고 실시간 WebRTC 트래픽이 필터링되는지 문의해 보세요.

VPN, 프록시, 캡티브 포털 또는 방화벽이 신호 또는 미디어 전송을 방해할 수 있습니다. 조직에서 VPN 사용이 필수인 경우, 해당 정책을 우회하지 마십시오. IT 부서에 Jitsi 호스트의 VPN 사용이 허용되는지 문의하십시오. VPN 연결을 끊은 상태에서 비교가 허용되는 경우, 잠시 동안만 연결을 끊고 다시 VPN을 활성화하십시오.

4. 기기 및 앱 상태를 확인하세요

휴대전화에서 테스트하는 동안 Jitsi 앱이나 브라우저를 전경 상태로 유지하고, 기기에서 허용하는 경우 해당 테스트에 대해 배터리 절약 제한을 해제하세요. 모바일 운영 체제는 백그라운드 네트워크 활동을 일시 중단할 수 있습니다. 또한 앱과 운영 체제가 최신 버전인지 확인하고, 연결에 계속 실패하는 경우 기기를 재시작하세요. 마이크 또는 카메라 권한 문제는 일반적으로 네트워크 연결 끊김보다는 기기 접근에 영향을 미치므로 이러한 증상은 별도로 처리해야 합니다.

오디오/비디오는 나오지 않지만 회의 페이지는 열려 있는 경우

카메라를 일시적으로 끄고 오디오가 안정적인지 확인하십시오. 이렇게 하면 대역폭 사용량을 줄일 수 있지만 서버 경로 문제를 해결하지는 못합니다. 한 네트워크에서 오디오와 비디오가 동시에 작동하지 않지만 다른 네트워크에서는 정상적으로 작동하는 경우 방화벽 또는 NAT 제한 사항을 확인하십시오. Jitsi 자체 호스팅 가이드에서는 일반 웹 액세스에 TCP 443, 일반 오디오/비디오 회의에 UDP 10000, UDP 차단 시 coturn 대체 포트로 TCP 5349를 사용하도록 안내하고 있으며, 선택적 STUN 사용 시 UDP 3478도 사용될 수 있습니다. 이러한 포트는 서버 측 배포 요구 사항이며 참가자가 개인 장치에서 열어야 하는 포트가 아닙니다. 최신 Jitsi 방화벽 및 NAT 지침을 참조하십시오 .

다른 연결에서 회의가 정상적으로 작동하는 경우, 해당 내용을 네트워크 관리자에게 보고하십시오. 방화벽을 일괄적으로 차단해달라고 요청하기보다는 Jitsi 호스트 이름과 WebRTC 트래픽에 대한 조직의 규칙을 검토해 달라고 요청하십시오.

자체 호스팅 Jitsi 관리자 확인

접근성 및 미디어 경로를 확인하십시오.

공용 DNS 이름이 예상 서버로 확인되는지, TLS 인증서가 유효한지, 필요한 트래픽이 올바른 호스트에 도달하는지 확인하십시오. 서버가 라우터 또는 클라우드 방화벽 뒤에 있는 경우 호스트 방화벽과 상위 보안 그룹 또는 포트 포워딩 규칙을 모두 검사하십시오. 클라우드 방화벽에서 동일한 트래픽을 차단하는 경우 상위 방화벽의 규칙은 도움이 되지 않습니다.

sudo ufw status verbose
sudo ss -lntup

이 명령들은 로컬 방화벽 규칙과 수신 소켓을 보여주지만, 외부에서 서비스에 접속할 수 있다는 것을 증명하는 것은 아닙니다. 외부 네트워크에서 테스트하여 라우터 또는 서비스 제공업체가 관련 트래픽을 Jitsi Videobridge로 전달하는지 확인하십시오. Jitsi는 NAT 뒤에 구축된 환경에서 외부에서 통화가 되지 않을 경우, 공용 및 로컬 주소 매핑을 올바르게 설정해야 할 수 있다고 안내합니다.

TLS, 리버스 프록시 및 Docker 설정을 검토하세요.

리버스 프록시를 배포할 경우 HTTPS가 제대로 작동하는지, 그리고 프록시가 WebSocket 시그널링을 올바르게 전달하는지 확인해야 합니다. 공식 Docker 가이드 에는 Nginx 예제에 필요한 경로와 헤더가 설명되어 있습니다 /xmpp-websocket. 페이지는 제공하지만 WebSocket 연결을 끊는 프록시는 사용자가 회의 세션을 유지할 수 없게 만들 수 있습니다.

Docker Compose를 사용할 때는 PUBLIC_URL방문자가 실제로 사용하는 공용 도메인과 일치하는지, 그리고 게시된 호스트 포트가 방화벽 및 프록시 설정과 일치하는지 확인하십시오. Jitsi 가이드에서는 실제 회의를 HTTPS 대신 HTTP를 통해 직접 제공하면 WebRTC 문제가 발생할 수 있다고 경고합니다. 사용하는 Jitsi 버전과 배포 방법을 확인하지 않고 다른 Jitsi 릴리스의 구성 스니펫을 복사하지 마십시오.

서버 로그와 사고 발생 시간을 연관시켜 분석합니다.

연결 끊김 시간을 서비스 로그와 비교하십시오. Debian 또는 Ubuntu 패키지 설치의 경우 Jitsi는 /var/log/jitsi/jvb.log, /var/log/jitsi/jicofo.log, 등의 로그 파일을 기록합니다 /var/log/prosody/prosody.log. Docker 배포의 경우 컨테이너를 통해 로그가 저장되므로 관련 컨테이너 출력과 설치된 릴리스의 구성 디렉터리를 확인하십시오.

sudo tail -n 150 /var/log/jitsi/jvb.log
sudo tail -n 150 /var/log/jitsi/jicofo.log
sudo tail -n 150 /var/log/prosody/prosody.log

해당 사건 발생 시점 주변에서 서비스 재시작, 브리지 등록 변경, WebSocket 오류, 인증서 오류 또는 반복적인 연결 시간 초과 등의 원인을 검색하십시오. 로그를 공유하기 전에 참가자 식별자, 회의실 이름, IP 주소 및 토큰은 삭제하십시오. Debian/Ubuntu 자체 호스팅 가이드 에서는 기본적인 디버깅 단계로 다른 브라우저 사용, WebRTC 지원 확인, 방화벽/NAT 규칙 검토 등을 권장합니다.

문제 해결 과정 점검표

Jitsi 호스트, 대략적인 타임스탬프 및 시간대, 장치, 운영 체제, 브라우저 또는 앱 버전, 그리고 문제가 한 사람에게만 영향을 미치는지 아니면 회의 전체에 영향을 미치는지 기록하십시오.
다른 브라우저나 네트워크를 사용할 경우 결과가 달라지는지 확인하십시오.
자체 호스팅 서버의 경우 최근 프록시, 방화벽, DNS, 인증서 또는 Jitsi 업그레이드 내역을 포함하십시오.
진단에 필요한 최소한의 정보만 공유하고, 개인실 정보 및 자격 증명은 삭제하십시오.
meet.jit.si 또는 다른 관리형 호스트를 사용하는 경우, 보고서를 회의 주최자 또는 서비스 지원팀에 보내주십시오. 참가자는 해당 호스트의 방화벽이나 서버 구성을 변경할 수 없습니다.

수정 사항을 확인하는 방법

원래 기기와 네트워크에서 테스트 회의에 참여하고, 오류가 발생하는 시간대를 충분히 확보할 수 있도록 연결 상태를 유지한 후 오디오와 비디오가 정상적으로 작동하는지 확인하십시오. 문제가 모든 참가자에게 영향을 미치는 경우 다른 참가자와 함께 이 과정을 반복하십시오. 자체 호스팅 환경의 경우, 서버 네트워크 외부에서 브라우저 신호와 미디어 전송을 모두 확인하십시오. 페이지 로드 성공만으로는 충분하지 않으며, 회의 연결이 유지되고 참가자들이 오디오와 비디오를 주고받을 수 있어야 합니다.