为什么限流时要给出明确的状态码
当站点压力上升，服务器常用的做法有两种：一是让请求挂到超时或返回 500，二是主动返回 503 或 429。前者在日志里表现为连接中断或服务错误，蜘蛛只能按自己的退避策略重试；后者是明确告诉对方「现在不行，过一会儿再来」。对抓取节奏来说，主动返回带 Retry-After 的 503 通常比让请求撞到超时更可控，因为它把等待时间变成了双方都能读到的约定。
503 与 429：先分清两种信号
两者语义不同。503 Service Unavailable 表示服务临时不可用，常见于维护窗口、后端过载、下游依赖故障；429 Too Many Requests 表示请求频率超出限制，更适合针对单一来源做速率控制。选错状态码不会让问题消失，只会让后续排查失去线索：看到 429 会先想频率，看到 503 会先想服务本身。
Retry-After 的写法与常见坑
Retry-After 支持两种格式，一种是以秒为单位的整数，一种是 HTTP-date 时间戳。秒数写法简单，不依赖双方时钟；HTTP-date 可读性好，但要求服务器时钟准确，否则可能给出已经过去的时间，或过远的未来时间。
- 秒数按实际恢复时间估算，维护窗口十分钟就写 600，不要随手写 86400。
- 返回 503 时同时给出 Retry-After，蜘蛛更容易按你给的节奏回访；只给 503 不给该头，回访间隔由对方决定。
- HTTP-date 使用 GMT 格式，不要和本地时区混用，日志时区与服务时区也要对齐后再判断。
- 长时间维持一个很大的 Retry-After，等于主动压低抓取频次，恢复后不会立刻回到原来的节奏。
哪些场景适合用 503
- 计划内维护：发布、迁移、数据库变更，预计几十分钟内恢复。
- 突发流量：源站被打满，先挡住一部分请求，保住核心页面的可用性。
- 下游依赖故障：缓存、搜索服务或数据库不可用造成的临时错误。
也要说清楚不适合的场景：长期下线的栏目、确定不再提供的内容，应该用 404 或 410 让它退出抓取队列，而不是一直用 503 拖着。把 503 当软删除使用，入口会长期占用抓取预算，恢复后也难以判断该目录是否还有价值。
排查顺序
- 先看访问日志里 503 的比例和分布，判断是全站、某个目录还是某个接口。
- 检查响应是否带有 Retry-After，格式是秒还是 GMT 时间，数值是否与预期恢复时间相符。
- 确认 CDN 或反向代理有没有把 503 当成可缓存响应，避免恢复后仍返回旧状态。
- 核对维护页是否返回 200 但内容为空，这种「假 200」会让蜘蛛把空页当正常页面处理。
- 观察恢复后的回访曲线，看抓取频次是否逐步回升，而不是长时间停在低谷。
和抓取节奏的配合
503 本身不是惩罚，但持续时间、覆盖范围和出现频率会影响蜘蛛对站点的判断。短时、范围明确、带 Retry-After 的 503 通常影响有限；长时间、全站、没有说明的 503 则可能让抓取频次下降，恢复后需要一段时间才能回到原来的水平。如果只是希望某个目录少被抓，优先考虑 robots.txt 规则或内链收敛，而不是靠 503 制造障碍。限流应该解决真实的资源问题，而不是当作长期的流量开关。
状态码是写给抓取方看的说明书。写清楚「现在不行、什么时候再来」，比让请求撞到超时更有助于恢复后的抓取回到正常节奏。