Cloudflare Tunnel 完全指南：零公网 IP、零端口暴露、免费 HTTPS 内网穿透实战（2026）

52 分钟
25838 字
分类: 进阶教程
标签: Cloudflare Tunnel 内网穿透 Zero Trust Cloudflared 反向代理 Docker

最后更新于：2026年08月

⚠️ 重要声明：本文仅从技术研究角度介绍 Cloudflare Tunnel 的工程实现与合法使用场景。请在遵守当地法律法规和 Cloudflare 服务条款的前提下阅读和应用本文内容。请勿将本技术用于任何非法用途。

Cloudflare Tunnel 完全指南
Cloudflare Tunnel：零公网 IP 的免费内网穿透方案

FRP 需要一台有公网 IP 的 VPS 作为中转，SSH 反向隧道连接不稳定容易断，OpenWRT 的 Cloudflare Tunnel 插件只适合路由器场景——Cloudflare Tunnel（原名 Argo Tunnel，俗称"云flared"） 让内网穿透的门槛降到了零：不需要公网 IP、不需要开放任何端口、自带全球 CDN 加速、自动 HTTPS 证书、完全免费（个人使用额度极其充裕）。

只需要在内网机器上运行一个 cloudflared 守护进程，主动向 Cloudflare 边缘节点建立一条加密的 QUIC/HTTP2 出站隧道，外部流量通过 Cloudflare 全球 300+ 节点转发到你的内网服务。配合 Zero Trust Access 还能给内网服务加一层 SSO 登录墙，配合 WARP 客户端能实现企业级 Split Tunnel 私有网络访问。

本文从架构原理、快速上手、全协议隧道、Zero Trust 安全控制、WARP 私有组网、Docker 部署，到高可用架构与故障排查，12 个章节系统拆解 Cloudflare Tunnel 的生产级用法。

🧭 第一部分：Cloudflare Tunnel 是什么？

1.1 内网穿透方案全景对比

PLAINTEXT
┌────────────────────────────────────────────────────────────────────────┐
│                     内网穿透方案全景对比（2026）                          │
├──────────────┬──────────────────┬──────────────────┬──────────────────┤
│ 方案          │ Cloudflare Tunnel │ FRP              │ SSH 反向隧道     │
├──────────────┼──────────────────┼──────────────────┼──────────────────┤
│ 需要公网 VPS  │ ❌ 不需要         │ ✅ 必需          │ ✅ 必需          │
│ 开放端口      │ ❌ 不需要         │ ✅ frps 端口     │ ✅ SSH 端口      │
│ 免费额度      │ ✅ 个人免费       │ ✅ 完全开源免费  │ ✅ 完全免费      │
│ HTTPS 证书    │ ✅ 自动申请续期   │ ❌ 需自配        │ ❌ 需自配        │
│ CDN 加速      │ ✅ 全球 300+ 节点 │ ❌ VPS 单节点    │ ❌ VPS 单节点    │
│ TCP/UDP 支持  │ ✅ WARP 模式     │ ✅ 原生支持      │ ✅ TCP 原生      │
│ SSO 访问控制  │ ✅ Zero Trust    │ ❌ 基础 Token    │ ❌ 基础密钥      │
│ Web 管理面板  │ ✅ Zero Trust UI │ ✅ Dashboard     │ ❌ 无            │
│ DDoS 防护     │ ✅ Cloudflare 自带│ ❌ 需自配        │ ❌ 需自配        │
│ 速度限制      │ 免费 1GB/连接/日  │ 无限制(看 VPS)   │ 无限制(看 VPS)   │
│ 最佳场景      │ Web 服务 / 远程办公│ 自建高性能中转   │ 简单临时转发    │
└──────────────┴──────────────────┴──────────────────┴──────────────────┘

一句话结论：如果你没有公网 IP、不想折腾 VPS、主要跑 Web 服务——Cloudflare Tunnel 是综合体验最好的选择。如果你需要跑高带宽 TCP/UDP 游戏/流媒体且有 VPS——FRP 更合适。如果你只是临时用一下——SSH 隧道够用。

1.2 Cloudflare Tunnel 核心架构

PLAINTEXT
┌──────────────────────────────────────────────────────────────────────────┐
│              Cloudflare Tunnel 架构原理（零入站连接）                       │
│                                                                          │
│  ┌──────────────────────────┐     Anycast QUIC/HTTP2      ┌────────────┐ │
│  │  你的内网机器            │ ─────── 主动出站连接 ──────→ │ Cloudflare │ │
│  │  (NAS / Home Lab / PC)   │ ←────── 加密隧道 ────────  │  边缘节点   │ │
│  │                          │     （保持长连接）           │  300+ 全球  │ │
│  │  ┌──────────┐            │                               └────┬───────┘ │
│  │  │ web:3000 │←── 转发 ──┼── tunnel (本地 127.0.0.1)         │         │
│  │  ├──────────┤            │                                    │         │
│  │  │ ssh:22   │←── 转发 ──┼── private network (WARP)           │         │
│  │  ├──────────┤            │                                    │         │
│  │  │ rdp:3389 │←── 转发 ──┼── private network                   │         │
│  │  └──────────┘            │                                    │         │
│  └──────────────────────────┘                                    │         │
│                                                                  ▼         │
│  ┌─────────┐   HTTPS(443)    ┌─────────────────┐   DNS 解析   ┌───────┐  │
│  │  用户    │ ──────────────→│ 你的域名 CF 托管 │ ←───────────│ 用户  │  │
│  │ 浏览器   │ ←──────────────│ Cloudflare 回源  │ ───────────→│ 访问  │  │
│  └─────────┘   CDN 响应     └─────────────────┘   CNAME/HTTPS └───────┘  │
│                                                                          │
│  ✅ 关键特性：内网机器只出不进，不需要开放任何端口，不需要公网 IP            │
│  ✅ 所有入站流量先过 Cloudflare WAF/DDoS 防护                               │
└──────────────────────────────────────────────────────────────────────────┘

1.3 功能矩阵：cloudflared 2026.8 全部能力

PLAINTEXT
┌──────────────────────────────────────────────────────────────┐
│  cloudflared 能力矩阵（2026.8 最新版）                         │
├──────────────────────────────────────────────────────────────┤
│  📡 隧道入口类型                                              │
│  ├── Public Hostname 模式：通过 CF 域名向公网暴露             │
│  │   ├── HTTP/HTTPS / WebSocket / gRPC / Server-Sent Events  │
│  │   ├── 自动证书 + HTTP/3 (QUIC) 支持                        │
│  │   └── WAF / Rate Limit / Bot Management 联动              │
│  ├── WARP + Private Network 模式：仅 WARP 客户端可访问        │
│  │   ├── TCP / UDP / ICMP 全协议                              │
│  │   ├── 任意端口（SSH 22 / RDP 3389 / SMB 445 / 数据库）    │
│  │   └── 企业级 Split Tunnel 分流访问                         │
│  └── Local Only 模式：仅本机/局域网访问（替代 ssh -L）        │
│                                                              │
│  🔐 安全能力                                                  │
│  ├── Zero Trust Access (SSO)：Google/OIDC/SAML 登录墙        │
│  ├── Service Token：脚本/服务非交互式访问令牌                │
│  ├── mTLS：客户端证书双向认证                                │
│  ├── IP / Geo / Device Posture 策略限制                     │
│  └── 每 24 小时自动轮换隧道加密密钥                          │
│                                                              │
│  📊 运维能力                                                  │
│  ├── 命名隧道（Named Tunnel）：配置保存在云端，可跨机器迁移   │
│  ├── 配置版本管理 + 一键回滚                                 │
│  ├── 连接数 / 延迟 / 错误率实时 Dashboard                   │
│  ├── 多副本高可用（Replicas）：自动故障转移                  │
│  └── 多种部署方式（二进制 / systemd / Docker / K8s Helm）    │
└──────────────────────────────────────────────────────────────┘

⚡ 第二部分：10 分钟快速上手

2.1 前置条件检查清单

PLAINTEXT
✅  一个 Cloudflare 账号（免费版即可）
✅  一个域名托管在 Cloudflare DNS（用 CF NS 服务器）
✅  内网一台能访问外网的 Linux / macOS / Windows 机器
✅  内网机器能运行 cloudflared（CPU 架构任意：x86 / ARM / ARM64）
✅  防火墙放行出站 UDP 7844（QUIC） 和 TCP 7844（回退）

💡 免费版够用吗？ 完全够用。免费版 Cloudflare Zero Trust 额度：50 用户、100 条命名隧道、无限公网 Hostname、每连接每日 1GB 流量、WARP 私有网络不限流量。绝大多数个人和小团队完全够用。

2.2 五步搞定：一键安装+登录+创建隧道

BASH
# ─────────────────────────────────────────────
#  Step 1: 安装 cloudflared（三选一）
# ─────────────────────────────────────────────

# 方式 A：一键脚本（推荐，自动识别架构）
curl -L --output cloudflared.deb \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb

# 方式 B：macOS Homebrew
brew install cloudflare/cloudflare/cloudflared

# 方式 C：Docker（后面详细讲）
# docker pull cloudflare/cloudflared:latest

# 验证安装
cloudflared --version
# 预期输出：cloudflared version 2026.8.0

# ─────────────────────────────────────────────
#  Step 2: 登录 Cloudflare 账号（获取证书）
# ─────────────────────────────────────────────
cloudflared tunnel login

# ✅ 终端会输出一个 URL，复制到浏览器打开
# ✅ 在 Cloudflare 页面选择你的域名，点击"授权"
# ✅ 授权成功后，证书会自动保存到：
#    Linux:   ~/.cloudflared/cert.pem
#    macOS:   ~/.cloudflared/cert.pem
#    Windows: %USERPROFILE%\.cloudflared\cert.pem
BASH
# ─────────────────────────────────────────────
#  Step 3: 创建一条"命名隧道"
# ─────────────────────────────────────────────
# 命名隧道的好处：配置存在云端，不怕本地丢数据，能在多台机器切换
cloudflared tunnel create my-first-tunnel

# ✅ 成功输出示例：
# Tunnel credentials written to /home/you/.cloudflared/<隧道UUID>.json.
# cloudflared chose this tunnel ID for you:  xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
# Keep this ID secret! It's your tunnel's unique credential.

# 查看已创建的隧道
cloudflared tunnel list
# 你会看到：ID / NAME / CREATED / CONNECTIONS

# ─────────────────────────────────────────────
#  Step 4: 绑定一个公网域名 + 配置转发
# ─────────────────────────────────────────────
# 假设你想把 https://app.example.com 转发到内网的 http://localhost:3000
# 先写一个 config.yml

mkdir -p ~/.cloudflared
cat > ~/.cloudflared/config.yml << 'EOF'
tunnel: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  # ← 替换成你的隧道 ID
credentials-file: /home/you/.cloudflared/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json

ingress:
  # 第一条规则：app.example.com → 内网 3000 端口
  - hostname: app.example.com
    service: http://localhost:3000
    originRequest:
      noTLSVerify: true        # 如果源站是自签 HTTPS，跳过校验
      connectTimeout: 30s
      tcpKeepAlive: 30s

  # 第二条规则：兜底（必须有）
  - service: http_status:404
EOF

# ─────────────────────────────────────────────
#  Step 5: 一键配置 DNS + 启动隧道
# ─────────────────────────────────────────────
# 自动在 Cloudflare DNS 创建 CNAME 记录
# app.example.com → <隧道UUID>.cfargotunnel.com
cloudflared tunnel route dns my-first-tunnel app.example.com

# 前台启动测试（看日志）
cloudflared tunnel run my-first-tunnel

# 🎉 完成！
# 现在浏览器打开 https://app.example.com 就能访问内网 3000 端口了
# 全程没有开放任何端口，没有配置 VPS，证书也已经自动生效

2.3 生产部署：注册为 systemd 服务

测试没问题后，把 cloudflared 注册为开机自启的系统服务：

BASH
# cloudflared 自带一键安装服务的命令
sudo cloudflared service install

# ✅ 自动完成以下动作：
# 1. 创建 /etc/systemd/system/cloudflared.service
# 2. 创建 /etc/cloudflared/ 目录
# 3. 把配置和证书复制到 /etc/cloudflared/
# 4. enable + start 服务

# 检查服务状态
sudo systemctl status cloudflared
sudo journalctl -u cloudflared -f --no-pager   # 实时看日志

# 查看当前隧道连接情况（有几个边缘节点连接）
cloudflared tunnel info my-first-tunnel

🌐 第三部分：Ingress 规则深度配置

3.1 Ingress 规则匹配顺序与完整语法

cloudflared 的 ingress 是整个隧道流量分发的核心引擎，从上到下顺序匹配，第一个命中的规则生效，最后必须有兜底规则。

YAML
# ~/.cloudflared/config.yml —— 完整 Ingress 示例
tunnel: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
credentials-file: /etc/cloudflared/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json

# ── 全局默认值（每条规则可单独覆盖） ──
originRequest:
  connectTimeout: 30s          # 源站 TCP 握手超时
  tcpKeepAlive: 30s            # TCP Keep-Alive 间隔
  noHappyEyeballs: false       # 禁用 IPv6/IPv4 竞速（源站无 IPv6 时开）
  keepAliveConnections: 100    # 到源站的连接池大小
  keepAliveTimeout: 90s        # 空闲连接保留时间
  httpHostHeader: ""           # 改写发给源站的 Host 头
  originServerName: ""         # 发给源站的 TLS SNI
  caPool: ""                   # 源站自签 CA 证书路径
  noTLSVerify: false           # 跳过源站 TLS 校验（不推荐生产用）
  disableChunkedEncoding: false# 禁用分块编码（某些老旧 Web 服务需要）
  bastionMode: false           # 堡垒机模式（WARP 私有网络用）

# ── Ingress 分发引擎（从上到下匹配，命中即停） ──
ingress:
  # ① 精准域名匹配 + 路径前缀匹配
  - hostname: blog.example.com
    path: ^/wp-(admin|login).*$   # 正则匹配：只转发后台
    service: http://192.168.1.50:8080

  # ② 通配符子域名（需要 *.example.com 的证书，CF 自动处理）
  - hostname: "*.dev.example.com"
    service: http://localhost:8000
    originRequest:
      httpHostHeader: "{<1>}.dev.local"   # {<1>} 替换为通配符捕获组
      # 例：alice.dev.example.com → Host: alice.dev.local

  # ③ 带 gRPC / WebSocket 协议的服务
  - hostname: api.example.com
    service: https://10.0.0.10:8443
    originRequest:
      noTLSVerify: true
      # WebSocket / gRPC / SSE 不需要额外配置，默认全部支持
      # CF 边缘会自动处理 Upgrade 头和帧转发

  # ④ 静态文件 / 直接返回 HTTP 状态码（不用源站）
  - hostname: status.example.com
    service: http_status:200              # 返回空 200

  - hostname: maintenance.example.com
    service: http_status:503              # 返回 503 维护页
    # 配合 CF 页面规则显示自定义维护界面

  # ⑤ 跳转到其他 URL（3xx 重定向）
  - hostname: old-blog.example.com
    service: https://new-blog.example.com
    # 自动生成 301 永久重定向，保留路径和 Query

  # ⑥ 兜底规则（必须！否则 cloudflared 启动报错）
  # 命中不了上面所有规则的请求，走这里
  - service: http_status:404

3.2 多服务实战：一台机器暴露 5 个内网应用

YAML
# 实战：一台 NAS 上跑了 Nextcloud + Jellyfin + Home Assistant + Vaultwarden + AdGuard
tunnel: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
credentials-file: /etc/cloudflared/creds.json

ingress:
  # Nextcloud - 注意需要配置 trusted_proxies
  - hostname: cloud.example.com
    service: http://127.0.0.1:8080
    originRequest:
      httpHostHeader: cloud.example.com

  # Jellyfin - WebSocket 用于播放进度同步
  - hostname: media.example.com
    service: http://127.0.0.1:8096

  # Home Assistant - 长连接 + SSE
  - hostname: home.example.com
    service: http://127.0.0.1:8123
    originRequest:
      # HA 必须配置 use_x_forwarded_for 和 trusted_proxies
      httpHostHeader: home.example.com

  # Vaultwarden (Bitwarden) - HTTPS + WebSocket
  - hostname: pass.example.com
    service: http://127.0.0.1:8222

  # AdGuard Home 管理面板
  - hostname: dns.example.com
    service: http://127.0.0.1:3000

  - service: http_status:404

⚠️ 重要提示：反向代理给应用后，应用层面一定要把 Cloudflare Tunnel 识别为可信代理（trusted proxy），否则应用会拿到 127.0.0.1 作为客户端 IP，导致限速、日志、风控全部失效。Cloudflare 的 CDN IP 段列表在 ips.cloudflare.com 可下载。

🔌 第四部分：SSH / RDP / SMB / 数据库 —— 非 HTTP 协议全方案

4.1 方案选择：Public Hostname vs WARP Private Network

PLAINTEXT
┌──────────────────────────────────────────────────────────────────┐
│       非 HTTP 协议的两种暴露方式对比                                │
├────────────────────────────────┬─────────────────────────────────┤
│ 方式 A：通过 cloudflared 客户端  │ 方式 B：通过 WARP App 私有网络   │
│ （cloudflared access ssh）     │  （1.1.1.1 App 开启 Zero Trust）│
├────────────────────────────────┼─────────────────────────────────┤
│ ✅ 不需要安装 WARP              │ ✅ 系统级路由，所有 App 透明     │
│ ✅ 浏览器也能访问 SSH / RDP     │ ✅ 支持 UDP / ICMP / 任意端口    │
│ ✅ 自带 SSO 登录 + 短令牌       │ ✅ Split Tunnel 分流更灵活       │
│ ❌ 仅限 TCP，每个端口要单独配置  │ ❌ 需要安装 WARP 客户端          │
│ ❌ 每次连接要重新 token         │ ❌ 需要登录 Zero Trust 账号      │
├────────────────────────────────┴─────────────────────────────────┤
│  🌰 适用场景对比：                                                 │
│  · 偶尔远程连家里 SSH → 方式 A（轻）                              │
│  · 手机 RDP 连办公电脑 → 方式 A（浏览器也能用）                    │
│  · 开发机全天连公司内网 SMB/数据库 → 方式 B（系统级透明）          │
│  · 访问内网摄像头 RTSP (UDP) → 方式 B（UDP 只支持 WARP）          │
└──────────────────────────────────────────────────────────────────┘

4.2 方式 A：cloudflared access —— 浏览器里就能 SSH / RDP

第一步：配置 Ingress，增加一个 SSH 入口

YAML
# 在 config.yml 的 ingress 里加一条
ingress:
  # ... 其他 hostname ...

  # 新建一个子域名专门做 SSH 接入
  - hostname: ssh.example.com
    service: ssh://127.0.0.1:22      # 协议前缀 ssh:// 或 tcp://
    originRequest:
      bastionMode: true               # 🔑 开启堡垒机模式

  - service: http_status:404

重启 cloudflared 生效：sudo systemctl restart cloudflared

第二步：用 cloudflared 客户端连接（两种方式）

BASH
# ── 方式 A1：一条命令直接 SSH（推荐脚本化） ──
# 用户端也需要安装 cloudflared（Windows 也行）
# 不需要登录，不需要证书
ssh user@ssh.example.com \
  -o "ProxyCommand=cloudflared access ssh --hostname %h"

# 第一次会弹出浏览器 Zero Trust SSO 登录
# 登录成功后自动建立隧道，不需要输入密码
BASH
# ── 方式 A2：用 Service Token（脚本 / Cron / CI 用） ──
# 在 Zero Trust Dashboard → Access → Service Tokens 创建
# 得到 Client ID 和 Client Secret

export CF_ACCESS_CLIENT_ID="xxxxx-xxxxx-xxxxx"
export CF_ACCESS_CLIENT_SECRET="yyyyyyyyyyyyyyyyyyyy"

# 直接连，不需要浏览器交互，适合脚本
ssh deploy@ssh.example.com \
  -o "ProxyCommand=cloudflared access ssh \
      --hostname %h \
      --id $CF_ACCESS_CLIENT_ID \
      --secret $CF_ACCESS_CLIENT_SECRET"

💡 不需要在服务器暴露 22 端口！ SSH 流量全部走 Cloudflare Tunnel 加密通道入站，即使 sshd 只监听 127.0.0.1 也没问题。配合 Zero Trust 访问策略，可以要求「Google SSO + 公司邮箱域 + 受管设备」才允许连 SSH，比 VPN + 密钥安全几个量级。

RDP、VNC、MySQL、Redis 同理：

YAML
# config.yml ingress 继续加：
  - hostname: rdp.example.com
    service: tcp://192.168.1.100:3389    # RDP

  - hostname: db-admin.example.com
    service: tcp://10.0.0.20:3306        # MySQL

然后用 cloudflared 的本地端口转发模式在客户端接：

BASH
# 客户端：把远端 tcp://db-admin.example.com 映射到本地 3307
cloudflared access tcp \
  --hostname db-admin.example.com \
  --url 127.0.0.1:3307

# 现在本机连 127.0.0.1:3307 就等于连内网 MySQL 的 3306
mysql -h 127.0.0.1 -P 3307 -u root -p

4.3 方式 B：WARP + Private Network —— 系统级透明访问（企业级）

💡 这是 Cloudflare Tunnel 最强大也最容易被忽视的功能。WARP 私有网络可以把整个内网 CIDR（比如 192.168.1.0/24、10.0.0.0/8）路由到 WARP 客户端。用户的手机/笔记本开着 WARP 就能直接访问内网的任意 IP 任意端口，就像连了企业 VPN，但不需要配置 VPN 服务器。

Step 1：在 Zero Trust Dashboard 开 Private Network

PLAINTEXT
Cloudflare Zero Trust Dashboard → Networks → Tunnels
  选中你的隧道 → 点击 "Configure" → "Private Network" 选项卡
    → Add a private network
      CIDR: 192.168.1.0/24        ← 你家内网网段
      Additional comment: Home LAN
    → Save

Step 2：在 WARP 客户端开启 Zero Trust

PLAINTEXT
手机 / 笔记本安装 WARP (1.1.1.1) App
  → Settings → Account → Login with Cloudflare Zero Trust
  → 输入你的 Zero Trust 团队域名（形如 your-team.cloudflareaccess.com）
  → SSO 登录
  → 打开 WARP 开关（Connected 状态）

Step 3：验证

BASH
# 开着 WARP 的终端里直接 ping 内网 IP
ping 192.168.1.50     # 你家 NAS 的内网 IP —— 通了！
ssh user@192.168.1.50  # 直接 SSH —— 通了！
\\192.168.1.50\Share  # Windows 直接访问 SMB —— 通了！

Step 4：配置 Split Tunnel 分流（必做，否则所有流量走 WARP 会慢）

PLAINTEXT
Zero Trust Dashboard → Settings → WARP Client → Device settings
  → 选中 Default profile → Configure → Split Tunnels
    → Mode: Exclude IPs and domains（默认就是这个）
    → Manage —— 确认没有排除你内网的 CIDR
    → 如果默认排除了"所有私网 IP"，把 192.168.0.0/16 从排除列表删掉
    → 改完 WARP 客户端要断开重连才能生效

✅ 实际体验：手机 5G 在外边，开 WARP 就能直接看家里 NAS 上的 Jellyfin、查 AdGuard 面板、SSH 改路由器配置，完全不需要端口映射和动态域名。

🛡️ 第五部分：Zero Trust Access —— 给内网服务加 SSO 登录墙

5.1 为什么需要它？

PLAINTEXT
┌───────────────────────────────────────────────────────────────┐
│  痛点场景：                                                     │
│  · 公网直接暴露 Home Assistant → 黑客扫到就能暴力破解密码       │
│  · 想给公司同事共享内部 Jira → 每个人要单独开账号密码           │
│  · 给外包临时访问 Grafana → 要手动建号、回收                   │
│                                                               │
│  Zero Trust Access 的解法：                                    │
│  在 Cloudflare 边缘和你的应用之间，加一层统一的身份校验层       │
│  浏览器访问你的域名 → 先跳 Cloudflare SSO 登录 → 登录成功     │
│  → 带 JWT 凭证继续访问源站 → 源站可选校验或不校验              │
└───────────────────────────────────────────────────────────────┘

5.2 创建一条 Access Application：5 分钟完成

以给 admin.example.com 加 Google 登录为例：

PLAINTEXT
Step 1: 配置身份源 (IdP)
  Zero Trust Dashboard → Settings → Authentication
  → Login methods → Add new → Google
  → Client ID / Client Secret 填 Google Cloud Console 创建的凭据
  → 允许的域: your-company.com（只允许公司邮箱登录）
  → Save

Step 2: 创建 Application（访问策略应用）
  Zero Trust → Access → Applications → Add an application
  → Self-hosted
    Name: Admin Dashboard
    Application domain: admin.example.com
    Session duration: 1 day
    Instant auth checks（自动刷新令牌）: 开

Step 3: 配置 Policies（谁能访问）
  Policy name: Allow employees
  Action: Allow
  Include: Login method - Google
           Emails ending in - @your-company.com
  Require（可选）: Country - CN
                  Device posture - Managed device
                  Gateway WARP - On

Step 4: 保存完成
  浏览器访问 https://admin.example.com
  → 自动跳转到 Cloudflare 登录页 → 选 Google → 选公司邮箱
  → 登录成功 → 看到应用
  ✅ 完成，不需要改应用里的一行代码

5.3 高级：Service Auth（给 API / 脚本访问）

浏览器能 SSO，但 CI/CD、脚本、Prometheus Remote Write 这种非浏览器访问需要 Service Token：

PLAINTEXT
Zero Trust → Access → Service Tokens → Create
  Token name: Prometheus Scraper
  Duration: 1 year
  → 生成后保存：
     CLIENT ID:   1234567890abcdef.access
     CLIENT SECRET: aaaabbbbccccdddd1111222233334444

然后给这个 token 加一条 Policy：
  Policy name: Allow Prometheus
  Action: Allow
  Include: Service Token - Prometheus Scraper

脚本访问：
  curl -H "CF-Access-Client-Id: 1234567890abcdef.access" \
       -H "CF-Access-Client-Secret: aaaabbbbccccdddd1111222233334444" \
       https://admin.example.com/api/metrics

🐳 第六部分：Docker / Docker Compose 部署

6.1 单容器最简部署

BASH
# 一次性：先在有浏览器的机器跑一次 login 拿到 cert.pem
# 或者在服务器上手动生成（复制 URL 到浏览器点授权）
docker run -v ~/.cloudflared:/home/nonroot/.cloudflared \
  cloudflare/cloudflared:latest tunnel login

# 启动 tunnel（挂载证书和配置）
docker run -d \
  --name cloudflared \
  --restart unless-stopped \
  -v ~/.cloudflared:/home/nonroot/.cloudflared:ro \
  -e TZ=Asia/Shanghai \
  --network host \
  cloudflare/cloudflared:latest \
  tunnel --config /home/nonroot/.cloudflared/config.yml run

💡 --network host 是最简单的：cloudflared 容器和宿主机共享网络栈，直接 localhost:3000 就能转发到宿主机的 3000 端口。如果你不想用 host 网络，可以用 docker bridge，这时候要把 service: http://localhost:3000 改成宿主机 IP，或者用容器名 + container_name 互相 link。

6.2 Docker Compose：自托管全家桶 + CF Tunnel 一键拉起

YAML
# ~/homelab/docker-compose.yml
# 一个文件拉起 cloudflared + Nextcloud + Vaultwarden + Jellyfin
# 所有服务只监听 127.0.0.1，不需要公网暴露，靠 cloudflared 入站

services:
  cloudflared:
    image: cloudflare/cloudflared:2026.8.0
    container_name: cloudflared
    restart: unless-stopped
    user: "root"    # 方便挂载 /etc/cloudflared
    volumes:
      - ./cloudflared:/etc/cloudflared:ro
    command: tunnel --config /etc/cloudflared/config.yml run
    environment:
      - TZ=Asia/Shanghai
    depends_on:
      - nextcloud
      - vaultwarden
      - jellyfin
    network_mode: host   # 直接用宿主机网络，转发 localhost:xxx 最简

  nextcloud:
    image: nextcloud:29-fpm-alpine
    container_name: nextcloud
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:80"   # 只监听本机，不对外网开放
    volumes:
      - ./nextcloud:/var/www/html
    environment:
      - PHP_MEMORY_LIMIT=2G
      - PHP_UPLOAD_LIMIT=20G
      - TRUSTED_PROXIES=173.245.48.0/20 103.21.244.0/22  # CF IP 段（示例）

  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    ports:
      - "127.0.0.1:8222:80"   # 只监听本机
    volumes:
      - ./vaultwarden:/data
    environment:
      - DOMAIN=https://pass.example.com
      - WEBSOCKET_ENABLED=true
      - SIGNUPS_ALLOWED=false   # 禁止公开注册

  jellyfin:
    image: lscr.io/linuxserver/jellyfin:latest
    container_name: jellyfin
    restart: unless-stopped
    ports:
      - "127.0.0.1:8096:8096"  # 只监听本机
    volumes:
      - ./jellyfin/config:/config
      - /mnt/media:/data/media
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai

对应的 cloudflared config.yml：

YAML
# ./cloudflared/config.yml
tunnel: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
credentials-file: /etc/cloudflared/creds.json

ingress:
  - hostname: cloud.example.com
    service: http://127.0.0.1:8080

  - hostname: pass.example.com
    service: http://127.0.0.1:8222

  - hostname: media.example.com
    service: http://127.0.0.1:8096

  - service: http_status:404

6.3 只暴露给 Docker 内部：不用 host 网络的安全写法

YAML
services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    volumes:
      - ./cloudflared:/etc/cloudflared:ro
    command: tunnel --config /etc/cloudflared/config.yml run
    networks:
      - internal-net          # 只和业务容器连同一个内网
    # 🔒 不映射任何端口，cloudflared 只做出站连接

  whoami:
    image: traefik/whoami
    container_name: whoami
    networks: [internal-net]  # 和 cloudflared 同网
    # 🔒 不映射任何端口

networks:
  internal-net:
    internal: true            # 🔒 纯内网，容器不能上外网（可选）
YAML
# config.yml —— 用容器名做 service：
ingress:
  - hostname: whoami.example.com
    service: http://whoami:80   # Docker DNS 自动解析容器名

  - service: http_status:404

🏗️ 第七部分：命名隧道 + 多副本高可用架构

7.1 为什么推荐命名隧道（Named Tunnel）

PLAINTEXT
旧模式（Legacy Tunnel）：
  cloudflared tunnel --hostname app.example.com --url localhost:3000
  × 每次启动 CF 随机给你分配一个隧道 ID
  × 证书 + 配置都在本地，换机器要重新来
  × 一台机器挂了，DNS 记录还指老隧道 → 服务断
  × 不能多副本，不能高可用

命名隧道（Named Tunnel，2023 后默认）：
  ✅ 隧道 ID 永久不变，保存在 Cloudflare 云端
  ✅ 配置保存在云端（或本地 config.yml）
  ✅ CNAME 固定指向 <id>.cfargotunnel.com
  ✅ 同一隧道可以跑 N 个 cloudflared 进程当副本
  ✅ 一个副本掉线，CF 自动把流量切到健康的副本

7.2 多副本 Replicas：生产零停机

PLAINTEXT
          ┌──────────────────────────┐
          │  Cloudflare 边缘节点      │
          │  (收到 *.example.com)     │
          └────────────┬─────────────┘
                       │  Anycast 负载均衡
            ┌──────────┴──────────┐
            ▼                     ▼
   ┌─────────────────┐   ┌─────────────────┐
   │  cloudflared A   │   │  cloudflared B   │
   │  家里 NAS        │   │  办公室小主机     │
   │  (副本 1 / 4)    │   │  (副本 5-8 / 4?) │
   └────────┬────────┘   └────────┬────────┘
            │                     │
       转发到各自的内网         转发到各自的内网
       web: 3000              web: 3000  (同步相同内容)
BASH
# 隧道配置完全一样的两台机器，分别复制
# creds.json + config.yml 到 A 和 B
# 两边各自执行：
cloudflared tunnel run my-first-tunnel

# 在 Cloudflare Dashboard → Networks → Tunnels
# 点进这条隧道 → Health 选项卡
# 看到 Connections: 2 个数据中心 × 每个 cloudflared 自动 4 连接
# 总共有 8 条活跃隧道连接 = 完全足够

# 手动验证高可用：
#  1. 打开 Dashboard 看连接数
#  2. 在 A 机器 systemctl stop cloudflared
#  3. 刷网页，服务依旧在线（有短暂的 <5秒 TCP 重连）
#  4. Dashboard 里看到 A 的连接消失，剩下 B 的 4 条
#  5. A 启动回来 → 连接数自动恢复到 8

7.3 跨地域双活容灾架构（进阶）

YAML
# config.yml 两个地域各一条隧道，用 Cloudflare Load Balancer 做主备
# 两条隧道分别绑定不同 hostname
#  北京机房: bj-app.example.com → tunnel-bj
#  上海机房: sh-app.example.com → tunnel-sh

# 然后 Zero Trust → Traffic → Load Balancers
# 创建一个 app.example.com 的 LB
#   Origin Pool 1 (北京): bj-app.example.com weight=50
#   Origin Pool 2 (上海): sh-app.example.com weight=50
#   Health Check: HTTPS / /healthz
#   Session Affinity: By cookie (应用需要登录会话时开)
#   Failover: 一个池全部不健康时切到另一个

📈 第八部分：性能优化与可观测性

8.1 连接速度优化 Checklist

PLAINTEXT
┌────────────────────────────────────────────────────────────────┐
│  Cloudflare Tunnel 性能影响因素（重要程度从高到低）               │
├────────────────────────────────────────────────────────────────┤
│  ① 内网机器到 CF 边缘节点的 RTT（决定性）                        │
│     → 选离你物理近的 VPS 做出口                                 │
│     → 家庭宽带选 CN2 / 联通 AS9929 / 移动 CMIN2 线路          │
│     → UDP 7844 (QUIC) 一定要放行，性能比 TCP 回退高 2-3 倍      │
│                                                                 │
│  ② 协议选择                                                    │
│     → HTTP 类：打开 HTTP/3 (QUIC) 访问                         │
│     → 大文件：建议开 Range 请求、启用 CF Cache Everything       │
│     → 小文件静态站：用 CF Cache Rule 把 HTML 也缓存             │
│                                                                 │
│  ③ 源站参数调优                                                │
│     → keepAliveConnections: 100+（高并发场景）                 │
│     → noHappyEyeballs: true（源站没 IPv6 时必开）              │
│     → connectTimeout: 合理值（内网建议 10s 够了）               │
│                                                                 │
│  ④ 高并发：多副本                                              │
│     → 单 cloudflared 进程建议上限 ≈ 500 并发连接              │
│     → 超了就多开几个副本（Replicas，cloudflared 自动负载均衡）  │
│                                                                 │
│  ⑤ 免费额度注意                                                │
│     → Public Hostname 模式：每人/连接 1GB/天                   │
│     → WARP 私有网络：不限流量，但带宽受 WARP 客户端限制         │
└────────────────────────────────────────────────────────────────┘

8.2 可观测性三件套：Dashboard + Logs + Metrics

BASH
# ── 1. 隧道健康概览 ──
# 终端看隧道状态和连接情况
cloudflared tunnel info my-first-tunnel
# 输出：
#   Name: my-first-tunnel
#   ID:   xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
#   Created: 1 month ago
#   Connections at 2026-08-02:
#     1x LAX (Los Angeles, 美国)     19d 2h 健康
#     1x SJC (San Jose, 美国)       19d 2h 健康
#     2x SIN (Singapore, 新加坡)    19d 2h 健康   ← 离中国近的优先
#     1x NRT (Tokyo, 日本)          19d 2h 健康
#     1x HKG (Hong Kong, 中国香港)  19d 2h 健康

# ── 2. 日志排查（systemd 场景） ──
# 实时看最近 100 行
journalctl -u cloudflared -n 100 -f --no-pager

# 只看错误和警告
journalctl -u cloudflared --priority warning --since "1 hour ago"

# 常见错误码速查：
#   error="connection closed"        → 隧道重启或网络波动，正常
#   error="no ingress rule matches" → Ingress 漏配置，加兜底规则
#   error="unable to reach origin"  → 源站服务没起或端口写错

# ── 3. Prometheus Metrics（开启 /metrics 端点） ──
# 在 config.yml 顶部加：
metrics: 127.0.0.1:20001     # 本机 20001 端口暴露 Prometheus 指标

# 然后 Prometheus 抓取
curl -s 127.0.0.1:20001/metrics | head -20
# 关键指标：
#   cloudflared_tunnel_active_streams       当前活跃请求数
#   cloudflared_tunnel_requests_total       总请求数（按状态码 label）
#   cloudflared_tunnel_response_seconds     响应延迟分布
#   cloudflared_tunnel_server_locations     每个边缘节点 RTT（排障神器）

8.3 日志推送到 Loki / ELK（进阶）

YAML
# config.yml 加：
loglevel: info    # debug / info / warn / error
transport-loglevel: info

# 用 vector / fluent-bit 把 journald 日志推出去
# vector.toml 示例片段：
# [sources.cloudflared]
# type = "journald"
# units = ["cloudflared"]
# include_kubernetes_pod_annotations = false
#
# [sinks.loki]
# type = "loki"
# inputs = ["cloudflared"]
# endpoint = "https://loki.internal.example.com"
# labels = { app = "cloudflared" }

🔒 第九部分：安全加固与合规

9.1 安全设计原则

PLAINTEXT
┌─────────────────────────────────────────────────────────────┐
│  Cloudflare Tunnel 的安全设计（零信任默认）                    │
├─────────────────────────────────────────────────────────────┤
│  🔒 默认零开放端口                                           │
│     · 不需要在防火墙开任何 inbound 规则                      │
│     · 只需要 outbound UDP 7844 + TCP 7844 (fallback)        │
│                                                              │
│  🔒 隧道加密 & 密钥轮换                                      │
│     · 每连接用 QUIC TLS 1.3 + 独立会话密钥                  │
│     · 命名隧道凭据每日轮换                                   │
│     · 边缘节点源站回源也用自己的公网 TLS 证书                │
│                                                              │
│  🔒 应用层防御（CF 边缘原生）                                │
│     · WAF (SQLi / XSS / RCE 规则集)                         │
│     · DDoS / L7 CC / Bot Management                         │
│     · Rate Limit（按 IP / Cookie / 头字段）                 │
│                                                              │
│  🔒 访问控制（Zero Trust Access）                           │
│     · SSO / SAML / OIDC / mTLS                              │
│     · IP 地理位置 / 设备状态 / 网关策略                     │
└─────────────────────────────────────────────────────────────┘

9.2 生产安全 Checklist

PLAINTEXT
✅  1. 用命名隧道，不用旧 Legacy 模式
        (config.yml 有 tunnel: UUID 字段即可)

✅  2. cert.pem 和 <UUID>.json 文件权限 0400
        sudo chmod 0400 /etc/cloudflared/*.json
        sudo chown root:root /etc/cloudflared/*.json

✅  3. cloudflared 以非 root 用户运行（Docker 默认就是 nonroot）
        systemd 场景建议 User=cloudflared

✅  4. 所有 Web 应用加 Zero Trust Application
        · 后台管理面板必须加 SSO（Home Assistant / NPM / Portainer）
        · 纯 API 用 Service Token
        · 内部文档用"公司邮箱域 + 受管设备"策略

✅  5. 源站只监听 127.0.0.1 或 docker internal 网络
        · 不要在 0.0.0.0 上监听，除了 CF 入站你根本不需要
        · 应用配置 trusted_proxies 只允许 Cloudflare IP

✅  6. 开启 mTLS（针对高价值服务，如管理后台）
        Zero Trust → Access → Mutual TLS
        → 生成 CA，下发客户端证书给可信设备
        → 没证书的浏览器直接 403，连 SSO 页都不展示

✅  7. WAF 规则针对你的应用场景开
        · Wordpress：开规则集 WordPress - WAF
        · 通用：开 OWASP Top 10 + Core Ruleset
        · 国家/地区：只允许你真实用户的国家访问

✅  8. 定期审计
        · Zero Trust → Audit Log：谁、何时、用什么方式访问了
        · 每月轮换一次 Service Token
        · 查看 Inactive tunnels，把没用的删掉

9.3 与其他方案的安全性对比

PLAINTEXT
┌──────────────────┬─────────────────┬──────────────┬──────────────┐
│ 安全特性          │ Cloudflare Tunn │ FRP v0.61    │ SSH Tunnel   │
├──────────────────┼─────────────────┼──────────────┼──────────────┤
│ 无需入站端口      │ ✅               │ ✅ (仅 frps)  │ ✅ (仅 VPS)  │
│ 原生 WAF / DDoS   │ ✅ CF 全球防护   │ ❌ 自配       │ ❌ 自配      │
│ SSO 接入          │ ✅ 零代码集成     │ ❌ 自建       │ ❌ 自建      │
│ 凭据自动轮换      │ ✅ 每日自动       │ ❌ 手动       │ ❌ 手动      │
│ 默认 TLS 加密     │ ✅ QUIC TLS1.3   │ ⚠️ 手动开启  │ ✅ SSH2     │
│ mTLS 双向认证     │ ✅ 托管 CA       │ ⚠️ 用插件    │ ⚠️ 可配置   │
│ 审计日志 SaaS 版  │ ✅ Zero Trust 中 │ ❌ 自己存    │ ❌ 自己存  │
└──────────────────┴─────────────────┴──────────────┴──────────────┘

🧯 第十部分：常见问题与故障排查

10.1 启动阶段报错

错误信息根因解决方案
couldn't read tunnel credentials from...creds.json 路径错或权限检查 config.yml 里的 credentials-file 绝对路径；文件权限 0400
tunnel with name xxx not found隧道名拼错了执行 cloudflared tunnel list 看真名叫什么
no ingress rule matches hostname xxx域名没在 ingress 规则里加一条匹配的 hostname，或在 ingress 最后加 service: http_status:404 兜底
no matching login certificate foundcert.pem 过期或域名不对重跑 cloudflared tunnel login，选正确域名重新授权
unable to connect to edge: dial udp :7844: i/o timeout防火墙拦了出站 UDP 7844放行出站 UDP 7844；实在不行 cloudflared 会自动降级 TCP 7844

10.2 运行中访问异常

症状 A：打开域名显示 error 1033 / 502 Bad Gateway

PLAINTEXT
# 依次排查：
# 1. 看 cloudflared 是否在跑
systemctl status cloudflared

# 2. 看 Ingress 规则和 hostname 是否匹配
grep "hostname:" ~/.cloudflared/config.yml

# 3. 看源站是否活着
curl -I http://localhost:3000        # 在 cloudflared 同机执行
                                      # 如果返回 connection refused 是源站问题

# 4. 看源站是不是自己 HTTPS + 自签证书
#    → ingress 对应 service 的 originRequest 加 noTLSVerify: true
#    → 或提供 caPool 指向自签 CA（推荐）

# 5. 看 CF DNS 记录是否正确
dig app.example.com CNAME +short
# 应该是 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.cfargotunnel.com
# 如果不是，重跑：
cloudflared tunnel route dns my-tunnel app.example.com

症状 B：速度慢 / 加载图片卡

PLAINTEXT
# 1. 检查隧道连接在哪
cloudflared tunnel info my-tunnel | grep Connections
# 理想情况：HKG / NRT / SIN 有连接
# 如果全是 LAX / SJC（美西），你的出口路由绕路了

# 2. 检查是不是用了 TCP 回退
journalctl -u cloudflared --since 1d | grep -i "fallback\|quic"
# 如果有 fallback=true，是 UDP 7844 不通，尽快放行

# 3. 大文件/静态资源用 CF Cache
#    Cache Rules → Cache Everything → Edge TTL 1 day
#    源站只用回源一次，后续全走 CF 边缘 300+ 节点

# 4. WARP 访问内网慢
#    → WARP → Settings → Advanced → Connection Options
#    → 选 "Gateway with WARP"（不要纯 WARP 模式）
#    → 看路由到哪个数据中心：https://help.teams.cloudflare.com

症状 C：Non-HTTP (SSH/RDP) 连不上

PLAINTEXT
# Public Hostname ssh:// 模式：
# 1. 服务端 Ingress 是不是写了 ssh:// 前缀
# 2. bastionMode: true 有没有开
# 3. 客户端 ProxyCommand 有没有写对
#    ssh -vvv user@host 看详细日志
# 4. 如果用了 Zero Trust Policy，看 Audit Log 是不是被 Policy 拒了

# WARP Private Network 模式：
# 1. Dashboard → Tunnels → 你的隧道 → Private Network 里加了 CIDR 没
# 2. WARP App 里 Settings → Network → Firewall → Allow private IP ranges
# 3. Split Tunnel 有没有排除了你的私网 CIDR
# 4. 客户端 `traceroute 192.168.1.50` 看是不是走 WARP 虚拟接口

10.3 额度与费用相关

PLAINTEXT
Q: Cloudflare Tunnel 真的免费吗？永久吗？
A: Zero Trust 免费版（Starter）至今是 50 用户免费，隧道数/hostname 不限。
   CF 官方反复表示 Free Tier 长期保留。但如果你是超大用户
   （>1000 并发 / >5TB/月公网流量）会被提示升级 Teams。

Q: 免费版 WARP 私有网络限流量吗？
A: 不限流量，但单 WARP 客户端免费版有约 200-400 Mbps 的公平使用上限。
   够用 4K 串流了。

Q: 能把 CF Tunnel 当大文件/PT 下载节点吗？
A: 不推荐。免费版单连接每日 1GB 流量上限（Public Hostname 模式），
   CF 对异常大流量账号可能限速。这种场景用有 VPS 的 FRP 更合适。

🔗 第十一部分：与 FRP / SSH 隧道组合使用

11.1 组合架构：最佳实践推荐

不同场景用最合适的工具，不要非此即彼。推荐的组合架构：

PLAINTEXT
┌──────────────────────────────────────────────────────────────────┐
│                   个人/小团队推荐组合架构                           │
│                                                                  │
│  Web 服务（博客 / Nextcloud / Vaultwarden / HA）                 │
│  ─────────────────────────────────────────────                  │
│     ✅ Cloudflare Tunnel 首选                                   │
│     · 零配置 HTTPS + CDN + WAF                                  │
│     · 不需要公网 IP，免费额度够用                                │
│                                                                  │
│  SSH / RDP 远程办公（偶尔用）                                    │
│  ─────────────────────────────────────────────                  │
│     ✅ cloudflared access ssh 首选                              │
│     · 加 Zero Trust SSO，比单独 SSH 密钥安全                    │
│                                                                  │
│  高性能 TCP/UDP（游戏 / 直播推流 / 大文件）                      │
│  ─────────────────────────────────────────────                  │
│     ✅ FRP (有 VPS 时) 首选                                     │
│     · 不限流量、低延迟、你掌控数据路径                          │
│     · Cloudflare Tunnel 的 WARP 也能临时用，但带宽上限有限      │
│                                                                  │
│  临时转发 / 应急调试                                            │
│  ─────────────────────────────────────────────                  │
│     ✅ SSH -R / autossh 快速上手                                │
│     · 一条命令，不需要注册和安装                                │
│                                                                  │
│  路由器级（家里所有设备透明走内网穿透）                          │
│  ─────────────────────────────────────────────                  │
│     ✅ OpenWRT 插件版 cloudflared + FRP                         │
│     · 见项目已有文章：openwrt-cloudflare-tunnel-2026.md          │
└──────────────────────────────────────────────────────────────────┘

11.2 混合部署：CF 作为 FRP 前置防护

如果你已经在用 FRP 暴露 Web 服务，不想完全迁移，可以给 FRP 前面套一层 Caddy + Cloudflare（参考已有文章 caddy-reverse-proxy-https-guide.md 和 frp-nat-traversal-complete-guide.md）：

PLAINTEXT
用户 → Cloudflare CDN/WAF → 你的 VPS Caddy → VPS 上的 frps → 内网 frpc → 源站
         (DDoS 防护 +      (TLS 终结 +       (TCP 转发)
          缓存 + WAF)       证书管理)

这样同时拿到 FRP 的无流量限制 和 Cloudflare 的 CDN + WAF 防护，两者优点都吃。

📚 第十二部分：命令速查表 + 学习路径

12.1 命令速查表（打印贴屏幕）

BASH
# ═══════ 账户与隧道管理 ═══════
cloudflared tunnel login                   # 登录/授权
cloudflared tunnel list                    # 列出所有隧道
cloudflared tunnel info <name/ID>          # 隧道详情+健康连接数
cloudflared tunnel create <name>           # 新建命名隧道
cloudflared tunnel delete <name>           # 删除隧道
cloudflared tunnel route dns <tunnel> <host>   # 绑定 DNS CNAME
cloudflared tunnel route ip add <CIDR> <tunnel> # 绑定私有网段

# ═══════ 启动与运行 ═══════
cloudflared tunnel --config cfg.yml run    # 前台跑（看日志）
sudo cloudflared service install           # 注册 systemd 服务
sudo systemctl status/restart cloudflared  # 管理服务
journalctl -u cloudflared -f               # 实时看日志

# ═══════ 客户端接入（非 HTTP）═══════
cloudflared access ssh --hostname ssh.example.com   # SSH ProxyCommand
cloudflared access tcp --hostname rdp.example.com --url 127.0.0.1:3389

# ═══════ 诊断与调试 ═══════
cloudflared tunnel ingress validate        # 校验 config.yml 语法
cloudflared tunnel ingress rule https://app.example.com/foo  # 命中测试
cloudflared --loglevel debug tunnel run    # Debug 模式前台

12.2 学习路径建议

PLAINTEXT
┌────────────────────────────────────────────────────────────────┐
│  Cloudflare Tunnel 学习路径（从 0 到生产部署）                    │
├────────────────────────────────────────────────────────────────┤
│  🟢 入门（1 天）                                                 │
│  · 2.1 ~ 2.3 快速上手一条龙                                      │
│  · 暴露一个本地 whoami / whoami 容器                             │
│  · 感受"零端口 + 自动 HTTPS"是什么体验                           │
│                                                                 │
│  🟡 进阶（3 天）                                                 │
│  · 第三部分 Ingress 深度配置：通配符域名 + 多服务                 │
│  · 第四部分 SSH/RDP 用 cloudflared access 连                     │
│  · 第五部分给 Admin 面板加 Google SSO                            │
│                                                                 │
│  🟠 熟练（1 周）                                                 │
│  · 第六部分 Docker Compose 全家桶部署                            │
│  · WARP 私有网络 + Split Tunnel（手机透明连家里）                │
│  · 第七部分多副本 Replicas 高可用                                │
│                                                                 │
│  🔴 生产（长期）                                                 │
│  · 第八部分可观测性 + 监控告警                                   │
│  · 第九部分 mTLS + WAF + 策略合规                                │
│  · 第十一部分 FRP + CF Tunnel 混合架构                           │
└────────────────────────────────────────────────────────────────┘

12.3 参考资料 & 延伸阅读

✅ 总结

Cloudflare Tunnel 把"内网服务暴露到公网"这件事变的像点外卖一样简单——你只要点单（写 ingress 规则），剩下的 DNS、CDN、HTTPS、DDoS 防护全帮你做了。2026 年的今天，个人/小团队场景下，它已经取代了 80% 我以前会用 FRP 或 SSH 隧道做的事。

但它不是万能的：

最好的架构从来不是只选一种工具，而是在每种场景下用最合适的工具，按需要组合。

下一步建议：马上打开终端走一遍第二部分的「10 分钟快速上手」，先把一个 whoami 服务暴露出来体验一下。体验完你就会明白为什么它现在是自托管社区的标配。

版权声明

作者: 易邦

链接: https://blog.e8k.net/posts/cloudflare-tunnel-complete-guide/

许可证: 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

相关内容