Back to Blog

Recovering a Blocked Server

Records en-US
Table of Contents
Table of Contents

Recovering from a Block

The Night I Brought the Server Down 🌙

Late at night, I decided to deploy RSSHub.
The reason was simply that AO3's built-in RSS feed was too strange… I wanted a more convenient way to subscribe, with some tag filtering so I wouldn't have to weed out odd tags by hand every day. I'd heard RSSHub let you build your own feeds, and started without a second thought.
The tinkering never stops, after all...
Without thinking much, I ran the official docker-compose configuration. Containers came down one by one, the Chrome browser environment and Redis were all deployed, and I was quite pleased. Surely I'd be connecting my own feeds soon…
One moment, I was marveling at how big RSSHub was, how long all those services took to download, and how poor this machine's connection was—an Error just from pulling an image…

The next moment, the server disconnected.

At first, I thought it was a random drop. But ping failed, SSH wouldn't connect, and everything running on it stopped working. I opened the domains for my deployed services: image hosting, monitoring, all the little services were down. 🫠 I began to realize this wasn't a small problem.
I asked what might have caused it:

Once the RSSHub containers started, they scraped content aggressively and exhausted the Oracle free instance's bandwidth or network resources. Oracle's free machines are very sensitive to outbound bandwidth use…

So it wasn't a random disconnect or my own bad connection. The server itself had had its outbound bandwidth blocked…

Trying to Fix It, and Failing ⚠️

I hadn't registered this machine myself. Dad had been playing with servers and given me one of his free Oracle VPS instances. I didn't have full control, only the account, port, and password. Without SSH, I could do nothing… All I could do was message him in the middle of the night and ask whether he could restart it.

Dad said Oracle's stock system had monitoring software installed. The image downloads had probably used too much bandwidth, been flagged as abnormal, and had their outbound access cut off. His server-monitoring system also showed that the machine had gone offline… SSH was unreachable, and all the containers were stuck.
There was nothing I could do at my end. I had to rely on Dad to restart it manually from Oracle's console—and got a thorough grilling in the process 😭. Thankfully, after an anxious wait, the server came back. But that wasn't the end. I cleaned up Docker and restarted the services, then tried to log into the website monitor. Still couldn't get in…

The Reverse Proxy Stops Working 🧩

My domain points to a VPS in Singapore, running a reverse proxy through Nginx Proxy Manager. Its upstream is this Oracle server's public IP. In theory, after restarting restored outbound connectivity and the services, the domain should have worked too.
But I found:
The domain still wouldn't open. The services still threw errors.
In a panic, I tried pinging the domains. Nothing…
In desperation, I went onto the VPS and reflexively used curl on ip.sb—that site really is easy to remember—and found that the returned IP was IPv6…
Then it hit me: the problem was the outbound connection.

What WARP Did 🌐

I asked, and learned that Dad had enabled WARP as a global proxy on the Oracle machine. After the reboot, it had all started automatically…
All outbound traffic went through WARP, causing trouble with the reverse proxy. Maybe it was a habit of his, for proxying traffic and unblocking streaming services. But it caused a huge headache.

All my NPM reverse proxies pointed directly to public IPs. Once WARP took over, those public-IP proxy routes stopped working… With WARP enabled, all the server's traffic passed through its proxy, and external requests couldn't reach the original IP.

After WARP forwarding:
The VPS initiates outbound connections, but doesn't correctly respond to connections initiated from outside.
The reverse proxy actively connects to Oracle's public IP → the Oracle VPS has actually bypassed that public route through WARP, so the response packets don't come back.

That also explained why the services I'd set up ran normally locally, yet couldn't be reached from outside.

Turning to Tailscale ✅

If I couldn't connect over the public network, an internal network was my only option.
I immediately remembered Tailscale. Just join the internal tailnet. I use it for remote desktop every day, and it works so well…
The final solution was:
Keep WARP, but reconnect through Tailscale, changing the proxy's upstream to the internal Tailscale IP.
This time, the services recovered quickly and stayed stable. They were even noticeably faster than before.
Most websites on that server are currently reverse-proxied through another machine—mainly because Nginx Proxy Manager is so handy. Replacing direct public-network forwarding with forwarding between internal IPs seems to cut website latency quite a bit… 🤔

A Little Detour 🛜

After getting my website monitor back, I discovered that DNS resolution was failing for all my sites, with the same error each time.

I spent ages investigating the host's DNS, which was completely fine. While scratching my head, I suddenly remembered that all my services ran in Docker...
I went into the container to check the service's reslov.conf. Sure enough, only 127.0.0.11 remained. All the DNS settings were gone.

I added DNS settings to docker-compose.yml, ran down and then up, and everything returned to normal.
Can WARP forwarding affect the DNS inside my Docker containers too? Amazing. 😑

Afterword 📝

The first time I broke a server was at two in the morning, deploying a little service I thought couldn't possibly cause trouble. The whole machine went offline, the websites went down, and I couldn't reach the console. I had to rely on someone restarting it remotely…
At least it wasn't my most important server.
If it had been the one hosting my blog—this very site—I might have crashed before the server did. 😵‍💫

A reminder, I suppose.

0 / 2000
Loading comments...