VPS' IP Address will be blocked in Iran and China after using Outline VPN

[kalhori124]

Recently, Iran and China's firewalls detect Outline VPN protocol then IP address of the server will be blocked after a while ( it depends on volume of traffic between Clients and server ).

Unfortunately, after blocking I cannot connect to the server even with SSH protocol and I have to delete the VPS and create a new VPS with new IP address ! I created and deleted 4 VPSs in a week !

Is it possible to obfuscate Outline VPN protocol ?

[Tintac-CN]

The GFW has acquired the means to precisely detect the shadowsocks server for a while.You should try some new protocols like VMESS and shadowsocks with AEAD. But once you cost too much bandwidth on single IP, your IP will be banned for sure. So the best way is try use CDN to transfer data to your server(shadowsocks in websocket, V2ray support this feature), I don't think they will ban all these IP using by some major CDN provider.

[kalhori124]

Thank you for VMESS ( v2ray ) suggestion, Do you know any CDN provider that works as a relay for VPN protocols ?

[ghost]

use websocket transport layer, see their manual. www.v2ray.com

kalhori124 notifications@github.com 于 2018年7月10日周二 01:44写道：

Thank you for VMESS ( v2ray ) suggestion, Do you know any CDN provider that works as a relay for VPN protocols ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Jigsaw-Code/outline-server/issues/193#issuecomment-403561867, or mute the thread https://github.com/notifications/unsubscribe-auth/AQVHEjDo8YvRq0mxBCXIL6PByvKG7JhKks5uE5Z8gaJpZM4VGzwV .

[kalhori124]

Hi @fortuna Do you have any plan to obfuscate Outline VPN protocol ?

[fortuna]

@kalhori124 I'm sorry to hear you are having problems. One of the goals of making it easy to create a server was that you can do it whenever it gets blocked. But I agree that's a big issue, specially if the servers get blocked within only a day or two.

Outline uses Shadowsocks, which is a protocol that is already obfuscated. It's unclear to me what is triggering the blocking. It may not be the protocol per se. It would be great if someone from the community could investigate that. I'm curious if using a different protocols would make any difference. We'll try to investigate, but it's hard for us to learn more about the blocking without being in the actual networks.

Is your server accessed from many different IPs simultaneously?

[4044ever]

Just wondering, standalone Shadowsocks using some sort of selective routing based on GFW blocking. When I go to (China blocked) google and type 'my IP' then google returns my VPN IP. But when I go to MyIP.cn it returns my current network IP.

Outline does not have that feature. Wouldn't that help to avoid detection?

[ghost]

All of my server use 'global mode' and works well for a years

4044ever notifications@github.com 于 2018年7月11日周三 14:37写道：

Just wondering, standalone Shadowsocks using some sort of selective routing based on GFW blocking. When I go to (China blocked) google and type 'my IP' then google returns my VPN IP. But when I go to MyIP.cn it returns my current network IP.

Outline does not have that feature. Wouldn't that help to avoid detection?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/Jigsaw-Code/outline-server/issues/193#issuecomment-404061131, or mute the thread https://github.com/notifications/unsubscribe-auth/AQVHEnJbSNczS7m-q9q3N-46qmkNFzr5ks5uFZ0ZgaJpZM4VGzwV .

[4044ever]

All of my server use 'global mode' and works well for a years

What good is a server when you can't connect to it? The initial question was also about blocked access, not unblocked access.

Questions remains open.

[Tintac-CN]

Cloudflare can relay websocket net flow, some chinese cloud provider like Aliyun can even relay H2 network data.However, acquiring an CDN in china may need some illegal methods to avoid the identification check.

kalhori124 notifications@github.com 于2018年7月10日周二 上午1:44写道：

Thank you for VMESS ( v2ray ) suggestion, Do you know any CDN provider that works as a relay for VPN protocols ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Jigsaw-Code/outline-server/issues/193#issuecomment-403561867, or mute the thread https://github.com/notifications/unsubscribe-auth/AiS9Grb8F1-dl8BBZTXRgsQ6tbUwqSn-ks5uE5Z8gaJpZM4VGzwV .

[4044ever]

@Tintac-CN Are there any instructions for setting up Cloudflare for Outline? This sounds very interesting.

If possible in English, 但是中文也可以

(this would be perfect for a new topic)

[Tintac-CN]

Using CDN as data transporting methods is impossible for Outline, because outline doesn't include websocket feature right now.The CDN can only retransmit formal web data，like H2，websocket.

4044ever notifications@github.com 于2018年7月12日周四 下午6:21写道：

@Tintac-CN https://github.com/Tintac-CN Are there any instructions for setting up Cloudflare for Outline? This sounds very interesting.

If possible in English, 但是中文也可以

(this would be perfect for a new topic)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Jigsaw-Code/outline-server/issues/193#issuecomment-404465192, or mute the thread https://github.com/notifications/unsubscribe-auth/AiS9GlgZDRU1w89GHMkFZ_P7LzeGWJmYks5uFyMWgaJpZM4VGzwV .

[fortuna]

We want to consider other protocols, but as I mentioned before, it's unclear to us if the protocol is the reason for the blocking. Would a different protocol make any difference? You will still have lots of random-looking traffic going to a single IP address.

In any case, we see the value of allowing proxying over HTTPS and Websockets, and we have an internet standard proposal to be discussed at the IETF next week that allows web proxies to proxy UDP or IP over Websockets. People interested are welcome to follow: https://datatracker.ietf.org/doc/draft-schwartz-httpbis-helium/

[fortuna]

Selective routing is something we are looking into. If you proxy a small fraction of the traffic, that draws a lot less attention, at the cost of reducing privacy.

[kalhori124]

@fortuna I have tested three other protocols ( Stunnel , Txthinking/Brook and OpenConnect ) and there are not any problems except OpenConnect protocol that need to change TCP/UDP port from 443 to 800 in order to work.

But when I use Outline VPN and use it with huge volume bandwidth, the firewall will autmatically blocked the IP address of the server and I cannot connect to the server ( even SSH protocol ) but the server is accessible from other countries.

I realize that the firewall will unblock the IP address of the server automatically after three days and Outline VPN will be available to use but if I use it again with huge volume bandwidth it will be locked again !

[kalhori124]

@fortuna I am using Stunnel for five years and my server never blocked ! Is it possible to use Stunnel in Outline VPN ?

[ghost]

You mean huge volume bandwidth with stunnel not get blocked? Thats sounds good. I want know how huge bandwidth, I just downloaded about 70GB file over shadowsocks at about 20Mbps, everything OK (then I run out of my server traffic), my ISP is CERNET, server runs v2ray. If need, I'll test at China Telecom next month.

Collect block report could help us understand how GFW works.

stunnel socks vpn sounds great, it has built in authentication. The problem is this project already use shadowsocks protocol...

kalhori124 notifications@github.com 于 2018年7月15日周日 03:02写道：

@fortuna https://github.com/fortuna I am using Stunnel for five years and my server never blocked ! Is it possible to use Stunnel in Outline VPN ?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/Jigsaw-Code/outline-server/issues/193#issuecomment-405043273, or mute the thread https://github.com/notifications/unsubscribe-auth/AQVHEptlhP_RcLNSRVvLImDRy4wRRl5Cks5uGkAvgaJpZM4VGzwV .

[VictoriaRaymond]

Just saw V2Ray mentioned here, and come for some advertisement 😉

V2Ray provides transport methods such as WebSocket and HTTP/2, that can transfer data through a third-party gateway. A common usage is to tunnel through CloudFlare using WebSocket, when proxy client can't talk to proxy server directly. V2Ray's transport supports both Shadowsocks and VMess (its own protocol), and other protocol like MTProto proxy.

We believe VMess is better than Shadowsocks for the following reason:

1. it supports multi-user on a single TCP port.
2. it forces UDP over TCP, i.e. server opens only TCP ports. It is highly suspicious when a server opens both UDP and TCP protocol on the same port number, like what Shadowsocks does.
3. VMess can leverage TLS to provide forward secrecy, when privacy is a concern. Otherwise, VMess uses PSK encryption in favor of less latency.
4. We are adding random padding to VMess protocol. This will be done in the next few releases. We are releasing on weekly basis btw.

@fortuna as you are interested, V2Ray also provides routing based on domain, IP and other factors. With this feature, V2Ray can be configured to bypass domestic IPs, or tunnel traffic to multiple proxy servers based on the destination. For example, if you want to watch Netflix through a US proxy, and also BBC via a UK proxy at the same time, this can be easily done in V2Ray (while it is difficult is Shadowsocks).

[fortuna]

@kalhori124 Thanks for the information. That gives us a little more understanding on how the blocking operates.

• Stunnel: I'm surprised that they block Shadowsocks, but not TLS. That would mean they can put the two protocols in different buckets. I wonder if it's because we have the UDP port open. We don't return replies to invalid requests to protect against probing, but you can still watch traffic, and I wonder if there's some ICMP going on. Exploring having UDP closed and investigating the ICMP packages is something we can try. If TLS works, I imagine simple secure web proxies (over HTTPS) should work too. My team also created https://github.com/caddyserver/forwardproxy. Have you tried that?

• OpenConnect: It seems this is also a TLS-based protocol, which is another sign TLS is not being disturbed.

• Brook: What protocol did you use with it?

[fortuna]

@VictoriaRaymond, thanks for the input!

1. Multi-user on single port is definitely we want to have. I have an experimental version of that as a fork of go-shadowsocks2 that I'll look into upstreaming.

2. I agree on UDP traffic being suspicious. I wonder if opening a different port for UDP would mitigate the issue. We can stop using UDP, but I believe there's a performance cost to that. Unlike system proxies, we operate at the IP layer, intercepting all the system traffic. We can't connect to domain names like SOCKS and need to proxy DNS requests.

3. Forward secrecy is great. That's definitely something we wish to have. However, as far as I can tell, you can only get forward secrecy if you have a handshake, and handshakes are usually easy to detect and block. Maybe VMess is not blocked now, but a handshake fingerprint could make it very easy to block if it gets widely adopted. On Outline, one way to work around the forward secrecy issue is to keep generating new access keys that you use for a short period of time.

4. What attacks do you have in mind? Padding can have significant impact on performance, but it may be an effective measure against fingerprinting the handshake. :+1:

Good to know about your routing features. The challenge to us is that we operate at the IP level, so it's hard to do routing based on the domain. Does V2Ray support intercepting all the traffic or does it work as a system proxy? If you operate at the IP layer, how do you route based on domains?

[VictoriaRaymond]

Maybe VMess is not blocked now, but a handshake fingerprint could make it very easy to block if it gets widely adopted.

TLS is an optional feature for those who require forward secrecy. The bare VMess protocol works with PSK and doesn't have handshake fingerprint.

What attacks do you have in mind? Padding can have significant impact on performance, but it may be an effective measure against fingerprinting the handshake.

As TLS (or HTTP2) gets more and more popular, we assume it will be more often Shadowsocks (or VMess) carries TLS traffic. Shadowsocks itself doesn't have fingerprint, but TLS does. For example, the ClientHello message is around 160 to 170 bytes long, and ServerHello message is 70 to 75 bytes (reference). Shadowsocks's header is somewhat 30 bytes long. Combining these factors, one may tell that this TCP connection uses an unknown protocol to carry TLS traffic. In such case, the connection (or IP) may be blocked by the firewall without knowing whether it is truly Shadowsocks or not.

To mitigate such issue, V2Ray introduces an multiplexing feature, named Mux.Cool (Chinese only, sorry), which combines multiple TCP connections into one. The fingerprint of TLS gets hidden in the master connection.

We also realize that the fingerprint may get exposed when there is only one TLS connection at a time. That's why we are experimenting the random padding feature.

Does V2Ray support intercepting all the traffic or does it work as a system proxy?

It works as a system proxy, similar to Shadowsocks. Some other developers uses tun2socks to intercept all traffic and then proxy them through V2Ray. I guess you already familiar with that part.

If you operate at the IP layer, how do you route based on domains?

There is one difficulty with IP tunnel. When a domain gets DNS poisoned, IP based proxy will fail. V2Ray (if configured) intercepts HTTP and TLS connection, and then tries to correct the destination address based its handshake info.

[fortuna]

@VictoriaRaymond Multiplexing definitely helps with fingerprinting. Have you considered the more standard multiplexed protocols QUIC, or HTTP/2 over TLS? Why did you decide to go with Mux.Cool over other options?

[VictoriaRaymond]

V2Ray supports h2 over TLS too 😊. It was added after Golang finalized h2 package. So the main reason was toolchain.

Mux.Cool was introduced as a simple multiplexing feature. It does multiplexing only. There is no authentication and encryption. Mux.Cool was designed to work with Shadowsocks or VMess, as an additional optimization for short connections.

Here is a little bit about h2 in V2Ray. V2Ray has 3 layer of protocols:

1. content processing (Mux.Cool)
2. authentication (Shadowsocks, VMess, Socks, HTTP, MTProxy, etc)
3. transport (WebSocket, h2, plain TCP/UDP, etc)

For example, one may configure an Mux + Shadowsocks + WebSocket combination. WebSocket is the outer most layer, and Mux is inner most.

The transport layer is mainly for interacting with other tools. The WebSocket or h2 traffic can be proxied through a Web server such as Nginx or Caddy. The traffic of the proxy can be hidden in this way.

There is no clear boundary between these three layers, e.g., Mux + VMess + WebSocket is more or less equivalent to VMess + h2, or h2 only. We keep our own protocols in order to iterate quickly and experiment many features as possible.

[justin223]

Guys, please add obfuscation to server and client implementations, as it's easy to be detected by GFW and the whole IP segment of VPS vendor will be blocked by GFW.

I've tried several vendor (Vultr, DO, Scaleway...) without obfuscation and only a few days working before my IP been blocked. Yes, it was shadowsocks that time that I deployed on my servers. Then I deploy shadowsocks with simple-obfs plugin, both server side and client side, everything goes well till now.

Please check on shadowsocks-libev and simple-obfs repos to find solution to this. Sever side: shadowsocks-libev simple-obfs

Client side: simple-obfs-android simple-obfs

**IT'S URGENT** as the more users, the easier it is to be detected and blocked.

[kapitainsky]

I can confirm @justin223 comments. I am in China at the moment and as few months ago Outline worked without any issues now it stopped after few days. Most likely blocked as changing server IP solves it temporarily. At least as usage in China is concerned some extra obfuscation is needed.

[fortuna]

GoQuiet seems to be an even better alternative: https://github.com/cbeuw/GoQuiet/wiki/Advantages-over-similar-obfuscators.

They seem to make the traffic look like HTTP or TLS. I wonder if it's just a matter of time to block them though. TLS is easy to fingerprint: https://tlsfingerprint.io/top/ https://github.com/LeeBrotherston/tls-fingerprinting

So the censor could write rules that block the specific fingerprint of simple-obf or GoQuiet if they are used widely enough. Protocol mimicry also opens the door to probing attacks. And it seems none of those solutions support UDP :-(

In any case, that's something we want to explore. There are other things to consider, like whether UDP is giving us away, in which case obfuscation wouldn't help.

@justin223 @kapitainsky : when you ran your unobfuscated servers, were they Outline servers? If not, did they have UDP enabled?

[justin223]

@fortuna It was Shadowsocks-libev port, and no UDP enabled, as IMO TCP connections are more reliable than UDP ones.

When my IP was blocked, I cannot SSH to my server, and no ACK received from server side, so TCP connections cannot be established. But on the working server right now, I change cipher from the default "aes-256-cfb" to an AEAD cipher "aes-256-gcm", together with obfuscation feature, and no blocking till now.

[kapitainsky]

@fortuna The servers in my case are shadowsocks-libev 3.2.0 with UDP enabled

[testcaoy7]

@fortuna What is the default cipher that Outline use? I use Outline from Shanghai with all default settings (I do not know how to change cipher settings) and everything appears fine. If Outline uses an AEAD cipher, server should not get blocked because AEAD ciphers prevents active detection of Shadowsocks (At least that is what I heard).

[testcaoy7]

I think GFW may has different sensitivity based on different physical location. In Shanghai, even insecure protocol like PPTP worked......

[fortuna]

@justin223 Good call on switching to the AEAD ciphers. The old ciphers make your server vulnerable to probing attacks, since the server couldn't really tell whether you knew the password.

@testcaoy7 in Outline we use chacha20-ietf-poly1305: https://github.com/Jigsaw-Code/outline-server/blob/69cf89c48e1e92ca38c88d0877758fc7f28e1196/src/shadowbox/server/managed_user.ts#L97 Among the safe ciphers it seems to be the fastest one if you don't have hardware acceleration and the only one that is mandatory in the Shadowsocks current standard.

[hadifarnoud]

@fortuna does this mean Outline will use AEAD? if not, is there a way to do it manually?

[ghost]

@hadifarnoud emmmm...... They already use aead.

[fortuna]

@hadifarnoud The chacha20-ietf-poly1305 we use is AEAD

[x0r2d2]

Nobody didn't mention shadowsocksr. Obfs is already part of the shadowsocksr. @fortuna Take a look to shadowsocksr, maybe you will find it useful for outline project. https://github.com/shadowsocksrr/shadowsocksr

[kklem0]

I can confirmed that it is UDP that gave it away. I'm quite often in China and Dubai, they both detect UDP and block the server when using UDP (when using both pure UDP (Wireguard) or UDP + TCP (Shadowsocks)).

Right now I'm renting servers both inside and outside the countries, use udp2raw-tunnel + Wireguard to tunnel the servers, install Shadowsocks in outside servers, proxy Shadowsocks through the tunnel, and have the ports open in the inside servers, then use Outline clients. As they don't block UDP ports that are inside the country, this works well.

The downside of using udp2raw-tunnel (which uses raw socket to add TCP header on UDP package) was that it requires to add an iptables rule on the server side, but they finally has udp2raw-multiplatform that doesn't require iptables, but then we still need to use 2 ports, one for UDP and one for TCP, which is OK.

Now that Wireguard finally works well in all platforms that I care about (iOS as well 🙂), I believe the best solution is to use Wireguard + udp2raw, then all traffic goes through the FakeTCP port which still has all the cool things of using UDP.

Please do not remove Shadowsocks support in all the clients though, as it is right now the best solution we could get because system proxy solution of Shadowsocks cannot tunnel UDP packages.

[stefanovazzocell]

@fortuna How about combining multiple servers and automatically switching between then after a random amount of time (or bandwidth)? This could spread the traffic a little and maybe draw less suspicion over a single server, hopefully making it harder to be sure that a server is used as a vpn. Or at least make blocking more costly.

Anyone has any thoughts on this? I am mostly thinking about the second comment made by @Tintac-CN ... Hopefully this idea can help mitigate detection. Imagine creating "clusters" and automatically provision them and have outline do some smart routing between them.

It would be cool to give server operators (or even users in some cases) the option to switch between different configurations and adapt to what works best for a specific situation. Maybe that could help people collect more feedback for outline (but unfortunately this last option will possibly increase the complexity for the server operators... I don't know if you rather keep it simple)

[kklem0]

@fortuna How about combining multiple servers and automatically switching between then after a random amount of time (or bandwidth)? This could spread the traffic a little and maybe draw less suspicion over a single server, hopefully making it harder to be sure that a server is used as a vpn. Or at least make blocking more costly.

Anyone has any thoughts on this? I am mostly thinking about the second comment made by @Tintac-CN ... Hopefully this idea can help mitigate detection. Imagine creating "clusters" and automatically provision them and have outline do some smart routing between them.

It would be cool to give server operators (or even users in some cases) the option to switch between different configurations and adapt to what works best for a specific situation. Maybe that could help people collect more feedback for outline (but unfortunately this last option will possibly increase the complexity for the server operators... I don't know if you rather keep it simple)

Tried that in China and busted.

[stefanovazzocell]

@clementhk Alright, thank you for the info. How about compared to the 'usual'? Did it last longer before being detected? Did it get detected faster?

[testcaoy7]

Please give up Shadowsocks. In fact, there is another project called "Trojan" (https://github.com/trojan-gfw/trojan). Trojan uses real TLS to encrypt traffic and firewalls will see these traffic as normal HTTPS.

Set up Trojan is very easy (just like shadowsocks it uses a password.) and server certificates can be obtained freely from Lets Encrypt.

[ghost]

@testcaoy7 But you still need register a domain name for your server(according to their manual). There're so many project use real TLS (even real HTTPS and can be proxy by a real HTTP server) and easy to setup, and they all need a domain name.

[testcaoy7]

@studentmain Oops... I am sorry. I forget the domain name thing. Can we issue IP address based self-signed certificate to address the domain name issue?

[ghost]

According to their document, we shouldn't do that:

Apply for or self-sign (NOT RECOMMENDED) an SSL certificate.

So, according to their document, the last option is following step:

1. buy a domain automatically
   • Can we do it with DO or GCP?
   • How about self hosting server?
   • Buy domain from another provider?
   • How if user already have a domain or just don't want to buy one?
2. then set DNS record
3. maybe deploy a fake website on server automatically?
   • What kind of fake site?
   • How if user already has a real website on it?
4. then apply for a free cert automatically
5. then deploy the software itself.

Shouldn't be many technical problem problem here. As Outline-Manager can purchase server, it's easy for it to purchase a domain.

[testcaoy7]

@studentmain Maybe you can maintain a fork of trojan which uses PSK cipher suites. RFC5487 defines secure PSK cipher suites such as TLS_PSK_WITH_AES_128_GCM_SHA256. Certificates and domains are not needed in PSK cipher suites.

PS: I suggested supporting PSK cipher suites to the author of trojan before, but he/she decided not to support this feature because "it does not look like normal HTTPS behavior". I do not know if this is true. But I tried a legacy PSK cipher (PSK with AES-CBC) with stunnel and it works very well.

[ghost]

@testcaoy7 Uncommon cipher (specifically, PSK) is a fingerprint too.

[fortuna]

On self-signed certificates @testcaoy7 if you use a self-signed certificate, without a mechanism to validate it (we use a certificate fingerprint), then the censor can easily man-in-the-middle your connection.

On using HTTPS If you want to use HTTPS, you can use Caddy's forward proxy plugin. Caddy's handle the TLS certificate generation and renewal for you, and the plugin was designed to be probing-resistant. However, you still need a domain, and there's no user management UI. Not as easy as Outline. Also: HTTPS doesn't proxy UDP, so videos will be forced over TCP and have a poorer performance.

[fortuna]

On rotating IPs One solution that I believe will be easy to implement, if you have a domain name :unamused:, is to make your domain resolve to multiple IP addresses, and make all the IP addresses point to your server. Then the client could rotate over the IPs for each connection. That's not currently implemented, and it's a little hard to implement, since it would have to be in the shadowsocks-libev code. Once we migrate to the go-tun2socks network stack, it will be a lot easier.

One nice thing about domain names is that you can change the IP without resending keys, making it easier to recover from blocking. However the domain resolution may be still blocked, so we will need to be smart about that (e.g. using encrypted DNS, caching IPs, talking directly to authoritative, etc).

[fortuna]

On using Single Port Outline now supports serving all users on a single port. We've heard from server admins that setting the port to 443 made their servers not be blocked anymore. I recommend people here try that and report back.

You can do that by adding "portForNewAccessKeys":443 (don't forget the quotes) to shadowbox_server_config.json and calling docker restart shadowbox. For reference server_config.ts has the config file format.

Update: You can now edit the port for new keys on the Outline Manager UI, or via the management API

[siavashs]

I tested port 443 on Digital Ocean yesterday and it was not reachable from Iran.

[ghost]

I have been using outline for a few months now and it usually took about 30 days for node IP to ban in Iran. however it has recently been faster. My last Vultr node got banned after 5 days with 20 users and total 40GBs of bandwidth usage which I assume is not high.

I am creating my next server with "portForNewAccessKeys":443 and I will let you know if it would banned or not.

As @fortuna previously mentioned, "One of the goals of making it easy to create a server was that you can do it whenever it gets blocked." and I believe this goal has been achieved by the Outline Project. However, if there was some migration feature available for users, it would have been less time-consuming whenever the nodes get banned. My point is if we could transfer users keys from one (presumably banned) Outline Server to another fresh one with the least possible time, it could justify the users to continue using Outline. Right now, I create each user one-by-one in the new server which is nightmare to be honest.

I also like to mention that I have had a Cisco OpenConnect server which has been active for more than two years with more than 50 users and it has not been detected or banned even once. I am not sure about the underlying architecture of OpenConnect's data transmission but as a side note, I think it could be helpful to look into.

[kalhori124]

@fortuna

If you use Outline ( Shadowsocks ) in Iran, China, Azerbaijan, and the United Arab Emirates, your VPS IP address will be blocked after a while.

I am using OpenConnect, Stunnel, and Vmess protocols and there is not any problem with these protocols, but the installation of these protocols on the server side and client side is not easy as Outline VPN is for ordinary people.