“主网上线还有两周，RPC 一直报 429”——节点服务商看到这句话，先别急着报价

判断时关注的线索

• 主网上线日期已经出现
• 429 限流影响测试
• 消息提到备用 RPC 或小流量测试

本文为模拟复合场景，文中消息、数字、期限和业务情形均为典型化表达，不代表真实客户、真实群聊、合同或实际成效。

周三下午，节点服务商销售林序把技术售前下周的档期又过了一遍：两场老客户的扩容评估，一场新客户的多链对比测试，已经排满。最近几天，他跟进的一条链的社区里不断有人提到 RPC 接口报 429，测试网和主网的公告下面都有类似的声音。他现在的处境是：客户的耐心窗口很短，技术售前的档期更短，他必须做一个判断——这条 429 的消息流，是项目方的一次临时限流排查，还是他们正在为主网上线评估备用节点供应商。这个判断决定他下周一上班的第一件事，是重新排档期，还是继续做客户回访。

429 只说明请求被拦下，说明不了节点商不行

先拆开 429 这个错误码。

RPC（Remote Procedure Call，远程过程调用）是节点服务商提供给开发者的接口，应用通过它读取链上数据、发送交易。429 是 HTTP 状态码里表示 Too Many Requests（请求过多）的一种，含义是服务端在单位时间内收到的请求超过了设定阈值，把超出的部分直接拒绝。这个阈值通常由节点服务商自己配置，也可能设在负载均衡或防火墙那一层。换句话说，429 只能说明请求被拦下了，它没有说清楚阈值是谁设的、设了多少、超了多少。看到 429 就断定“现有节点商不行”，等于跳过了拆解错误码这一步。

限流（rate limiting，限制单位时间内的请求次数）是节点服务商的常规保护：防止某个用户的高频请求拖垮公共接口，也防攻击流量。项目方如果接的是免费公共节点，429 几乎是日常。所以销售面对 429 的第一个动作不是准备报价，而是弄清楚这是谁的限流、限在哪一层。动手之前，还需要先分清报错发生在测试网（上线前用来验证的网络）还是主网（正式运行、承载真实资产的网络），两者的请求特征和采购逻辑完全不同。

抱怨来自谁，决定这条消息值不值得回

林序没有直接回复，而是先追溯消息的源头——看抱怨出自谁。Telegram 群里他通常能看到两类消息（本文中的群消息、时间线与期限均为复合示意，用于说明判断过程，不代表真实客户或实际成效）。

一类来自项目方运维账号，比如“RPC 429 持续出现，API key 已经升到最高档还是被限”。这句里最有分量的是“API key 升到最高档”：API key 是调用接口时的身份凭证，不同档位对应不同的请求额度，这句话说明对方已经是某家节点服务商的付费客户，用量正在触顶，存在真实的容量缺口。另一类来自普通社区用户，比如“公共 RPC 又 429 了，烦”，底下没有人接话，项目方也没有回应。

区分这两类，是销售判断的第一步。群里能看见的证据包括：抱怨来自项目方账号还是普通用户；消息里有没有提到套餐、key 档位或请求量；有没有人跟进，跟进的是谁。仍然未知的是：对方实际的请求峰值、请求主要来自哪个地区、现有套餐是否真的触顶、以及他们是否已经在测试别家。这些信息不会自己出现在群里，需要销售去问。

如果抱怨值得追溯，林序会把他有权限查看的 Telegram 群里关于这条链的消息按时间收拢，去掉重复转发，保留原始消息、来源和上下文，再排成时间线。Top商业线索做的是这一层：只处理他主动连接、有权访问的群，不读取私人聊天，也不自动联系群里的任何人；它给出的分类和优先级只供人工核实，判断这单值不值得跟，仍然由林序和技术售前完成。这样他能看到抱怨从哪天开始、频率有没有上升、有没有人已经回复过，而不是凭印象觉得“好像很多人提过 429”。

第一次回复只问五件事，不报价

如果林序判断值得跟进，他的第一次回复会保持克制。一条示例（非真实对话）：“看到群里聊到 RPC 429，想先确认几个情况：报错主要出现在测试网还是主网？请求峰值大概在什么时段、集中在哪些地区？现在用的是哪家、什么档位的套餐？按你们的时间表，什么时候需要结论？方便的话，我们可以安排一次针对你们请求特征的限流评估，先不涉及报价。”

这五件事——目标链和网络、请求峰值与时段、请求地区、现有套餐档位、测试期限——是后续判断的地基。地区决定节点就近部署的位置，峰值决定套餐档位是否够用，测试期限决定技术售前的档期怎么排。报价应该放在这些答案之后，而不是之前。

三个条件同时出现，才值得调动技术售前

单个 429 抱怨不值得占用技术售前。以下三个条件同时出现时，才值得把档期调出来：抱怨来自项目方自己的账号，而不是普通用户；消息里明确提到现有节点商、套餐档位或请求量，说明对方已经在用付费服务并接近上限；抱怨不是一次性事件，而是持续了几天，同时主网或重要版本的上线日期就在眼前。

“主网上线还有两周”是这里最容易被误读的期限。上线前的容量评估和备用节点测试是常见的采购动作，这确实是窗口，但也是一个容易扑空的窗口——很多项目方在评估阶段只收集数据，预算和决策还没有落地。技术售前介入的目标，是拿到对方的请求特征和测试环境，做一次针对性的限流评估，而不是带着报价单上门。

应该放弃的假线索

有些 429 看起来像机会，跟进反而浪费档期。节点服务商官方账号在频道里发布限流阈值调整公告，随后有人跟帖抱怨，这是公告引发的讨论，不是采购信号；公共节点在遭受攻击后的恢复期出现 429，属于临时事件，过去就没了；群里只有一条孤零零的抱怨，没有时间线、没有后续、也没有人响应，说明不了任何采购意图。这些情况下，不跟，但把消息记下来作为观察样本，如果一周后出现来自项目方的新抱怨，再重新评估。

错误码会继续出现，销售要做的是在 429 出现时先拆开它：谁在限流、限在哪一层、抱怨来自谁、还缺哪些信息。把这些问清楚，主网上线前的两周，技术售前的档期才不会花在假线索上。