WebRTC 연결 테스트
작성 · 수정
지금 쓰는 네트워크에서 브라우저끼리 직접 WebRTC 연결이 되는지 확인하세요. 브라우저가 제시할 수 있는 연결 후보를 모아 종류와 시간을 보여주고, 판정 이유를 설명합니다. 내 주소는 이 화면에만 표시되며 ChatLite로 전송되지 않습니다.
- host 후보
- —
- 서버 반사형(srflx)
- —
- 릴레이
- —
- 첫 srflx까지
- —
- 수집 시간
- —
| 종류 | 프로토콜 | 주소 | 포트 | 발견 시각 |
|---|
주소는 이 화면에만 표시됩니다. 이 페이지는 ChatLite로 아무것도 보내지 않습니다. 공인 주소를 알아내기 위해 브라우저가 구글의 공개 STUN 서버에 STUN 요청을 보내는데, 이는 모든 WebRTC 통화가 하는 일입니다.
이 테스트가 하는 일
두 브라우저 사이의 WebRTC 연결은 가능한 네트워크 경로를 찾는 일에서 시작합니다. 가능한 경로 하나하나를 ICE 후보라고 부릅니다. 이 테스트는 ChatLite가 쓰는 것과 같은 공개 STUN 서버 세 곳을 이용해 내 브라우저에서 그 탐색을 시작하고, 어떤 후보가 얼마나 빨리 나타나는지 지켜봅니다. 그다음 직접 연결이 잘 되거나 실패하는 흔한 패턴과 비교해 판정합니다. 실제 통화를 하지도 않고 상대방도 없으므로, 결과는 내 쪽 연결 상태만 설명합니다.
결과 읽는 법
host 후보
host 후보는 내 기기나 내부 네트워크의 주소입니다. 와이파이 주소가 그 예입니다. 브라우저는 실제 주소 대신 .local로 끝나는 무작위 이름을 쓰는 경우가 많은데, 같은 네트워크의 컴퓨터만 이 이름을 풀 수 있습니다. 개인정보를 보호하려는 동작이며 오류가 아닙니다. host 후보만으로는 같은 네트워크에 있는 두 기기끼리는 연결할 수 있지만, 서로 다른 네트워크에 있는 기기끼리는 연결할 수 없습니다.
서버 반사형(srflx) 후보
srflx 후보는 STUN 서버가 본 내 공인 주소, 즉 공유기가 내 트래픽에 붙여 준 주소와 포트입니다. 네트워크 밖의 상대가 나에게 닿을 수 있게 해 주는 후보입니다. 하나라도 있으면 STUN이 동작하고 UDP가 바깥으로 나간다는 뜻입니다. 이 테스트는 STUN 서버별로 보고된 공인 포트도 비교합니다. 같다면 공유기가 누구와 통신하든 같은 공인 포트를 쓰는 비교적 우호적인 경우이고, 다르다면 목적지마다 새 포트를 고르는 경우로 직접 연결이 더 어렵습니다.
relay 후보
relay 후보는 직접 경로가 안 될 때 트래픽을 전달해 주는 TURN 서버의 주소입니다. 이 테스트는 일부러 TURN 서버를 쓰지 않으므로 relay 개수는 0이어야 정상입니다. 릴레이는 엄격한 네트워크를 위한 안전망이지만 운영하는 쪽에 대역폭 비용이 들기 때문에 무료 서비스 대부분이 모두에게 제공하지 못하며, ChatLite도 릴레이를 항상 쓸 수 있다고 보장하지 않습니다.
시간
대부분의 네트워크는 첫 STUN 요청에 1초 안에 응답합니다. 첫 srflx 후보가 몇 초 뒤에야 나오거나 테스트가 제한 시간에서 멈춘다면, 패킷이 버려지거나 지연되고 있다는 뜻입니다. 혼잡한 회선, 트래픽을 검사하는 방화벽, 거리를 늘리는 VPN을 의심해 볼 수 있습니다.
판정
판정은 내 쪽만 보고 내린 판단입니다. 결과가 좋아도 모든 통화가 연결된다는 약속은 아닙니다. 상대방의 네트워크도 나만큼 중요하기 때문입니다. 결과가 나쁘다고 통화가 불가능한 것은 아니며, 통화가 릴레이 서버에 달려 있을 수 있다는 뜻입니다.
결과가 나쁠 때 할 일
- VPN이나 프록시를 끄고 다시 실행해 보세요. 많은 VPN이 다른 나라의 서버로 트래픽을 보내면서 나타나는 후보를 바꿉니다.
- 휴대폰 핫스팟처럼 다른 네트워크에서 해 보세요. 거기서는 잘 된다면 원래 네트워크가 UDP를 막거나 제한하는 것입니다. 회사·학교 네트워크 글에서 네트워크 관리자에게 무엇을 요청할지 정리해 두었습니다.
- WebRTC를 제한하는 확장 프로그램을 확인하세요. 일부 개인정보 보호 확장은 후보를 숨기거나 프록시로 우회시키며, 후보가 하나도 없는 결과의 흔한 원인입니다.
- 브라우저나 시스템 정책을 확인하세요. 회사·학교에서 관리하는 컴퓨터에서는 관리자가 WebRTC를 꺼 둘 수 있습니다.
- 공유기를 재시작해 보세요. 드물게 오래 켜 둔 공유기가 UDP 매핑을 많이 처리하다 잘못 동작하는 경우가 있습니다.
브라우저별 차이
요즘 데스크톱과 모바일 브라우저는 이 테스트가 쓰는 통화 기능을 모두 지원하지만, 보여주는 정보는 다릅니다. 요즘 많은 브라우저는 로컬 주소를 .local 이름 뒤에 숨깁니다. 후보를 만든 STUN 서버를 알려 주는 브라우저도 있고 그렇지 않은 브라우저도 있으며, STUN 요청 실패의 오류 정보도 다릅니다. 엄격한 개인정보 모드의 파이어폭스나 개인정보 중심 브라우저는 WebRTC를 제한해 후보가 적거나 없을 수 있습니다. 같은 컴퓨터에서 브라우저마다 결과가 다르다면 네트워크가 아니라 브라우저가 원인입니다.
개인정보: 내 주소는 어디로 가나요
이 페이지는 스스로 웹 요청을 보내지 않으며, 후보를 저장하거나 전송하는 코드도 없습니다. 다만 공인 주소를 알아내는 유일한 방법이므로 브라우저가 STUN 서버와 통신하도록 요청합니다. 이 서버들은 구글이 운영하며, 어떤 WebRTC 통화에서든 그렇듯 내 네트워크에서 온 요청을 보게 됩니다. ChatLite 서버는 이 페이지에서 아무것도 받지 않습니다. 주소 표는 열려 있는 탭에만 존재합니다. 체크박스는 도움을 요청할 때 스크린샷을 찍을 수 있도록 주소의 대부분을 가려 주고, 복사 버튼은 주소를 뺀 요약을 만들어 줍니다.
자주 묻는 질문
내 IP 주소가 ChatLite로 전송되나요?
아니요. 주소는 내 화면에만 표시되고 ChatLite로는 아무것도 전송되지 않습니다. 브라우저는 WebRTC가 공인 주소를 알아내는 데 필요한 구글의 공개 STUN 서버와 통신합니다.
relay 후보가 0개인 이유는 무엇인가요?
이 테스트가 TURN 서버를 쓰지 않기 때문입니다. relay 후보는 TURN 서버가 설정되어 있고 닿을 수 있을 때만 생깁니다.
결과는 좋은데 통화는 실패했어요.
통화에는 양쪽 네트워크를 잇는 경로가 필요합니다. 상대 네트워크, 중간의 방화벽, 카메라 문제가 통화를 막을 수 있습니다. 카메라·마이크 테스트도 해 보세요.
지원 담당자에게 내 주소를 보여줘도 안전한가요?
공인·로컬 주소는 대략적인 위치와 네트워크 구성을 드러내므로 믿을 수 있는 사람에게만 알려 주세요. 주소 가리기 옵션과 요약 복사 버튼은 그 때문에 있습니다.
참고 자료
이 글을 확인하는 데 쓴 공식 문서입니다. 문서는 각 운영 주체가 관리하며 바뀔 수 있습니다. 한국어 메뉴 이름은 버전과 언어 설정에 따라 다를 수 있으니, 화면의 이름과 다르면 비슷한 항목을 찾거나 공식 문서의 영어 이름을 참고하세요.
ChatLite의 현재 동작을 기준으로 검토한 날짜: .