网站首选域名设置，突增流量下先查资源还是先查跳转
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /934012c59072.html
📄
网站首选域名设置，突增流量下先查资源还是先查跳转
先给结论：如果突增来自真实用户或外部推荐，而首选域名的跳转链、规范标签和内部链接同时出现异常，优先排查配置错误，而不是先扩容；因为配置错误会把本应集中到一个主机的流量拆散，扩容只会掩盖问题。反之，如果监控显示单机连接数、带宽或数据库连接池先到瓶颈，而各域名的响应状态完全一致，才应把资源压力列为首要嫌疑。
用一个假设情境把两种判断分开
假设某站点同时绑定 example.com 与 www.example.com，首选域名设置为前者，并配置了 301 跳转。某天因外部推荐，访问量在两小时内上升到平时的数倍。此时有两种看似合理的做法：一是立即给源站加机器，二是先检查首选域名相关配置。
判断依据不是访问量本身，而是同一时刻不同域名的表现差异。如果 www 版本开始返回 200 而不是 301，或者部分页面在 www 上可正常打开、在首选域名上超时，说明流量被分散到了未预期的入口，配置错误的可能性更高。如果两个域名都返回相同的 301 或 200，且延迟同步上升，则更可能是资源压力。
看响应码分布，而不是只看总量
资源压力通常表现为响应变慢、超时增多，但状态码结构基本稳定。配置错误则容易出现状态码突变，例如：
- 原本应返回 301 的备用域名开始返回 200；
- 首选域名的页面出现 404 或 500，而备用域名正常；
- 同一路径在两个域名下返回不同内容，且规范标签指向不一致。
这些现象指向的是跳转规则、服务器块匹配或证书覆盖范围的问题，而不是单纯的 CPU 或带宽不足。此时加机器不会减少错误状态码，反而可能让两个域名都被更多请求打到。
检查内部链接与站点地图是否仍指向首选域名
突增期间，如果页面里的内部链接、canonical 标签或站点地图中的 URL 混用了两个域名，爬虫和用户会被引导到非首选入口。一个实际动作是：抽取突增期间被访问最多的若干页面，检查其中指向自身的绝对 URL 是否与首选域名一致。
如果发现大量链接仍指向备用域名，下一步应优先修正模板或配置中的域名引用，而不是扩容。因为这类问题会持续把权重和请求分散，扩容只是让分散的速度更快。需要说明的是，站点地图不保证收录，robots.txt 的抓取限制也不等于可靠的索引移除，所以这些信号只能作为配置一致性的参考，不能单独证明处理正确。
资源压力的证据长什么样
当以下条件同时成立时，资源压力更可能是主因：
- 两个域名的响应状态码分布与突增前基本一致；
- 首选域名的 301 跳转仍然生效，且跳转目标正确；
- 服务器监控显示连接数、内存或数据库等待时间先于错误率上升；
- 静态资源与动态页面的延迟上升幅度接近。
此时可以先做限流或扩容，但应保留对首选域名跳转的监控。因为资源压力缓解后，如果状态码分布没有恢复，说明配置问题仍然存在，只是被高延迟掩盖了。
一个可执行的决策顺序
假设突增持续 30 分钟，按以下顺序操作：
- 第一步，分别请求首选域名和备用域名的同一路径，记录状态码与跳转目标。若两者不一致，进入配置排查。
- 第二步，若状态码一致，查看服务器连接数与错误日志的时间关系。若连接数先到上限，进入资源排查。
- 第三步，无论先查哪边，都保留一份突增期间的响应码样本。这份样本决定下一步是修正跳转规则，还是调整容量。
这个顺序的代价是：配置排查会占用几分钟，可能推迟扩容；但如果配置确实有误，这几分钟能避免把资源投入到错误的方向。反过来，如果先扩容而跳转规则已经失效，新增资源只会同时服务两个入口，首选域名的集中效果不会恢复。
哪些现象不能单独作为结论
请求量或抓取量归零、某个域名突然没有日志，都不能单独证明配置正确或错误。它们还可能是日志采样、缓存命中或监控断点造成的。HTTPS 也不保证安全无漏洞或排名，不同搜索引擎对规范信号的支持情况需要分别核查。把资源压力和配置错误分开，依靠的是同一时间窗口内多个入口的行为对比，而不是单一指标的升降。
