出海建站必备：用 Cloudflare Zero Trust 给内部后台加一道登录保护
出海建站必备：用 Cloudflare Zero Trust 给内部加一道登录保护
出海建站必备：用 Cloudflare Zero Trust 给内部加一道登录保护
做出海产品，会有一些不希望公开访问的页面，比如管理后台、内部数据面板、测试环境和临时运营工具。
这些页面虽然没有对外宣传，但只要能从公网访问，就有可能被扫描工具发现。
Cloudflare Zero Trust 提供了一个轻量方案。它可以在请求进入网站之前增加一层身份验证，只有符合规则的成员才能继续访问后面的应用。
对于人数不多的出海团队，免费版已经能覆盖不少内部工具。
Cloudflare Zero Trust 是什么
Cloudflare Zero Trust 是 Cloudflare One 平台中的一组安全能力，包含身份访问控制、私有网络连接、DNS 和 Web 流量过滤等功能。
这篇文章讨论的具体功能叫 Cloudflare Access。它相当于放在内部应用前面的一层身份代理。访问者打开管理后台时，请求会先到 Cloudflare，由 Access 判断访问者是谁、是否满足策略，验证通过后才会继续访问应用。
text访问内部后台 → Cloudflare Access 检查身份 → 匹配访问策略 → 允许或拒绝请求 → 验证通过后进入应用
应用本身不需要先实现一套完整的员工登录系统，也可以接入 Google、Microsoft Entra ID、Okta、GitHub、一次性邮箱验证码或 Cloudflare 账号等身份验证方式。
Cloudflare 从 2026 年 6 月开始，把 Cloudflare 自身的身份提供商设为新建 Zero Trust 组织的默认登录方式。团队成员可以直接使用已有的 Cloudflare 账号登录，旧组织仍保留原来的登录配置，也可以继续添加 OTP 或第三方身份提供商。
它适合保护哪些内容
最直接的场景是内部管理后台。网站前台继续公开访问，admin.example.com 只有指定成员登录后才能打开。
即使后台原本已经有账号密码，再增加一层 Access 也能减少登录页面直接暴露在公网的风险。
预发布环境也很适合使用。开发和测试中的页面需要让团队成员或外部合作方查看，但还不适合被搜索引擎和普通用户发现，可以针对 staging.example.com 单独设置访问策略。
团队内部的数据看板、客服工具、内容管理页和运营脚本界面也可以用同样的方法保护。
Cloudflare Access 支持按整个域名、子域名或具体路径配置应用，因此可以只保护 example.com/admin，也可以给多个独立子域名分别创建应用。
如果应用部署在私有网络中，还可以配合 Cloudflare Tunnel 和 Cloudflare One Client 使用，不必给服务器开放公网入口。
浏览器应用、SSH、RDP 和部分非 HTTP 服务都可以纳入访问控制，不过这些场景需要比普通后台多做一些网络配置。
怎么开始配置
进入 Cloudflare Dashboard 后打开 Zero Trust，第一次使用需要创建一个 Zero Trust 组织并选择套餐。Cloudflare 当前的免费方案面向 50 人以内的团队或概念验证。
免费方案在启用时仍可能要求填写付款方式。页面会显示当前应付为 0，但某些超出免费额度的功能或额外用量可能产生费用，因此启用前要看清计划和计费说明。
激活 Cloudflare Zero Trust 免费版
组织创建完成后，需要设置 Team name。Cloudflare 会根据这个名称生成唯一的 Team domain，例如：
textyour-team.cloudflareaccess.com
这个地址会出现在 Access 登录、App Launcher 和 Cloudflare One Client 等场景中。一个 Zero Trust 组织只有一个 Team domain，但可以创建多个 Access 应用。不同管理后台和内部工具会共用同一个团队登录域。
一个 Team domain 可以作为多个 Access 应用的共用登录入口
Cloudflare Zero Trust 的团队名称和团队域
Team name 配好后，在 Access controls 中添加应用。保护自己部署的网站时选择 Self-hosted application，填写要保护的域名、子域名或路径，例如：
textadmin.example.com
应用还需要至少一条允许策略。
小团队可以只允许几个指定邮箱，使用公司邮箱的团队可以限制邮箱域名。如果新组织默认使用 Cloudflare 身份提供商，也可以把访问范围限制为当前 Cloudflare Account 的成员。
配置保存后，用无痕窗口分别测试允许和拒绝场景。允许的账号应该完成登录并进入后台，未列入策略的邮箱应该停留在 Access 登录或拒绝页面。测试时还要确认退出登录、会话过期和更换账号后的行为符合预期。
实际使用效果
配置完成后，用户直接打开内部后台时，会先看到 Cloudflare Access 的登录页面。验证通过后，Cloudflare 向浏览器签发会话，后续请求在会话有效期内可以继续访问应用。
这层保护发生在请求到达应用之前。
免费版适合人数较少、访问规则相对简单的团队。
几个容易踩坑的地方
Team domain 属于整个 Zero Trust 组织，不属于某一个应用。同一组织可以保护多个域名和后台，但登录页共用同一个 cloudflareaccess.com 地址。
如果业务确实需要完全不同的 Team domain，需要拆成不同的 Cloudflare Account 或 Zero Trust 组织。
Team name 不要随意修改。名称变化后，身份提供商和已经注册的 Cloudflare One Client 都可能需要同步更新。
访问策略要限制到具体成员。
自动化任务、Webhook 和 OAuth Callback 无法完成浏览器登录，不能直接套用普通成员策略。
最后，Access 是应用前面的一道入口保护。涉及不同员工角色、数据权限、付款和删除等敏感操作时，应用内部仍然需要自己的权限判断。Cloudflare Access 负责决定谁能进入，应用负责决定进入之后能做什么。
Cloudflare Access 与应用内部权限分别控制进入资格和操作范围