HH108 'Cannot connect to the network' when Hardhat Network forks mainnet after pinning an old blockNumber

Answer the core question first

The HH108 error is a generic “cannot complete the initial JSON‑RPC handshake” failure. It does not distinguish between a network outage and a non‑archive node that no longer stores the requested block. To know which one is happening, you must query the endpoint directly.

Step 1 – Probe the upstream node

Run a raw JSON‑RPC request against the same URL you configured in networks.hardhat.forking:

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["0x{blockNumber}",false]}' \
  http://YOUR_ENDPOINT

Replace {blockNumber} with the hex value you pinned. Interpret the result:

• HTTP 200 + block object – the node still serves that block; the HH108 was a transient network glitch.
• HTTP 200 + null / “missing trie node” error – the node has pruned that block; you need an archive node or a newer pin.
• HTTP 5xx / timeout / DNS error – connectivity problem; check your network, firewall, or API key.

Step 2 – Understand hardhat_reset

hardhat_reset is a Hardhat‑specific JSON‑RPC method that re‑initialises the in‑memory fork state (accounts, pending txs, snapshots). It does not delete the on‑disk fork cache that Hardhat keeps under ./.hardhat/cache (or the platform‑specific cache directory). Changing the fork configuration (URL or blockNumber) automatically invalidates the relevant cache key, but if you suspect corruption you should delete the cache folder manually:

rm -rf .hardhat/cache

After clearing the cache, the next hardhat_reset will fetch fresh state from the upstream node.

Step 3 – Is blockNumber pinning the right strategy?

Pinning a block number is the recommended way to get deterministic forks across runs. Without a pin, each Hardhat session forks from the latest block and test results drift as the chain advances, which is problematic in CI pipelines. However, pinning works only if the upstream endpoint can serve that historical state—i.e., it must be an archive node. If you must fork from a months‑old block, use a provider that offers archive access (e.g., Alchemy, Infura archive tier). Otherwise, the fork will fail with HH108 or return null for the block, as you’ve observed.

Missing diagnostic detail

To refine the recommendation, it would help to know: Which RPC provider and tier are you using for the url? If it’s a free tier that keeps only the last few weeks, that explains the failure. If it’s an archive tier, a different issue (e.g., cache corruption) is likely.