Zoom: "Unable to connect" 오류 코드 5003 — 브라우저는 되는데 데스크톱 앱만 Zoom 에 못 붙을 때

안녕하세요, BlueByte입니다. Join 을 누르면 Zoom 데스크톱 앱이 몇 초 생각하다가 Unable to connect 와 Error code: 5003 이 적힌 작은 대화상자를 돌려줍니다. 브라우저의 웹 클라이언트는 같은 미팅에 아무 문제 없이 들어가니 계정도 미팅도 멀쩡합니다. Zoom 의 5003 공식 문서는 "기기와 Zoom 서버 사이의 연결을 막는 문제가 있다"고만 말합니다. 맞는 말이지만, 회사 네트워크에서 흔히 뜻하는 네 가지 중 어느 것인지는 알려주지 않습니다. 오늘은 5003 이 무엇인지, 왜 앱은 죽어도 브라우저는 살아 있는지, 문제의 PC 에서 직접 돌릴 수 있는 세 가지 확인, 원인별 해결, 그리고 Zoom 내장 연결 진단 도구로 확인하는 법까지 하나씩 짚어보겠습니다.

5003 의 뜻, 그리고 브라우저는 왜 되는지

5003 은 클라이언트 쪽 연결 실패입니다. 앱이 Zoom 서비스와의 연결을 끝내지 못한 것입니다. 대화상자 문구는 버전마다 다르지만 코드는 같고, Zoom 의 104101 문서는 똑같은 문장과 똑같은 방화벽·프록시·백신·ISP 절차로 설명합니다. 5003 문서는 그 앞에 제거·재설치만 더할 뿐입니다. 브라우저 클라이언트가 살아남는 건 여느 웹사이트가 필요한 것 — *.zoom.us 와 *.zoom.com 으로 가는 TCP 443 — 만 있으면 되기 때문입니다. 데스크톱 앱은 더 많은 것을 씁니다. Zoom 방화벽 문서는 미팅용으로 TCP 443, 8801, 8802 와 UDP 3478, 3479, 8801–8810 을 들고, 클라이언트가 인증서 검증을 위해 CA 호스트 목록 — ocsp.digicert.com, crl3.digicert.com, crl4.digicert.com 과 Entrust, GoDaddy, Sectigo, UserTrust, Comodo, Starfield 의 대응 호스트 — 을 필요로 한다고 명시합니다. 이 추가 경로 중 하나라도 건드리면 앱은 깨지고 브라우저는 멀쩡합니다.

연결이 끊기는 네 군데

zoom.us 에 대한 SSL 검사. 트래픽을 복호화하는 프록시는 Zoom 의 인증서 대신 자기 인증서를 내밉니다. Zoom 의 안내는 명확합니다 — zoom.us 와 *.zoom.us 를 프록시·SSL 검사에서 제외하라는 것 — 다만 5003 을 그 증상으로 지목하지는 않습니다. 이 연결은 브라우저는 회사 CA 를 신뢰하는데 앱은 실패하던 사례에서 나온 저희 해석이고, 아래 issuer 프로브가 여러분의 경우에 해당하는지 알려줍니다.

443 포트에서 멈추는 방화벽. 웹 클라이언트는 되고, 앱은 미팅 포트나 CA 폐기 목록 호스트가 필요해지는 순간 실패합니다.

엔드포인트 소프트웨어. 백신의 웹 실드와 VPN 스플릿 터널은 프록시와 같은 자리에 앉아 있습니다. Zoom 의 5003 절차는 네트워크 관리자와 방화벽·프록시를 확인한 다음, 그 순서로, 방해할 수 있는 백신을 끄라고 합니다.

손상된 설치. Zoom 의 5003 절차 첫 두 단계는 제거 후 최신 버전 설치입니다. 관리되는 네트워크에서는 가장 드문 원인이지만, 옆자리는 모두 들어가는데 한 대만 실패하는 경우를 해결해 주는 것이 이것입니다.

직접 확인하기: 문제의 PC 에서 하는 세 가지 점검

먼저 zoom.us 로 가는 TCP 443 이 열려 있기는 한지 봅니다. Windows PowerShell 에서:

Test-NetConnection zoom.us -Port 443

TcpTestSucceeded : True 면 포트는 열린 것이고, False 면 프록시가 아니라 방화벽입니다. 둘째로, 이 PC 가 받고 있는 인증서에 누가 서명했는지 봅니다(macOS·Linux, 또는 Windows 의 Git Bash):

curl -sv --max-time 10 -o /dev/null https://zoom.us/ 2>&1 | grep -E "issuer|^< HTTP/"

깨끗한 회선에서 직접 확인해 보면 이런 결과가 나옵니다. 중간 인증서는 바뀔 수 있지만, 조직은 회사가 아니라 공개 CA 여야 합니다:

*  issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
< HTTP/2 301

issuer 에 회사 이름이나 프록시 벤더 이름이 있으면 SSL 검사입니다. 셋째로, 앱 안에서 Zoom 자체 진단을 돌립니다. Windows 는 Ctrl+Alt+Shift+D, macOS 는 Cmd+Option+Shift+D 를 누르면 Network Connectivity Tool 이 열립니다. General Network 테스트는 어댑터, IP 주소, 프록시, 미팅·채팅 서비스의 Service Status 를 보고하고 MTR 추적을 돌리며, Export Log 는 티켓에 붙일 파일을 만들어 줍니다. 설정을 바꾸는 것은 없으니 사용자 PC 에서 돌려도 안전합니다.

해결 1: zoom.us 를 SSL 검사에서 빼기

Zoom 문서의 권고대로 프록시나 방화벽의 복호화 제외 목록에 zoom.us 와 *.zoom.us 를 넣고, issuer 가 다시 공개 CA 가 될 때까지 curl 프로브를 다시 돌립니다. Zoom 은 443 포트의 HTTPS/SSL 프록시를 지원하고 시스템 프록시를 자동으로 감지하며, 프록시가 자격 증명을 요구하면 앱이 사용자 이름과 비밀번호를 물을 수 있습니다. 앱이 답할 수 없는 인증 방식을 요구하는 프록시도 여기서 드러나므로, 같은 프록시를 브라우저에서 써 보고 비교하세요.

해결 2: 앱이 필요로 하는 포트와 호스트 열기

*.zoom.us 와 *.zoom.com 으로 가는 TCP 80/443 과 UDP 443 에 더해, Zoom 미팅 IP 대역 — 방화벽 문서에서 텍스트 파일로 내려받을 수 있습니다 — 으로 나가는 TCP 443, 8801, 8802 와 UDP 3478, 3479, 8801–8810 을 허용하고, 거기 적힌 인증서 검증 호스트도 허용합니다. Zoom 은 대역을 갱신하므로, 변경 티켓에는 스냅샷을 붙여 넣지 말고 문서 링크를 넣으세요.

해결 3: 엔드포인트 소프트웨어, 그다음 깨끗한 재설치

백신의 웹 실드에서 Zoom 을 제외하거나, 테스트로 잠깐 끄고 다시 시도합니다. VPN 을 끊고 다시 시도해서 되면 스플릿 터널 규칙이 *.zoom.us 를 막힌 경로로 보내고 있는 것입니다. 그러고 나서야 Zoom 의 첫 두 단계를 따릅니다. Zoom 을 제거하고 zoom.us/download 에서 현재 버전을 설치합니다.

실제 사례: 새 복호화 정책, 웹은 되는데 데스크톱은 먹통

한 IT 팀이 목요일 저녁에 SSL 검사를 선택 카테고리에서 전체로 바꿨습니다. 금요일 아침 모든 데스크톱 앱이 5003 을 돌려줬고 브라우저 클라이언트는 정상 입장했기 때문에, 첫 한 시간은 사용자 계정과 재설치에 쓰였습니다. 한 자리에서 돌린 curl 프로브가 1분 만에 결론을 냈습니다. issuer 가 회사 CA 였습니다. 팀이 제외 목록에 zoom.us 와 *.zoom.us 를 추가하자 issuer 줄이 DigiCert 로 돌아왔고, 다른 PC 는 손대지 않고도 앱이 입장했습니다.

Zoom 도구로 확인하고, 재발을 막기

변경 후 Network Connectivity Tool 의 Service Status 는 깨끗해야 하고, zoom.us/test 입장은 오디오·비디오가 있는 테스트 미팅에 닿아야 합니다. 재발을 막으려면 세 가지 프로브를 프록시 변경 체크리스트에 넣고, 티켓에는 Zoom 방화벽 문서의 복사본이 아니라 링크를 두며, 프록시 벤더 업그레이드 뒤에는 다시 확인하세요.

비슷해 보이지만 다른 코드들

104101–104118 은 같은 계열입니다. Zoom 의 104101 문서는 똑같은 문장과, 재설치만 뺀 똑같은 네트워크 절차를 쓰므로 같은 점검을 돌리면 됩니다. 브라우저 클라이언트도 실패한다면 앱만의 문제가 아니니 DNS 와 전면 차단부터 보세요. 그리고 연결은 되는데 소리나 화면이 없는 미팅은 5003 이 아닙니다. 저희 경험으로는 UDP 대역 쪽이고, 연결 도구의 phone·meeting 테스트가 보여줍니다.

다음에 앱만 안 되는 Zoom 장애가 책상에 올라오면 이 순서를 거꾸로 따라가 보세요. 443 포트, issuer 줄, 연결 도구 — 그리고 사용자 계정이 아니라 프록시를 고치면 됩니다.