以太坊节点常见错误：同步失败、内存暴涨与RPC异常的系统化排查思路

节点跑久了，总会遇到各种各样的错误。本以太坊节点常见错误手册把笔者多年运维中遇到过的高频问题分类整理，并给出系统化的排查思路。这些经验同样适用于BSC、Arbitrum、Optimism等以太坊兼容链。

一、同步失败的几种典型场景

第一类：peer数过低，节点找不到足够对端，同步进度卡死。修复思路是检查防火墙是否阻塞了30303端口，或者更换bootnode列表。第二类：磁盘IO跟不上，导致每次写block都超时。建议检查iostat指标，必要时换NVMe SSD。第三类：客户端版本与网络硬分叉不兼容，必须升级到最新版本。

如果你刚部署完节点，建议先按 以太坊节点开发教程 中提到的检查清单核对一次环境，再回到本节排错。

二、内存暴涨与OOM

Geth与Erigon在高峰期都可能出现内存暴涨。常见原因有三类：第一，缓存配置过大，例如 --cache 设置超过实际可用内存；第二，归档节点开启了完整trace，导致大量历史数据被加载；第三，第三方RPC调用方写了无界查询，例如 eth_getLogs 不带区块上下限。

排查时建议结合 pprof 或者 perf 抓火焰图，定位真正吃内存的代码路径。对面向外部用户的RPC，必须做严格的参数校验，禁止「按地址全量拉取」这类高危查询。

三、RPC异常与超时

RPC异常的常见表现是请求间歇性返回 500 或者超时。排查路径：第一步检查反向代理（Nginx/Caddy）日志，看是否有连接被截断；第二步检查节点本地metrics，看响应队列是否堆积；第三步检查上游业务，看是否存在突发的大量调用。

对于面向币安等中心化交易所的对接场景，可以参考 Binance合约交易怎么玩 中提到的资金费率监控逻辑，把链上RPC健康度与CEX侧的撮合状态做联合监控，避免出现「单点故障引发整体策略停摆」。

四、磁盘写放大与性能退化

节点跑半年后，磁盘空间使用上升属于正常，但如果发现写放大系数突然变大，IOPS急剧上升，则需要警惕。常见原因包括：未启用TRIM、文件系统碎片严重、客户端版本存在已知的存储bug。

修复路径通常是：先备份数据目录，再做一次离线压缩与重建。Erigon自带 erigon snapshots 工具，可以把历史快照压缩到只读卷，腾出空间给新数据。重建之后请按 以太坊节点是什么 中提到的节点分类，确认自己使用的是合适的节点类型，避免过度配置。

五、JWT与共识层通信错误

The Merge之后，最常被忽视的错误来自Engine API的JWT校验。常见表现是执行层日志里反复出现 unauthorized，或者共识层日志里出现 Engine call failed。修复思路是：检查执行层与共识层是否使用同一份jwt.hex，检查文件权限是否只对节点用户开放，检查执行层启动参数是否包含 --authrpc.jwtsecret。

如果你的项目使用了Rollup，类似的鉴权机制也存在于Sequencer与L1之间的消息通道。理解了主网的JWT配置，再去看 Rollup是什么 中的鉴权部分，会感觉熟悉很多。

本以太坊节点常见错误手册并非穷举，而是给出一份「面对错误如何系统排查」的方法论。把这套方法论内化，遇到新的、没见过的错误时也能从容应对。最关键的一条始终是：先看日志、再看指标、最后看配置，不要绕过这条顺序。