模块 3b — 设备配置文件（Device Profiles）

目标： 为不同设备群组应用不同的 Cloudflare One 客户端设置——让受管笔记本、BYOD 手机、服务器、承包商各自获得正确的模式、分流与 DNS 行为。

这是对模块 3 B 部分的可选深入。如果你组织里所有设备都应表现一致，单个 Default 配置文件就够了——当笔记本、BYOD、服务器或承包商需要区别对待时再回到这里。

什么是设备配置文件

设备配置文件是一组具名的 Cloudflare One 客户端设置（模式、分流、DNS 行为、开关锁等），外加决定它应用到哪些设备的匹配规则。设备连接时，Cloudflare 依据这些规则为它选出一个配置文件。

设置分为两层：

📺 它们在哪： Zero Trust → Team & Resources → Devices → Device profiles。配置文件位于 General profiles 下。（旧版控制台放在 Settings → WARP Client ——是同一功能。）

⏱️ 提醒： 更改可能需要最多 10 分钟才到达设备。

五种客户端模式（每个配置文件先定这个）

模式是配置文件里最重要的设置——它决定该设备上哪些 Zero Trust 功能生效。

💡 提示： 多数组织受管笔记本用 Gateway with WARP，BYOD 用 Device Information Only（或 Include 模式的 Gateway with WARP）。

A 部分 — 创建设备配置文件

1. 👉 Zero Trust → Team & Resources → Devices → Device profiles → General profiles。
2. 👉 点击 Create new profile。
   • 📺 你会看到： 新配置文件以 Default 配置文件的副本开始，因此你只需改动不同之处。
3. ⌨️ 清晰命名，如 BYOD phones 或 Linux servers。
4. 👉 创建匹配规则，界定哪些设备使用此配置文件——见 B 部分。
5. 👉 配置客户端设置（模式、开关锁、自动连接等）。
6. 👉 点击 Create profile。
   • ⚠️ 注意： Split Tunnels 与 Local Domain Fallback 只能在保存后编辑。先创建，再重新打开设置它们（D、E 部分）。
7. 👉 回到列表，把配置文件拖动到正确位置——顺序很重要（C 部分）。

✅ 检查点： 你的新配置文件出现在 Profile settings 列表中，位于 Default 之上。

B 部分 — 匹配规则（选择器）

匹配规则决定配置文件应用到哪些设备。由选择器、运算符和取值组成。

⚠️ 基于身份的选择器（邮箱、群组、SAML）仅当用户通过 IdP 登录注册时才生效。用服务令牌注册的设备无法按身份匹配——请改用 OS、受管网络或服务令牌。

运算符：

💡 示例——“承包商”配置文件： 选择器 User group names · 运算符 is · 取值 contractors。这样你 IdP 中 contractors 群组的任何人都会自动获得该配置文件（更严格的）设置。

C 部分 — 优先级顺序（设备如何被匹配）

这是最容易搞错的部分，值得讲清楚：

1. 设备连接时，Cloudflare 从上到下读取配置文件列表。
2. 它使用设备匹配到的第一个配置文件，然后停止。下方的配置文件无法覆盖它。
3. Default 配置文件始终固定在最底部，仅当设备上方都不匹配时才应用。

   配置文件列表（自上 ↓ 下评估）           一台在 “finance” 群组的 Windows 笔记本…
   ┌─────────────────────────────────────┐
   │ 1. Linux servers      (os = linux)   │  ✗ 非 linux
   │ 2. Finance team       (group finance)│  ✓ 匹配 → 使用此配置文件，就此停止
   │ 3. BYOD phones        (os = ios/andr)│  （不再评估）
   │ 4. Default            (总在最后)      │  （不再评估）
   └─────────────────────────────────────┘

⚠️ 注意： 把更具体的配置文件放上面，更宽泛的放下面。若宽泛配置文件（如“所有 Windows”）在具体的（如“finance 中的 Windows”）之上，具体那条将永不匹配。

💡 提示： 若你把某个自定义配置文件提升为 Default，它的设置会被复制进 Default 配置文件。

D 部分 — Split Tunnels（按配置文件）

Split Tunnels 决定哪些 IP 流量 经过 Cloudflare、哪些绕过。请在保存配置文件之后配置（打开配置文件 → Split Tunnels → Manage）。

常见使用场景：让 Cloudflare One 客户端与 VPN 并存（Exclude 模式），或仅为某个特定私有网络授予访问（Include 模式）。

两种模式

⚠️ 切换模式会清空你的条目。 在 Exclude 与 Include 之间切换时，列表会恢复为 Cloudflare 默认值。请先复制现有条目（Manage → 记录下来），以便重新添加。

🔑 Split Tunnels 只影响 IP 流量——不影响 DNS

这是最容易被误解的一点。Split Tunnels 控制的是 IP 数据包的流向。DNS 是独立的： 即使你排除了某站点的 IP，其 DNS 查询仍由 Gateway 解析（并受你的 DNS 策略约束），除非你把该域名也加入 Local Domain Fallback（E 部分）。Split Tunnels 与 Local Domain Fallback 设计上是配合使用来处理私有资源的。

条目类型——IP 地址 vs 域名

点击 Manage → 添加时，你可选择 IP Address 或 Domain：

• IP 地址 / CIDR（⭐ 推荐）——如 10.0.0.0/8。快速且可预测。要从较大网段中切出较小网段，可用 UI 内置的 CIDR 计算器。
• 域名——如 example.com。当用户访问它时，域名会被解析（由 Gateway，或经 Local Domain Fallback 的私有 DNS），随后 Split Tunnels 动态地 include/exclude 返回的 IP。若该域名没有公共 DNS 记录，你必须添加一条 Local Domain Fallback 条目（E 部分）才能解析。

💡 优先用 IP 而非域名。 域名更慢——客户端每次都要即时做 IP 查询并改写路由表/本地防火墙。保持列表简短：每个条目都增加解析时间，且存在按账户的上限。

需要了解的默认值

• Exclude 模式默认已排除 RFC 1918 私有网段、CGNAT 网段 100.64.0.0/10（供 Cloudflare One 服务使用）以及组播网段。
• ⚠️ 若你需要经客户端访问私有应用/主机名：
  • Exclude 模式： 从排除列表中移除 100.64.0.0/10（并把你本地实际使用的非 Cloudflare CGNAT 网段加回，以免冲突）。
  • Include 模式： 添加这些以便私有主机名可解析——IPv4 100.80.0.0/16 与 IPv6 2606:4700:0cf1:4000::/64，外加你私有网络自身的 CIDR。

常见 Exclude 模式用例

• Microsoft 365 / Teams / Zoom / VoIP——需要用户真实设备 IP、或对延迟敏感的应用，排除后往往表现更好。（设备设置里有一键 Directly route Microsoft 365 traffic 选项。）
• 分阶段迁移期间与既有 VPN 并存。

⚠️ 权衡： 你排除的任何流量都会绕过 Gateway——该流量将失去过滤、DLP 与日志。若你需要对某目的地保留可见性或策略，就不要排除它。

💡 提示： 要向用户路由某个私有网络（如 10.50.0.0/16），在 Include 模式添加该 CIDR，或确保它在 Exclude 模式未被排除。

E 部分 — Local Domain Fallback（本地域名回退）

Local Domain Fallback（LDF） 让客户端用你自己管理的私有/内部 DNS 解析器解析特定域名，而不是把这些 DNS 查询发送到 Cloudflare Gateway。客户端会把匹配的查询直接代理到你指定的 DNS 服务器。

用于： Active Directory、*.internal 以及其他公共 DNS（和 Cloudflare）无法解析的仅内部域名——尤其当该 DNS 服务器仅能从用户设备访问时。

内置默认值（已为你处理）

开箱即用地，Zero Trust 会把常见的本地解析顶级域名排除在 Gateway 之外，交给设备自身的解析器处理。默认后缀为：

corp · domain · home · home.arpa · host · internal · intranet · invalid · lan · local · localdomain · localhost · private · test

你只需为该列表之外的私有域名添加条目（如 acme.internal、ad.acme.com）。

如何添加条目

1. 👉 打开配置文件 → Local Domain Fallback → Manage（仅在保存后可编辑）。
2. ⌨️ Domain——输入顶级（apex）域名，如 example.com。它被视为 *.example.com，因此所有子域都被覆盖。
3. ⌨️ DNS Servers——输入应解析它的解析器 IP（如 10.0.0.25）。为性能考虑请保持在 ≤ 8 台。客户端会查询全部并采用最快的响应——即使该响应是“无记录”，因此务必至少指定一台可靠服务器。（留空则客户端回退到 WARP 启动前设备所用的 DNS。）
4. ⌨️ 填写可选描述 → Save domain。

LDF 是按设备配置文件限定的。没有 LDF 资源的配置文件仅使用上面的默认后缀。

⚠️ 重要限制——Gateway 无可见性

由 Local Domain Fallback 处理的 DNS 查询绕过 Gateway 解析器，因此不受 Gateway DNS 策略约束，也不出现在 DNS 日志中。若你需要对私有 DNS 做过滤或记录，请改用 解析器策略（resolver policies）。

LDF vs. 解析器策略——该用哪个？

⭐ 建议： 若你的 DNS 服务器能连到 Cloudflare 接入匝道，优先用解析器策略以获得日志/可见性。若同一设备上两者都配置了，则 Local Domain Fallback 规则优先生效。

⚠️ AWS 陷阱： 不要把所有 *.amazonaws.com 都指向内部 Route 53 解析器——公共 AWS 端点（如 ssm.us-east-1.amazonaws.com）将无法解析并导致功能异常。只路由特定的 Route 53 区域或 VPC 端点（vpce.amazonaws.com）。

验证

• 👉 在设备上运行 warp-cli settings，查看 fallback domains 部分以确认你的条目已生效。

F 部分 — 全局设备客户端设置（所有设备）

这些位于配置文件之外，全组织生效。位置：Team & Resources → Devices → Device settings（全局区）：

G 部分 — 验证设备拿到了哪个配置文件

通过控制台：

1. 👉 Team & Resources → Devices → 打开某设备 → 查看其分配的配置文件。

通过设备（命令行）：

warp-cli settings

• 📺 查看 Profile ID 字段——它显示当前应用配置文件的 UUID。

✅ 检查点： 你的测试设备报告了你预期的配置文件（如 BYOD 设备显示 BYOD 配置文件，而非 Default）。

实战示例（照抄这些模式）

✅ 模块 3b 完成！

你现在拥有：

• ✅ 对全局设置与配置文件设置、以及五种客户端模式的理解
• ✅ 一个或多个带匹配规则的自定义设备配置文件
• ✅ 正确的优先级顺序（具体在上、宽泛在下）
• ✅ 按需设置的按配置文件分流与本地域名回退
• ✅ 验证设备所获配置文件的方法

快速排障

👉 下一步：模块 4 — ZTNA / Access

发布你的第一个私有应用，并替代对它的 VPN 访问。