Configuring the mKCP protocol in the 3X-UI and X-UI panels

The first question that may arise is: Why?
All the popular recent articles described setting up the VLESS protocol with XTLS-Reality, the essence of which is that the proxy server skillfully disguises itself as some popular site, imitating its behavior and posing as its real certificate. Today, it is still the most powerful and advanced proxy block bypass tool. But nothing in the world is perfect, and this option has a couple of disadvantages:

1. If the resource you are masquerading as is blocked, or simply has any technical problems on it, your proxy will also stop working (for example, microsoft.com, popular for these purposes, disabled TLS 1.3 for some time; as a result, many people could not connect to to your proxies).

2. Due to the use of TLS, the handshake when establishing a connection here is noticeably longer than in other protocols, which affects the comfort of surfing. In some cases, changing the masquerading domain helps (ideally, the server you are masquerading as should be located in the same country as your VPS, and ideally in the same data center), but for some, the connection establishment time can be critical .

3. VLESS with XTLS Always should work on port 443. In some cases (you share a server with someone else, or connect through a strict corporate proxy that MitM does) this may not be suitable for you.

To solve problems 1 and 2, as a fallback, the instructions often give advice on setting up an additional connection using the ShadowSocks-2022 protocol so that you can always connect to your proxy server, even if something happens to the XTLS-Reality masking. Shadowsocks is a great thing, but as time has shown, in the event of blocking based on white lists of protocols (which Roskomnadzor had fun with some time ago, and which is sometimes done in China according to the latest GFW-Report), it will also stop working – simply because Shadowsocks is not similar to any of the existing protocols, and it will definitely not be on the white list.

And here mKCP comes to our aid. mKCP is a variant of the KCP protocol, which was originally invented to work through poor communication channels with a lot of packet loss (for example, when you are using 3G/4G and the network in your area is heavily congested during peak hours). For us, it is valuable for its other properties:

1. It is very easy to set up. There is no need to look for any masking domains, think about certificates, etc.

2. It does not work over TCP, but through UDP. As, again, practice shows, censors often focus on TCP filtering and forget about UDP, so it’s very good to have such an alternative;

3. It can disguise its packet headers as uTP (BitTorrent), DTLS (used in WebRTC, for example for instant messaging calls), SRTP (Facetime) and WeChat.

4. As a bonus (in fact, this was its main purpose), with fine tuning on the server and on the client (uplink/downlink parameters), it can greatly help out when working through an unstable communication channel.

   Not bad, right?

However, there are also disadvantages. mKCP is only supported in XRay based clients.
What will work: v2RayN (Windows), Nekoray (with XRay core), v2RayNG (Android), Streisand (iPhone) and other XRay based clients. What Not will work: Hiddify-Next, Nekobox for Android, and other clients based on Sing-box.

Well, yes, we need to clarify that mKCP in our case is only a transport protocol, and work inside it will be carried out using the already familiar VLESS.

I foresee the question: is it possible to use different protocols on the server at the same time? Answer: yes, you can, but it’s better not to mix XTLS-Reality with the rest. That is, you plan to use XTLS-Reality, connect through it, and leave Shadowsocks and mKCP for a rainy day, if something happens. Or vice versa, if Shadowsocks and mKCP work more stable and responsive for you, use one of them, and let Reality be in reserve.

Setting up a connection in the panel

Setting everything up is not easy, but very simple.

Given: you have the 3X-UI or X-UI panel installed, for example, according to the instructions from MiraclePtr. In it you can already have inbounds created for VLESS+Reality or Shadowsocks. And now we need to add a new inbound for mKCP. On the inbounds tab, click Add Inbound and fill in:

Remark – name, can be anything (I have HelloHabr)

Protocol – “vless” (this is a protocol for authentication, it will be wrapped in mKCP)

ListenIP – you can leave it blank (listen on all addresses), or specify the specific IP address of your server where you want to accept connections

Port – the panel will generate it automatically, you can use any one. One thing: Tor with the Snowflake transport uses ports 30000-60000, so if you disguise it as WebRTC, choose a lower port, well, just in case, you never know, suddenly Roskompozor will have an aggravation 🙂

Client – the panel will create a new user with a UUID for you.

Let's continue:

Transmission – this is important, choose mKCP

Obfuscation – choose what to disguise yourself as, for example, uTP (this is Bittorrent) or DTLS (this is WebRTC), or something else. I can’t give you specific advice on “which is better,” but no one forbids creating several inbounds on different ports with different types of obfuscation. The main thing is not to choose “wireguard” 🙂

Password – the panel will generate a password automatically, it will be used as a key to encrypt the transmitted data.

MTU, TTI – leave it as default. You can then try to reduce the MTU if there are problems with access to some resources, but the standard 1350 should work without problems.

Uplink/Downlink – to begin with, you can leave it as default. In theory, there should be values ​​corresponding to the real server channel, and – important – in megabytesnot megabits! That is, if your server has a channel of 100 megabits, it should be 12/12. But, as I said, everything worked fine for me with the default settings of 5/20, and changing these values ​​only makes sense if everything is working very slowly or unstable for you.
If working through poor communication channels is important to you, then on the client side you will need to configure the same parameters in accordance with the communication channel parameters. If you don’t have problems with the connection, then we don’t touch these values ​​on the client either.

Read Buffer / Write Buffer – you can start with the default value of 2 megabytes. The higher the value, the higher the data transfer speed can be, but the more memory the proxy server will consume.

Everything else is as in the screenshot.

We save the settings and see that we have created our new inbound:

In some versions of the panel, you will also need to restart XRay or the panel itself.

After this, you can open the client field for our new inbound, and just like for VLESS/Reality and Shadowsocks, there you can get a connection string or QR code that you can drive/scan into your mKCP-enabled client and connect to the proxy .