我们维护来自以下 3 个来源的文档链接。
1. docs.abc.com
2. docs.def.com
3. docs.ghi.com
但我们不会向用户提供直接链接。因此，我们提供了文档链接，如下所示。
docs.mysite.com/abc/other-link-info
docs.mysite.com/def/other-link-info
docs.mysite.com/ghi/other-link-info
因此，当用户的浏览器尝试访问链接时，浏览器会点击我们的网站 docs.mysite.com，并且我们有两种方法来提供文档。
方法 1： 对于每个链接，我们将计算文档的实际链接（源链接）并从源链接下载文档。然后我们将文档流式传输给用户。
这种方法的缺点是会增加服务器的负载和带宽使用量。
方法 2： 创建 3 个 CNAME 别名，按照以下方式以便自动提供文档。
docs.mysite.com/abc => docs.abc.com
docs.mysite.com/def => docs.def.com
docs.mysite.com/ghi => docs.ghi.com
这样做的好处是服务器不会有负载和带宽占用。但我不确定这种方法是否可行。
一方面的问题： 如果我们创建指向 mybucket.s3.amazonaws.com 的 CNAME 别名（如 docs.xyz.com），最终用户是否会知道源链接或我们将文档存储在哪里。我们不希望最终用户知道我们将文档存储在哪里，而且很多时候这些文档不是我们的。
另一个附带问题： 如果我们有一个指向 mybucket.s3.amazonaws.com 的 CNAME 别名（如 docs.xyz.com），我们可以在 xyz.com 域上使用 MX 记录和其他记录吗？
非常感谢您花时间阅读本文。
答案1
如上所述，这无法通过 DNS 设置实现。
docs.mysite.com但是，您可以通过让服务器缓存从原始服务器检索到的文件并从其自己的存储中提供这些缓存文件来改进方法＃1 。
nginx您可以使用它proxy_cache来建立来自原始服务器的代理内容的缓存。
答案2
不，这行不通。DNS 与协议无关。您可以设置一个 Web 服务器来接收这些请求，然后重定向到您想要将用户发送到的链接。
答案3
不可以。这显然不是 CNAME 的作用。
foo.example.com.可以是 CNAME
http://foo.example.com/不能是 CNAME
http://foo.example.com/bar不能是 CNAME
CNAME 将一个 DNS 标签别名为另一个。URL 不是 DNS 标签。另外，需要说明的是，URL 不是域名。