Why Does Ethereum Sync Stall? Common Issues and Fixes

Common Ethereum Sync Issues

Ethereum data synchronization is a necessary step for newcomers, and many users repeatedly encounter similar problems. The following FAQ collects the most common questions and provides practical solutions.

Blocks lag by dozens and never finish syncing

The node has only downloaded block headers, so the remaining blocks appear as a long wait. The only solutions are to be patient or upgrade hardware and restart the sync.

Sync stuck at 99%

This is the same situation as the previous question; the display differs but the underlying cause is identical.

How to check sync status

Enter the console and run the eth_syncing command. If the result is false, the node is not syncing. Otherwise you will see a JSON‑like object, for example:

{
  "currentBlock": 290584, // current block height
  "highestBlock": 891836, // highest known block on the network
  "pulledStates": 361434,
  "startingBlock": 0
}

Wait until knownStates reaches its maximum, which can be in the billions.

Why does eth.blockNumber return 0?

When the blockchain is not fully synchronized, the block height query returns 0 because the node has not yet processed any blocks.

Why is the account balance zero?

If a transaction has not been synced, the local node reports a zero or incorrect balance for the affected address. Use the command:

eth.getBalance("0x8b275d360a5d435e9dfcf27d610362ee2fdf460c")

How much data is synced in total?

With the default fast‑sync mode, a fully synced node stores roughly 150 GB of data. The exact size depends on the sync mode and whether the node was restarted during sync.

Which sync mode should I use?

Most users should stick with the default fast‑sync mode. The full mode downloads the entire state and takes much longer and requires more storage.

How to speed up syncing

Ensure sufficient network bandwidth.

Use a fast SSD (or at least a high‑speed HDD).

Connect to many active peers.

Increase the cache size, e.g., --cache 256 (default is 128 MB, minimum 16 MB).

Recommended hardware for stable sync

A configuration of at least 2 CPU cores, 4 GB RAM, 2 Mbit/s bandwidth, and a 500 GB SSD is the minimum; adding swap space helps avoid OOM kills. Cloud servers can use a 100 Mbit/s plan paid by traffic.

Typical warning logs

WARN [03-17|16:16:34] Synchronisation failed, retrying err="block download canceled (requested)"
WARN [03-17|16:19:04] Synchronisation failed, dropping peer = 97685428ba8e71a0 err=timeout
...

When such warnings appear, consider restarting the node or manually adding reliable peers.

How to view and add peers

Check the current peer count: net.peerCount Add a new peer (replace the enode URL with a reachable node):

admin.addPeer("enode://0d1b9eed7afe2d5878d5d8a4c2066b600a3bcac2e5730586421af224e93a58cd03cac75bf0b2a62fd8049cd3692a085758cc1e407c8b2c94bb069814a5e8d0f0@209.9.106.245:30303")

Common Ethereum block explorers

https://etherscan.io/

https://block.bitbank.com/eth/

How long does a full sync take?

On a high‑end machine the process finishes in about 24 hours; on modest hardware it may take several days or even weeks.

What normal sync logs look like

INFO [03-17|17:02:57] Imported new chain segment = 1 txs = 380 mgas = 7.980 elapsed = 45.080s mgasps = 0.177 number = 5235156 hash = 7c7414…
INFO [03-17|17:03:42] Imported new chain segment = 1 txs = 379 mgas = 7.978 elapsed = 45.242s mgasps = 0.176 number = 5235157 hash = eb9541…
...

When the node is still downloading state entries, logs show entries like:

INFO [06-18|10:10:34] Imported new state entries count = 384 elapsed = 131.007ms processed = 17120103 pending = 23855

These logs indicate normal progress, whereas repeated WARN messages point to connectivity or timeout issues.