Firefox에서 첫 WebSocket 메시지만 안 보인다면?

세 줄 요약

서버가 안 보낸 것이 아니라 검사 화면이 놓쳤을 수 있다

연결 직후 첫 메시지만 Network 목록에 없다면 Firefox 버전부터 확인할 이유가 있다. Firefox 158 릴리스 노트는 연결이 성립한 직후 도착한 WebSocket 메시지를 Network Monitor가 놓칠 수 있던 문제를 수정했다고 밝혔다.

수정 대상은 개발자 도구의 관찰 문제다. 목록에 행이 없다는 사실을 곧바로 서버의 미전송이나 앱의 수신 실패로 해석하면, 정상적으로 오간 메시지를 두고 서버 코드를 고치게 될 수 있다.

Bug 1719394의 최초 신고자는 Rustpad 연결의 첫 Identity 프레임이 보이지 않는다고 보고했다. 담당자도 첫 프레임 누락을 재현했다. 이 사례는 연결 뒤의 메시지가 보인다고 해서 초기 메시지 목록도 완전했다고 가정할 수 없음을 보여 준다.

첫 프레임을 살피려면 연결이 만들어지는 순간부터 관찰해야 한다. Network Monitor 문서에 따르면 도구 상자가 열려 있는 동안 요청이 기록된다. 이미 끝난 연결 시작 과정을 나중에 도구를 열어 되살리는 방식으로 접근하면 안 된다.

재접속을 여러 번 했다면 URL이 같아도 각각 다른 연결이다. 처음 열었던 요청을 계속 보고 있는지, 방금 생성한 요청을 보고 있는지 구분해야 첫 메시지를 올바르게 비교할 수 있다.

Firefox의 WebSocket 검사 안내는 Response의 텍스트 필터와 방향 필터를 제공한다. 찾는 메시지가 없다면 필터를 비우고 기록이 일시정지돼 있지 않은지 확인한다.

기본 All 목록은 제어 프레임을 제외한다. 따라서 Ping이 안 보이는 현상은 연결 직후의 앱 메시지가 빠지는 버그와 같은 증상으로 묶으면 안 된다. 먼저 어떤 종류의 프레임을 찾고 있는지 정해야 한다.

검사 도구와 별도로 앱이 실제 받은 데이터를 남기면 판단 근거가 하나 더 생긴다. WebSocket의 message 이벤트는 연결을 통해 데이터를 수신했을 때 발생한다. 다음은 앱 코드에서 기존 socket을 만든 직후 등록할 수신 로그 예시다.

socket.addEventListener("message", (event) => {
  console.log("WS received:", event.data);
});

첫 메시지를 비교하려면 리스너도 처음부터 등록돼 있어야 한다. 초기 메시지가 지난 뒤 콘솔에 코드를 넣으면 이미 지나간 이벤트는 이 로그에 남지 않는다. 별도 연결을 하나 더 만들어 기록한 결과도 원래 연결의 수신 증거가 아니다.

같은 메시지가 앱 로그에는 있고 Response 목록에만 없다면 표시·기록 쪽을 먼저 살펴볼 수 있다. 양쪽에 없으면 그것만으로 서버가 보내지 않았다고 확정할 수는 없다. 연결의 일치 여부, 서버 발송 기록, 앱의 리스너 등록 시점을 함께 확인해야 한다.

Firefox 158의 수정은 이런 조사에서 개발자 도구가 놓치던 초기 데이터를 보완한다. 오래된 버전의 빈 목록만으로 판단하기보다, 수정된 버전에서 새 연결을 포착하고 같은 메시지를 앱 기록과 나란히 보는 것이 다음 단계다.