Simplified instructions for deploying VLESS and Shadowsocks-2022 proxies based on XRay server on a Linux server

What are we doing here?

1. Deploying a proxy based on the VLESS and Shadowsocks-22 protocols using the XRay server

Why is this necessary?

Roskomnadzor has learned to block popular VPN protocols quite well: OpenVPN, Wireguard and some others. VLESS allows you to disguise traffic as a regular TLS connection to a site, which at this stage of Roskomnadzor's development bypasses all existing methods of blocking traffic and allows you to have unfiltered access to the Internet.

Why do we need Shadowsocks-22 then?

VLESS uses a “fronting” mechanism – from the censor's point of view, we simulate a connection to a regular site, not to a VPN or proxy. This requires an unrelated site – for example, microsoft.com. Sometimes this can lead to problems: the censor can block access to the site by domain, and then everything will stop working. In some cases, the site owner can limit connections to it, suspecting bad activity on our part – and then everything will stop working too.

The proxy on Shadowsocks-22 is deployed for the company as a backup option for accessing the network, in case the VLESS configuration suddenly stops working.

Restrictions:

Both VLESS and Shadowsocks-22 are PROXY, not VPN. With all the nuances that follow from this.

Shadowsocks-22 is more susceptible to blocking, since from the point of view of the censor's filters the traffic looks like a random mess. This allows blocking such proxies by introducing “white lists” – i.e. only the traffic that the censor clearly recognizes will be allowed. In this way, access to Shadowsocks proxies has been repeatedly blocked in Dagestan and Siberia. VLESS is less susceptible to such blocking – at the moment, an attempt to block it by the censor will lead to the inoperability of most sites.

What will be required?

1. Debian 11\12 or Ubuntu 22.04\24.04 + basic reading and console skills
2. The server should not be in the Russian Federation – but, for example, in the Netherlands. These can be purchased for rubles and on a Russian card through many hosters (for example, IHOR or VDSina). Any server with 1-2 streams and 512 megabytes of memory should be enough.

Install XRay on the server:

1. apt install curl mc htop nano 2. bash -c “$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)” @ install 3. systemctl stop xray.service 4. ./usr/local/bin/xray uuid 5. ./usr/local/bin/xray x25519 (the keys should be written down, they will not be saved anywhere as a file) 6. nano /usr/local/etc/xray/config.json

Example config:

{
"log": {
"loglevel": "info"
},
"routing": {
"rules": [],
"domainStrategy": "AsIs"
},
"inbounds": [
{
"port": 42639,
"tag": "ss",
"protocol": "shadowsocks",
"settings": {
"method": "2022-blake3-aes-128-gcm",
"password": "сюда вставить выхлоп команды openssl rand -base64 16",
"network": "tcp,udp"
}
},
{
"port": 443,
"protocol": "vless",
"tag": "vless_tls",
"settings": {
"clients": [
{
"id": "сюда вставить ID из выхлопа ./usr/local/bin/xray uuid",
"email": "user@server",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "www.microsoft.com:443",
"xver": 0,
"serverNames": [
"www.microsoft.com"
],
"privateKey": "сюда вставить приватный ключ из выхлопа ./usr/local/bin/xray x25519",
"minClientVer": "",
"maxClientVer": "",
"maxTimeDiff": 0,
"shortIds": [
"сюда вставить выхлоп команды openssl rand -hex 8"
]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls"
]
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
]
}

The domain microsoft.com is given as an example, you can and should replace it with something of your own. It is highly recommended to use this to find a suitable domain for masking. The main requirement is TLSv1.3 support. It is best to choose a site physically hosted in the country of your server.

We prepare the configuration lines that can be inserted into the client; they look something like this:

VLESS:

vless://@:443?security=reality&encryption=none&pbk=&headerType=none&fp=chrome&type=tcp&flow=xtls-rprx-vision&sni=&sid=#

Shadowsocks-22:

ss://@:#

Any of them can be crammed into QR as plain text, most clients can import them. You can generate a QR code, for example Hereyou will need to select the “Text” option in the “Contents” field and click the “Generate” button.

We install the client and put the config into it.

Android: Hiddify https://github.com/hiddify/hiddify-nextv2rayNG https://github.com/2dust/v2rayNG/Nekobox for Android GitHub – MatsuriDayo/NekoBoxForAndroid: NekoBox for Android / sing-box / universal proxy toolchain for Android

iOS: Foxray, Streisand (available in AppStore)

Desktops: Nekoray https://github.com/MatsuriDayo/nekoray and Hiddify https://github.com/hiddify/hiddify-next

At this point it should already work – but it's better to bother and file the config further so that it protrudes less on the surface.

Be sure to rehang ssh from port 22 to any other port, somewhere on 10-40 thousand ports. This is necessary so that the server to which we send our connections, pretending to be a law-abiding site, does not respond to ssh. Otherwise, for a potential Roskomnadzor scanner, this will be a practically cast-iron argument to decide that a proxy is running on this server and ban it on TSPU.

Resolve the domain that is used for fronting (the domain from serverNames in the config) to IP using nslookup and create the following rules for the firewall:

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 443 -j DNAT --to-destination <IP>:443
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination <IP>:80

What these rules do is forward traffic from a potential censor scanner to the real site we're pretending to be – i.e. UDP on port 443 and TCP on port 80. This helps with camouflage.

It is recommended to make these rules persistent, i.e. put them in rc.local, systemd service or somewhere else.

It is highly recommended to study what routing is. This is necessary, among other things, to allow sites located in the Russian Federation, and the rest through a proxy. If you do not do this, the censor can compare the resources you access and assume that you are using a proxy, and then block it. There have already been cases of such blocking in China, and it would be naive to assume that Roskomnadzor will never learn this.

Below is an example of how this is configured in Nekoray on the desktop. Clients like Hiddify offer to select a region of operation at the first launch, with automatic application of the necessary routing rules based on public geoip/geosite. Preferences->Routing setting->Simple route->Custom route and paste the config. If necessary, add suffixes or keywords. The list can and should be supplemented depending on your own preferences.

{
"rules": [
{
"domain_keyword": [
"google",
"vkontakte",
"userapi",
"yandex",
"yastatic",
"dzen",
"yahoo",
"microsoft",
"tinkoff",
"tbank",
"gosuslugi",
"lkfl",
"lkfl2",
"nalog",
"sberbank"

],
"outbound": "direct"
},
{
"domain_suffix": [
".ru",
".su",
".by",
".рф",
"vk.com",
"userapi.com",
"youtube.com",
"gstatic.com",
"gosuslugi.ru",
"esia.gosuslugi.ru",
"tbank.ru",
"www.tbank.ru",
"sme.tinkoff.ru",
"lkfl2.nalog.ru",
"sberbank.ru",
"www.sberbank.ru",
"sber.ru",
"www.sber.ru",
"online.sber.ru",
"online.sberbank.ru"

],
"outbound": "direct"
}
]
}

In mine tg channel I have posted all the current methods for bypassing YouTube blocking with detailed instructions, you can choose the most suitable methods for yourself – for Smart TV, for PC, for Phone, Android, IOS, etc., as well as links to articles with various VLESS protocol settings. Everything is secured!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *