# Multipath TCP (MPTCP) для DiscourseHub и PWA в iOS Safari за Caddy **URL:** \ **Category:** Self-hosting\ **Tags:** docker, discourse-hub, pwa, advanced-setup, ios\ **Created:** [12.Октябрь.2026 11:17:03 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:** 1
**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:** [12.Октябрь.2026 11:17:03 UTC](https://meta.discourse.org/t/multipath-tcp-mptcp-for-discoursehub-and-ios-safari-pwa-behind-caddy/414499/1 "2026-10-12T11:17:03Z")
Продолжение обсуждения из [Caddy перед Nginx приложения через Docker Compose](https://meta.discourse.org/t/caddy-in-front-of-app-s-nginx-via-docker-compose/410123): После моего предыдущего обсуждения о запуске Caddy перед контейнером nginx Discourse для обеспечения HTTP/3 и QUIC 0-RTT, я занимаюсь отдельным, но связанным вопросом: **может ли Multipath TCP (MPTCP) улучшить непрерывность соединения для пользователей iOS, переключающихся между Wi-Fi и сотовой сетью.** Моя предыдущая работа была в основном посвящена производительности начальной загрузки страницы. Этот вопрос иной: я регулярно обращаюсь к моему частному архиву исследований на Discourse, перемещаясь между различными местами, и прерывания соединения или буферизация могут задерживать доступ к важной информации. ## Почему я задаю этот вопрос В некоторых местах Wi-Fi работает стабильно, а прием сотовой связи плохой; в других — ситуация обратная. Обычное переключение сетей в iOS не всегда обеспечивает необходимую мне непрерывность. Я уже использую отдельные технологии связывания/резервирования сетей (bonding/failover) для устойчивости соединения, но мне интересно понять, можно ли достичь части этой непрерывности нативно между клиентом iOS и моим сервером Discourse. В частности, меня интересует передача соединения (handover) и избегание зависших запросов, а не обязательно агрегация пропускной способности двух соединений. ## Что я выяснил пока [Документация о совместимости Linux MPTCP](https://www.mptcp.dev/apps.html) указывает, что Caddy версии 2.10.0 и выше поддерживает MPTCP по умолчанию, при условии поддержки со стороны операционной системы. [Документация Apple по MPTCP](https://developer.apple.com/documentation/foundation/improving-network-reliability-using-multipath-tcp) описывает, как приложения могут подключить MPTCP через `URLSessionConfiguration`. Однако я также нашел [объяснение на форумах разработчиков Apple](https://developer.apple.com/forums/thread/795547), согласно которому `WKWebView` не предоставляет аналогичного параметра конфигурации MPTCP. Это оставляет меня в неопределенности относительно того, смогут ли DiscourseHub, Safari или установленное iOS PWA воспользоваться преимуществами MPTCP, особенно когда также доступно HTTP/3 поверх QUIC. ## Подтвержденная серверная среда Я проверил производственный VPS с помощью команд только для чтения, не изменяя его конфигурацию. - **Обратный прокси:** Caddy v2.11.4, официальный Docker-образ `caddy:2.11.4` - **Хост:** Ubuntu, ядро Linux `6.8.0-146-generic` - **MPTCP на хосте:** `net.mptcp.enabled = 1` - **MPTCP в контейнере:** `/proc/sys/net/mptcp/enabled = 1` - **Сеть Docker:** `caddy_default`, драйвер `bridge`, параметры `{}` - **Окружение Go:** `GODEBUG` не установлен - **Опубликованные порты:** TCP 80, TCP 443 и UDP 443, по IPv4 и IPv6 Nginx Discourse остается за Caddy, при этом Caddy предоставляет публичные точки доступа HTTPS и HTTP/3. Эти проверки свидетельствуют о том, что сервер имеет базовые предпосылки для поддержки MPTCP, хотя я не проверял фактическое согласование MPTCP через проброс портов Docker. ## Вопросы 1. **DiscourseHub:** Использует ли его сетевой стек для iOS компоненты, способные запрашивать MPTCP, или его основное веб-содержимое обрабатывается через сетевые API, которые не предоставляют такую возможность? 2. **Safari и установленные PWA:** Есть ли какая-либо разница между доступом к Discourse через DiscourseHub, Safari и установленное iOS PWA? Должен ли клиент явно запрашивать MPTCP, или любой из этих способов доступа может получить от этого пользу прозрачным образом? 3. **Сетевая инфраструктура Docker:** Может ли конфигурация bridge/NAT сохранить начальное согласование MPTCP и дополнительные подпотоки (subflows), или это может привести к откату соединений на обычный TCP? 4. **HTTP/3 против MPTCP:** Поскольку HTTP/3 использует QUIC поверх UDP, а не TCP, обеспечит ли миграция соединения QUIC сопоставимую непрерывность при переключении сетей? Существует ли практическая разница между HTTP/2 поверх MPTCP и HTTP/3 поверх QUIC в этой ситуации? 5. **Восстановление на стороне Discourse:** Существуют ли в Discourse или его iOS-клиентах механизмы для восстановления прерванных запросов при изменении базовой сети? Есть ли рекомендуемый способ установить, какой транспорт фактически использует iOS-клиент? Я не предлагаю, чтобы сам Discourse управлял несколькими сетевыми интерфейсами. Я пытаюсь понять, где проходит граница ответственности между iOS-клиентом, транспортным протоколом, Docker/Caddy и Discourse, и есть ли существующие возможности, которыми я мог бы воспользоваться. Буду благодарен за любые подсказки или исправления моего понимания. Спасибо! --- _[View the full topic](https://meta.discourse.org/t/multipath-tcp-mptcp-for-discoursehub-and-ios-safari-pwa-behind-caddy/414499)._