用途
Cloudflare Zero Trust 用于在不使用 VPN 的情况下，为应用提供安全的远程访问。它由两部分组成：Cloudflare Tunnel 负责安全连接，Cloudflare Access 负责认证与授权。
核心原则：认证不是可选项。每个隧道从第一天起就必须具备访问控制。资料明确指出：未认证的隧道等于公开暴露的服务，等于安全事件。若出现“稍后再加认证”“没有认证也一直没问题”“不想用登录打扰用户”“内部应用能否跳过认证”“先做演示、之后再加固”等想法，都属于安全违规。正确的心态是：无认证隧道即暴露服务即严重漏洞；用户便利性低于安全要求；“仅内部”不是安全控制；演示也应默认安全。
何时使用
适用于以下场景：为任意应用搭建 Cloudflare Tunnel；配置 Cloudflare Access 认证；安全暴露内部应用；以零信任模型替代 VPN 访问；集成 OIDC/SSO 提供商（Azure AD、Okta、Google）；在 Docker 容器中运行 cloudflared；排查 502 Bad Gateway 错误；通过仪表盘或 CLI 管理隧道。
触发该技能的典型症状包括：“需要把本地应用暴露到互联网”“正在搭建 Cloudflare Tunnel”“给隧道加认证”“配置 Azure AD / Okta / OIDC”“Cloudflare Tunnel 出现 502 Bad Gateway”“在 Docker 中运行 cloudflared”。
主要能力
隧道管理方式
提供两种管理方式。远程管理（仪表盘）适合 GUI 用户、快速搭建、团队协作；本地管理（config.yml）适合基础设施即代码、自动化、版本控制、CI/CD。仪表盘方式通过 Zero Trust → Networks → Tunnels → Create 创建，选择 Cloudflared 连接器，命名隧道，在源服务器安装 cloudflared，复制令牌运行 cloudflared service install <TOKEN>，再配置公共主机名与 Access。本地管理方式使用 cloudflared tunnel create myapp-tunnel 创建隧道，生成凭据文件，编写 config.yml，配置 ingress 规则（含必需的 catch-all 规则 - service: http_status:404），通过 cloudflared tunnel route dns 路由 DNS，再以 cloudflared tunnel run 前台运行或安装为系统服务。
现代协议与私有网络
涉及 WebSockets、HTTP/2、gRPC 时需加载 protocols.md；WebSockets 建议 keepAliveTimeout: 300s，HTTP/2 需要 TLS 源并设置 http2Origin: true，gRPC 使用 WARP 路由而非公共主机名。暴露 SSH、RDP、数据库或自定义 TCP/UDP 协议时需加载 private-networks.md；SSH 使用 ssh://192.168.1.10:22，RDP 使用 rdp://192.168.1.20:3389，数据库使用 tcp://192.168.1.30:5432，Docker 中应使用服务名而非 localhost。
容器化部署
Docker/Kubernetes 中关键差异是 localhost 无法解析，应使用容器名或服务名，如 http://myapp:8080 或 http://myapp-service:8080。凭据以只读方式挂载，Kubernetes 使用 ConfigMap 存配置、Secret 存凭据。健康检查可用 cloudflared tunnel info，生产环境建议至少 2 个副本以实现零停机更新。
Access 应用与策略
自托管应用通过 Zero Trust → Access → Applications → Add an application 选择 Self-hosted 配置，设置名称、会话时长、应用域名与身份提供商，并至少添加一条 Allow 策略。策略可基于邮箱、邮箱域名、IdP 组，可要求 MFA、目的说明或临时认证。SaaS 应用从目录选择并按向导集成。策略设计遵循最小权限原则，评估顺序为 Bypass、Block、Allow、Service Auth。
OIDC/SSO 集成
支持 Azure AD（Entra ID）、Okta 及通用 OIDC 提供商。Azure AD 需在 Azure Portal 注册应用，重定向 URI 为 https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback，复制客户端 ID 与密钥，添加 Group.Read.All 权限与 groups 声明，再在 Cloudflare Zero Trust → Settings → Authentication 添加。Okta 创建 OIDC Web 应用，重定向 URI 为 https://<team-name>.cloudflareaccess.com/cdn-cgi/access/callback。通用 OIDC 需填写 Auth URL、Token URL、JWKS 证书 URL，支持时勾选 PKCE。
服务认证（M2M/API）
配置 CI/CD、微服务或任何非人类认证时需加载 service-auth.md。创建令牌路径为 Zero Trust → Access → Service Auth，使用请求头 CF-Access-Client-Id、CF-Access-Client-Secret，建议每 90 天轮换，存放于密钥管理器而非代码中。
使用方式与排查
搭建流程为：定义需求（谁需要访问、认证提供商、Docker 还是主机）→ 选择管理方式 → 创建隧道 → 在正式上线前配置 Access 认证 → 测试认证 → 对用户启用 → 监控日志。关键点是在暴露隧道前先配置 Access 认证，绝不部署未认证隧道，哪怕是临时的。
502 Bad Gateway 表示隧道已连接 Cloudflare 但无法到达源站。排查步骤：本地 curl -v http://localhost:8080 测试源站；查看 cloudflared 日志（systemd 用 journalctl -u cloudflared，Docker 用 docker logs cloudflared）；Docker 中执行 docker exec cloudflared curl http://myapp:8080；前台运行隧道查看实时错误。常见原因包括源站宕机、Docker 中使用 localhost、自签名证书、端口错误、防火墙规则。
认证循环（重定向循环）表现为浏览器反复跳转登录页。需检查是否有 Allow 策略匹配用户、IdP 重定向 URI 是否与 Cloudflare 一致。
适用场景与限制
适用于需要安全暴露内部应用、替代 VPN、集成企业 SSO、容器化部署与自动化管理的团队。资料未提供具体收费、价格、平台限制或效果数据，这些信息暂未提供。