I ran some tests with the Outline SDK, which may work differently than other implementations. It looks like the blocking depends on the location of the server. It also depends on the port number. I was also able to confirm that the initial packet size makes a difference, but only in some ISPs.
- Bee Line seems to be the only one considering the packet size, but only for the Vultr server, not DigitalOcean.
- MTS blocked Shadowsocks access to a server on DigitalOcean, but not Vultr. They are likely using the IP address.
- Blocking on DigitalOcean only happened for the key on port 443. No blocking for the key on the same server, but on port 5555.
- MegaFon blocked Shadowsocks access to a server on Vultr, but not on DigitalOcean. They are likely using the IP address as well.
- The packet size didn’t make a difference for MegaFon and MTS
- Tele2 is not blocking.
Tests
The tests used port 443 for the DigitalOcean server and port 20888 for the Vultr server.
I was not able to reproduce blocking on Tele2. Results for Bee Line depended on the initial packet. Results for MTS and Megafon depended on where the server was.
With a DigitalOcean server and large initial packet (over 800 bytes):
MTS was consistently timing out
MegaFon worked most times, with some timeouts. Inconsistent.
Tele2 was consistently working- Bee Line was consistently working
Example:
Using a smaller initial packet didn’t seem to make a difference.
However, when using a key on a different port, 5555, on the same DigitalOcean server, I could consistently connect to the server on all ISPs:
I was also able to connect to the management API on that server, on another high port number.
With a Vultr server and large initial packet:
- MTS was consistently working
- MegaFon was consistently blocked. Not a timeout. I was getting an EOF from the SOCKS5 service I was using, so the Shadowsocks client probably got a FIN or a RESET.
- Tele2 was consistently working
- Bee Line was consistently timing out
Example:
With a Vultr server and small initial packet (300 bytes):
- MTS was consistently working
- MegaFon was consistently blocked. Not a timeout. I was getting an EOF from the SOCKS5 service I was using, so the Shadowsocks client probably got a FIN or a RESET.
- Tele2 was consistently working
- Bee Line was consistently working
Example:
ISPs are targeting specific cloud providers, as reported in April.
I was able to demonstrate that www.digitalocean.com, which runs on Cloudflare, is blocked by SNI. You observe timeouts:
I did manage to successfully fetch the page on Tele2 once.
If you use TLS Record Fragmentation, you can successfully, and consistently fetch the page:
