MCI DPI got super aggressive!

[amir-devman]

For the last 10 days until now, we in Iran have been experiencing a massive DPI detection on MCI (not any other ISPs, rest are fine) for xray-core based protocol mostly reality.
It looks like it doesn't matter what IP or SNI you're using or how many are using a proxy server, your IP gets blocked within a few hours no matter how much traffic you have, you just get blocked...(at least this is my experience and people around me)

And you only can send data which means The Xray-cores accepts the connection but cannot send back the response while the IP is blocked, I don't know what the solution is and at this point xray-core or any other protocol is useless... and the only solution is to find a non-block IP address every hour after your server got blocked and again you get blocked... this is the loop we are facing and it is getting more aggressive and more accurate over time. (I think it can be because of people used any IP addresses and made them graylisted)

I think we should step forward towards this situation and find a way to mitigate this because protocols like Reality doing nothing currently.
Is there anything we should do in our configuration or changing the keys/shortIds or what because they seemed to be not working?

[ashad765]

I'm using Reality right now with my own domain (steal oneself) on MCI and it just working fine. Stealing SNI will be easily detected by just a simple DNS resolve because your SNI won't resolve to your vps IP.

[amir-devman]

I did not steal SNI, I used my own

[shakibamoshiri]

This is not about xray or any other VPN servers, MCI is targeting all the suspicious servers and throttle/disallow TLS handshake for those IPs, So any TLS handshake will fail . You can see this using WireShark .

TLS handshake has 6 steps, with MCI it never completes and you will see TCP re-transmission till the clients stops
By the way this major shift from MCI is not applied nationwide , mostly

• Tehran
• Kurdistan
• Systan and Baluchstan

has been affected

[shakibamoshiri]

@ashad765
I am new to xray , so please give me some docs to get started or I will find more about Hy2
Mostly I tested xary - ws - tls (with and without CDN).
I assume if Hy2 uses UDP your hypothesis should work

[ashad765]

Hysteria
Hysteria 2

[shakibamoshiri]

@ashad765
Testing it with three clients

• linux main app
• windows v2rayN https://github.com/2dust/v2rayN/releases
• android https://github.com/MatsuriDayo/NekoBoxForAndroid/releases/download/1.2.9/NB4A-1.2.9-arm64-v8a.apk

None worked. On Android for a foreign server error was "timeout" and for a domestic server error was "unknown ssl certificate".

For cert LetsCrypt being used.

I assume either the server or client configuration is wrong.
If you have a proper working configuration please share it while

• server address
• password
• etc
  have been removed , I add my own

here is the server I used

listen: :443
tls:
  cert: /etc/example.com/cert.pem
  key: /etc/example.com/privkey.pem
obfs:
  type: salamander
  salamander:
    password: **********
auth:
  type: password
  password: *****************
quic:
  initStreamReceiveWindow: 8388608
  maxStreamReceiveWindow: 8388608
  initConnReceiveWindow: 20971520
  maxConnReceiveWindow: 20971520
  maxIdleTimeout: 60s
  maxIncomingStreams: 1024
  disablePathMTUDiscovery: false
bandwidth:
  up: 1 gbps
  down: 1 gbps
ignoreClientBandwidth: false
disableUDP: false
udpIdleTimeout: 60s
resolver:
  type: udp
  tcp:
    addr: 8.8.8.8:53
    timeout: 4s
  udp:
    addr: 8.8.4.4:53
    timeout: 4s
  tls:
    addr: 1.1.1.1:853
    timeout: 10s
    sni: cloudflare-dns.com
    insecure: false
  https:
    addr: 1.1.1.1:443
    timeout: 10s
    sni: cloudflare-dns.com

and client

server: *.*.*.*:443
auth: ***************
transport:
  type: udp
  udp:
    hopInterval: 30s
obfs:
  type: salamander
  salamander:
    password: ************
tls:
  sni: *********
  insecure: false
bandwidth: 
  up: 20 mbps
  down: 100 mbps
quic:
  initStreamReceiveWindow: 8388608 
  maxStreamReceiveWindow: 8388608 
  initConnReceiveWindow: 20971520 
  maxConnReceiveWindow: 20971520 
  maxIdleTimeout: 30s 
  keepAlivePeriod: 10s 
  disablePathMTUDiscovery: false
fastOpen: true
lazy: true
socks5:
  listen: 127.0.0.1:10808
http:
  listen: 127.0.0.1:10809

[ashad765]

Private key should be in .key format and not .pem
(If .pem file are in Base64 format it won't make any different, but maybe your .pem file are in binary format)
Here is a very minimal config
server config

listen: :443
tls:
  cert: your_cert.crt
  key: your_key.key
auth:
  type: password
  password: yourpassword
masquerade: 
  type: proxy
  proxy:
    url: https://apple.com/
    rewriteHost: true

And client

server: yourdomain:443
auth: yourpassword
bandwidth:
  up: 20 mbps
  down: 100 mbps
socks5:
  listen: 127.0.0.1:1080
http:
  listen: 127.0.0.1:8080

[shakibamoshiri]

The name extension has no effect on file content, so wrong file I selected.
After fixing it (yet .pem format) I could connect but to a server inside Iran. To outside MTN, MCI, TCL all timed out
UDP 443 was blocked :|

[us254]

[shakibamoshiri]

which city/state did you run the test ?
The problem differs from city to city

[amir-devman]

Seems like changing everything on your reality proxies such as IP, SNI, shortId, and public key and private key worked for me, and no more detection after 24 hours whatsoever. I'm hopeful this is the case and something about my config was causing it to be detected that fast (like less than an hour).
I don't know if still reality configs are getting aggressively blocked because I didn't get blocked and detected after changing everything.

Edit: I didn't use any SNI like "ghbi.ir" that even works on a blocked server. I've bought a domain and used it as my reality SNI and it's also fallback to a website.