Iran limiting v2ray and shadowsocks private servers

[linehman]

Some of my private v2ray ( vmess ws tls with no fake site + tcp tls ) and shadowsocks + cloak servers are getting limited in Iran. I was running all configs on the same servers so I'm not sure which one got exposed or maybe they limited them based on traffic or other things. interesting thing is they are limited on one or two isp but working on others right now.

[free-the-internet]

Some of my private v2ray ( vmess ws tls with no fake site + tcp tls ) and shadowsocks + cloak servers are getting limited in Iran. I was running all configs on the same servers so I'm not sure which one got exposed or maybe they limited them based on traffic or other things. interesting thing is they are limited on one or two isp but working on others right now.

Limiting means IP blocking or Handshake intervention?
Could you see in detail with Wireshark, please?

[seakfind]

So it could be the VPS provider that was a red flag. Or it could be the volume of traffic. Or it could be the presence of TLS in the protocol (I believe Cloak does not use TLS, but you mentioned TLS in the other configurations).

Can you tell me:

1. Were you using a large, well-known VPS provider that is often used by people creating private proxies?
2. Can you estimate how many Gigabytes per day you downloaded from the server?
3. What percentage of your total traffic went to this server each day?
4. Have you tried obfuscating TLS-in-TLS with the new "Vision" technique?
5. Is UDP unblocked, and if so, have you tried Hysteria or TUIC?
6. When you say "limited" do you mean throttled, or do you mean completely blocked?

[linehman]

By limited I mean heavily throttled, telegram keeps reconnecting every few seconds and text messages are barely sent and recieved. browsing sites is so slow that is almost impossible. Also Now it's throttled on all isps.
I really can't test this out with wireshark right now. my provider is a small company that is not well known. My monthly traffic is around 1 terabyte. one mistake that I made was routing all my traffic to the server and not using geosite config for local websites. I couldn't get Hysteria to work and don't have any idea about the other methods mentioned. Overall I posted this issue to let people know about it and take better measures to prevent getting blacklisted.

[seakfind]

If you are interested in trying "Vision," I translated the instructions for one example into English about a month ago.

https://github.com/seakfind/examples/tree/main/VLESS-TCP-XTLS-Vision

The client in this example bypasses the proxy for all destinations with an IP address in China or a DNS name in China. Obviously you would want to change those routing rules. As a safeguard, the server is also configured to block IP addresses in China.

The idea behind "Vision" is that TLS handshakes within TLS encryption should have random padding added to packet lengths. This stops the traffic from looking like an obvious TLS-in-TLS proxy server.

[arandomgstring]

@linehman

Use MUX and set concurrency to 1 and tell me the results. I am fairly confident that you receive "failed to dial Websocket error" no? "Timeout and io" errors are common as well. They have limited foreign IPs bandwidth, and the number of your connection to an IP shouldn't go beyond 4~8ish. Also check DNS leak, if you have any, that is the cause.

@seakfind
Doesn't VISION only works for TLS 1.3? More than 50% of times I see TLS 1.2 in Wireshark, so it's not as promising as it sounds, I presume. Unless somehow we force all webservers we are visiting to use TLS 1.3. Is it doable though?

[linehman]

@arandomgstring enabling mux did not help and couldn't get connected anymore. anyway it's not worth it to spend more time with this vps. it's clearly flagged and limited. my other servers are working fine.

[Argo160]

They have limited almost all the bridge vps using 1 on 1 traffic
there should be a way to have the bridge only for sending or receiving so the 1 on 1 will be avoided and limit goes away.
any idea?

[linehman]

Well, I suppose the best way is using geosite data function in clients to seperate iranian sites from foreign ones. there is already a repo for iranian hosted domain in github that you can use.

[linehman]

@seakfind I tried your suggestion on a new vps. while it is working, I'm getting some ssl errors (SSL_ERROR_BAD_MAC_ALERT or SSL_ERROR_PROTOCOL_VERSION_ALERT) or blank pages when web browsing that gets fixed if I refresh the page a few times and overall web browsing is a bit slow. Also when playing a video on youtube it gets interrupted and lags after playing for around 10 seconds and afterwards it sometimes plays just fine or keeps lagging. overall it's quite good considering other configs performances right now. do you think this is more resistant to identifying server ip( getting rate limited) or using nginx/caddy + trojan/v2ray ?

[free-the-internet]

It seems VMess + TLS + H2 can not connect anymore in Iran.
I don't know the reason yet.

[arandomgstring]

@free-the-internet

Can you ping the domain of your server to see if it's blocked on IP level or not?

1. Either you get bogon IP for your domain, which is the problem that I have already mentioned here DNS SERVFAIL for servers with Cloudflare's name servers (gray and orange cloud) #172 . You need to adjust your host file, for example add xx.xxx.xxx.xxx yourdomain.com to your host file and use this command "ipconfig /flushdns" in cmd and ping again, this time you will get the true result. If you are able to ping your server, you can connect to you server.

2. Ping the IP address of your server. If it returns timeouts, that means your server is blocked at IP level. Nothing can be done about it, buy another VPS.

3. If the ping results is fine, and still you can't connect to yourserver, open Wireshark and capture its packets and share it with us to find the reason.

[free-the-internet]

@free-the-internet

Can you ping the domain of your server to see if it's blocked on IP level or not?

1. Either you get bogon IP for your domain, which is the problem that I have already mentioned here DNS poisoning of all servers with Cloudflare's name servers (gray and orange cloud) #172 . You need to adjust your host file, for example add xx.xxx.xxx.xxx yourdomain.com to your host file and use this command "ipconfig /flushdns" in cmd and ping again, this time you will get the true result. If you are able to ping your server, you can connect to you server.
2. Ping the IP address of your server. If it returns timeouts, that means your server is blocked at IP level. Nothing can be done about it, buy another VPS.
3. If the ping results is fine, and still you can't connect to yourserver, open Wireshark and capture its packets and share it with us to find the reason.

I changed to VLESS xtls+rprx+vision, now it can connect but it is very slow in MTN and TCI networks. In other networks it is also slower than before, but still can be used.
I see many timeouts and errors regarding to connection resets on my server.
I don't know what is happening at this time:

• It's dropping the packets at censor's routers?
• It's throttling the TLS traffic going to private servers (not well known IPs)?
• My server marked as proxy and now has restrictions to be communicated?

2022/12/15 16:59:15 my.client.ip.addr:20462 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:20462: i/o timeout
2022/12/15 16:59:15 my.client.ip.addr:21217 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:21217: read: connection reset by peer
2022/12/15 16:59:16 my.client.ip.addr:21222 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:21222: read: connection reset by peer
2022/12/15 16:59:21 my.client.ip.addr:20468 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:20468: i/o timeout
2022/12/15 16:59:22 my.client.ip.addr:20471 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:20471: i/o timeout
2022/12/15 16:59:22 my.client.ip.addr:20472 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:20472: i/o timeout
2022/12/15 16:59:22 my.client.ip.addr:20473 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:20473: i/o timeout
2022/12/15 16:59:23 my.client.ip.addr:20475 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:20475: i/o timeout
2022/12/15 16:59:25 my.client.ip.addr:21215 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:21215: read: connection reset by peer
2022/12/15 16:59:25 my.client.ip.addr:20483 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:20483: read: connection reset by peer
2022/12/15 16:59:32 my.client.ip.addr:20489 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:20489: i/o timeout
2022/12/15 16:59:33 my.client.ip.addr:20491 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:20491: i/o timeout
2022/12/15 16:59:34 my.client.ip.addr:21209 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:21209: i/o timeout
2022/12/15 16:59:34 my.client.ip.addr:21210 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:21210: i/o timeout
2022/12/15 16:59:37 my.client.ip.addr:21211 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:21211: i/o timeout
2022/12/15 16:59:39 my.client.ip.addr:21213 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:21213: i/o timeout
2022/12/15 16:59:40 my.client.ip.addr:21216 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:21216: i/o timeout
2022/12/15 16:59:41 my.client.ip.addr:21218 rejected  proxy/vless/encoding: failed to read request version > read tcp my.server.ip.addr:443->my.client.ip.addr:21218: i/o timeout

[arandomgstring]

@free-the-internet

OK. That means you are not blocked at IP level at least. However, without seeing packets it's quite hard to deduce the real cause of problem. Turn on mux, set it to 1 to be sure, and see if the problem persists. Some times ISPs apply QoS to servers, and because of that you can't have several simultaneous connection with a server. Mux mitigates this issue. If mux doesn't help, your problem can be literally anything. But I guess mux will help.

Tell me, when you restart your connection to the proxy server, at the first few seconds, is your speed better and then it gradually becomes worse, or since the very beginning you receive timeouts? Do you receive timeout for all websites, or it only happens for streaming/gaming/or certain websites?

Can you change port 443 to something else and see if you are still facing the same problem? (I don't advise using any port other than 443, however, if other ports work well it means that 443 is limited, temporarily, because of QoS).

Finally I don't think that your server is "flagged" as per se. Either your server IP range has been limited (this happened 1 month ago for French VPSs from certain VPS provider) or you kept your connection to server for long period of time, making your server limited temporarily. From my observation, even if you download "large" files from Iranian sites (not famous ones), in the middle of downloading you receive many timeouts too, so QoS happens for everyone.

Vision imo is not mature enough (or perhaps TLS1.3 features, such as early data are not mature), and there is no difference between vision and say normal VLESS + TLS + TCP, except for the fact that in vision you simply receive encrypted packets from your destination without double encryption (TLS in TLS), which makes packets smaller (thereby networking faster) and that's it. There is no reason for vision to work and VLESS + TLS + TCP (or VMess + TLS ) not to work; their traffic is literally the same in DPI. Although Vmess + TLS makes your packets too big, because of triple encryption (TLS + TLS + VMESS). Personally I will wait for stable version of vision. Maybe the vision itself has caused these timeout problems? What kind of errors you had when you used VMess + TLS?

[free-the-internet]

@free-the-internet

OK. That means you are not blocked at IP level at least. However, without seeing packets it's quite hard to deduce the real cause of problem. Turn on mux, set it to 1 to be sure, and see if the problem persists. Some times ISPs apply QoS to servers, and because of that you can't have several simultaneous connection with a server. Mux mitigates this issue. If mux doesn't help, your problem can be literally anything. But I guess mux will help.

Tell me, when you restart your connection to the proxy server, at the first few seconds, is your speed better and then it gradually becomes worse, or since the very beginning you receive timeouts? Do you receive timeout for all websites, or it only happens for streaming/gaming/or certain websites?

Can you change port 443 to something else and see if you are still facing the same problem? (I don't advise using any port other than 443, however, if other ports work well it means that 443 is limited, temporarily, because of QoS).

Finally I don't think that your server is "flagged" as per se. Either your server IP range has been limited (this happened 1 month ago for French VPSs from certain VPS provider) or you kept your connection to server for long period of time, making your server limited temporarily. From my observation, even if you download "large" files from Iranian sites (not famous ones), in the middle of downloading you receive many timeouts too, so QoS happens for everyone.

Vision imo is not mature enough (or perhaps TLS1.3 features, such as early data are not mature), and there is no difference between vision and say normal VLESS + TLS + TCP, except for the fact that in vision you simply receive encrypted packets from your destination without double encryption (TLS in TLS), which makes packets smaller (thereby networking faster) and that's it. There is no reason for vision to work and VLESS + TLS + TCP (or VMess + TLS ) not to work; their traffic is literally the same in DPI. Although Vmess + TLS makes your packets too big, because of triple encryption (TLS + TLS + VMESS). Personally I will wait for stable version of vision. Maybe the vision itself has caused these timeout problems? What kind of errors you had when you used VMess + TLS?

Thanks for your recommendation.
Pinging the server from Iran, shows steady latency without loss.
Downloading (in Iran) a file from well-known websites like debian.org, without proxy is also fast and fine.
It is only after connecting to proxy server that we have huge losses.
This maybe means that they somehow knew that this connection belongs to proxy, hence throttling it.
And, yet I have this server for more than a couple of months now.

I should mention that my VMess + TLS + H2 was not connecting anymore! This is the reason I moved to VLESS.
The error with VMess:

I will enable mux, and let you know.

[linehman]

Hi, @free-the-internet
It's highly possible that your server ip is throttled. to test this out, you can run nginx alone on one port and just put a test file in the root directory of the site, then check the download speed from your server.

[arandomgstring]

@free-the-internet

I think you have given me the most valuable piece of information, that I didn't pay attention to it.

I should mention that my VMess + TLS + H2 was not connecting anymore!

Many Iranian users have been reporting to @klzgrad that they are not able to connect to Naiveproxy. But why was that? It could've been TLS fingerpriting for sure, but some argued that (klzgrad/naiveproxy#404), it is not the case. But now that I am seeing your issue (and your solution to it), I think everything makes sense now. According to @grimpenmire Chrome by default uses http 1.1 klzgrad/naiveproxy#390 (comment) . And you, for some reason, couldn't connect to your server using H2 as well, even though you were using Xray for this purpose, not Naiveproxy.

I am only hypothesizing here, but could it be that they are blocking H2 traffic with some special features that @klzgrad described here klzgrad/naiveproxy#1 ? I mean it cannot be a coincidence that suddenly switching from VMess + TLS + H2 to vision made your proxy work. At least you can connect to it. You haven't mentioned it, but I assume you are using TCP in network settings of vision, am I correct?! Suddenly switching from H2 to something else let you connect to your server.

[free-the-internet]

@free-the-internet

I think you have given me the most valuable piece of information, that I didn't pay attention to it.

I should mention that my VMess + TLS + H2 was not connecting anymore!

Many Iranian users have been reporting to @klzgrad that they are not able to connect to Naiveproxy. But why was that? It could've been TLS fingerpriting for sure, but some argued that (klzgrad/naiveproxy#404), it is not the case. But now that I am seeing your issue (and your solution to it), I think everything makes sense now. According to @grimpenmire Chrome by default uses http 1.1 klzgrad/naiveproxy#390 (comment) . And you, for some reason, couldn't connect to your server using H2 as well, even though you were using Xray for this purpose, not Naiveproxy.

I am only hypothesizing here, but could it be that they are blocking H2 traffic with some special features that @klzgrad described here klzgrad/naiveproxy#1 ? I mean it cannot be a coincidence that suddenly switching from VMess + TLS + H2 to vision made your proxy work. At least you can connect to it. You haven't mentioned it, but I assume you are using TCP in network settings of vision, am I correct?! Suddenly switching from H2 to something else let you connect to your server.

Yes, I'm switched from H2 to TCP. But, I should read the posts you mentioned first. I can return to previous setup and check again if the problem is H2? BTW, isn't it the case that HTTP2 is wrapped into encrypted TCP packets? Considering that HTTP2 is only Application layer, and TCP is the transport. If this is true, how they managed to distinguish HTTP2 from HTPP1.1 ?
Maybe in Xray there is not such a padding for HTTP2 (klzgrad/naiveproxy#1 (comment))?

I'll check the speed today using a real web server (as @linehman said), and report here the results.

[grimpenmire]

If this is true, how they managed to distinguish HTTP2 from HTPP1.1 ?

This part at least is easy to answer. The application-layer protocol is negotiated using the ALPN extension in ClientHello/ServerHello, which is clear-text.

[free-the-internet]

Hi, @free-the-internet It's highly possible that your server ip is throttled. to test this out, you can run nginx alone on one port and just put a test file in the root directory of the site, then check the download speed from your server.

Seems when there is a web server, speed is normal when downloading a file.
After connecting the VPN, sometimes speed is 0, and then goes up, then goes down, meaning that it is fluctuating.
I would go with something that has NGINX, which one is okay?
Opinions?

[linehman]

nginx and caddy are fine. honestly today almost all protocols have problems. looks like they are just messing up the network and throttling foreign traffic after a few seconds of data transfer. using a local node in iran, all issues are solved. I just don't like buying an iranian vps for this. since they are gonna know your identity.

[arandomgstring]

@free-the-internet

After connecting the VPN, sometimes speed is 0, and then goes up, then goes down, meaning that it is fluctuating.
I would go with something that has NGINX, which one is okay?

Honestly, this behavior is to be expected, since the flow of information is totally different when you download a file from your server, compare to when you use your server as a proxy. This is why I suggested that you should turn MUX on, because with MUX, all of your traffic will be proxified by a single socket, which kinda (not exactly) makes your traffic look like downloading a file through single connection. By default however, xray opens infinitely different parallel connections to your server, and send small volume of traffic through them. Messing with this type of traffic is super easy without breaking anything.

@linehman

nginx and caddy are fine. honestly today almost all protocols have problems. looks like they are just messing up the network and throttling foreign traffic after a few seconds of data transfer. using a local node in iran, all issues are solved. I just don't like buying an iranian vps for this. since they are gonna know your identity.

I mean, what if they know your identity? It is not like they can actually see what type of data you are sending through their server, well unless someone heavy tech enough, modifies xray source code, and compiles it in your server, and then uses your configuration on it, to see every single packet decrypted as middle man. But again, do they have time, force, and money for something like this? If they see your proxy usage, at most they will block your account and that is it. It is just not "money wise" to buy 2 VPSs just for sake of censorship.

[free-the-internet]

@arandomgstring
mux needs to be enabled only in client side (as I read)? V2rayNG hasn't this option and we need to enter custom json like config.
mux keeps all the traffic only inside 1 TCP connection or it creates N (default=8) TCP connections in parallel to carry the whole traffic? Obviously, the second case is more like downloading a file in parallel. The first case seems horrible for me.

FYI, I changed to Vless + TLS + TCP, now its more robust than rprx.

[Azadzadeh]

mux keeps all the traffic only inside 1 TCP connection or it creates N (default=8) TCP connections in parallel to carry the whole traffic? Obviously, the second case is more like downloading a file in parallel. The first case seems horrible for me.

When mux is enabled, with concurrency set to 8, the client uses a maximum of 8 TCP connections inside a single TLS session. It's particularly useful in scenarios when TLS connections are being dropped randomly (like the current situation in Iran) since each TLS handshake takes a long time to be established and this leads to increased latency.

FYI, I changed to Vless + TLS + TCP, now its more robust than rprx.

How do you test robustness of a configuration?

FWIW, here they are recommending against enabling mux for xray.

[cross-hello]

@arandomgstring mux needs to be enabled only in client side (as I read)? V2rayNG hasn't this option and we need to enter custom json like config. mux keeps all the traffic only inside 1 TCP connection or it creates N (default=8) TCP connections in parallel to carry the whole traffic? Obviously, the second case is more like downloading a file in parallel. The first case seems horrible for me.

FYI, I changed to Vless + TLS + TCP, now its more robust than rprx.

You could enable all latest features in mobile.
Run [Termux] (https://github.com/termux/termux-app) (Android), git clone *ray code repository and compile.
Clone your pc configuration to mobile and run.
This time you could set any listening port(socks, http,...).
Then you use arbitrary phone app supporting http/socks traffic agent to listen the ports.

[arandomgstring]

@free-the-internet
@Azadzadeh has already answered your question, so I have nothing else to add. And thanks for information about the working protocol. Indeed, not matter how I look at this, it seems H2 causes issues. As for rprx I estimate it needs 3 months at minimum, and 1 year at maximum to become mature enough.

@Azadzadeh

FWIW, XTLS/Xray-examples#20 they are recommending against enabling mux for xray.

All they say is that H2 + gRPC itself mimics mux option, so this option is not recommended. Other configurations, such as Vless + TLS + TCP can of course enjoy mux option. Not to mention H2 is causing issues in Iran.

[Azadzadeh]

All they say is that H2 + gRPC itself mimics mux option, so this option is not recommended. Other configurations, such as Vless + TLS + TCP can of course enjoy mux option. Not to mention H2 is causing issues in Iran.

Thanks. Do you know which transport method (TCP, HTTP2, gRPC, ws, etc) works better in Iran? Can they detect the transport method?
Also, do you know the difference between XTLS and TLS?

[arandomgstring]

@Azadzadeh

I theory pure TCP should work the best, since there is no additional application layer beside TLS + VLESS/VMESS, etc of networking.

WS is needed if you want to hide your VPS ip behind a CDN, though it will increase your latency and cloudflare CDN seems useless in Iran. If you use WS you can also use nginx and run a real website on your VPS ip:port, so that if a real censor bother to look at your domain they will see a real website there. From my understanding, browsers use web-sockets under-hood, therefore the increased latency caused by WS might be actually good, security wise, since it makes your traffic looks like a browser traffic. Although, I am 100% sure that we are very far from the point that they measure such latencies.

HTTP2 seems to be heavily throttled or even blocked, according to report of people here.

I have no experience using gRPC, though all I can say is that, its traffic is not very common. Messengers mainly use this protocol, but websites? I haven't seen any. Same goes for Quic. Quic is used by google and its services, but I haven't seen any noteable website that use this protocol.

Wireguard is a no go. They have already blocked it; and its traffic is absolutely obvious! Though I'd like to say, Proton VPN on stealth mode (which sometimes connects on smartphones) uses Wireguard + TLS underhood. I am not aware of any xray config that does this, but I predict that soon, we will be able to mimic stealth protocol of proton vpn with xray. Its performance, on theory should be comparable, if not better than of pure TCP. Because Wireguard is a "silent protocol" and we won't be sending many ACK packets using this protocol.

Also, do you know the difference between XTLS and TLS?

This is all I know
https://github.com/seakfind/examples/blob/main/xtls-vision/README.md

[Azadzadeh]

Thanks

If you use WS you can also use nginx and run a real website on your VPS ip:port, so that if a real censor bother to look at your domain they will see a real website there.

I don't think camouflage website is related to using WS as a transfer medium. From what I know, suppose you are using xray or trojan-go for a client at port 2456. If the active probe of GFW (or Iran's version of it) comes in, knocking on the port, or repeating a former TCP packet, it better behave like a website.
For example, if the server's anti-gfw application simply blocks the incoming fake packets from GFW probe, it would add the IP/domain to the list or downright censor it.
AFAIK, only trojan-go takes this matter seriously. Its server app won't even start if a decoy website is not served at port 80.
Trojan-Go has other problems though...

Wireguard is a no go. They have already blocked it; and its traffic is absolutely obvious!

Agreed. WG doesn't have any encryption (it's out-of-scope for them). Moreover, it's a UDP protocol. Recent events proved that Iran's GFW does not hesitate to completely block UDP. Unfortunately, hysteria is in the same boat, at least for Iranians.

IMO, WireGuard+encryption is also a bit lackluster. As long as the server app is not designed for resisting GFW from the ground up, it would be useless for Iranians. You can see how ProtonVPN:stealth disconnects after a few minutes.

I have high hopes for Trojan-Go or naiveproxy. But the former is not actively developed and I haven't managed to make any of them work in Iran as good as Xray+VLESS+TCP+TLS.

[mononobi]

I have configured a v2ray/vmess server, with internal and external servers. I can connect to proxy using the app and I also see the external server IP when I check my ip on the web. but I don't know why, all websites are still blocked, I mean it seems that proxy does not work correctly, do you have any idea about it?

[Azadzadeh]

I have configured a v2ray/vmess server, with internal and external servers.

Don't use VMESS. Use VLESS + TCP + TLS.

I can connect to proxy using the app and I also see the external server IP when I check my ip on the web.

Do the HTTPS server test I mentioned here on your problematic network.

but I don't know why, all websites are still blocked, I mean it seems that proxy does not work correctly, do you have any idea about it?

Probably the censor is able to detect your method and denies the connection. But still, I don't think you would be able to check your client IP through public IP detection websites as they function through HTTP not ICMP. What does https://ipleak.net/ show?

[arandomgstring]

@mononobi

I mean it seems that proxy does not work correctly, do you have any idea about it?

Yes. With 99% of certainty, it is because of DNS. Do an extended test here https://www.dnsleaktest.com/ you see Iran's flag? https://www.expressvpn.com/dns-leak-test here too. If so, then it's absolutely DNS problem. Refer to this topic #156 and find solutions, such as neckoray, proxifier, firefox remote dns, etc.

[mononobi]

I have configured a v2ray/vmess server, with internal and external servers.

Don't use VMESS. Use VLESS + TCP + TLS.

I can connect to proxy using the app and I also see the external server IP when I check my ip on the web.

Do the HTTPS server test I mentioned here on your problematic network.

but I don't know why, all websites are still blocked, I mean it seems that proxy does not work correctly, do you have any idea about it?

Probably the censor is able to detect your method and denies the connection. But still, I don't think you would be able to check your client IP through public IP detection websites as they function through HTTP not ICMP. What does https://ipleak.net/ show?

Thanks for your answer.
There was an odd issue where, on mobile, I had fully working proxy. But on desktop I had the problem which I had explained. So I started changing some of the dns related settings on desktop app.
And I found out it was because of outbound domain strategy, it was set to AsIs by default, but when I changed it to UseIP the problem solved. Now I have full internet access also using desktop app.

And I have to mention that while I had the said issue, my public ip was the external server ip (which is correct). And dns queries where also made to google but still I had no free access.

[mononobi]

@mononobi

I mean it seems that proxy does not work correctly, do you have any idea about it?

Yes. With 99% of certainty, it is because of DNS. Do an extended test here https://www.dnsleaktest.com/ you see Iran's flag? https://www.expressvpn.com/dns-leak-test here too. If so, then it's absolutely DNS problem. Refer to this topic #156 and find solutions, such as neckoray, proxifier, firefox remote dns, etc.

Thanks for your answer.
Yeah I solved the issue and I explained it in my last comment. I am using nekoray on linux and the problem was related to outbound domain strategy.

[free-the-internet]

And I found out it was because of outbound domain strategy, it was set to AsIs by default, but when I changed it to UseIP the problem solved. Now I have full internet access also using desktop app.

Interesting,
Could you please share your config file for the client? (Of course omit the sensitive addresses)

[mononobi]

And I found out it was because of outbound domain strategy, it was set to AsIs by default, but when I changed it to UseIP the problem solved. Now I have full internet access also using desktop app.

Interesting, Could you please share your config file for the client? (Of course omit the sensitive addresses)

Yeah, do you mean the profile configs?
because profile has little stuff in it, but other configs are in the app and I don't know how to export its configs, any idea?

[mononobi]

And I found out it was because of outbound domain strategy, it was set to AsIs by default, but when I changed it to UseIP the problem solved. Now I have full internet access also using desktop app.

Interesting, Could you please share your config file for the client? (Of course omit the sensitive addresses)

Yeah, do you mean the profile configs? because profile has little stuff in it, but other configs are in the app and I don't know how to export its configs, any idea?

here is profile config:

{ "bean": { "_v": 0, "addr": "*.*.*.*", "aid": 0, "id": "UUID", "name": "name", "port": 80, "sec": "chacha20-poly1305", "stream": { "ed_len": 0, "insecure": false, "net": "ws", "path": "/graphql" } }, "gid": 0, "id": 0, "traffic": { "dl": 1175765719, "ul": 8038257 }, "type": "vmess", "yc": 1520 }

[cross-hello]

Maybe thus

"routing": {
    "domainStrategy": "IPOnDemand", // choose from "AsIs", "IPIfNonMatch",  "IPOnDemand"
}

[mononobi]

Maybe thus

"routing": {
    "domainStrategy": "IPOnDemand", // choose from "AsIs", "IPIfNonMatch",  "IPOnDemand"
}

On desktop app there are two domain strategies:

1. Outbound Domain Strategy -> this one is not available on mobile app.
2. Domain Strategy - > this one is available on both mobile and desktop apps.

The value for the no.2 item (Domain Strategy) on mobile was "AsIs" and proxy had no
issues and I had access to blocked sites. so I didn't change this value on desktop app
either (the values for this are "AsIs", "IPIfNonMatch", "IPOnDemand")

But the problem was the no.1 item (Outbound Domain Strategy) which is only available on desktop app.
and its values are ("AsIs", "UseIP", "UseIPv4", "UseIPv6", "PreferIPv4", "PreferIPv6") and when I changed it
from "AsIs" to "UseIPv4" the problem on desktop also solved and all blocked sites where accessible.

[Evolve6996]

@arandomgstring

I started to slowly read topics again since I am busy.

I wish I could get more testers for naiveproxy to test my hypothesis about H2 censorship. It seems to be correct though, according to @free-the-internet at least.

I am running trojan with h2 since 3 mounts ago and had no issue ofc, it throttled now but that's a different problem.

is naive only working on h2?

why do they have to entirely block such a core thing like h2?

[arandomgstring]

@Evolve6996

why do they have to entirely block such a core thing like h2?

Beat me. They have almost blocked UDP altogether, which is core of messengers, gaming, etc. H2 is nothing.

[Evolve6996]

@Evolve6996

why do they have to entirely block such a core thing like h2?

Beat me. They have almost blocked UDP altogether, which is core of messengers, gaming, etc. H2 is nothing.

I said entirely. I think what they were doing was finding less impactful ways as we see during recent mounts things started to get worse day by day, probably they gave up on aiming protocols and now want to go for more harsh methods. the situation is really getting complex.

[pouyaSamie]

It seems Irancell, Z-tel, and some other providers have blocked UDP completely that's why the connections are so slow on the other hand MCI works pretty well almost with everything even shadow socks without obfuscation... I tried everything combination SSR was the best result on Z-tel and Irancell I could get... Trojan is the next and Vless + xtls also works
And also be sure to run bbr on your vps it makes a big difference

[free-the-internet]

It seems Irancell, Z-tel, and some other providers have blocked UDP completely that's why the connections are so slow on the other hand MCI works pretty well almost with everything even shadow socks without obfuscation... I tried everything combination SSR was the best result on Z-tel and Irancell I could get... Trojan is the next and Vless + xtls also works And also be sure to run bbr on your vps it makes a big difference

UDP to foreigner IPs?
Do you still experience throttling on 443 with TCP/HTTPS?

[LeonardoMercer]

well today was the first day of total cutout for me, neither of the port, protocols on either of the ports or clients actually connect (there are gaps which if youre lucky you can get in for a few mins before you get shut out) so far IKEv2,TCP and as in today WSTunnel have all their band throttled. since i dont have access to v2ray (failed the setup multiple times) UDP on port 1194 "works" as in name only. nekoray servers as well get blocked within 12 hours. i guess there is heavy monitoring on all lines
(surfshark was the only thing that its protocols would bypass and it got hit the day after i tested it).
this is the current state in iran. if you have any workaround to connect to a vms please @ me bc im running out of places to look.
thanks

[mononobi]

well today was the first day of total cutout for me, neither of the port, protocols on either of the ports or clients actually connect (there are gaps which if youre lucky you can get in for a few mins before you get shut out) so far IKEv2,TCP and as in today WSTunnel have all their band throttled. since i dont have access to v2ray (failed the setup multiple times) UDP on port 1194 "works" as in name only. nekoray servers as well get blocked within 12 hours. i guess there is heavy monitoring on all lines (surfshark was the only thing that its protocols would bypass and it got hit the day after i tested it). this is the current state in iran. if you have any workaround to connect to a vms please @ me bc im running out of places to look. thanks

Hey @LeonardoMercer
You can follow this guide to be able to create a v2ray setup (which will work both direct or with an internal layer):

https://github.com/mononobi/configs/blob/master/linux/vpn-server-setup/vmess-proxy-setup/server/setup.txt

[pouyaSamie]

You should use https + vmess/vless + nginx/Apache + any free cdn ( for iran Arvan cloud or Derak ) or Cloudflare it works pretty good for me. Be sure to use 443 port then you can turn on proxy in CDN
I will send a complete guide here

[MantorpLasse]

Hi pouyaSamie] could you send the guide , I have a vps that I set up for my friend and she cant use it anylonger. I'm keen on to fix it for her.

[pouyaSamie]

Hi pouyaSamie] could you send the guide , I have a vps that I set up for my friend and she cant use it anylonger. I'm keen on to fix it for her.

Hi, I have written a full detailed tutorial. for that. please check it on my GitHub page. It will use vmess+ Nginx + CDN through SLL

https://github.com/pouyaSamie/FreeInternet

[Roham0010]

@pouyaSamie
Are you sure that the Nginx is really needed?
We can just add the domain name and the TLS certificates to the configuration of the v2ray we are creating by enabling the tls option and there is no need to install Nginx in this case.
Is there any difference between adding the fake domain and certificate to the v2ray config or installing the Nginx and doing all that?
I followed this tutorial btw: https://privacymelon.com/how-to-setup-v2ray-ws-tls-cdn/

[pouyaSamie]

Yea it is needed because you need to keep websocket alive and also you need to he aboe redirect your request from port 443 to your vmess port… if you run your vmess on port 443 cdn wont allow that to pass and it will fail. At least from what i tried ... but if you could do it with proxy on the CDN i think you should be good to go

[Roham0010]

@pouyaSamie
I already have a vmess on port 443 and it's working.
There are sometimes tls handshake timeouts but I don't think it has anything to do with the configuration 🤔
(My DNS proxy status is also enabled)

[pouyaSamie]

@pouyaSamie

I already have a vmess on port 443 and it's working.

There are sometimes tls handshake timeouts but I don't think it has anything to do with the configuration 🤔

(My DNS proxy status is also enabled)

Thats good. I tried it with ArvanCloud cdn and it didnt work but with Nginx in fron it works perfectly

[SasukeFreestyle]

@pouyaSamie

Hi!

I've made a repo containing a guide using Nginx fallback for anti probe detection.

https://github.com/SasukeFreestyle/XTLS-Iran-TLS

This also works with CDN but you need to configure it in nginx

I do not recommend using X-UI because it does not contain an outbound CIDR block for Iranian IP's or websites.
X-UI also runs with root user and from a security perspective I don't recommend this.

If your server does not have this CIDR block, every Iranian app or users will proxy connection from your server back to Iran, and with many users this looks very suspicious from a firewall/DPI perspective. This is because you are hosting a "website" and a website does normally not initiate (first) connection back to another IP/website in Iran.

Check my config here
https://github.com/SasukeFreestyle/XTLS-Iran-TLS/blob/main/config.json

Your solution also uses websockets which are somewhat outdated. You should use XTLS-RPRX-Vision and a uTLS fingerprint in V2rayN

Also you are missing certbot renew script for your xray. when certbot renews its certificates your xray server will stop working because it has loaded old certificates, and you need to then manually restart xray.

If you use my renewal script it will automatically stop xray, renew certificates and start xray with new certificates.

[pouyaSamie]

@pouyaSamie

Hi!

I've made a repo containing a guide using Nginx fallback for anti probe detection.

https://github.com/SasukeFreestyle/XTLS-Iran-TLS

This also works with CDN but you need to configure it in nginx

I do not recommend using X-UI because it does not contain an outbound CIDR block for Iranian IP's or websites.

X-UI also runs with root user and from a security perspective I don't recommend this.

If your server does not have this CIDR block, every Iranian app or users will proxy connection from your server back to Iran, and with many users this looks very suspicious from a firewall/DPI perspective. This is because you are hosting a "website" and a website does normally not initiate (first) connection back to another IP/website in Iran.

Check my config here

https://github.com/SasukeFreestyle/XTLS-Iran-TLS/blob/main/config.json

Your solution also uses websockets which are somewhat outdated. You should use XTLS-RPRX-Vision and a uTLS fingerprint in V2rayN

Also you are missing certbot renew script for your xray. when certbot renews its certificates your xray server will stop working because it has loaded old certificates, and you need to then manually restart xray.

If you use my renewal script it will automatically stop xray, renew certificates and start xray with new certificates.

Hi thanx for your update
To be honest for now im totally happy with my config this is my result now with Hamrah aval using vpn

By the way X-UI has an update with newest changes.

[adelmrk]

Now what?
from 1 march 2023 XRAY-CORE down with TCI-ISP
I can get ping and tracert with my personal server but cant login with SSH.
need to change better protocol for me.
what is your offers? (need to be tested with TCI ISP)

[hack3rcon]

Hello,
A friend in Iran has a problem with the V2Ray and Shodowsocks. He got the following error and can't connect to his V2Ray server:
2024/02/25 14:08:13 [Debug] app/log: Logger started 2024/02/25 14:08:13 [Debug] app/proxyman/inbound: creating stream worker on 0.0.0.0:9090 2024/02/25 14:08:13 [Info] transport/internet/tcp: listening TCP on 0.0.0.0:9090 2024/02/25 14:08:13 [Warning] V2Ray 5.12.1 started 2024/02/25 14:08:55 [Info] [959473960] proxy/shadowsocks: tunnelling request to tcp:9.9.9.9:853 2024/02/25 14:08:55 [Warning] [959473960] app/dispatcher: default route for tcp:9.9.9.9:853 2024/02/25 14:08:55 [Info] [959473960] proxy/freedom: opening connection to tcp:9.9.9.9:853 2024/02/25 14:08:55 [Info] [959473960] transport/internet/tcp: dialing TCP to tcp:9.9.9.9:853 2024/02/25 14:08:55 [Info] [3719334211] proxy/shadowsocks: tunnelling request to tcp:IP:5222 2024/02/25 14:08:55 [Warning] [3719334211] app/dispatcher: default route for tcp:IP:5222 2024/02/25 14:08:55 [Info] [3719334211] proxy/freedom: opening connection to tcp:IP:5222 2024/02/25 14:08:55 [Info] [3719334211] transport/internet/tcp: dialing TCP to tcp:IP:5222 2024/02/25 14:08:56 [Info] [903413974] proxy/shadowsocks: tunnelling request to tcp:IP:443 2024/02/25 14:08:56 [Warning] [903413974] app/dispatcher: default route for tcp:IP:443 2024/02/25 14:08:56 [Info] [903413974] proxy/freedom: opening connection to tcp:IP:443 2024/02/25 14:08:56 [Info] [903413974] transport/internet/tcp: dialing TCP to tcp:IP:443 2024/02/25 14:09:07 [Info] [959473960] app/proxyman/inbound: connection ends > proxy/shadowsocks: connection ends > context canceled 2024/02/25 14:09:07 [Info] [959473960] app/proxyman/outbound: failed to process outbound traffic > proxy/freedom: connection ends > context canceled 2024/02/25 14:09:15 [Info] [4083135377] proxy/shadowsocks: tunnelling request to tcp:9.9.9.9:853 2024/02/25 14:09:15 [Warning] [4083135377] app/dispatcher: default route for tcp:9.9.9.9:853 2024/02/25 14:09:15 [Info] [4083135377] proxy/freedom: opening connection to tcp:9.9.9.9:853 2024/02/25 14:09:15 [Info] [4083135377] transport/internet/tcp: dialing TCP to tcp:9.9.9.9:853 2024/02/25 14:09:28 [Info] [4083135377] app/proxyman/inbound: connection ends > proxy/shadowsocks: connection ends > context canceled 2024/02/25 14:09:28 [Info] [4083135377] app/proxyman/outbound: failed to process outbound traffic > proxy/freedom: connection ends > context canceled 2024/02/25 14:09:36 [Info] [150780187] proxy/shadowsocks: tunnelling request to tcp:9.9.9.9:853 2024/02/25 14:09:36 [Warning] [150780187] app/dispatcher: default route for tcp:9.9.9.9:853 2024/02/25 14:09:36 [Info] [150780187] proxy/freedom: opening connection to tcp:9.9.9.9:853 2024/02/25 14:09:36 [Info] [150780187] transport/internet/tcp: dialing TCP to tcp:9.9.9.9:853 2024/02/25 14:09:37 [Info] [1434522752] proxy/shadowsocks: tunnelling request to tcp:9.9.9.9:853 2024/02/25 14:09:37 [Warning] [1434522752] app/dispatcher: default route for tcp:9.9.9.9:853 2024/02/25 14:09:37 [Info] [1434522752] proxy/freedom: opening connection to tcp:9.9.9.9:853 2024/02/25 14:09:37 [Info] [1434522752] transport/internet/tcp: dialing TCP to tcp:9.9.9.9:853 2024/02/25 14:09:37 [Info] [2544724651] proxy/shadowsocks: tunnelling request to tcp:android.googleapis.com:443 2024/02/25 14:09:37 [Warning] [2544724651] app/dispatcher: default route for tcp:android.googleapis.com:443 2024/02/25 14:09:37 [Info] [2544724651] proxy/freedom: opening connection to tcp:android.googleapis.com:443 2024/02/25 14:09:37 [Info] [2544724651] transport/internet/tcp: dialing TCP to tcp:android.googleapis.com:443 2024/02/25 14:09:37 [Info] [2469683110] proxy/shadowsocks: tunnelling request to tcp:mtalk.google.com:5228 2024/02/25 14:09:37 [Warning] [2469683110] app/dispatcher: default route for tcp:mtalk.google.com:5228

Any idea?