网站返回429，怎样定位限流来源
429表示请求受到频率限制。它可能来自入口防护、反向代理、应用接口，也可能是应用转发了上游服务的限制。先确认限制是谁发出的，再调整请求或规则。单看错误页面样式，无法确定是哪一层拦截。
先找出具体哪一个请求被限制
在浏览器开发者工具的“网络”面板中查看：是整个页面返回429，还是页面正常但某个接口、图片或轮询请求失败？记录请求路径、方法、状态码、发生时间、响应中的请求标识。保存前去掉Cookie、Authorization和地址中的敏感参数。
普通访问者应按页面提示等待；管理自己的网站时，先暂停异常脚本或密集刷新。响应头里的Retry-After可能是等待秒数，也可能是一个HTTP日期；客户端应尊重它，不要刚收到限制就立即重试。
Linux或macOS可对自己有权检查的、确认不会产生业务动作的GET地址取一次响应头。下例域名仅作占位，执行前替换；不要用下单、发信、支付或修改数据的接口测试：
curl -q -sS --connect-timeout 5 --max-time 15 \
-D - -o /dev/null 'https://example.com/'命令保留当前响应头、丢弃正文，不自动跟随跳转，不循环请求。若结果是301或302，说明这次只看到了跳转，不能把它当作最终页面结果。输出中的Set-Cookie等字段同样需要脱敏。需要登录的接口优先查看已有浏览器请求，不把完整会话凭据复制到命令里。
顺着请求路径对日志
| 观察到的证据 | 下一步 |
|---|---|
| 入口防护记录命中限流，源站无对应访问 | 核对命中的规则、统计维度、时间窗口及来源 |
| 代理层记录拒绝，应用未收到请求 | 检查代理限流配置与拒绝日志 |
| 应用收到请求并主动返回429 | 查账户配额、接口频率及应用日志 |
| 应用调用上游后收到429 | 确认上游额度和本地重试是否放大请求 |
用时间、路径和请求标识关联同一次请求，先统一日志时区。没有源站日志只能作为线索：访问日志可能关闭、采样或写入其他文件。Server响应头也可能被代理改写，不能独自作为归因依据。
Nginx的limit_req模块默认拒绝状态码是503，也可以配置其他状态码。因此看到429既不能直接认定是Nginx，也不能排除它；应查实际启用的配置及对应错误日志。只检查已有日志，先别为了排障打印全部请求头和登录信息。
常见根因与对应调整
- 页面重复轮询：检查多个标签页、重复绑定的定时器、失败后立即重试。减少重复请求，设置有限次数的退避重试，遵守服务端等待时间。
- 大量用户被算成一个来源：核对代理后的客户端地址识别。只有确认的代理地址才可作为可信转发来源，不能盲目信任任意X-Forwarded-For。
- 账户或接口配额用尽：确认按账号、令牌还是接口统计。只调整自己管理且证据明确的配额或调用节奏，保留必要保护。
- 上游先限流：减少并发、合并重复查询，等待额度恢复。不要轮换IP或伪装请求绕过限制。
写入类请求是否能重试，要依据接口的幂等与去重约定；不能看到429就自动重放支付、开通或邮件任务。修改前保存原规则，单次调整后等待限制窗口结束，用正常访问量确认恢复，同时观察规则是否仍按预期生效。失败则恢复本次改动，不在生产站点用高并发反复验证。