手里的站点上线半年了有天查搜索资源平台发现首页权重全跑到不带 www 的根域名上而带 www 的主域名却没分到多少流量。这种问题在站长圈里太常见了——注册域名的时候顺手填了个 A 记录用户顺手输了个网址搜索引擎又喜欢把两个域名当成两个站对待。解决办法说简单也简单无非是把不带 www 的根域名 301 重定向到 www 主域名。但真要动手配置不同的服务器环境、不同的 CDN 前置各种细节能把人绕晕。这篇文章把我实际跑过的 5 种方案完整整理出来从 Nginx、Apache 这种传统 Web 服务器到 Varnish 缓存层、Node.js 应用层再到 Cloudflare 这种面板级设置每种方法都带配置代码和踩坑提示。适合刚买域名的小站长、Linux 服务器运维、前后端开发者以及准备做域名规范化迁移的团队。看完你不仅能配置出正确的 301还能理解为什么这么做遇到跳转循环、证书报错这类问题也能自己排查。1. 为什么必须处理根域名和 www 域名的关系1.1 两个域名在用户眼里是同一个在搜索引擎眼里不是先理清一个基本概念example.com 和 www.example.com 在 DNS 解析层面完全是两个独立记录。用户在浏览器地址栏输入 example.comDNS 解析的是根域名的 A 记录输入 www.example.com解析的是 www 这个子域名的 A 记录。两条记录可以指向完全不同的服务器哪怕服务器上跑的是同一个站点搜索引擎也默认这是两个独立站点。这就带来了一个很实际的问题站点内容重复。比如首页 title、正文已经发布的信息会被搜索引擎分别抓取两遍。抓取之后搜索引擎要把权重分配到 URL 上结果就是权重被拆成两半。有些新手可能觉得无所谓反正浏览器都能打开但站点运营时间越长、外部链接越多权重分裂的损失就越明显。我在一个实际项目里见过根域名和 www 域名权重各占 50% 左右把 301 跳转配置好后三个月内 www 域名的自然搜索流量涨了接近一倍就是因为权重集中到一个域名上了。另外还有 Cookie 作用域的问题。www.example.com 的 Cookie 默认只能在 www 这个子域名下生效根域名 example.com 下的 Cookie 作用域则是整个主域。如果用户先在根域名登录再跳到 www 域名登录态经常丢失体验非常割裂。1.2 为什么必须是 301不能用 302重定向有 301 和 302 两种状态码区别很多人没搞清楚。301 是 Moved Permanently表示永久移动搜索引擎收到这个状态码后会把旧 URL 的权重、收录信息完全转移到新 URL并且后续抓取会直接使用新地址。302 是 Found或者叫 Moved Temporarily表示临时跳转搜索引擎会认为旧 URL 仍然有效只是这次临时跳到了别处权重不会转移收录信息也不变。所以如果要做域名规范化必须用 301。用 302 的话根域名的收录和权重不会合并到 www 域名等于跳了个寂寞。我见过有人用 JS 跳转或者 meta refresh 做这种重定向更不可取搜索引擎虽然能识别但传递权重的能力远不如 301。这是原则问题不要图省事。1.3 根域名和外部域名的区别以及选型的考量注册域名的时候根域名和外部域名这个概念很多人混淆。根域名就是你注册下来的那个完整的主域名比如 example.com。外部域名通常是指你从注册商那里买的所有后缀比如 example.com、example.net、example.org 这些都属于外部域名但互相之间没有任何关系不能因为注册了 example.com 就认为 example.net 也自动可用。选 www 还是非 www 作为主域名没有绝对的对错但一定要选一个并坚持下去。业内大部分站点选 www原因有几个一是 CDN、云服务商对 www 子域名的支持更成熟通配符证书 *.example.com 能覆盖 www 和其他子域名但根域名需要单独申请证书二是 www 在历史上被广泛使用用户潜意识里觉得 www 才是“正规网站”三是根域名更短适合做品牌传播比如一些极简风格的站点就坚持用根域名。我个人建议普通站点选 www省心。2. 方法一Nginx 环境下的根域名跳转2.1 最简配置server 段里直接 returnNginx 是目前市场占有率最高的 Web 服务器配置 301 也是最简单的一种。核心思路是给根域名单独建一个 server 块专门用来做跳转然后 www 域名的 server 块负责正常处理业务。server { listen 80; server_name example.com; return 301 http://www.example.com$request_uri; } server { listen 80; server_name www.example.com; root /var/www/example; index index.html; # 其他站点配置 }这段配置的关键在return 301后面用了$request_uri变量。它的作用是保留原始请求的完整路径和查询参数。比如用户访问http://example.com/article/123?page2会直接跳到http://www.example.com/article/123?page2路径一个字符都不会丢。这里我建议优先用return而不是rewrite。虽然 rewrite 也能实现跳转但 nginx 在处理 rewrite 时会重新走一遍 URI 解析流程性能上不如 return 直接返回响应。在大量并发下return 的效率优势明显配置也更简洁没有歧义。这是我在压测对比两种写法后的实际感受。配置完成后执行nginx -t检查语法然后systemctl reload nginx或nginx -s reload热加载配置不需要重启服务。2.2 HTTPS 场景下如何避免跳转循环站点上了 HTTPS 之后配置要比纯 HTTP 复杂一些因为 80 端口和 443 端口各有一套规则。我的做法是80 端口统一跳到 HTTPS 的 www 域名443 端口的非 www 域名也跳转到 HTTPS 的 www 域名。server { listen 80; server_name example.com www.example.com; return 301 https://www.example.com$request_uri; } server { listen 443 ssl; server_name example.com; ssl_certificate /etc/nginx/ssl/example.com.pem; ssl_certificate_key /etc/nginx/ssl/example.com.key; return 301 https://www.example.com$request_uri; } server { listen 443 ssl; server_name www.example.com; ssl_certificate /etc/nginx/ssl/example.com.pem; ssl_certificate_key /etc/nginx/ssl/example.com.key; root /var/www/example; index index.html; # 其他站点配置 }这样配置的好处是无论用户从哪个地址进来最终都落在唯一的 https://www.example.com 上。要注意一点如果你有多个域名都接入了同一个 HTTPS 证书必须确保证书覆盖了根域名和 www 域名。比如单独一张 example.com 的证书在访问 www.example.com 时会报证书不匹配跳转会先卡在浏览器警告页上。我用 curl 验证一下这种配置的跳转是否正常curl -I http://example.com返回结果应该类似HTTP/1.1 301 Moved Permanently Server: nginx Location: https://www.example.com/看到状态码是 301Location 指向带 www 的 HTTPS 地址就说明配置生效了。还有一个小细节Nginx 里同一组证书路径可以写成变量避免三处重复但如果你的 Nginx 版本较老或配置风格偏保守直接写全路径更稳妥。3. 方法二Apache 环境下的根域名跳转3.1 .htaccess 方式配置如果服务器面板是宝塔、cPanel 这类基于 Apache 的环境最方便的做法是在站点根目录的 .htaccess 文件里加跳转规则。这种方式不需要重启 Apache改完立刻生效适合虚拟主机用户。RewriteEngine On RewriteCond %{HTTP_HOST} ^example\.com$ [NC] RewriteRule ^(.*)$ https://www.example.com/$1 [R301,L]拆开解释一下RewriteEngine On开启重写引擎RewriteCond是条件判断这里的正则^example\.com$表示匹配纯 example.com[NC]表示忽略大小写。后面的RewriteRule是具体规则^(.*)$捕获整个请求路径$1回填到目标地址中。[R301,L]表示执行 301 跳转并且是最后一条规则不再继续匹配后续规则。有个容易踩的坑如果 .htaccess 里同时还有别的重写规则顺序很关键。301 跳转规则必须放在所有规则最前面否则请求可能被其他规则先拦截跳转就不生效了。我在一个项目里遇到过把规则加到了 WordPress 的伪静态规则后面结果怎么都不跳转后来排错了半天才发现是顺序问题。3.2 在 httpd.conf 的 VirtualHost 中配置对于有服务器 root 权限的用户我更推荐直接在 VirtualHost 里配置而不是用 .htaccess。因为 .htaccess 每次请求都要被 Apache 读取解析一次对性能有影响生产环境能不用就不用。在 VirtualHost 里写规则Apache 在启动时就加载配置性能更好也更清晰。VirtualHost *:80 ServerName example.com Redirect 301 / https://www.example.com/ /VirtualHost VirtualHost *:80 ServerName www.example.com DocumentRoot /var/www/html/example # 其他配置 /VirtualHost注意 Redirect 指令后面那个/它表示把根域名下所有路径都重定向到目标地址。这里也可以用RedirectMatch 301 (.*) https://www.example.com$1来做更灵活的路径匹配但普通跳转用 Redirect 就够了。配置完后执行apachectl configtest检查语法再systemctl reload httpd或systemctl reload apache2加载配置。3.3 确保 mod_rewrite 或 mod_alias 已启用如果用 .htaccess 的 Rewrite 方式需要保证 mod_rewrite 模块已启用。查看模块是否加载apachectl -M | grep rewrite有输出就说明已经加载。如果没加载在 Debian/Ubuntu 下执行a2enmod rewriteCentOS/RHEL 下在 httpd.conf 中取消LoadModule rewrite_module modules/mod_rewrite.so的注释然后重启 Apache。用 Redirect 方式则依赖 mod_alias这个模块默认基本都开着。我在给一台老服务器迁移站点时遇到过奇怪现象.htaccess 里的规则看起来没问题但就是不生效。排查到最后发现httpd.conf 里的AllowOverride None根本没改成AllowOverride All导致 Apache 直接忽略了 .htaccess。这个细节很容易被忽略修改 .htaccess 之前先确认一下站点目录的 AllowOverride 配置。4. 方法三Varnish 缓存层全局拦截4.1 VCL 中处理根域名跳转站点前面挂了 Varnish 做缓存加速的话跳转逻辑最好放在 VCL 层处理。这样根域名的请求根本不会到达后端 Web 服务器既减轻了后端压力又能保证所有进站流量统一跳转。配置在 vcl_recv 和 vcl_synth 两个子程序里配合完成。sub vcl_recv { if (req.http.host example.com) { set req.http.X-Redirect-Url https://www.example.com req.url; return (synth(750, Moved Permanently)); } } sub vcl_synth { if (resp.status 750) { set resp.http.Location req.http.X-Redirect-Url; set resp.status 301; return (deliver); } }VCL 的逻辑是用synth(750)生成一个自定义响应然后在 vcl_synth 里把这个响应转换成标准的 301 跳转。这里用 750 这个自定义状态码是 Varnish 社区常用的做法目的是区分正常的 301 和 VCL 内部主动生成的跳转。代码里的req.url会自动带上原始的路径和查询参数不需要额外拼接。4.2 Varnish 方案的注意点用 Varnish 做跳转有几个注意点。第一vcl_synth里要确保设了Location响应头并且状态码是 301否则用户在浏览器里看到的可能是一片空白或者一个错误页面。第二如果 Varnish 前面还套了 CDNCDN 到 Varnish 的请求头里 Host 字段可能是 CDN 回源时的真实域名这种情况需要看 CDN 回源时是否透传了原始 Host。第三Varnish 本身不处理 HTTPS 的终止443 端口的 TLS 通常是通过前置负载均衡器或 Nginx 处理后再转到 Varnish。因此如果站点是 HTTPS跳转目标直接写https://www.example.com没问题的。配置 VCL 时建议先用varnishd -C -f /etc/varnish/default.vcl做一次编译检查确认语法无误再加载避免线上事故。5. 方法四Node.js 应用层重定向5.1 原生 HTTP 模块的最小跳转服务Node.js 项目如果自己管理 HTTP 层没有前置 Nginx 或 Apache可以在应用入口处做一个中间件判断。下面是用原生http模块实现的最小跳转服务逻辑简单直观便于理解。const http require(http); const server http.createServer((req, res) { if (req.headers.host example.com) { res.writeHead(301, { Location: https://www.example.com req.url }); res.end(); return; } res.writeHead(200, { Content-Type: text/plain; charsetutf-8 }); res.end(正常访问 www.example.com 时的业务响应); }); server.listen(80, () { console.log(Server running on port 80); });这里用req.headers.host获取请求的域名与example.com做精确匹配。匹配成功后通过writeHead设置 301 状态码和 Location 响应头然后结束响应。req.url保留了完整的路径和查询参数跳转时不会丢失内容。如果用https.createServer逻辑完全一致只要把 Location 里的协议改成 https 即可。这种方式的优点是零依赖一个文件就能跑起来适合本地实验场景。5.2 Express 框架中间件写法实际业务中大部分 Node 项目都用了 Express 或 Koa 这类框架。在 Express 中的写法更简洁直接在中间件里做判断即可。const express require(express); const app express(); app.use((req, res, next) { const host req.headers.host; if (host example.com) { return res.redirect(301, https://www.example.com req.originalUrl); } next(); }); app.get(/, (req, res) { res.send(欢迎访问 www.example.com); }); app.listen(80);注意这里用res.redirect(301, ...)表示永久跳转如果不传 301 这个参数Express 默认返回 302。很多新手在这里容易踩坑以为默认就是 301结果配置了半天搜索引擎完全不认。Node 方案适合小团队快速实现但它毕竟是在应用层处理每个请求都要经过 Node 进程不如 Nginx 那类前置跳转高效。如果 Node 后面配置了 PM2 守护进程改完代码记得用pm2 reload让改动生效。6. 方法五DNS/CDN 面板级别设置6.1 Cloudflare Page Rules 实现 301如果域名 CDN 用的是 Cloudflare最省事的方法就是直接在面板上操作不用碰服务器配置。Cloudflare 的 Page Rules 功能可以针对指定的 URL 做转发支持 301 状态码。配置步骤登录 Cloudflare选择站点进入 Page Rules。点击 Create Page Rule。URL 规则填写example.com/*Setting 中选择Forwarding URLStatus code 选择301 - Permanent RedirectDestination URL 填写https://www.example.com/$1点击 Save and Deploy。这个配置生效的速度非常快通常几十秒内全球节点同步。$1是 Cloudflare 的通配符变量会把 URL 规则里*匹配到的路径原样带到目标地址。比如http://example.com/about会跳到https://www.example.com/about。在 Cloudflare 里做跳转的好处是请求在边缘节点就直接被处理了不会回源到服务器对源站完全零压力。即使你的源站 IP 变了跳转规则也不会受影响。6.2 国内云解析商的类似能力国内主流的 DNS 解析服务商比如阿里云、腾讯云、华为云在解析控制台通常也有“显性 URL”或“隐性 URL”这种记录类型。选择显性 URL 并填写目标地址就能实现 301 跳转。这种方案的本质是云解析服务商帮你在 DNS 层面返回一个 301 响应。具体做法在 DNS 解析列表里给根域名添加一条 URL 类型的记录主机记录留空或用 表示记录类型选显性 URL记录值填https://www.example.com解析线路默认TTL 默认即可。不过要注意显性 URL 功能有时候依赖云厂商的跳转服务器某些地区或某些线路下可能不稳定。而且这种记录类型不支持路径级别的匹配只能做整站跳转。所以我通常建议如果站点有独立服务器优先用 Nginx 这类服务器层方案只有用虚拟主机不方便改配置时才用面板跳转代替。6.3 使用面板方案的适用场景面板级跳转最大的优势是零代码、零服务器操作适合不想折腾配置文件、没有服务器管理权限的用户。但缺点是灵活性不足比如无法做条件判断某种 UA 跳转、某个 IP 段放行也无法在同一条规则里做复杂的路径改写。此外如果根域名和 www 域名都接入了 CDN你需要确认 CDN 的 SSL 证书是否同时覆盖了这两个域名否则跳转过程可能出现证书警告。我在一个客户项目里遇到过一个情况客户同时用了云解析的显性 URL 和服务器上的 Nginx 301导致用户访问根域名时重复跳转了两三次才到最终地址。所以要记住同一时间只保留一种跳转配置不要在多个层面做重复设置。7. 验证效果与常见问题排查7.1 用 curl 验证 301 是否生效配置完跳转后第一步就是用 curl 验证。curl 是一个命令行工具几乎在所有 Linux 和 macOS 环境都预装了Windows 10 以上系统也在自带列表里。命令如下curl -I http://example.com-I参数表示只发送 HEAD 请求获取响应头信息不下载页面内容。看到的结果应该是类似这样的HTTP/1.1 301 Moved Permanently Date: Tue, 05 Nov 2024 10:00:00 GMT Server: nginx Location: https://www.example.com/ Content-Type: text/html Content-Length: 169重点关注两行第一行的状态码必须是 301不能是 200、302、404第二行是关键Location 头必须指向带 www 的地址且协议应该是最终想用的 HTTPS 或 HTTP。如果 Location 不对跳转就是错的。想同时验证 www 域名是否能正常访问执行curl -I https://www.example.com这个请求应该返回 200 或网站原本的业务状态码而不是再次跳转。7.2 常见问题速查表私信里经常有人问跳转失败的问题我把遇到过的典型问题整理成一个表格方便排查问题现象可能原因解决方法根域名跳转后提示重定向过多服务器层和 CDN 层同时配置了跳转形成循环只保留一处跳转配置逐层排查 Location 链跳转后 HTTPS 证书报警目标域名的证书没覆盖 www 子域名换用 *.example.com 通配符证书或补一张 www 证书根域名跳转正常但带路径的链接 404目标地址没带原始路径参数检查配置Nginx 用 $request_uriApache 用 $1 捕获路径搜索引擎迟迟不更新收录跳转生效时间不足或跳转状态是 302确认返回 301提交站点改版工具加速收录局域网内测试域名不生效本地 hosts 没解析根域名在客户端 hosts 文件添加服务器 IP 与域名映射以上是高频问题后面这条单独解释一下。7.3 局域网开发时的额外注意事项开发人员在本地或内网环境调试这个功能时经常会遇到 DNS 解析的问题。公网域名在局域网里没有内网 DNS 服务器的解析记录访问example.com不会指向你本机的开发服务器。解决办法是在 hosts 文件里手动添加映射Linux 和 macOS 是/etc/hostsWindows 是C:\Windows\System32\drivers\etc\hosts。192.168.1.100 example.com 192.168.1.100 www.example.com其中192.168.1.100是局域网内运行 Web 服务的 Linux 服务器 IP。配置完 hosts把 Nginx 监听端口改成 80 后浏览器访问根域名就能触发 301 跳转了。还有一个容易忽略的点如果用路由器或内网 DNS 提供的域名解析注意 DNS 缓存问题。改了 hosts 或服务器配置后先在命令行执行ipconfig/flushdnsWindows或sudo systemd-resolve --flush-cachesLinux刷新缓存再测试跳转。7.4 我的验证习惯与收尾建议配置完所有跳转后我习惯顺手再跑一次全路径验证把根域名下带参数、带子目录的地址都 curl 一遍确认 query string 和路径都没有丢失。然后在搜索资源平台提交一次 URL 改版加速搜索引擎对迁移的感知。在域名要不要带 www 这件事上我个人最终选了 www 作为主域名因为通配符证书、CDN 兼容性都更省心。但这不代表根域名方案不好——如果你品牌名足够短主推根域名也没问题只要把 www 反向 301 到根域名即可方法和上面完全对称。如果你正在部署一个新站点我的忠告是在网站上线第一天就把跳转配置好不要等搜索引擎收录了根域名才开始改不然旧收录迁移需要额外时间。已经跑了很久的老站点也不用慌301 是成熟方案搜索引擎处理这种域名规范化问题非常熟练配置正确后几个月内权重就会慢慢集中到目标域名上。