如何选择域名：访问量突增时先查资源压力还是配置错误
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6161b509a221.html
📄
如何选择域名：访问量突增时先查资源压力还是配置错误
先看突增是否伴随响应时间同步上升：如果响应时间随流量一起变长、CPU 或连接数逼近上限，优先按资源压力处理；如果响应时间基本不变、却集中出现 4xx、5xx 或特定路径失败，优先按配置错误排查。缺少完整监控或服务器权限时，仍可先用外部可观测的响应时间、状态码分布和单路径复测做最小判断，但不能据此断定根因。
两种条件下该先动哪一步
条件一：你能看到服务器侧指标，且突增期间 CPU、内存、连接数或带宽中至少一项接近饱和。此时第一步是限流或扩容，而不是改配置。动作可以是在入口层对高消耗路径临时限速，观察响应时间是否回落。若回落，说明瓶颈更可能在资源侧；若限速后错误率不降反升，说明还有配置层问题被流量掩盖。
条件二：你只能看到外部表现，没有服务器权限。此时第一步是固定一条已知正常的 URL，在不同时间点重复请求，记录状态码和耗时。如果这条 URL 在突增期间仍然稳定，而其他路径大量失败，配置错误的可能性上升；如果连这条 URL 也变慢或超时，资源压力更值得先查。这个动作的结论只是缩小范围，不能替代服务器侧证据。
区分资源压力与配置错误的证据
资源压力的典型证据是：错误随并发升高而增多，降低流量后自行恢复，且恢复过程平滑。配置错误的典型证据是：错误与流量高低不同步，某个路径、某个 Host 或某种请求方法一触发就失败，降低流量后依旧存在。
- 看状态码分布：502、503、504 更偏向资源或上游不可用；大量 404、403、301 循环更偏向配置或规则错误。
- 看时间相关性：错误曲线与流量曲线几乎重合，偏向资源；错误在流量回落之后仍持续，偏向配置。
- 看路径集中度：只有少数路径失败，偏向该路径的规则或代码；全站均匀失败，偏向入口、DNS 或整体资源。
- 看变更记录：突增前后若有人改过重写规则、缓存策略或安全策略，配置错误的优先级应提前。
这些证据只能提示方向。请求量或抓取量归零、错误率突然下降，也可能是缓存命中、上游限流或攻击停止造成的，不能单独证明某次处理正确。
一个注明假设的短例子
假设某站点突增期间 5xx 从 0.5% 升到 8%，同时平均响应时间从 200ms 升到 900ms，CPU 使用率接近上限。按资源压力处理：临时限制高消耗接口的并发，十分钟后响应时间回落到 300ms，5xx 降到 2%。剩余 2% 集中在一条带查询参数的旧路径上，且降流量后仍存在，这时再按配置错误检查该路径的重写或参数处理规则。这个顺序避免了一开始就改规则、却把真正的容量问题留在原地。
执行动作如何影响下一步
先限流并观察响应时间，是成本最低的分流动作。若响应时间明显改善，下一步应补容量或优化高消耗查询，而不是继续调配置。若限流后错误结构不变，下一步应抓取失败请求的完整响应头，核对入口规则、缓存键和上游超时设置。
若你连限流入口都没有，最小动作是记录突增前后同一 URL 的状态码和耗时序列，并保存失败样本。这个动作不能证明根因，但能让你在获得权限后直接对比，减少重复试错。无论走哪条路径，都要把“资源压力”和“配置错误”当作可并存的假设，而不是互斥结论。
