同步不只是下载一份越来越大的文件
区块链节点同步，是让本地客户端跟上对应网络的有效记录和状态。过程中既要接收数据，也要进行相应验证和整理；不同客户端、模式与网络设计，会采用不同实现。
以Geth为例，同步涉及区块头、区块体、回执和状态数据。下载量很大却暂时查不到最新余额，不一定意味着文件丢失，也可能仍在构建或修复当前状态。应先看它正在完成哪一阶段。
以太坊还要看两个客户端是否配合
当前以太坊节点通常由执行客户端与共识客户端协作。执行端处理交易执行及状态，共识端提供链进展相关信息。只启动Geth或只看到一个端口能够连接，不足以证明完整节点已经正常工作。
核对时需要分别查看两端日志、连接情况和同步状态，并确认它们配置的是同一网络。接口能够返回一个结果，只说明服务有所响应；这个结果是否足够新，还要进一步检查。
区块高度接近，也可能还在追赶状态
Geth的快照同步会下载并验证相关数据，重建状态后还可能进入状态修复阶段。与此同时，网络仍持续产生新数据，所以“还剩多少”不是一个从开始就固定不变的数字。
官方文档说明，状态修复阶段很难给出可靠的总进度百分比。不要因为某个估算时间停住，就立即删除数据库重来；先判断日志是否继续推进，以及磁盘读写、网络传输等条件是否成为瓶颈。
用多项证据判断是否适合提供查询
较稳妥的判断包括：客户端报告同步完成，最新区块时间没有明显落后，共识与执行端状态正常，并且连续几次只读查询能随新区块更新。单看对等节点数量或进程存活，容易漏掉数据停滞。
对外提供数据时，还应说明本地保存范围。裁剪节点、归档节点的历史状态查询能力不同，查不到很久以前的某项状态，不必然等于当前同步失败。请求范围应与节点用途匹配。
排查先保留现场，再改变配置
发现落后时，可以先记下时间、网络、客户端版本、同步状态及日志错误，再对照官方文档排查。不要把含有访问凭据的完整配置随意公开，也不要为了加快同步关闭必要验证。
同步速度受实际数据规模、硬件与连接条件影响，不能仅凭核心数承诺固定完成时间。把“程序运行”“数据追平”“历史查询可用”分成三个验收目标，通常比反复重启更容易找到真正的问题。