私有捆绑调试：常见故障模式

简短回答 — 未进入下一个区块的私人捆绑包已错过包含。包含未命中有两种情况：被中继拒绝（中继拒绝将您的包转发给构建器）和被构建器拒绝（中继转发它，没有构建器包含它）。第一种有明确的错误响应；第二种是沉默。八个最常见的原因，大致按照您应该检查的顺序排列：过时的费用模型、提示不匹配（例如忘记了 revertingTxHashes）、模拟和发送之间的模拟漂移、目标块滑动、中继延迟、构建器速率限制、有效负载编码错误和完全构建器覆盖差距。每个在您的日志中都有一个独特的签名。下面的诊断树根据您实际看到的内容告诉您要怀疑哪些内容，而不是猜测。

精通之路

• 什么是 MEV？
• Backrun vs 三明治策略
• 包含概率 101
• 修复失败的捆绑包指南
• 私人捆绑调试（当前）

“包裹未落地”实际上告诉您什么

私人捆绑包的接收路径为：

1. 您的客户端序列化捆绑包并将其发送到中继（relay.flashbots.net、rpc.titanbuilder.xyz 等）。
2. 中继验证模式，运行模拟，然后转发给参与的构建者。
3. 如果您的捆绑包将其区块价值提高到高于次佳替代方案，则构建者会包含您的捆绑包。
4. 提议者发布他们获得最高报酬的建筑块。

失败可能发生在第 2 步（明显——中继返回错误）、第 3 步（大多无声——中继接受了，但没有构建器包含）或第 4 步（无声——赢得位置的是别的构建器）。大多数运营者看到"捆绑包未落地"就认为原因是单一的。但几乎从来不是这样。

八种故障模式

1.过时的收费模式

症状： 模拟器显示捆绑包有利可图，中继接受，没有构建器包含。

原因： 在模拟和发送之间，基本费用发生了足够大的变化，以至于您的优先费用不再具有竞争力。

**修复：**在签署捆绑包之前立即重新查询 eth_feeHistory ；如果签名时的费用与模拟的费用差异超过配置的阈值，则拒绝。在 Polygon 和繁忙的主网时段，单个区块内的费用可能会变化 20-30%。

2.提示不匹配

症状： 中继返回 400 /“无效提示”/“不支持的参数”。

原因： 您发送了中继不支持的提示，或者忘记了中继所需的提示。常见违规者：revertingTxHashes 对于可能恢复的交易； minTimestamp / maxTimestamp; replacementUuid 用于重新提交。

**修复：**检查中继的文档架构以了解您要定位的版本。大多数中继默默地接受额外的字段；有些人拒绝。在部署之前，在每个中继上使用金丝雀包进行测试。

3.模拟漂移

症状： 模拟器呈绿色，真实发送在包含时恢复。

原因： eth_callBundle 模拟和实际块之间的状态发生了变化。在 DEX 逆运行中常见：池价格变动，您模拟的价格不再是当前价格。

**修复：**应针对目标区块的预期状态进行模拟，而不是当前区块头。对于 12 秒的主网时隙，这意味着先获取当前状态，在模拟中应用触发交易，然后再叠加你的回程交易。如果你的模拟没有对触发交易建模，那么模拟结果就是在骗你。

4.目标块滑点

症状： 捆绑包被接受，比目标晚了一个区块，利润大大低于模拟。

原因： 您的捆绑包有一个目标块，但中继或构建器将其推回。当提议者占用不同的构建器块时，通常会在高需求时段发生。

修复： 设置一个紧的 targetBlockNumber 和一个 maxBlockNumber ，仅向前一两个块。错过总比晚到且价格更差好。有些策略仅限于第一个块——显式编码。

5.中继延迟

**症状：**与一天中的时间相关；捆绑包丢失集中在延迟最严重的时段。

原因： 中继的 RTT 足够高，以至于您的捆绑包在构建器已经锁定块之后到达。

修复： 测量您使用的每个中继的 p95 RTT。主网上任何超过 150 毫秒的事情都是值得怀疑的；超过约 300 毫秒已损坏。将发件人移近（不同区域、不同云提供商）或切换中继。定期运行 WSS 延迟测试。

6.构建器速率限制

症状： 429 Too Many Requests、503 Service Unavailable 或静默下降到特定速率以上。

原因： 您超出了中继的速率限制。免费等级上限大幅提高；甚至付费等级对每秒捆绑提交率也有上限。

**修复：**检查您的层限制，如果您的策略每秒生成许多候选者，请检查批量提交，并在 429 上彻底退出。如果您确实需要更多速率，请升级或跨多个中继进行扇出以实现自然速率分配。

7.负载编码错误

症状： 中继返回“无效捆绑”、“格式错误的交易”或 422。

原因： RLP 编码错误、缺少 chainId、EIP-1559 与旧版不匹配、签名格式错误。

修复： 使用新工具（例如 cast tx --decode）解码序列化包并与您的预期进行比较。常见问题：复制粘贴教程中的代码后使用错误的 chainId 进行签名。另外：某些中继仅需要 2 类 (EIP-1559)；遗留的交易会被默默地丢弃。

8. 构建器覆盖范围差距

症状： 捆绑包被中继接受，但没有构建器包含它，且无特定错误。

原因： 您提交的中继所对接的构建器，没有赢得下一个区块的提议权。单中继提交在每个区块上都存在这种风险。

修复： 扇出至至少四个构建器（Flashbots、Titan、beaverbuild、rsync-builder 是现代默认设置）。跟踪哪个中继成功发送了每个捆绑包；随着时间的推移，将你的扇出权重转向获胜者。 FRB Agent 自动执行此扇出和权重调整。

诊断流程

当捆绑包丢失时，请按以下顺序遍历流程：

1、中继是否返回错误？→检查错误码；映射到故障模式 2、6 或 7。 2. 没有中继错误，没有包含？ → 根据实际挖掘的块检查 eth_callBundle 重新模拟。如果 sim 现在显示恢复 → 模式 3（漂移）。如果 sim 说有利润，但你不包括在内 → 模式 1、4 或 8。 3. 失败捆绑包的延迟直方图。 → 如果 p95 延迟升高 → 模式 5。 4. 最后 N 个捆绑包中中继的包含率。 → 如果一个中继的比率已崩溃 → 模式 8（该中继的构建器覆盖范围已下降）。

记录什么以便可以进行调试

• 捆绑包提交时间戳 + 中继 + 层
• 模拟利润（模拟哈希+结果）
• 目标块+最大块
• 中继响应（状态代码+正文摘录）
• 纳入结果：是否被纳入？在哪个区块？支付了多少 Gas？实现了多少利润？
• 延迟：从本地“决定发送”→中继接受→区块开采的时间

这足以填充每日包含率按原因仪表板。大多数“FRB 不工作”票证在针对完整日志集的一次查询中得到解决。

何时修复策略与基础设施

模拟利润和实际利润之间的持续差距（>10%，持续几天）是一个“策略”问题——模型在某些方面是错误的。提交的捆绑包和包含的捆绑包之间的一致差距（包含率低于 60%，而策略预计包含率超过 80%）是一个“基础设施”问题——中继覆盖范围、延迟或费用模型。

上面的诊断流程会告诉您应该先查看哪一侧。先看错了方向，正是许多运营者花费数周调优一个根本没问题的策略的原因。

相关阅读

• 修复失败的捆绑包指南
• 包含概率 101
• 最佳以太坊私有 RPC