채팅 페이지는 열리는데 실시간 연결이 실패할 때 살펴볼 곳

채팅 페이지를 불러오기 전에 네트워크 패널을 열고, 화면의 뼈대를 그리는 요청이 아니라 메시지를 나르는 요청을 찾으세요. 문서, 스크립트, 로그인 교환, 채팅 전송은 각각 다른 호스트로 갈 수 있습니다. VPN 때문에 채팅이 깨졌다는 보고의 대부분은 실제로 이 네 가지 요청 중 하나가 실패한 이야기입니다. 순서대로 지켜보면 답은 대개 첫 이 분 안에 보입니다.

메시지를 나르는 요청을 찾기

페이지가 안정된 뒤 유형으로 거르세요. WebSocket은 별도 항목으로 나타나고, 이벤트 스트림은 응답이 늘어나면서 열린 채로 남고, 롱 폴링은 일정한 간격으로 반복됩니다. 업데이트를 나르는 항목에 대해 스킴, 호스트, 포트, 상태를 기록하세요. 로그인 전에 시작했는지 후에 시작했는지 적어 두세요. 인증 전에 열린 전송은 보통 인증 후에 열린 것과 설계가 다르기 때문입니다. 업그레이드 요청이나 수용된 콘텐츠 유형에 대해서는 요청 헤더를 읽으세요. 배포된 페이지가 실제로 고른 전송이 거기에 드러납니다.

오래된 포럼 글은 제품이 몇 년 전에 쓰지 않게 된 전송을 설명합니다. 그러니 글보다 브라우저가 기록한 것을 믿으세요. 항목이 아예 없다면 클라이언트 코드가 연결을 시도조차 하지 않았을 수 있고, 이는 더 앞선 스크립트나 설정 실패를 가리킵니다. 페이지가 열린다는 것은 문서가 도착했다는 것만 증명하며, 그 구분이 네트워크를 디버깅하는 상황인지 자체를 결정합니다.

설정, 전달, 수명은 서로 다른 방식으로 실패한다

WebSocket은 101 상태로 응답되는 HTTP 업그레이드로 열리고, 그 뒤의 모든 것은 페이지 가져오기가 아니라 프레임으로 나뉜 메시지입니다. RFC 6455는 이 두 단계를 분명히 나눠 둡니다. 이벤트 스트림은 스트리밍 콘텐츠 유형으로 응답하고 응답 본문을 열린 채로 유지합니다. 둘 다 열리지 않을 수 있고, 열려도 아무것도 전달하지 않을 수 있으며, 열려서 전달하다가 조용히 죽을 수도 있습니다.

wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events

프로필을 건드리기 전에 첫 번째 의미 있는 실패를 잡으세요. 세 가지 시점이 서로 다른 계층을 가리키기 때문입니다. 핸드셰이크가 끝나지 않는다면 같은 호스트로 일반 HTTPS 요청을 보내 무엇이라도 도달하는지 비교하세요. 끝났는데 메시지가 오지 않는다면 다른 계정에서 시험 메시지를 보내는 동안 프레임이나 스트림 본문을 지켜보세요. 작동하다가 멈춘다면 정확한 시각과 종료 코드를 적으세요. 그 두 가지가 어느 쪽이 포기했는지 알려줍니다.

코드 1006은 종료 프레임 없이 소켓이 닫혔다는 뜻이며, 중간 장비나 유휴 타임아웃이 브라우저 안에서 보이는 모습이 바로 그렇습니다. VPN 하트비트는 안쪽 애플리케이션 세션이 살아 있다는 증거가 아닙니다.

실시간 호스트는 별개의 목적지다

채팅 백엔드는 흔히 자기 호스트 이름에서 동작하며, 때로는 다른 포트나 별도 인증서 뒤에 있습니다. 그 목적지에는 자체 이름 해석, 경로, 프록시 처리가 필요하고, 분할 터널링은 페이지를 포함하면서 소켓을 제외할 수 있습니다. 클라이언트 기기에서 실시간 호스트 이름을 해석하고 그 네트워크에서 기대하는 주소로 응답하는지 확인하세요. 인증서 체인은 특히 그 호스트 이름에 대해 확인하세요. 사이트를 덮는 와일드카드가 소켓 엔드포인트까지 늘 덮지는 않기 때문입니다.

경로에 프록시가 있다면 업그레이드나 오래 유지되는 응답을 버퍼링하지 않고 통과시키는지 확인하세요. HTML을 다시 쓰는 기업 프록시는 WebSocket 업그레이드를 자주 잘못 다루며, 그래서 페이지는 그려지는데 채팅은 끝내 연결되지 않습니다. 따라서 같은 제품에 대한 두 요청은 같은 호스트에 대한 두 요청이 아닙니다.

보안 검사가 아니라 목적지 목록을 고친다

목적지 목록을 고치는 것은 라우팅 변경이며 경로 소유자의 일입니다. 인증서 검증을 느슨하게 하거나 Origin 헤더를 없애는 것은 보안 변경이며 정책 소유자의 일이고, 그 사람이 티켓을 디버깅하는 사람인 경우는 드뭅니다. 연결이 되어 보이게 하는 가장 빠른 방법은 보통 사고를 가능하게 하는 가장 빠른 방법입니다.

무엇이든 바꾸기 전에 백엔드가 어떤 오리진을 받아들이는지 애플리케이션 소유자에게 물어보고, 그 답을 프록시를 관리하는 사람에게 넘기세요. 인증서 오류가 터널을 통할 때만 나타난다면 우회를 설치하는 대신 가로채는 장비를 점검하세요.

넘겨줄 만큼 기록한다

쓸모 있는 산출물은 짧습니다. 페이지 URL, 실시간 엔드포인트, 핸드셰이크 결과, 첫 실패 시각, 재연결을 시도했는지 여부. 여기에 VPN 프로필 이름과 사용하던 네트워크를 더하면 읽는 사람이 여섯 가지를 묻지 않고도 시험을 재현할 수 있습니다. 쿠키, 인증 헤더, 메시지 본문은 가리고, 전체 아카이브 내보내기보다 타이밍 열의 스크린샷을 고르세요. 프레임과 네트워크 아카이브에는 사적인 메시지와 세션 토큰이 들어 있을 수 있으니 첨부하기 전에 확인하세요.

실패가 조용한 종료라면 종료 코드와 그 직전의 유휴 구간을 포함하세요. 그 두 가지가 보통 타임아웃의 주인을 알려주기 때문입니다. 타임아웃 값을 스스로 짐작하지 말고 기록을 애플리케이션 또는 게이트웨이 소유자에게 넘기세요. 지원되는 keepalive 동작에 대한 그들의 답이 티켓을 닫는 답입니다.