Caddy 뒤에서 DiscourseHub 및 iOS Safari PWA용 Multipath TCP (MPTCP)

후속: 중단된 iOS 게시물 편집 및 HTTP/3 연결 연속성

제가 이전에 질문했던 연결 연속성 문제의 실제 사례를 이제 마주하게 되었습니다.

2026년 10월 21일, iPhone 16 Pro에서 Safari PWA를 사용하여 제 개인 Discourse 인스턴스에서 게시물을 편집하던 중 파란색 저장 중(Saving) 바가 멈춰 버렸습니다. 저는 방금 강의 노트를 음성 입력으로 추가한 상태였습니다.

편집기(composer)에 더 이상 접근할 수 없었으며, 파란색 저장 중 바를 터치해도 마찬가지였습니다. 따라서 저장되지 않은 텍스트를 다른 곳으로 복사할 수 없었습니다.

보통보다 긴 시간 동안 기다린 후, 셀룰러 네트워크 연결을 시도하기 위해 Wi-Fi를 수동으로 비활성화했습니다. 페이지는 즉시 변하지 않았고, 이후의 탐색 시도도 모두 멈춘 것처럼 보였습니다.

그 후 Caddy와 nginx 로그 및 해당 게시물의 수정 이력을 확인했습니다.

BST 12:20:08 시점:

  • Caddy는 대학 Wi-Fi 연결에서 온 HTTP/3 PUT /posts/70695 요청을 기록했으며, 요청 본문 1,000바이트 전체는 수신되었으나 상태 코드는 0이었습니다.

  • nginx는 해당 요청을 HTTP 400으로 기록했으며, Discourse 라우트나 업스트림 처리 시간이 기록되지 않았습니다.

  • 셀룰러 연결에서 발생한 다른 두 개의 iPhone 요청도 같은 초에 HTTP 400 응답을 받았습니다.

  • 그 시점에 성공적으로 기록된 게시물 수정본은 없었습니다.

이후 BST 12:20:55에 이루어진 다음 편집은 성공했지만, 음성 입력으로 작성한 텍스트는 사라져 있었습니다.

또한 BST 12:19:44에 Discourse 초안 자동 저장이 성공적으로 수행되었으나, 그 안에 누락된 텍스트가 포함되어 있었는지 확인할 수는 없습니다.

Wi-Fi를 수동으로 비활성화하는 것이 미완료된 요청들을 중단시켰을 수 있다는 점은 이해합니다. 하지만 원래의 저장 작업은 제가 네트워크 연결을 변경하기 전에 이미 멈춰 있는 상태였습니다.

이는 제 원본 게시물과 관련된 두 가지 질문을 제기합니다:

  1. QUIC 연결 마이그레이션: iOS 브라우저가 새로운 연결을 설정하거나 미완료된 요청을 포기하는 대신 기존 HTTP/3 연결의 마이그레이션을 시도했는지 여부를 파악하는 권장 방법이 있습니까?

  2. Discourse 편집기 복구: 게시물 편집 요청이 멈추거나 중단될 경우, 편집기는 ‘저장 중’ 상태 뒤에 가려져 접근 불가능한 상태로 유지되는 것이 정상적인가요? 저장되지 않은 텍스트를 보존해야 할 타임아웃, 재시도 또는 복구 메커니즘이 이미 존재합니까?

저는 연결성을 회복하려고 시도하기 전에 편집기로 돌아가서 제 작업을 복사할 수 없었기 때문에 특히 두 번째 질문에 관심이 많습니다.

이 사고로 인해 Caddy, nginx 또는 HTTP/3 설정을 변경하지 않았습니다. 현재까지의 증거로는 초기 저장 작업이 왜 멈췄는지 아직 명확히 식별할 수 없기 때문입니다.