Spreading a blockchain node across three continents (and a subtle networking lesson along the way)
A solo blockchain project I've been building had a real, honest weakness: every piece of its public infrastructure ultimately depended on one home internet connection staying up. A recent multi-hour outage made that weakness concrete rather than theoretical — the fix needed to be real infrastructure, not just a plan.
The real goal
Independent, fully-synced nodes on separate continents, separate power grids, separate providers — so no single regional failure could stop the network.
What that actually took
Setting up a second cloud server in a new region was the easy part — provision, install the toolchain, transfer a database snapshot, build, and let it catch up over the peer-to-peer network. Within minutes of starting, a fresh node on a different continent was fully synchronized and correctly validating new blocks in real time.
The genuinely interesting part came from something adjacent: an attempt to also relocate a mining pool's coordination service onto one of these new servers, alongside its node.
The subtle bug that surfaced
The pool needed to be reachable on a specific, non-standard port. The DNS setup in front of it was a reverse proxy service that — like many such services on their free tiers — only forwards standard web ports (80/443) through its proxy layer. A custom port like this one needed a direct, unproxied DNS record instead.
That part was a straightforward fix. What wasn't straightforward: client software (a mining program) that connects to this same infrastructure had, for good historical reasons, been written with an assumption baked in — any real public domain name should be reached over an encrypted connection on port 443, since that's how the main service had always worked. The client code quietly ignored whatever port a user actually typed for any non-local address, always substituting 443 instead.
This had been completely correct and invisible for the main, original service. It became a real, confusing failure only once a second service, on the same broader infrastructure, needed a genuinely different connection pattern — a real domain name, but a specific non-standard port, without a proxy in between at all.
The actual lesson
Assumptions that are true for 100% of existing use cases are exactly the ones most likely to break silently the moment a new use case comes along that doesn't fit the same shape — and they tend to break in ways that look like a completely unrelated problem (a DNS setting, in this case) until you actually trace the connection logic itself.
The honest fix here wasn't glamorous: a small, explicit check for the specific known port that legitimately needs the proxy-and-encryption path, with everything else falling through to a direct connection using whatever port was actually given. Small, targeted, and — importantly — verified against the one existing use case that absolutely could not be allowed to break in the process.
Where things landed
The core multi-continent node deployment is live and proven. The pool-specific migration got rolled back for the day once the networking assumption above surfaced mid-flight — a deliberate choice to return to a known-good state rather than push a partially-diagnosed fix live, with a plan to finish it properly, tested in isolation, another day.
Sometimes the right engineering call is finishing the fix. Sometimes it's recognizing you've found a real, interesting problem worth solving carefully rather than in a hurry.
SOCIAL SHARE CARD GENERATOR