Skip to main content
Question

Availability of Deezer.com Web version in Kazakhstan

  • April 7, 2026
  • 2 replies
  • 26 views

Hello!

 

Recently (today, 07.04.2026) i have met the situation of Deezer.com availability in Kazakhstan. It cannot be opened neither from fixed (Kazakhtelecom) nor from mobile (Beeline) network. I receive “Connection aborted” message. Mobile application works fine. Ping and tracert works. 

I have tested the access via VPN (exit point in NL) -also works. 

So, it seems that Deezer has blocked by carriers (due to government decision), or by Deezer /CDN platform itself (from inside). 

Hence, i want to ask Deezer team to shed some light on this issue - is it Deezer restriction (KZ is in the list of supported countries, though) or it is governmental decision (and i want to know, if Deezer team plans to overcome it somehow)? 

 

2 replies

  • Guitar Hero
  • April 7, 2026

I have exactly the same problem! 

I am not able to connect to deezer via two fixed ISP I have tried personally. I tried all the usual steps - cookies, different browsers, etc - nothing worked. I also asked one of my friends in a different city to try and access the main page for deezer - same problem - getting a generic The connection has timed out error. 

Also, once in a while when I try to connect I get “Secure Connection Failed An error occurred during a connection to deezer.com. PR_END_OF_FILE_ERROR”

Although using other country VPN worked just fine. 

I contacted Deezer support but after opening the issue they completely ignored me, even after sending them another email - no answer whatsoever.

 

So all in all it looks like either deezer shadowbanned Kazakhstan or Kazakhstan government started blocking deezer for whatever reason.


  • Guitar Hero
  • April 7, 2026

Vibe-researching it, it looks like its KZ government after all

 

Your tests basically prove that the route to Deezer is fine, but the TLS handshake is being killed from the network side, which is exactly what a DPI/SNI‑based block looks like

What your outputs show

  • ping deezer.com works normally with 0% loss and reasonable RTT, so IP routing and basic connectivity to the CloudFront edge are OK.

  • openssl s_client sends a ClientHello (SSLv2/v3 write client hello A), then immediately gets ssl handshake failure with “no peer certificate available”, meaning the handshake is aborted before the server presents a cert.

  • curl -v https://deezer.com and https://www.deezer.com both connect to IP and then fail with NSS error -5938 (PR_END_OF_FILE_ERROR), i.e., the TCP connection is accepted but the TLS layer is closed/reset without a handshake response.

  • traceroute reaches Cogent in Europe and then just stops, which is not unusual if ICMP is filtered near the CDN, but combined with the TLS behavior it’s consistent with application‑level (TLS) interference, not pure routing failure.

This pattern—successful TCP connect, ClientHello sent, no ServerHello/certificate, and then abrupt close—is exactly how SNI‑based blocking via TLS interference is commonly implemented.

From a pure tech perspective, you’ve fully diagnosed it: you’re hitting coordinated TLS interference on Deezer from Kazakhstan, and a VPN is the only reliable path around it right now.