自动跳转的域名源码深度剖析

5个坑让你域名自动跳转失效？新手避坑实战指南 看了一堆教程还是不会写项目？别慌，我当年也在这上面栽了跟头。刚接手一个电商后台，需求很简单：老域名 old-site.com 访问时，自动跳转到新域名 new-site.com。结果上线后，用户反馈链接打不开，或者跳过去又跳回来，死循环。那一刻我才明白，新手避坑比死记硬背语法重要一万倍。今天就把我踩过的坑、查过的源码、试过的方案，全给你掏出来。 坑的现象：为什么你的跳转“失灵”了？ 先说现象。很多初学者以为，只要服务器返回一个 301 或 302 状态码，跳转就稳了。但实际项目里，你经常会遇到三种“灵异”现象： 第一，跳转后参数丢失。 用户在 old-site.com/page?id=123 搜索，跳到了 new-site.com/page，?id=123 没了。用户懵了，以为系统崩了。 第二，HTTPS 和 HTTP 互相打架。 用户输入 http://old-site.com，跳到了 https://new-site.com，但浏览器地址栏显示不安全，或者某些子资源加载失败。更糟的是，如果配置不当，可能出现 http://old - https://old - http://new - https://new 的多次重定向，导致超时。 第三，缓存作祟。 明明代码改了，跳转逻辑对了，但用户还是看到旧行为。你刷新页面、清缓存都没用，因为 CDN 或者浏览器把 301 响应缓存了。 我在掘金技术社区看到过不少类似讨论，很多人卡在“为什么我明明写了 301，浏览器却不生效？”其实，90% 的问题不在代码逻辑，而在请求链路和配置细节上。 根本原因：你以为的“跳转”其实是个复杂链条 要解决这些问题，得先搞清楚“自动跳转的域名”背后到底发生了什么。 很多人以为，跳转就是服务器说“你去那边”，浏览器就乖乖去。其实不然。一个完整的域名自动跳转，涉及四层：DNS 解析层：浏览器先把域名解析成 IP。如果 DNS 记录配置错了，比如 CNAME 指向了废弃的服务器，后面全白搭。 Web 服务器层（Nginx/Apache）：这是最核心的一层。Nginx 的 return 301 或 rewrite 指令，决定了跳转的目标地址、是否保留参数、是否强制 HTTPS。 CDN/网关层：如果前面挂了 Cloudflare、阿里云 CDN，CDN 节点可能先响应了 301，或者缓存了旧的 301 响应。 浏览器层：浏览器有重定向次数限制（通常 20 次），如果循环跳转，直接报错。同时，浏览器会缓存 301 永久重定向，这既是优点（快），也是坑（改配置后不生效）。最关键的认知是：301 和 302 有本质区别。 301 是“永久搬家”，浏览器会记住，下次直接访问新地址，不再问服务器；302 是“临时借用”，每次都要问服务器。做域名迁移，必须用 301，否则 SEO 权重会分散，用户体验也差。 很多新手用 302 做迁移，以为“反正都能跳”，结果 SEO 流量掉了一半，这就是典型的新手避坑盲区。 正确写法对比：Nginx 里的魔鬼细节 下面这段配置，是我从一个真实故障现场提炼出来的。左边是“看似正确”的写法，右边是“生产环境推荐”的写法。 # 错误写法：看似简洁，实则埋雷 server {listen 80;server_name old-site.com;# 坑1：没处理 HTTPS，HTTP 用户会被跳去 HTTP 新域名# 坑2：$request_uri 包含了查询字符串，但如果新域名有路径映射，可能出错# 坑3：没加 Cache-Control，CDN 可能缓存这个 301return 301 http://new-site.com$request_uri; }server {listen 443 ssl;server_name old-site.com;# 坑4：HTTPS 老域名直接跳 HTTP 新域名？协议降级，不安全return 301 http://new-site.com$request_uri; }# 正确写法：生产环境推荐 server {listen 80;server_name old-site.com;# 强制 HTTPS，避免协议混合return 301 https://$host$request_uri; }server {listen 443 ssl;server_name old-site.com;# 关键1：$host 保留原主机头，但这里我们要换域名，所以硬编码新域名# 关键2：$request_uri 自动包含路径和查询参数，完美保留 ?id=123# 关键3：添加 Header，明确告知 CDN 不要缓存这个重定向add_header Cache-Control no-store, no-cache, must-revalidate;add_header Pragma no-cache;add_header Expires 0;# 使用 https 协议，安全且一致return 301 https://new-site.com$request_uri; }逐行讲解关键点：$host vs server_name：$host 是请求头中的 Host 值，用户输入什么就是什么。但在域名迁移场景中，我们通常硬编码新域名 new-site.com，因为我们要的是“所有访问老域名的都去新域名”，而不是“保留原 Host 头”。 $request_uri 的魔力：它会自动拼接路径和查询字符串。比如用户访问 old-site.com/a/b?x=1y=2，$request_uri 就是 /a/b?x=1y=2，拼上去就是 https://new-site.com/a/b?x=1y=2。参数不会丢。 Cache-Control 头：这是很多新手忽略的。301 响应如果被 CDN 缓存，你改 Nginx 配置后，CDN 节点还是返回旧的 301。加上 no-store，确保每次请求都回源验证。 HTTPS 强制：老域名的 HTTP 和 HTTPS 都要处理。HTTP 先跳 HTTPS 老域名，再跳新域名 HTTPS？不，那样多一跳。最佳实践是：HTTP 老域名直接 301 到 HTTPS 新域名，HTTPS 老域名也 301 到 HTTPS 新域名。减少重定向次数，提升速度。复现与修复代码：从本地到生产 光讲理论不够，我带你走一遍完整流程。 步骤 1：本地复现问题 用 Docker 起一个 Nginx，配置上面的“错误写法”。用 curl -I http://old-site.local 测试。你会发现，响应头里有 Location: http://new-site.local/path，但没看到 Cache-Control。 步骤 2：检查 DNS 和 CDN 登录你的域名服务商，确认 old-site.com 的 A 记录或 CNAME 指向的是你 Nginx 的 IP。如果前面有 CDN，去 CDN 控制台看“缓存规则”，确认 301 响应是否被缓存。如果是，清除 CDN 缓存，或者配置“忽略缓存头”。 步骤 3：部署正确配置 把“正确写法”部署到生产环境。用 curl -I -L http://old-site.com 跟踪重定向。你应该看到： HTTP/1.1 301 Moved Permanently Location: https://new-site.com ...HTTP/1.1 200 OK注意，这里只有一跳。如果看到两跳（先 HTTP 老 - HTTPS 老 - HTTPS 新），说明你的 HTTP 配置没直接跳新域名。 步骤 4：验证参数保留 访问 http://old-site.com/search?q=testpage=2，确认最终 URL 是 https://new-site.com/search?q=testpage=2。参数完整。 步骤 5：处理 SEO 和浏览器缓存 301 上线后，去 Google Search Console 提交 sitemap，告诉搜索引擎老域名已迁移。同时，提醒用户清除浏览器缓存，或者等几天，因为 301 被浏览器缓存后，部分用户可能还是直接访问老域名（但浏览器会直接去新域名，不会发请求到老服务器，所以不影响服务器负载）。 规避建议：建立你的“跳转检查清单” 为了避免下次再踩坑，我总结了一份域名自动跳转检查清单，你可以直接保存：状态码选对了吗？ 域名迁移必须 301，临时测试用 302。别搞混。 协议统一了吗？ 所有入口（HTTP/HTTPS）都指向 HTTPS 新域名。避免协议降级。 参数保留了吗？ 用 $request_uri 或等效变量，确保查询字符串不丢。 缓存处理了吗？ 添加 Cache-Control: no-store，并在 CDN 层配置忽略缓存。 DNS 正确吗？ 确认老域名的 DNS 解析指向当前服务器，而不是废弃的 IP。 重定向次数少于 3 次？ 用 curl -L 测试，超过 3 次就优化链路。 SEO 通知了吗？ 在 Search Console 提交迁移声明，避免权重流失。额外提醒： 如果你用的是 Apache，注意 .htaccess 里的 Redirect 301 指令，同样要处理协议和参数。如果是云函数或 Serverless 架构，跳转逻辑可能在代码层，记得在函数响应头里加 Cache-Control。 我在一个项目里就遇到过，云函数返回 301，但没加缓存头，CDN 缓存了 30 分钟，导致改配置后 30 分钟内用户还是跳错地址。这种坑，不踩一次真不知道有多烦。 最后说句掏心窝的话： 域名跳转看着简单，其实是前端、后端、运维、SEO 的交叉点。每个环节都可能出问题。作为项目现场管理员，你要做的不是记住每个配置项，而是建立一个“从请求发出到响应返回”的全链路视角。哪个环节断了，问题就在哪。 这个知识点你面试被问过吗？留言说说