场景
大部分人都拿过这个需求:站点同时有顶级域名(example.com)和 www 二级(www.example.com),为了不让搜索引擎把这俩当成两个站、分散权重,需要把其中一个 301 跳到另一个。
常规做法是在 Web 服务器(Nginx / Apache / IIS)里写一条 301 规则。但很多 DNS 服务商提供的"URL 转发"记录可以不走服务器层,直接在 DNS 解析时就完成跳转。配置极简单,不用动 Web 服务器配置,适合临时需求或者管不到服务器配置的场景。
本文整理这几个东西:URL 转发是什么、隐性和显性区别、什么情况用、不能用的坑。
什么是 URL 记录
常规的 DNS 记录类型(A、CNAME、AAAA、TXT 等)是把域名指向一个 IP / 别名,然后浏览器自己去那个 IP 发 HTTP 请求。URL 记录不一样,它直接告诉 DNS 服务商:"这个域名访问时给我跳到另一个 URL"。
具体怎么实现:DNS 服务商在自己机房架了一组转发服务器,当 URL 记录解析时,会把请求路由到这些服务器上,服务器代为完成跳转或转发。所以这其实是个服务商提供的代理层,不是纯 DNS 协议的能力。
支持 URL 记录的主要 DNS 服务商:
- DNSPod(腾讯云)
- 阿里云 DNS
- Cloudflare(用 Page Rules 实现)
- 华为云 DNS
- 大部分注册商自带的 DNS(NameSilo、Namecheap、GoDaddy 等)
显性转发(301 重定向)
用户访问 http://biekanle.com → DNS 转发服务器返回 301 Moved Permanently + Location: https://blog.biekanle.com/ → 浏览器跳转,地址栏变成 https://blog.biekanle.com/。
特点:
- 用户看到的地址变了(地址栏显示 blog.biekanle.com)
- 搜索引擎认这是个真正的跳转,会把权重过户到目标域名
- 对 SEO 友好
等价于 Nginx 里:
server {
listen 80;
server_name biekanle.com;
return 301 https://blog.biekanle.com$request_uri;
}隐性转发(iframe 嵌套)
用户访问 http://biekanle.com → DNS 转发服务器返回一个简单 HTML,内含 <iframe src="https://blog.biekanle.com/" /> → 浏览器渲染这个 iframe,看起来内容是目标站,但地址栏一直显示原域名。
特点:
- 地址栏不变(伪装成你的二级域名)
- SEO 不友好 —— 搜索引擎看到的是 iframe,内容不被算作原域名
- 用户难以分享真实内容链接(分享出去都是原域名)
- 很多目标站会用
X-Frame-Options: DENY拒绝被 iframe,这种情况下隐性转发直接失败白屏
怎么选
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 主域名 → 子域名(SEO 合并权重) | 显性转发(301) | 保持 SEO 权重传递 |
| 把多个老域名集中到新主域 | 显性转发 | 告诉搜索引擎域名搬家 |
| 短域名 → 长域名,但不想露 | 隐性转发 | 地址栏保持原貌 |
| 个人短链服务 | 显性转发 | 让用户看到真实落地页 |
限制和坑(必须知道)
1. 目标地址 X-Frame-Options 限制
隐性转发用 iframe 实现。如果目标站点(blog.biekanle.com)的响应头里设了 X-Frame-Options: DENY 或 SAMEORIGIN,浏览器会拒绝渲染 iframe,转发后页面就是空白或者 "refused to connect"。
常见拒绝被 iframe 的站:Google、百度、淘宝、所有银行站、绝大多数 SaaS 后台。要嵌的话,只能改对方响应头(自己的站才能改),或者用显性转发。
2. 目标不能是 IP 或 IP:端口
URL 转发记录的目标只能是域名,不支持:
http://1.2.3.4❌http://1.2.3.4:8080❌http://example.com:8080❌(部分服务商支持,部分不支持)
要走 IP 或非标准端口,自己架 Nginx 做反向代理。
3. TLS,在 HTTP 之上加一层 TLS 加密,防止中间人窃听和篡改。">HTTPS 限制
转发前地址(biekanle.com)通常只支持 HTTP,不支持 HTTPS。原因是 DNS 服务商的转发服务器不会持有你的域名 SSL 证书。如果用户访问 https://biekanle.com,浏览器会先做 TLS 握手,握不上手就直接报错,根本走不到转发逻辑。
转发后地址(blog.biekanle.com)支持 HTTP 和 HTTPS 都行。
如果转发前也要 HTTPS,通常解决方法:
- 用 Cloudflare 接管 DNS,Cloudflare 给你颁发免费 SSL,在 Page Rules 里设转发(支持 HTTPS)
- 自己架 Nginx,装证书,服务器层做 301
4. 工信部备案要求
大陆服务商(腾讯、阿里、华为云)添加 URL 转发记录时,转发后的域名必须已经在工信部备案过(随便哪个接入商都行)。否则 URL 转发设置不进去。
实操示例:DNSPod 添加 URL 记录
- 登录 DNSPod 后台 → 找到你的域名 → 解析
- 点"添加记录" → 主机记录填
@(顶级) 或www - 记录类型选 "显性 URL" 或 "隐性 URL"(看上面表格)
- 记录值填完整目标 URL,比如
https://blog.biekanle.com - TTL 默认 600 秒就行
- 保存
等 5-10 分钟 DNS 缓存刷新,新规则生效。验证用 curl -I http://biekanle.com 看响应头,如果是 301 + Location: https://blog.biekanle.com 就是显性转发成功。
替代方案:Nginx 自己做
如果你能控制服务器,自己写 Nginx 比 DNS URL 记录灵活得多:
# /etc/nginx/conf.d/redirect.conf
server {
listen 80;
listen 443 ssl http2;
server_name biekanle.com www.biekanle.com;
ssl_certificate /etc/letsencrypt/live/biekanle.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/biekanle.com/privkey.pem;
# 全部 301 到 blog 子域名,保留路径和查询串
return 301 https://blog.biekanle.com$request_uri;
}这套方案 HTTP / HTTPS 都支持,可以保留路径(biekanle.com/foo 跳到 blog.biekanle.com/foo),还能自定义跳转规则(按 UA、按 IP、按 Cookie 区分),DNS URL 记录这些都做不到。
一句话总结
SEO 场景闭眼选显性转发(301),无论 DNS URL 记录还是 Nginx 都行。隐性转发只在极少数"想隐藏目标 URL"的场景才用,且要注意目标站允不允许被 iframe。
—— 别看了 · 2026