A month ago I launched a small site that tries to answer one question: which VPN actually works on my mobile carrier right now.
People vote, the votes go into a public table, and that's basically the whole product.
The reason I built it is dumb. My wife uses MegaFon, I use MTS. We bought the same VPN. It works for her, it works for me half the
time, and the company's support told me to restart my phone. After a few weeks of this, I realized that the question "is this VPN
any good" has stopped meaning anything in 2026. The right question is "is this VPN good on my specific carrier in my specific city
this week", and nobody answers that.
So I built a place where people answer it for each other. Live votes, no five-star reviews, just three options: works, partially
works, broken. With the carrier name attached.
The site is one month old. The first month was very educational and I want to share what I learned, because none of it is in any
tutorial.
You will move VDS providers at least once
The first hosting I used was a generic budget VPS. The IP was clean as far as my domain was concerned, but the same provider hosted
a long list of sites that were already in the national banned-domains registry. Pirate streaming, fake forex, the usual.
This is not directly your problem. Until it is. Russian network filtering sometimes escalates from per-domain to per-IP blocking
when one of the banned neighbors does something clever (encrypted handshakes, redirect tricks). When that happens, everyone on the
same subnet goes down at once. Your perfectly legal site is collateral damage.
I migrated to a different provider before I got swept up in this, but I almost waited too long. The lesson is: when you pick hosting
for a project that lives in a region with infrastructure-level censorship, check who your neighbors are. There are free tools that
list other domains on a given IP. Spend ten minutes there before you spend a year.
Search engines have weirder rules than you think
I had two domains over the project's lifetime. The first one got hit by a domain-level block (registry entry, not my fault). I set
up the second one, put proper 301 redirects on every path from the old to the new, and assumed Yandex would figure it out.
Yandex did not figure it out. For about three weeks the old domain kept showing up in search results, sending people through the
redirect chain, and the new domain was indexed but underranked. Then one Tuesday morning the algorithm collectively decided the old
domain was dead, dropped it from results entirely, and didn't yet move the rankings to the new one.
My traffic went from 450 visits per day to 48 in twenty-four hours.
The fix is to file an explicit "site move" form in the search console. Even when your redirects are textbook correct. The algorithm
won't process it automatically fast enough to save you from the gap.
I'm three days into the recovery from this. Things are coming back, but slowly. If you're running anything with even one domain
change in its history, go check that your search console knows about it explicitly.
Server Actions and proxies fight each other in silence
This was the technical part that took me by surprise. Modern web frameworks (won't name names, you can guess) ship CSRF protection
that compares the request's Origin header against the X-Forwarded-Host value. If they don't match, every form submission gets
rejected with a generic error.
If you have any kind of reverse proxy chain (and most production sites do, even if you didn't set it up that way), the inner proxy
can quietly overwrite the headers in a way that makes them no longer match. The browser sees a generic 500 error. The user thinks
your site is broken. You spend hours debugging the form before realizing the framework is refusing to even run your code.
The fix involves a couple of lines in your proxy configuration. The bug-hunt is twelve hours.
The general lesson, which I keep relearning: your proxy is lying to you about what it sends downstream. The first thing you build
for any project that goes behind a reverse proxy should be a way to inspect actual headers as the backend sees them. I should have
had this from day one.
What this month felt like, honestly
The biggest gap between expectation and reality was the share of time spent on infrastructure versus product. I expected to spend my
month writing features. I spent it migrating hosts, debugging mirror merges, fixing CSRF mismatches, and reading documentation for
filtering systems that aren't documented in any official place.
The site itself is fine. It works. People use it (around 460 registered users in the bot now, growing). I'm happy with it. But the
unglamorous work of keeping it accessible turned out to be the actual product, and I want anyone considering similar projects to
know that going in.
For anyone curious what the thing looks like, it's at vpnstatus.site. It's in Russian because that's where
the audience is. The technical and operational lessons translate.
What I would tell my one-month-ago self:
- Pick hosting by who your neighbors are, not by the price per gigabyte.
- Tell your search console about every domain change immediately, in writing, through the actual form. Don't wait for the algorithm to be smart.
- Build header inspection on day one if you have any proxy in front of your backend.
- Expect that the unglamorous infrastructure work is the work. Plan time for it.
The product was the easy part.