PyPI is not working in Russia: RKN of course is not blocking anything, but Python developers feel like hanging themselves
Something surprising has happened in Russia again: a critical part of global IT infrastructure suddenly started “opening badly,” while Roskomnadzor, of course, is not restricting anything and is not recording any problems at all.
This time PyPI went down — the Python Package Index, the official central catalog of libraries and software packages for the Python language. This is not some cat forum or yet another meme site. This is where developers use pip install to install libraries, frameworks, utilities, and half of the modern software that runs the web, analytics, automation, machine learning, and AI.
If PyPI does not work, this is not “well, one little site did not open.” This is when a developer suddenly cannot build projects, deploys break, CI/CD turns into reading tea leaves, and the familiar package installation command becomes a lottery: maybe it works, maybe it does not — turn on the VPN.
What our measurements show
Dozor 404 (Дозор 404) is our own monitoring system that checks websites from the user side: through home and mobile operators in Siberia, the European part of Russia, and the Far East (MTS, MegaFon, Beeline, Tele2, Rostelecom, Sibirskiy Medved (Сибирский Медведь)), not from European data centers.
Over the last 6 hours: 3.84% availability on average across all operators. On MTS — 1.5%, on MegaFon and Rostelecom — 0.7%, on Beeline and Sibirskiy Medved — 0%. In other words, for the end user in Russia, pypi.org effectively does not open through any operator.
The live status of the service with an up-to-date graph is on the PyPI in Dozor 404 page. It is also convenient to show colleagues and in chats instead of “it does not open for me, what about you?”.
What Roskomnadzor says
Users in Russia have complained about problems accessing pypi.org. According to Kod Durova (Код Дурова), the connection breaks at the TLS stage — that is, at the moment when the client and server are supposed to negotiate a secure connection. A similar symptom was previously observed with access problems to DeepSeek: without a VPN the service did not open, with a VPN it suddenly came back to life.
Roskomnadzor’s position looks especially elegant in this story. The agency told Ostorozhno, Novosti (Осторожно, новости) that it does not restrict access to the Python Package Index and does not record any problems with the resource.
A classic of the genre: users record it, diagnostic tools record it, developers record it, but RKN does not. Perhaps they have a special version of the internet there, where everything opens, nothing is blocked, Telegram always worked, YouTube was not slowed down, and Python simply lay down from exhaustion.
Is this a block or an outage?
Formally, this is not yet proof of blocking. No official decisions to restrict access to PyPI have been published, and the service itself has not reported a major outage. But the symptoms — a break at the TLS handshake, the same picture across all Russian operators, instant recovery through a VPN — match SNI filtering through TSPU, as has already happened with dozens of other services. We covered how to distinguish DPI/SNI/DNS/IP blocking separately.
This is the beauty of modern Russian network reality: nothing is blocked, packages simply do not install; nobody restricted anything, TLS just falls off; there are no problems, developers just somehow go looking for a VPN again.
What to do right now
- Turn on a VPN on the dev machine. The fastest workaround is to configure pip to go through a VPN tunnel. For which VPNs are currently working reliably in Russia, see our VPN selection guide and live list updated every 4 hours.
- Mirror through a corporate proxy / private Nexus. For teams: set up a local pip mirror (Nexus, Artifactory, devpi) on a VPS outside Russia and point pip to it. Configure it once — then it is resilient to any upstream blocking.
- Change index-url to an alternative:
pip install --index-url https://pypi.tuna.tsinghua.edu.cn/simple/ <package>— a Chinese PyPI mirror, historically stable from Russia. Not for long-term production use because of trust in the mirror, but as a temporary workaround it works. - In CI/CD — add retries with exponential backoff to
pip installplus fallback to a mirror. This minimizes “red” builds caused by 1–2 failed handshakes.
Why this matters more than “just another site”
If today PyPI accidentally went down, tomorrow npm may “get tired,” the day after tomorrow Maven Central, then Docker Hub, GitHub Releases, and everything else that normal development depends on. And every time we will be told that there are no restrictions, the internet has simply become more sovereign: so sovereign that even dependencies now have to be obtained through detours.
For the Russian IT environment, this is not a minor outage but a signal: development infrastructure in the country increasingly depends not on engineers, but on how the filters were configured today. And if these filters start hitting PyPI, it is not “abstract programmers” who suffer, but businesses, education, startups, researchers, data engineers, DevOps teams, and everyone who is simply trying to write code.
RKN says it is not restricting anything. Possibly. But then an even more unpleasant option remains: the filtering system is so smart that it no longer understands what it is breaking. And that, frankly, is even worse.
Against the backdrop of blocks — the most alarming meme of the week
“Does RKN want to move us all to 1C?” — this no longer sounds like a joke, but like an alarming meme with a production instruction attached.
You can track the status of PyPI and other key dev services in real time across all Russian operators in Dozor 404 — it currently shows the live picture for 99 web services: GitHub, npm, Docker Hub, PyPI, Maven, JetBrains, CodePen, and so on. If something else “lies down” next, you will see it first.