이 HTTPS 페이지에서 ws://localhost나 LAN 서버를 테스트할 수 있나요?
브라우저에 따라 다릅니다(2026년 10월 기준). Chrome 147 이상은 내 컴퓨터나 로컬 네트워크로 향하는 WebSocket 연결을 로컬 네트워크 접근으로 취급합니다. 처음에 이 사이트를 허용할지 묻고, '허용'을 선택하면 ws://localhost, ws://127.0.0.1, 그리고 192.168.1.10 같은 LAN IP 주소로의 ws:// 연결이 됩니다. Chrome에서는 LAN 서버를 IP 주소로 입력해야 하며, 일반 호스트 이름(.local 제외)은 로컬 네트워크 주소로 해석되더라도 차단됩니다. Firefox는 localhost에는 바로 연결하지만 LAN 주소로의 ws://는 차단합니다. Safari는 HTTPS 페이지에서 localhost와 LAN으로 향하는 ws://를 차단합니다. wss://는 혼합 콘텐츠 규칙의 영향을 받지 않습니다. 인증서가 신뢰된다면 어느 브라우저에서든 이 페이지에서 공개 서버에 연결됩니다. 다만 localhost나 LAN 주소라면 여기서도 Chrome이 먼저 로컬 네트워크 권한을 요청합니다.
이 페이지에서 ws://example.com에 연결되지 않는 이유는 무엇인가요?
이 페이지는 HTTPS로 제공되며, 브라우저는 HTTPS 페이지에서 공개 호스트로 향하는 암호화되지 않은 ws:// 연결을 차단합니다(혼합 콘텐츠). Chrome과 Firefox는 SecurityError로 즉시 거부하며, 도구가 이를 알려 줍니다. 서버의 wss:// 주소를 사용하십시오. 일반 http로 제공되는 공개 사이트에는 이 규칙이 없지만, 최신 Chrome에서는 그런 사이트가 localhost나 LAN에 아예 접근할 수 없습니다.
코드 1006으로 연결에 실패했습니다. 원인은 무엇인가요?
1006은 종료 핸드셰이크 없이 연결이 끝났다는 뜻일 뿐입니다. 핸드셰이크가 실패하면 WebSocket 표준은 브라우저가 원인을 페이지에 숨기도록 요구합니다. 401, 404, 거부된 포트, 인증서 오류, 거부된 Origin이 모두 똑같아 보이므로(Firefox는 인증서 오류를 1015로 보고합니다) 브라우저에서 바로 연결하는 웹 테스터는 원인을 보여 줄 수 없습니다. F12를 눌러 콘솔을 열면 Chrome과 Edge가 서버가 반환한 HTTP 상태를 출력합니다. 이 도구는 연결이 열리기 전의 실패와 열린 뒤의 끊김을 구분하고, 각각의 흔한 원인을 목록으로 보여 줍니다.
Authorization 같은 사용자 지정 헤더를 추가할 수 있나요?
아닙니다. 브라우저 WebSocket API는 웹 페이지가 요청 헤더를 설정하도록 허용하지 않으며, 브라우저는 정해진 헤더만 보냅니다(Origin과 서버 자체 사이트의 쿠키 포함). 서버가 지원하는 방식에 따라 흔히 쓰는 우회 방법은 다음과 같습니다. wss://host/ws?token=…처럼 URL에 토큰을 넣는 방법, 토큰을 서브프로토콜로 전달하는 방법(토큰 문자만 허용되므로 JWT는 되지만 = 나 /가 들어간 표준 Base64는 안 되며, 서버가 해당 서브프로토콜을 되돌려 보내야 함), 쿠키를 쓰는 방법(브라우저는 페이지 자체 사이트로만 안정적으로 보내므로 이 페이지에서는 대개 서버에 도달하지 않음)입니다. Postman 같은 도구는 브라우저가 아니기 때문에 헤더를 설정할 수 있습니다.
Postman에서는 되는데 여기서는 안 되는 이유는 무엇인가요?
Postman과 명령줄 클라이언트는 어떤 헤더든 설정할 수 있고 보통 Origin을 보내지 않습니다. 브라우저는 Authorization 헤더를 추가할 수 없고 항상 Origin: https://go-tools.org를 보냅니다. 서버가 헤더 토큰을 요구하거나 Origin을 확인한다면 브라우저의 핸드셰이크를 거부합니다. Origin을 허용하거나 다른 방법으로 토큰을 전달하십시오.
하트비트가 WebSocket ping 프레임을 보내나요?
아닙니다. 웹 페이지는 프로토콜 수준의 ping/pong 프레임을 보낼 수도 볼 수도 없으며, 서버가 ping을 보내면 브라우저가 알아서 pong으로 응답합니다. 이 도구의 주기 전송은 {"type":"ping"} 같은 일반 텍스트 메시지를 설정한 간격으로 보냅니다. 그런 메시지를 예상하지 않는 서버는 연결을 닫을 수 있으므로 기본값은 꺼짐입니다. 프록시를 거치는 유휴 연결을 유지하려면 서버가 ping을 보내게 하십시오.
Socket.IO 서버에 연결되지 않는 이유는 무엇인가요?
Socket.IO는 WebSocket 위에서 동작하는 프로토콜이지 순수 WebSocket이 아닙니다. Socket.IO v3/v4 서버는 /socket.io/?EIO=4&transport=websocket 경로를 기대하고, 0으로 시작하는 open 패킷을 보내며, 기본 네임스페이스 참여를 위해 40을 기다리고, ping 2에 pong 3으로 응답하지 않으면 연결을 닫습니다. Socket.IO 프리셋을 선택하면 도구가 이 과정을 모두 처리합니다. 그다음 이벤트를 42["event","data"] 형식으로 보내면 됩니다. HTTP 롱 폴링만 쓰도록 설정된 서버는 WebSocket을 전혀 받지 않습니다.
1분쯤 지나면 연결이 끊기는 이유는 무엇인가요?
대개 리버스 프록시의 유휴 타임아웃 때문입니다. Nginx는 기본적으로 60초 동안 데이터가 오가지 않으면 프록시된 연결을 닫으며(proxy_read_timeout), 페이지에는 코드 1006이 보입니다. 타임아웃을 늘리거나 서버가 ping 프레임을 보내게 하십시오. Nginx 뒤에 있다면 proxy_set_header Upgrade $http_upgrade;와 proxy_set_header Connection "upgrade";로 업그레이드를 전달하는지도 확인하십시오(Nginx 1.29.7 이전에는 proxy_http_version 1.1;도 필요).
자체 서명 인증서를 쓰는 wss:// 서버에는 어떻게 연결하나요?
새 탭에서 https://같은-호스트:포트/를 열고 인증서 경고를 수락한 다음, 돌아와서 연결합니다. 브라우저는 해당 호스트와 포트에 대한 예외를 기억합니다. 브라우저의 보호 수준을 낮추는 일이므로 직접 관리하는 테스트 서버에만 사용하십시오.
바이너리 메시지는 어떻게 보내고 읽나요?
전송 형식으로 HEX 또는 Base64를 선택합니다. HEX는 48 69 00 FF, 0x48,0x69, 486900FF를 모두 받아들입니다. 미리보기에 바이트가 표시되며, 잘못된 문자나 홀수 개의 자릿수는 전송되지 않고 위치와 함께 표시됩니다. 받은 바이너리 메시지는 한 줄에 16바이트씩 HEX로 표시되며, 로그 도구 모음에서 Base64로 전환할 수 있습니다. 받은 HEX를 텍스트로 읽으려면 16진수 문자열 변환에 붙여넣으십시오. 메시지가 go-tools 서버를 거치나요?
아닙니다. 브라우저가 입력한 주소로 직접 연결하며, 메시지는 저희 서버를 거치지 않습니다. 또한 이 도구는 '연결'을 누르기 전까지 WebSocket 연결을 열지 않으며, 주소와 메시지를 메모리에만 보관합니다. 페이지 URL이나 브라우저 저장소에는 저장하지 않습니다. 사이트의 다른 페이지와 마찬가지로 이 페이지도 분석 및 광고 스크립트를 불러옵니다.
테스트에 쓸 수 있는 서버가 있나요?
로컬 에코를 사용하십시오. 이 페이지 안에서 동작하며 보낸 내용을 모두 그대로 돌려주고 네트워크에 연결하지 않습니다. wss://echo.websocket.org/ 같은 공개 에코 서비스도 있지만 제3자 서비스입니다. 가용성이 보장되지 않으며, 메시지가 해당 제3자에게 전송됩니다.