# Multipath TCP (MPTCP) für DiscourseHub und iOS-Safari-PWA hinter Caddy **URL:** \ **Category:** Self-hosting\ **Tags:** docker, discourse-hub, pwa, advanced-setup, ios\ **Created:** [12. Oktober 2026 um 11:17 UTC](https://meta.discourse.org/t/multipath-tcp-mptcp-for-discoursehub-and-ios-safari-pwa-behind-caddy/414499 "2026-10-12T11:17:03Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)\ **Post date:** [21. Oktober 2026 um 18:49 UTC](https://meta.discourse.org/t/multipath-tcp-mptcp-for-discoursehub-and-ios-safari-pwa-behind-caddy/414499/2 "2026-10-21T18:49:13Z")
### Nachtrag: Unterbrochene iOS-Beitragsbearbeitung und HTTP/3-Verbindungsfortschritt Ich bin nun auf ein praktisches Beispiel des Verbindungsfortschrittsproblems gestoßen, nach dem ich gefragt hatte. Am 21. Oktober 2026, während ich einen Beitrag in meiner privaten Discourse-Instanz auf einem iPhone 16 Pro über die Safari-PWA bearbeitete, blieb die blaue **Speichern** -Leiste hängen. Ich hatte gerade einige zusätzliche Vorlesungsnotizen diktiert. Der Composer war nicht mehr zugänglich, auch wenn ich die blaue Speichern-Leiste berührte, sodass ich den ungespeicherten Text nicht an anderer Stelle kopieren konnte. Nachdem ich länger als üblich gewartet hatte, deaktivierte ich manuell das WLAN, um die Mobilfunkverbindung zu testen. Die Seite änderte sich nicht sofort, aber nachfolgende Navigationsversuche schienen ebenfalls einzuhängen. Anschließend untersuchte ich die Caddy- und nginx-Logs sowie die Revisionshistorie des Beitrags. Um **12:20:08 BST** : - Caddy protokollierte eine HTTP/3-`PUT /posts/70695`-Anfrage von der universitären WLAN-Verbindung, bei der alle 1.000 Bytes des Anfragekörpers empfangen wurden, jedoch mit Status `0`. - nginx protokollierte die entsprechende Anfrage als HTTP `400`, ohne Discourse-Route oder Upstream-Verarbeitungszeit. - Zwei weitere iPhone-Anfragen, die von der Mobilfunkverbindung stammten, erhielten in derselben Sekunde ebenfalls HTTP `400`. - Zu diesem Zeitpunkt wurde keine erfolgreiche Beitragsrevision aufgezeichnet. Eine anschließende Bearbeitung gelang um 12:20:55 BST, aber der diktierte Text fehlte. Es gab auch ein erfolgreiches automatisches Speichern eines Discourse-Entwurfs um 12:19:44 BST, obwohl ich nicht feststellen kann, ob es den fehlenden Text enthielt. Ich verstehe, dass das manuelle Deaktivieren des WLANs ausstehende Anfragen unterbrochen haben könnte. Allerdings war der ursprüngliche Speichervorgang bereits eingefroren, bevor ich die Netzwerkverbindung geändert habe. Dies wirft zwei Fragen im Zusammenhang mit meinem ursprünglichen Beitrag auf: 1. **QUIC-Verbindungsmigration:** Gibt es eine empfohlene Methode, um festzustellen, ob der iOS-Browser versuchte, die bestehende HTTP/3-Verbindung zu migrieren, anstatt eine neue Verbindung herzustellen oder ausstehende Anfragen abzubrechen? 2. **Discourse-Composer-Wiederherstellung:** Wenn eine Beitragsbearbeitungsanfrage einfriert oder unterbrochen wird, soll der Composer dann hinter dem Speicherzustand unverfügbar bleiben? Gibt es einen vorhandenen Timeout-, Retry- oder Wiederherstellungsmechanismus, der den ungespeicherten Text erhalten sollte? Mich interessiert insbesondere die zweite Frage, da ich vor dem Versuch, die Konnektivität wiederherzustellen, nicht zum Editor zurückkehren konnte, um meine Arbeit zu kopieren. Ich habe aufgrund dieses Vorfalls keine Caddy-, nginx- oder HTTP/3-Einstellungen geändert, da die verfügbaren Beweise noch nicht zeigen, was dazu geführt hat, dass der anfängliche Speichervorgang ins Stocken geriet. --- _[View the full topic](https://meta.discourse.org/t/multipath-tcp-mptcp-for-discoursehub-and-ios-safari-pwa-behind-caddy/414499)._