DiscourseHub 和 iOS Safari PWA 在 Caddy 后端的 Multipath TCP (MPTCP)

产品支持 安装
, , , ,
2

后续跟进：iOS 帖子编辑中断与 HTTP/3 连接连续性

我现在遇到了一个关于我之前询问的连接连续性问题的实际案例。

2026 年 10 月 21 日，当我在 iPhone 16 Pro 上使用 Safari PWA 编辑我私人 Discourse 实例中的帖子时，蓝色的保存中（Saving）进度条卡住了。我当时刚刚通过语音输入添加了一些额外的讲义笔记。

此时无法再访问编辑器，即使点击蓝色的“保存中”进度条也没有反应，因此我无法将未保存的文本复制到其他位置。

在等待了比平时更长的时间后，我手动禁用了 Wi-Fi，尝试切换到蜂窝网络。页面没有立即发生变化，但随后的导航尝试似乎也挂起了。

随后，我检查了 Caddy 和 nginx 日志以及该帖子的修订历史。

在 12:20:08 BST：

  • Caddy 记录了一个来自大学 Wi-Fi 连接的 HTTP/3 PUT /posts/70695 请求，已接收全部 1,000 字节的请求体，但状态码为 0。
  • nginx 将对应的请求记录为 HTTP 400，且没有 Discourse 路由或上游处理时间的记录。
  • 同一秒内，另外两个源自蜂窝网络的 iPhone 请求也收到了 HTTP 400 响应。
  • 当时没有记录到任何成功的帖子修订。

随后的一次编辑在 12:20:55 BST 成功完成，但语音输入的文本缺失了。

此外，在 12:19:44 BST 还有一次成功的 Discourse 草稿自动保存，但我无法确定其中是否包含缺失的文本。

我理解手动禁用 Wi-Fi 可能会中断未完成的请求。然而，在我更改网络连接之前，最初的“保存”操作就已经卡住了。

这引出了与我原始帖子相关的两个问题：

  1. QUIC 连接迁移： 是否有推荐的方法来确认 iOS 浏览器是尝试迁移现有的 HTTP/3 连接，而不是建立新连接或放弃未完成的请求？

  2. Discourse 编辑器恢复： 如果帖子编辑请求卡住或被中断，编辑器是否预期会保持在“保存中”状态下而无法访问？是否存在现有的超时、重试或恢复机制来保留未保存的文本？

我对第二个问题特别感兴趣，因为在我尝试恢复连接性之前，无法返回编辑器复制我的工作内容。

由于现有证据尚未确定是什么导致初始“保存”操作停滞，因此在本次事件发生后，我没有更改任何 Caddy、nginx 或 HTTP/3 设置。