虽然你的 DNS 记录 包含有关域名的信息，但代理状态控制该记录的 HTTP/HTTPS 流量是通过 Cloudflare 网络路由，还是直接到达你的源站服务器。
当记录为 **Proxied（已代理）**时，Cloudflare 位于访问者与服务器之间——沿途优化、缓存并保护流量。当记录为 **DNS-only（仅 DNS）**时，Cloudflare 会以服务器的实际 IP 地址响应，且不会通过其网络路由 HTTP/HTTPS 流量。
仅用于 IP 地址解析的记录——A、AAAA 与 CNAME 记录——可以代理。其他记录类型（例如 MX 或 TXT）始终为仅 DNS。
Cloudflare 建议代理所有服务于 Web 流量的 A、AAAA 与 CNAME 记录。用于其他用途的记录，例如用于证明域名所有权的 CNAME 记录，不应代理。
当你将 DNS 记录设置为 Proxied——在仪表板中显示为橙色云图标，也称为“orange-clouded”——Cloudflare 可以：
- 保护你的源站服务器（托管网站或应用程序的服务器）免受 DDoS 攻击 ↗。
- 优化、缓存并保护 对应用程序的所有请求。
- 将你的 Cloudflare 产品配置（例如 WAF 规则、缓存 与重定向规则）应用于传入流量。
example.com 的 DNS 管理：
| Type | Name | Content | Proxy status | TTL |
|---|---|---|---|---|
| A | blog |
192.0.2.1 |
Proxied | Auto |
| A | shop |
192.0.2.2 |
DNS only | Auto |
在上面的 DNS 表示例中，有两条 DNS 记录。名称为 blog 的记录已开启代理，名称为 shop 的记录关闭代理（即 DNS only）。
这意味着：
- 对代理记录
blog.example.com的 DNS 查询将以 Cloudflare anycast IP 地址——用于通过附近数据中心路由流量的共享 IP 地址——而不是192.0.2.1来回答。这可确保针对该名称的 HTTP/HTTPS 请求将发送到 Cloudflare 网络并可以被代理，从而实现上述优势。 - 对仅 DNS 记录
shop.example.com的 DNS 查询将以实际源站 IP 地址192.0.2.2来回答。这会将你的源站 IP 地址暴露给任何查询该记录的人，从而移除一层针对定向攻击的保护。Cloudflare 也无法对这些请求提供 HTTP/HTTPS 分析（仅有 DNS 分析）。
更多背景信息请参阅 Cloudflare 如何工作。
以下各节说明将 DNS 记录设置为 已代理 时的特定行为与预期结果。在特定场景中也可能存在一些限制。
默认情况下，所有代理记录的生存时间（TTL）为 Auto，设置为 300 秒。此值无法编辑。
此较短 TTL 可确保：若 Cloudflare 更改分配给你记录的 anycast IP 地址，更改会快速生效。递归解析器——代表最终用户查找记录的 DNS 服务器——缓存旧地址的时间不会超过 300 秒（五分钟）。
若你在同一名称上有多条 A 或 AAAA 记录，且其中至少一条已代理，Cloudflare 会将该名称上的所有 A 或 AAAA 记录视为已代理。
示例
example.com 的 DNS 管理：
| 类型 | 名称 | 内容 | 代理状态 | TTL |
|---|---|---|---|---|
| A | blog |
192.0.2.1 |
Proxied | Auto |
| A | blog |
192.0.2.5 |
DNS only | Auto |
在此示例中，所有发往 blog.example.com 的流量都将被视为两条记录均为 Proxied。
若 CNAME 链上的某个主机名——即一条 CNAME 记录指向另一条——已代理，Cloudflare 也会代理该请求。
示例
假设同一 Cloudflare 账户有两个不同的 zone：example.com 与 example.net。
example.com 的 DNS 管理：
| 类型 | 名称 | 内容 | 代理状态 | TTL |
|---|---|---|---|---|
| CNAME | example.com |
origin.example.net |
DNS only | Auto |
example.net 的 DNS 管理：
| 类型 | 名称 | 内容 | 代理状态 | TTL |
|---|---|---|---|---|
| CNAME | origin.example.net |
<origin> |
Proxied | Auto |
在此示例中，所有发往 example.com 的流量都将被视为 Proxied。
借助 CNAME flattening，Cloudflare 会跟随 CNAME 链找到最终 IP 地址，从而帮助 DNS 查询更快解析。代理的 CNAME 记录 默认会被扁平化，因为它们返回 Cloudflare anycast IP。
在某些情况下，Cloudflare 会显示警告消息或阻止你代理 CNAME 记录。这是为了避免错误配置，通常与其他 CDN 提供商或用于 DKIM ↗（电子邮件身份验证）验证的特定记录有关。
对于代理记录，若你的域名已启用 HTTP/2 或 HTTP/3 并且还在使用 Universal SSL，Cloudflare 会动态自动生成 HTTPS Service（HTTPS）记录。这些 DNS 记录预先向客户端提供如何连接到服务器的信息，无需初始明文 HTTP 连接来发现受支持的协议。
Cloudflare 对代理请求强制执行大小限制。这些限制因套餐而异，且在流量被代理时无法绕过。有关连接与请求限制的完整列表，请参阅连接限制。
Cloudflare 在 Cloudflare 与你的源站服务器之间强制执行默认的 Proxy Read Timeout。若你的源站未在定义的时间限制内发送 HTTP 响应，Cloudflare 将返回 524 错误。Enterprise 客户可以增加超时值。
当 A、AAAA 或 CNAME 记录为 DNS-only——在仪表板中显示为灰色云图标，也称为“gray-clouded”——对这些记录的 DNS 查询将解析为记录的实际源站 IP 地址，如示例所述。
DNS-only 仅建议用于不服务于 Web 流量的记录，例如用于电子邮件路由或第三方域名验证的记录。对于服务于 Web 流量的记录，DNS-only 意味着你的源站 IP 地址对任何查询该记录的人可见，从而可能使服务器暴露给恶意行为者与 DDoS 攻击 ↗。Cloudflare 也无法优化、缓存并保护这些请求，或为其提供 HTTP/HTTPS 分析。
某些 DNS 记录应为仅 DNS，因为它们所支持的服务与 Cloudflare 的 HTTP 代理不兼容。常见示例包括电子邮件记录、域名验证记录、SaaS 托管的网站以及非 HTTP 服务。