Twitter 超出速率限制：起因与修复（2026）

作者：Sorsa 编辑部

2026 年 7 月 11 日更新：对照 X 的定价文档核验了当前的 X API 按资源读取价格和 200 万帖读取上限，外加被广泛报道的 2026 年免费和 Premium 账号应用内阅读上限。

要点： Twitter/X 上的“超出速率限制”意味着你发出的请求多于当前窗口允许的，所以那个动作被短暂阻断。普通用户通过滚动、刷新或关注太快触发；开发者看到带错误码 88 的 HTTP 429。最快的修法是停下，等窗口重置。

“超出速率限制”这个词指向两个完全不同的问题，修法取决于你遇到的是哪一个。如果这条消息在你滚动或刷新应用时出现，你撞上了一个你账号的平台级上限。如果它在一个脚本或服务器日志里作为 HTTP 429 冒出来，你撞上了 X API 的按接口速率限制。本指南覆盖两者，从如何区分两者开始。

对开发者，同一个 429 不断出现的原因，往往是三个独立的限制全都返回 429：按接口的 15 分钟窗口、你 X 账号自己的上限，以及一个每月使用上限。我们运营 Sorsa API，一个替代性的 Twitter/X API，所以这些限制和它们产生的 429，我们每天都撞上：既在我们自己的数据管道里，也贯穿我们处理的读密集迁移。这也是为什么我们把 Sorsa 建成没有窗口模型：每个接口一个固定的每秒 20 次请求限制，没有 15 分钟重置，也没有要杂耍的按应用对按用户之分，读取跑得远比官方按资源定价便宜。下面的数字是你现在在 X 上要应对的，再往下，我们把两个模型并排放。

最后核验：2026 年 7 月 11 日，对照 X 的速率限制和定价文档。

目录

• 超出速率限制：应用内消息 vs API 429
• 浏览 X 时被阻断：起因与持续时长
• Twitter/X API 429：HTTP 状态和错误码 88
• 你撞上了哪个限制？一个 429 背后的三层
• 即时修法：读重置头并退避
• 如何避免 Twitter API 速率限制
• 一个付费套餐会移除速率限制吗？
• 实战中：一个不断卡在 429 上的社交聆听团队
• 常见问题

超出速率限制：应用内消息 vs API 429 {#rate-limit-exceeded-the-in-app-message-vs-the-api-429}

同样的几个字描述两种不相关的失败。一个是普通 X 账号上的平台阻断，显示在应用里或网站上。另一个是返回给调用 X API 的程序的一个 HTTP 429。两者有不同的起因、不同的重置行为和不同的修法，所以第一步是把你的症状匹配到对的列。

如果你是普通用户、从不碰开发者 API，只有前两行适用于你，修法几乎总是停下、等待。如果你在对着 API 构建，429 是一个你能在代码里读取并响应的信号，本指南的多数聚焦于此。这两个系统被分别强制执行。一个普通账号和一个开发者应用从不同的预算里支取，所以在其中一个里没事，并不保护你在另一个里也没事。

浏览 X 时被阻断：起因与持续时长 {#blocked-while-browsing-x-causes-and-how-long-it-lasts}

如果这条消息在你正常使用 X 时出现，你越过了一个绑定到你账号的平台级上限，而不是一个 API 限制。X 对阅读、发帖、关注、点赞和发消息施加这些上限，以放慢自动化、保护自己的基础设施。这个阻断是临时的，一旦窗口重置就自行清除。

普通用户最常见的触发是 2023 年 7 月引入、在 2026 年仍以放宽形式生效的每日阅读上限。X 不正式公布确切数字。但跨账号测试一致报道：未认证免费账号每天约 1,000 条帖子，已认证 Premium 账号约 1 万条，不到一个月的全新未认证账号约 500 条。每条滚过的帖子都算一次阅读，即便是你没点开的那些，所以在一个媒体丰富的信息流里大量滚动，通常就是绊倒你的原因。

其他账号动作有各自的上限。太快地关注和取关也会触发，大致每小时几十个就是问题的开始。连珠炮式点赞、发许多私信，或每小时多次改动账号邮箱，同样都能产生这条消息。连到你账号的第三方应用在后台发 API 调用，也从你的预算里支取。所以一个排程器、一个分析工具和一个粉丝追踪器同时跑，就能在你毫无动作时耗光额度。

阻断持续多久，取决于你撞上哪个上限：

• 多数基于窗口的阻断在滚动窗口过去后 15 到 60 分钟清除。
• 每日上限（包括阅读限制）在 UTC 午夜重置。
• 重复违规能把被标记账号上的限制延长到 24 到 72 小时。

修法简单，多数就是干净地等待。停止刷新，因为每次重试都能延长冷却。关掉应用或标签，走开半小时。如果你用第三方客户端，把它们全部登出，因为它们的后台调用可能才是真正的起因。查 Downdetector 或 X 自己的状态更新，以防一次全平台事故被误报为速率限制。如果阻断持续数小时，登出、清 cookie、再登回有时有帮助。要看按动作和账号类型的账号级上限完整拆解，我们关于 X 账号和 API 速率限制的参考，带当前数字列出了每一项。

Twitter/X API 429：HTTP 状态和错误码 88 {#the-twitterx-api-429-http-status-and-error-code-88}

在开发者 API 上，“超出速率限制”作为一个 HTTP 429 响应到达。这意味着你在当前窗口内向一个接口发的请求多于该接口的限制，所以下次调用被拒，直到窗口重置。429 是传输层信号；X 还在响应体里返回一个应用层标识符。

确切形状取决于你在调用哪个客户端和 API 版本，但这些全都描述同一个事件：

• 朴素状态行： HTTP 429 Too Many Requests。
• X v1.1 风格体： {"errors":[{"code":88,"message":"Rate limit exceeded"}]}，其中码 88 是 X 对这个错误的规范标识符。
• X v2 风格体： {"title":"Too Many Requests","detail":"Too Many Requests","type":"about:blank","status":429}。
• Tweepy： 抛出 tweepy.errors.TooManyRequests，你调用周围的一个通用异常处理器会捕获它。
• 在你自己应用背后： 前端往往把原始 429 替换成一条通用的“无法加载”消息，所以真实错误只出现在你的服务器日志里。

一旦你确认了一个 429 状态或码 88，包装无关紧要，同样的修法适用。要紧的是弄清你实际越过了哪个限制，因为在当前 X API 上，三个不同的限制各能返回一个 429，每个的修法都不同。如果错误具体在一个登录流程期间、而不是在读取期间触发，那它可能根本不是速率限制，而是一次反自动化核查；我们在关于“此请求看起来可能是自动化的”消息的指南里单独覆盖了那个。

你撞上了哪个限制？一个 429 背后的三层 {#which-limit-did-you-hit-the-three-layers-behind-a-429}

X API 上单个 429 能来自三个独立的系统。“明明离速率限制还远得很”之所以是这么常见的抱怨，正是因为人们只查一层、漏掉另外两层。读响应头，就能知道是哪一个拦下了你。

第 1 层：按接口的速率限制。 每个 X API v2 接口在一个滚动 15 分钟窗口上有各自的上限（少数用 24 小时窗口），在两个独立的池里追踪：一个针对 Bearer Token 认证的按应用限制，和一个针对 OAuth 用户令牌的按用户限制。例如，近期搜索允许每个用户每 15 分钟 300 次请求。1 万个用户打一个仅应用后端，全都从一个共享的按应用池里支取，所以一个应用即便没有任何单个用户超过其个人限制也能被限流。这是 x-rate-limit-* 头所描述的那一层。

第 2 层：你 X 账号自己的上限。 与开发者 API 限制分开，你应用背后的 X 账号被把来自网页、移动和 API 的动作合起来计的全平台上限约束。一个通过 API 发帖的自动化从与来自一部手机的手动发帖相同的每日预算里支取。如果你的工作流作用于一个账号、而非只读公开数据，一个账号上限能在你的按接口预算仍显示有余地时产生一个 429。

第 3 层：每月使用上限。 自 X 在 2026 年转到按量付费定价以来，标准账号带一个每月 200 万次帖子读取的硬顶。你能舒舒服服地待在每个 15 分钟窗口之内，却仍被阻断，因为每月上限已花光。速率限制控制你调用多快；使用上限控制你每个计费周期消耗多少。两者被分别追踪和强制执行。

下面是如何在几秒内区分这两者：

对读密集的工作，每月上限通常才是你首先撞上的，而不是速率限制。按接口窗口主要对写入、以及仅应用认证上的高并发数据管道，才成为真正的瓶颈。完整的按接口数字、逐池列出，在我们的 X API 速率限制参考里；200 万上限的成本那一面，在我们的 X API 定价拆解里。

即时修法：读重置头并退避 {#the-immediate-fix-read-the-reset-header-and-back-off}

摆脱一个第 1 层速率限制最快的方式，是精确地等窗口所需的时长，而不是一个盲目的固定间隔。每个 X API 响应（包括 429 本身）都携带三个告诉你身处何处的头：

x-rate-limit-limit: 900
x-rate-limit-remaining: 12
x-rate-limit-reset: 1783779300

x-rate-limit-limit 是当前窗口的上限。x-rate-limit-remaining 是你剩下的。x-rate-limit-reset 是窗口何时重开的一个 Unix 时间戳。用当前时间减去那个时间戳，你就精确知道要等多少秒。不涉及猜测。

朴素的恢复是睡固定 15 分钟再重试。这有效，但浪费时间。更好的模式是读重置时间戳、只等那么久，并在头缺失时回退到指数退避：

import time
import requests

def request_with_backoff(url, headers, params=None, max_retries=5):
    delay = 1
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers, params=params, timeout=30)
        if response.status_code != 429:
            response.raise_for_status()
            return response

        reset = response.headers.get("x-rate-limit-reset")
        if reset:
            wait = max(int(reset) - int(time.time()), 1)
        else:
            wait = delay          # 无头：指数退避
            delay *= 2
        print(f"429 hit, waiting {wait}s (attempt {attempt + 1}/{max_retries})")
        time.sleep(wait + 1)      # 越过重置的小缓冲

    raise RuntimeError("Rate limit retries exhausted")

有两条规则比代码更要紧。别即刻重试，因为一个紧凑的重试循环会跨其他接口烧掉你剩余的预算（在仅应用认证上），还能触发更重的限流。而且别在批量数据管道里忽略 429。一个采集循环里的一个 429，可能意味着在你的代码反应之前已有数百次失败请求。所以在每次调用前查 x-rate-limit-remaining，在它降到限制的大约 10% 到 20% 以下时暂停。当你在调试哪种调用模式耗光预算时，一份 x-rate-limit-remaining 的时间序列日志，是最有用的东西。

如何避免 Twitter API 速率限制 {#how-to-avoid-twitter-api-rate-limits}

退避让你熬过当前窗口。真正远离那堵墙，靠的是每单位数据花更少的请求。下面这些动作真正改变了成本账，取自我们团队处理的读密集数据管道迁移。

批量、而非循环单次查找。 X 的批量推文接口在一次调用里接受最多 100 个推文 ID，用户接口接受最多 100 个用户名或 ID，每个都是对着一个更高的批量限制的一次请求，而不是对着一个更紧限制的 100 次单独打击。第三方 API 把这推得更远：我们的批量推文接口每次请求接受 100 个推文 URL 或 ID，我们的批量资料查找接受 100 份资料，每个都算作你配额里的一次单独请求。

缓存慢变数据。 资料元数据、粉丝数和用户名转 ID 解析以天为单位变化，而不是秒。用一个 12 到 24 小时的 TTL 缓存它们，在缓存命中时跳过调用。互动指标动得更快，所以一个 1 到 6 小时的 TTL，对分析是一个合理的平衡。

用游标分页、别重新取。 用响应游标取下一页，而不是重跑原始查询。重跑等于把你已经付过费的同样内容再搜一遍。

能换的地方把轮询换成流式。 每 30 秒轮询近期搜索是对着一个接口每天 2,880 次请求。X 的过滤流则把匹配的帖子推过一个单一持久连接。对没有流式的提供方，在一个固定的每秒限制上快速轮询，覆盖多数实时需要；我们在关于实时 Twitter 监控的指南里更深入那些取舍。

跨认证池拆分。 按应用和按用户限制是独立的，所以用一个 Bearer Token 和一个 OAuth 用户令牌同时认证在支持两者的接口上给你两个桶。这只在服务端有帮助，在一个纯客户端应用里通常做不到。

如果你在读密集的工作上不断撞墙，结构性修法是完全离开窗口模型。一个固定速率限制，移除了在采集数据管道里造成多数 429 的 15 分钟重置，以及按应用对按用户之分。Sorsa 在每个套餐上以固定的每秒 20 次请求服务全部 40 个读取接口，这个限制可为高流量用例通过联系销售提高。

一个付费套餐会移除速率限制吗？ {#does-a-paid-plan-remove-the-rate-limit}

不会。在官方 X API 上，升级抬高上限，但不移除上限。每个层级仍按接口限流，Enterprise 合同（历史上从大约每月 $42,000 起）议定的是更高的窗口和抬高的使用上限，而不是一条无限的路。X 上没有移除速率限制的自助套餐。

如果你在读取上不断撞墙，存在两条结构性路线。一条是给 X 付更多钱换一个更高的上限，这仍把你留在窗口模型和 200 万帖读取每月上限之内。另一条是通过一个不建于固定窗口的第三方 API 读公开 X 数据，这样成本随你拉的东西扩展，而不是撞上一个硬重置悬崖。要看完整的实地对比，见我们对 Twitter API 替代方案的梳理。

具体对读取工作负载，两个模型这样排列：

一次 Sorsa 请求返回最多 100 条推文或最多 200 份资料，这就是那些每 1,000 数字的来源。在读密集的采集上，这折合每次读取比官方按资源定价便宜最高 50 倍，而 15 分钟窗口也完全消失。诚实的取舍是 Sorsa 只读：任何发帖、发私信或点赞的东西仍跑在官方 API 上，因为那是写入的合规路径。我们见到的常见模式，是把写入留在 X 上、把繁重的读取搬到一个按请求计费的提供方，这正是我们的迁移指南走一遍的做法。

其他第三方 API 也移除 X 的窗口上限，但多数是按量计费，而不是固定价。例如，TwitterAPI.io 收大约每 1,000 条推文 $0.15、每 1,000 份资料约 $0.18（2026 年 7 月查）。计量定价杀死固定窗口的 429，但账单仍随量扩展，且不是事先固定的。Sorsa 的固定套餐让月度成本可预测，且每次读取更便宜，从批量接口上每 1,000 条推文 $0.02 起。

实战中：一个不断卡在 429 上的社交聆听团队 {#in-practice-a-social-listening-team-that-kept-stalling-on-429s}

一个中型社交聆听工具（大约十几个工程师）在他们的 X 采集不断在跑到一半时卡住后找到我们。他们在一个紧凑循环上轮询近期搜索，为自己的客户捕捉品牌提及，再扇出到逐作者资料查找。他们弄不明白，为什么一个“每 15 分钟 300 次”的限制不断产生 429。起因是常见的那个：仅应用认证意味着每次搜索和每次资料查找，都从同一个按应用池里支取。光轮询节奏本身，就在扇出还没开始之前花掉了池子的多数。

我们没为他们写任何东西把他们移离官方 API；我们把读密集的采集搬到一个按请求计费的模型，并把轮询换成事件驱动的采集。在按资源定价上，那个读取量正好卡在便宜的按量付费和一份 $42,000 的 Enterprise 合同之间的尴尬地带。他们的读取账单降了超过 90%，而且一旦 15 分钟窗口和按应用对按用户之分不再掺和进来，429 就消失了。他们跑的那种持续品牌提及追踪，正是我们的社交聆听解决方案为之而建的。

常见问题 {#faq}

为什么 Twitter 说“超出速率限制”？

当你在一个设定时间窗口内发的请求多于一个上限允许的，Twitter/X 就显示“超出速率限制”，并阻断那个动作直到窗口重置。对普通用户，触发通常是阅读、滚动、关注或点赞太快。对开发者，它是来自 API 的一个 HTTP 429，其中一个接口的按窗口限制、一个账号上限，或每月使用上限被越过。

一个 Twitter 速率限制持续多久？

多数 Twitter/X 速率限制很短。来自滚动或快速动作的应用内阻断通常在滚动窗口过去后 15 到 60 分钟清除，而每日上限在 UTC 午夜重置。在 API 上，确切的重置时间在 x-rate-limit-reset 响应头里作为一个 Unix 时间戳、通常在 15 分钟外。一个账号上的重复违规能把限制延长到 24 到 72 小时。

你如何避免 Twitter API 速率限制？

关键是每单位数据花更少的请求。用在一次调用里返回最多 100 项的批量接口，而不是循环单次查找。把像资料这样的慢变数据缓存数小时。用游标分页，而不是重跑查询。并偏好流式或快速轮询，而不是紧凑轮询循环。读密集工作的结构性修法，是一个固定的每秒速率限制，而不是 X 的 15 分钟窗口。

一个付费套餐会移除 Twitter 速率限制吗？

不会。升级一个官方 X API 套餐会抬高上限，但从不移除速率限制；每个层级（包括 Enterprise）仍在一个 200 万帖读取每月上限之下按接口限流。一个像 Sorsa API 这样的只读替代方案，用每个套餐固定的每秒 20 次请求替换窗口模型，从批量接口上每 1,000 条推文 $0.02 起，这是移除 429，而不是抬高它。

X API 速率限制是按用户还是按应用？

两者都是，取决于接口和你的认证。Bearer Token 认证用按应用限制，其中来自你应用的每次请求共享一个池，所以一个应用即便没有单个用户超过其限制也能被限流。OAuth 用户令牌认证用按用户限制，其中每个已认证用户得到一个独立桶。许多接口公布两个数字。

为什么几乎没发什么请求就被限速了？

通常是三件事之一。上限既按应用也按用户，所以你的用户合起来超过了应用范围的限制。或你调用的接口有一个比你预期更紧的限制，所以查那个具体数字，而不是一个头条数字。又或者一个后台进程、一个被遗忘的脚本，或你的每月使用上限才是真正的起因。在每次调用上记录 x-rate-limit-remaining，让它显形。

开始上手

如果上面的 429 和 15 分钟窗口正是你试图摆脱的问题，感受差别最快的方式是自己跑几次调用。我们的交互式 playground在浏览器里执行实时接口、无需密钥也无需注册，所以你能在投入任何东西之前查响应形状。当你准备好构建时，Sorsa API 快速上手用请求头里一个单个 API 密钥认证你。每个新账号注册即送 100 次免费请求：一次性、无需绑卡、永不过期、在全部 40 个接口上有效，足够通过批量接口取最多 1 万条推文或 2 万份资料。超过那个，定价从批量接口上每 1,000 条推文 $0.02 起，套餐从每月 $49 起，以固定的每秒 20 次请求运行。没有应用审核、没有 OAuth 握手，也没有要记在脑子里的速率限制表。

审校：Keksich（Sorsa 创始人，X API 研究者）

本指南是如何汇成的：429 格式、x-rate-limit-* 头和按接口窗口行为对照 X 的官方速率限制文档核验，而应用内阅读上限对照 X 发布的限制指引和当前账号测试核验，全都在 2026 年 7 月 11 日，因为这些数字不太打招呼就变。三层诊断、感知重置的恢复代码和吞吐框定，来自我们自己运营一个替代性 Twitter/X API 的工作，以及我们团队处理的读密集数据管道迁移，包括上面匿名化的社交聆听案例（细节已合并、剥除任何可识别信息）。定价和使用上限数字从我们单独的 X API 定价报道里概括；竞品价格在 2026 年 7 月于源头查核。关于我们是谁以及如何联系我们，见关于 Sorsa。这里没有统计、来源或客户结果是虚构的。