从 WebStation 到 Cloudflare Tunnel：我的群晖网络架构演进

做家庭 Homelab，其实最终绕不开几个关键词：网络、反向代理、Docker 与稳定性。

前几年刚开始折腾群晖的时候，我的思路其实很简单：

WebStation
+
Docker
+
Alias

例如：

/epg
/jellyfin
/ai

当时感觉非常合理，甚至会觉得：

这不就是网站部署吗？

但后来服务越来越多：

• React / Next.js
• Jellyfin
• AI WebUI
• EPG
• Grafana
• code-server
• WebSocket 服务

整个系统开始逐渐变得混乱。

最开始只是偶发页面不存在、静态资源 404、WebSocket 失败、反向代理异常。后来这些问题越来越明显，我才意识到：WebStation 更像旧时代 Web Hosting 的产物。

它非常适合：

• PHP
• WordPress
• Apache
• Typecho

但并不真正适合：

• SPA
• WebSocket
• Docker App Gateway
• Timeline / Streaming
• React Runtime

尤其是 Alias + 子路径 这个方案。

现代前端其实大量默认运行在：

/

而不是：

/subpath

于是：

/epg
/jellyfin

这种结构会天然开始和现代前端冲突。

我后来慢慢意识到，现代 Homelab 的核心已经不是“网站托管”，而是：

服务编排 + 网络系统

这其实是一个非常大的认知变化。

于是后来我开始逐渐迁移整个架构：

Cloudflare Tunnel
+
Reverse Proxy
+
Docker Compose
+
Tailscale

最终变成现在这套方案。

它可能不是最快的。但在家庭网络环境下，足够稳定。而稳定，其实远比“理论最快”重要。

这篇文章记录什么h2

过去很长一段时间，我在群晖上部署服务时，习惯使用：

WebStation
+
Alias
+
Docker

一开始看起来很方便。

但随着 React / Next.js、WebSocket、AI WebUI、Jellyfin、EPG 系统和 Docker 服务越来越多，问题也越来越明显：

• 页面不存在
• 静态资源 404
• WebSocket 失败
• 页面白屏
• reverse proxy 混乱
• 国内公网访问越来越不稳定

后来我逐渐意识到，WebStation 更像“传统网站托管时代”的产物，而现代 Homelab / Docker / React 服务，其实已经是另一套体系。

于是我开始重新设计整个家庭服务器架构，最终形成了现在这套：

Cloudflare Tunnel
+
群晖 Reverse Proxy
+
Docker Compose
+
Tailscale

这篇文章主要记录：

• 为什么我放弃 WebStation Alias
• 为什么 Cloudflare Tunnel 非常适合家庭宽带
• 群晖 + Docker 的长期最佳实践
• 家庭网络环境下的优化经验

适用场景h2

这套方案适用于：

• 群晖 NAS
• Docker / Container Manager
• 家庭宽带
• 无公网 IP
• 80 / 443 被限制
• 想公网访问家庭服务
• React / Next.js / Jellyfin / EPG / AI WebUI 等现代 Web 应用

推荐整体架构h2

推荐架构是：

公网
  ↓
Cloudflare Tunnel
  ↓
群晖 Reverse Proxy
  ↓
Docker Services

架构图：

┌──────────────────┐
│     Browser      │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│ Cloudflare Edge  │
└────────┬─────────┘
         │ Tunnel
         ▼
┌──────────────────┐
│ Synology NAS     │
│ Reverse Proxy    │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│ Docker Services  │
│ EPG / Jellyfin   │
│ Grafana / AI     │
└──────────────────┘

核心思路很简单：公网入口交给 Cloudflare Tunnel，NAS 内部再用群晖 Reverse Proxy 转发到不同的 Docker 服务。

为什么不推荐 WebStation + Aliash2

WebStation 更适合传统网站，例如：

• WordPress
• PHP
• Apache
• Typecho
• 静态 HTML

它不太适合：

• React SPA
• Next.js
• WebSocket
• Docker Gateway
• 流媒体

Alias 的典型写法是：

/epg
/jellyfin
/ai

但很多现代应用默认运行在：

/

而不是：

/subpath

因此会出现：

• 页面不存在
• 静态资源 404
• WebSocket 失败
• redirect loop
• js/css 丢失

所以更推荐使用子域名。

推荐：

epg.matrixpunk.com
jellyfin.matrixpunk.com
ai.matrixpunk.com

不推荐：

matrixpunk.com/epg
matrixpunk.com/jellyfin

为什么 Cloudflare Tunnel 很适合家庭宽带h2

Tunnel 的本质不是：

公网主动访问你家

而是：

NAS 主动连接 Cloudflare

因此它不需要：

• 公网 IP
• DDNS
• 端口映射
• 开放 80 / 443

真实链路是：

用户
  ↓
Cloudflare Edge
  ↓
Cloudflare Tunnel
  ↓
群晖 Docker

这点对家庭宽带非常关键。很多家庭宽带没有公网 IPv4，80 / 443 入站端口也经常不可用。

为什么访问会慢h2

Cloudflare Tunnel 解决的是“能稳定访问”的问题，不是“绝对高速”的问题。

国际链路h3

Cloudflare Tunnel 很多时候仍然走国际线路，例如：

• 香港
• 日本
• 新加坡
• 欧洲

不同运营商、不同地区、不同时间段，体验会有明显差异。

QUIC / UDP 不稳定h3

cloudflared 默认可能使用 QUIC。QUIC 基于 UDP，而国内家庭宽带里 UDP 经常会遇到：

• UDP QoS
• 丢包
• 晚高峰波动
• 运营商限制

所以在家庭网络里，QUIC 不一定是最稳的选择。

家宽上传较弱h3

Tunnel 更依赖：

NAS → Cloudflare

也就是家庭宽带的上传稳定性。上传带宽小、晚高峰抖动、运营商路由差，都会影响最终访问体验。

推荐强制 HTTP2h2

推荐配置：

--protocol http2

原因很直接：TCP 通常比 QUIC / UDP 更稳。

推荐 Docker Composeh2

docker-compose.yml：

services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    network_mode: host
    command: tunnel run --protocol http2 --edge-ip-version 4
    environment:
      - TUNNEL_TOKEN=你的TunnelToken

配置说明h2

--protocol http2h3

避免 QUIC 在国内网络下的不稳定。

--edge-ip-version 4h3

国内很多宽带的 IPv6 质量反而更差，优先 IPv4 通常更稳。

network_mode: hosth3

群晖上推荐使用 host 网络模式，主要是为了避免：

• bridge 网络问题
• localhost 不通
• DNS 异常

restart: unless-stoppedh3

NAS 重启后自动恢复，不需要手动启动 Tunnel。

如何获取 Tunnel Tokenh2

进入：

https://one.dash.cloudflare.com

路径：

Networks
→ Tunnels
→ Create Tunnel
→ Docker

Cloudflare 会生成一段：

docker run ...

里面：

--token xxx

xxx 就是 Tunnel Token。

推荐目录结构h2

/docker
  /cloudflared
    docker-compose.yml

启动方式h2

docker compose up -d

查看日志：

docker logs -f cloudflared

成功日志里会出现：

Registered tunnel connection

推荐公网结构h2

推荐：

Tunnel
  ↓
群晖 Reverse Proxy
  ↓
Docker Services

例如：

群晖 Reverse Proxy 推荐h2

DSM 路径：

登录门户
→ 反向代理

示例：

Cloudflare Tunnel 只负责把请求送进 NAS，具体服务分发交给群晖 Reverse Proxy。这样每个服务都使用独立子域名，应用本身仍然运行在根路径 /。

哪些服务适合公网h2

推荐公网暴露：

• Blog
• EPG
• AI WebUI
• Grafana
• 轻量后台

不推荐公网暴露：

• DSM
• SSH
• Portainer
• 数据库
• SMB / NFS

这些更推荐使用 Tailscale 访问。

推荐长期架构h2

长期架构可以按职责拆分：

不推荐：

WebStation + Alias + Docker

推荐：

Cloudflare Tunnel
+
Reverse Proxy
+
子域名
+
Docker Compose

这是目前对群晖、HomeLab、家庭网络来说，长期更稳的方案。

适合我的最终实践h2

推荐公网暴露：

epg.matrixpunk.com
blog.matrixpunk.com
ai.matrixpunk.com

推荐仅内网访问：

DSM
SSH
Portainer
数据库

这些通过 Tailscale 访问即可。

最终架构图h2

                ┌─────────────────────┐
                │   Cloudflare DNS    │
                └─────────┬───────────┘
                          │
                          ▼
                ┌─────────────────────┐
                │ Cloudflare Tunnel   │
                └─────────┬───────────┘
                          │
                          ▼
                ┌─────────────────────┐
                │ Synology NAS        │
                │ Reverse Proxy       │
                └─────────┬───────────┘
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ EPG Service  │ │ Jellyfin     │ │ Grafana      │
│ Port 3000    │ │ Port 8096    │ │ Port 3001    │
└──────────────┘ └──────────────┘ └──────────────┘

经验总结h2

Tunnel 的核心价值不是高速，而是稳定暴露家庭服务。

在家庭网络环境里，推荐：

• HTTP2
• IPv4
• 子域名
• Reverse Proxy

尽量避免：

• QUIC
• Alias 子路径
• 复杂多层反代

简单、可恢复、职责清晰，才是家庭服务长期稳定运行的关键。