Thirty minutes after going public, my server logs looked like a crime scene.

Thirty minutes after going public, my server logs looked like a crime scene. I deployed to Railway and panicked. WordPress bots, phishing kit scanners, ID enumeration — and then the real problem hit.

It was DNS all along.

I Thought My Server Was Hacked. It Wasn’t.
I recently deployed my FastAPI backend to Railway (Paid Tier). The dashboard was green, the deployment was successful, and everything looked perfect. Then I opened the server logs.

I saw a flood of requests for paths I never created. There were .php files hitting a Python app and weird strings like sberchat.

Mar 19 2026 17:56:41   GET   /blogs/by/wp-admin/setup-config.php        404   696ms
Mar 19 2026 17:59:52   GET   /blogs/by/wordpress/wp-admin               404   966ms
Mar 19 2026 17:59:52   GET   /store/public/by/wordpress                 404   990ms
Mar 19 2026 17:59:52   GET   /posts/by/wordpress/wp-admin/setup-config  404   1s
What Was Actually Happening?
After the initial panic, I realized these weren't targeted attacks.

WordPress & PHP Scanners: Bots scan every public IP constantly. Since I’m running FastAPI (Python), my server returned a 404, and the bot moved on. This is pure background noise.

"Sberchat" TDS Probes: These bots are looking for their own phishing kits that might already be installed on compromised servers.

Account Enumeration: A crawler was brute-forcing random IDs against my /accounts/public/{id} endpoint. A solid reminder to implement rate limiting using Redis.

The Plot Twist: The Invisible Problem
While I was investigating these "hackers," I tried to log into my own app using my Mobile Hotspot. That’s when I saw the actual issue in the browser console: ERR_NAME_NOT_RESOLVED.

DNS: The Hidden Culprit
The Railway dashboard was green. The logs showed the bots were hitting the server fine. But my carrier's DNS had a stale cache entry.

The Fix:
I switched my active network interface to use Google’s DNS: