什么是二级域名：访问量突增期间怎样区分资源压力与配置错误
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2a6c1fdd0262.html
📄
什么是二级域名：访问量突增期间怎样区分资源压力与配置错误
先给有条件的结论：如果二级域名的流量曲线是平滑抬升，且所有路径的延迟一起变长，优先按资源压力处理；如果只有特定路径、特定状态码或特定地区出现异常，而其他路径仍然正常，优先按配置错误排查。这个判断在一种情况下会失效：二级域名与主域共用同一套源站、证书或DNS解析，资源压力会伪装成局部配置错误，反之亦然。
先看异常的形状，而不是总量
访问量突增时，最容易犯的错是盯着总量下结论。总量上升本身不区分原因，异常的形状才有区分力。资源压力的典型特征是“面状扩散”：二级域名下几乎所有URL的响应时间同步上升，5xx比例随并发升高而升高，静态资源与动态接口一起变慢。配置错误的典型特征是“点状或线状”：只有某一类路径返回403、404或重定向循环，其他路径的耗时几乎不变。
可操作的证据是分路径、分状态码、分时间窗拉三条曲线。如果5xx集中在某一前缀，例如只出现在 /api/ 或只出现在带查询参数的URL上，配置问题的可能性高于资源耗尽。如果5xx与并发量高度同步，降并发后立即回落，资源压力的可能性更高。
两种做法需要取舍：先扩容还是先查配置
假设一个二级域名 shop.example.com 突然流量翻倍，运维和SEO各执一词。做法A是先扩容，做法B是先冻结变更、逐项核对配置。两者都成立，但条件不同。
- 选做法A的条件：监控显示CPU、内存、连接数或带宽已接近上限，且异常路径覆盖全部URL。代价是扩容可能掩盖真正的配置问题，让错误被更高的容量暂时吸收，之后以更难复现的形式回来。
- 选做法B的条件：近期有过DNS、证书、重写规则或反向代理变更，且异常集中在少数路径。代价是如果确实是容量不足，排查期间会持续丢请求，影响面扩大。
一个务实的折中是：先扩容到能扛住当前峰值的最小幅度，同时冻结其他变更并开始逐项核对。扩容后如果异常路径的比例没有下降，就基本排除纯资源原因，转入配置排查。这一步的实际动作是记录扩容前后的分路径错误率，它直接决定下一步是继续加资源还是回滚配置。
会让判断失效的反例
有一种情况会让上面的区分全部失效：二级域名与主域共用源站、共用证书或共用同一层反向代理。此时主域的流量压力会通过共享资源传导到二级域名，表现为二级域名“局部”异常；反过来，二级域名的配置错误也可能污染共享层，让主域出现看似容量不足的症状。
识别方法是看异常是否跨域同步出现。如果主域和二级域名在同一分钟出现同类错误，优先怀疑共享层，而不是各自独立的原因。这时先隔离共享依赖，再分别观察，比在单域内反复扩容更有效。
抓取与索引信号不能单独证明原因
访问量突增常伴随抓取量上升，但抓取量变化不能单独证明是资源压力还是配置错误。robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录；这些信号只能说明爬虫行为，不能说明服务器为什么变慢或报错。同样，请求量归零既可能是配置把爬虫挡在门外，也可能是抓取预算被转移到别处，需要用日志中的状态码和响应时间交叉验证。
一个可用的区分动作是：把突增时段的日志按状态码分组，分别统计各组的平均响应时间。如果4xx组的响应时间很短而5xx组很长，说明部分请求被快速拒绝、部分请求在耗尽资源，两类原因可能同时存在，需要分开处理，而不是二选一。
下一步动作与结果如何影响后续
先做一次限时的对照：在流量高峰窗口内，对二级域名的一条正常路径和一条异常路径分别发起固定频率的探测，记录状态码与耗时。如果异常路径在低并发下仍然失败，配置错误的权重上升；如果异常路径在低并发下恢复正常，资源压力的权重上升。
这个结果决定下一步：偏配置就回滚最近一次变更并逐项复核；偏资源就按峰值扩容并观察分路径错误率是否回落。无论走哪条路，都要保留变更前后的分路径数据，否则下一轮突增时仍然只能靠猜。
