HOW TO BECOME AN AUTHOR Leading Russian companies talk about the present and future of clouds
My feed All streams Development Administration Design Management Marketing Sciencepop To come in
Internal error
Your account Sections Information Services
To come in Articles Site structure Corporate blog
Registration News For authors Display advertising
Hubs For companies Native projects
Authors Documentation Educational programs
Sandbox Agreement Startups
Confidentiality
© 2006–2024, Habr Technical support Language setting
HOW TO BECOME AN AUTHOR
My feed All streams Development Administration Design Management Marketing Sciencepop To come in
+42
Deleted-user584
April 13, 2023 at 06:24107
pm
STORIES
Bypassing blocks: setting up an XRay server for Shadowsocks-2022
and VLESS with XTLS-Vision, Websockets and a fake website
Average 14 min 196K
Linux setup*, Information Security*, System administration*, Network technologies*
Tutorial
This article is published under a Creative Commons BY-NC-SA license .
Previous articles in the series:
" Modern technologies for bypassing blocking: V2Ray, XRay, XTLS, Hysteria and all, all, all "
" Client programs for protocols for undetected bypass of site blocking: V2Ray/XRay, Clash, Sing-Box,
and others "
JOB
We've sorted out the protocols, sorted out the clients, now it's finally time to talk about how to set up
your personal proxy server with modern protocols to bypass blocking. We will be setting up a server System Administrator
84 vacancies
based on XRay (which is a fork of the famous V2Ray, and I will also mention Sing-Box a little) with
Shadowsocks-2022 and VLESS protocols with XTLS-Vision transport and a fake website to protect DevOps engineer
against detection. And as a backup option on the same server, we will configure fallback on 43 vacancies
VLESS+Websockets so that we can work through a CDN like Cloudflare if suddenly your server’s IP
Information Security Specialist
address gets blocked. At the end I will provide the settings for desktop and mobile clients to connect to 144 vacancies
all this.
All vacancies
Go.
I will describe the setup under Debian or Ubuntu Linux. If you have another distribution on your VPS, UPCOMING EVENTS
then everything will be approximately the same, although some commands and package names may
differ.
So, let’s say we already have a VPS with Debian or Ubuntu in some overseas jurisdiction, it has an IP
address, SSH is configured on it, and in general everything is fine so far. And you must also have some
kind of domain, not necessarily a paid one (although now with promotions you can register a domain in
some not very popular zone for just a dollar or two a year), even DynDNS will do. If you don’t have any
of the above, I advise you to read this and this article, which at the beginning describes the basic
installation and configuration of a VPS with Linux and registering a free domain via DynDNS. Well, we
move on. One day offer from VSK Co
May 16 – 17 09:00 – 18:00
I will give the first configuration option for an “empty server” - this is if there are no other services on your
server (but then you can also add a website, yes). In the second half of the article, I will tell you how to Online
configure XRay when you already have a web server running on your machine and you don’t want to
More details in the calendar M
touch its configuration again. The third option will be with Docker for the little ones .
Option one, complete, detailed
The XRay developers have prepared a script that automatically downloads XRay for the system in use
and creates a systemd unit (thanks to @alegz81 for reminding): https://github.com/XTLS/Xray-install
Installed in one long command
$ bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ inst
The only difference from the configuration described in the article will be that the XRay configs will be
located not in /opt/xray, but in /usr/local/etc/xray/.
Or we can install everything manually.
Let's go here: https://github.com/XTLS/Xray-core/releases and download the latest XRay-core build:
$ wget https://github.com/XTLS/Xray-core/releases/download/v1.8.0/Xray-linux-64.zip
We create a directory, unpack and make the file executable (it comes in a .zip archive, so permissions
are lost when packing and unpacking):
$ mkdir /opt/xray
$ unzip ./Xray-linux-64.zip -d /opt/xray
$ chmod +x /opt/xray/xray
Next, let's create a systemd unit and insert the following text there (I use nano, you, of course, can use
vi and whatever you like):
$ nano /usr/lib/systemd/system/xray.service
[Unit]
Description=XRay
[Service]
Type=simple
Restart=on-failure
RestartSec=30
WorkingDirectory=/opt/xray
ExecStart=/opt/xray/xray run -c /opt/xray/config.json
[Install]
WantedBy=multi-user.target
$ systemctl daemon-reload
$ systemctl enable xray
Please note that in this case xray will be launched as the root user. This is not very good in terms of
security, I did it this way in the example to simplify the manual, but in a good way you need to create a
separate user for xray, run it as him, do not forget to give him read rights to directories and files from
certbot/letsencrypt ( more on this a little later), and in order to be able to connect the server to port 443
or other <1000, set a special option for the binary/process.
This completes the installation of XRay; further steps will be the same both for manual setup and for
using a script.
We will need TLS certificates.
Install certbot and request a certificate for our domain (for example, example.com):
$ apt install certbot
$ certbot certonly --standalone --preferred-challenges http -d example.com
If you need to have two domains or a domain and a subdomain (for example, one will be accessible
directly, the other via a CDN), then you can specify another -d argument in this command and you will
have a certificate for two domains at once. It also supports wildcards.
Certbot will ask for your email just in case, ask if you agree with the rules, request a certificate from
LetsEncrypt, put it in the /etc/letsencrypt folder and create a rule so that it is updated every 3 months.
Every time you update a certificate, you need to restart the XRay server, let's ask certbot to do this
automatically:
$ nano /etc/letsencrypt/renewal/example.com.conf
and add the line at the end
renew_hook = systemctl reload xray
Now let's get to the fun part. Create and edit the config:
$ nano /opt/xray/config.json # или в /usr/local/etc/xray/ в случае использования скрипта
{
"log": {
"loglevel": "info"
},
"routing": {
"rules": [],
"domainStrategy": "AsIs"
},
"inbounds": [
{
"port": 23,
"tag": "ss",
"protocol": "shadowsocks",
"settings": {
"method": "2022-blake3-aes-128-gcm",
"password": "aaaaaaaaaaaaaaaabbbbbbbbbbbbbbbb",
"network": "tcp,udp"
}
},
{
"port": 443,
"protocol": "vless",
"tag": "vless_tls",
"settings": {
"clients": [
{
"id": "7957c33c-d9ca-11ed-afa1-0242ac120002",
"email": "user1@myserver",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none",
"fallbacks": [
{
"path": "/myverysecretpath",
"dest": "@vless-ws"
},
{
"dest": "8080"
}
]
},
"streamSettings": {
"network": "tcp",
"security": "tls",
"tlsSettings": {
"alpn": [
"http/1.1",
"h2"
],
"certificates": [
{
"certificateFile": "/etc/letsencrypt/live/example.com/fullchain.pem",
"keyFile": "/etc/letsencrypt/live/example.com/privkey.pem"
}
]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls"
]
}
},
{
"listen": "@vless-ws",
"protocol": "vless",
"tag": "vless_ws",
"settings": {
"clients": [
{
"id": "7957c33c-d9ca-11ed-afa1-0242ac120002",
"email": "user2@myserver"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "ws",
"security": "none",
"wsSettings": {
"path": "/myverysecretpath"
}
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
]
}
What to pay attention to. In inbounds we set the rules for processing incoming connections - the first is
Shadowsocks-2022 on port 23 (you can use any other port, of course). The fact that this protocol version
is 2022 is indicated by the method "2022-blake3-aes-128-gcm". The key can be any in hexadecimal
form, its length depends on the type of cipher, in the example a 128-bit cipher, if you use a 256-bit
cipher, then the key, accordingly, must be twice as long.
Next comes VLESS via TLS, standard port 443. In the “clients” section, client users are specified, in the
example there is only one. The client ID can be generated by any online UUID generator. Also, the “flow”
option is set for the user with the value “xtls-rprx-vision”, meaning that this user will connect using XTLS-
Vision. In the "streamSettings" settings you can see the paths to the certificates that we requested from
LetsEncrypt; the path should contain a file corresponding to your domain. “fallbacks” set rules about
what to do if the user was not identified, or the connection is not made through the pure VLESS protocol:
if we see an HTTP request with the URI /myverysecretpath, then we pass the connection to the vless-ws
handler, for everything the rest - to port 8080, where we will have a web server with a fake (or even real)
website.
And finally, the third option is VLESS via Websocket, on the same port 443. Thus, for example, you can
connect to the server not directly, but through a CDN, which will help if your server is suddenly blocked
by censors or if you are connecting through a strict corporate proxy. Setting it up is almost the same as
the previous point, the user UUID is the same, the only difference is that there is no “xtls-rprx-vision”
option, because it will not work through a CDN, and there is a “wsSettings” section, where the same
secret path is specified on the server /myverysecretpath as in fallbacks.
See also: Features of proxying via CDN/Websocket/gRPC to bypass blocking
In the comments to the previous article, it was mentioned that websocket transport does not always work
reliably and efficiently, and even with very large volumes of transmitted traffic, Cloudflare may get
offended and start asking to switch to a paid plan. Therefore, instead of websocket, some advise using
gRPC transport. I tried, and I couldn’t configure fallback on gRPC properly. In a comment to the article,
the habrauser @s7eepz attached an example of setting up fallback on gRPC via Nginx - but an
important point, Nginx must be built with a gRPC module. In Debian/Ubuntu and in the official
repositories from the developers it is compiled without it.
And as you may have noticed, the config mentions port 8080 for fallback. On it we should listen to a web
server with a masking site. The easiest way to do this is to install nginx behind it:
$ apt install nginx
$ nano /etc/nginx/sites-enabled/default
$ systemctl restart nginx
Where /etc/nginx/sites-enabled/default in the simplest case will be something like this:
server {
listen 127.0.0.1:8080 default_server;
listen [::1]:8080 default_server;
root /var/www/html;
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
try_files $uri $uri/ =404;
}
}
(the main change compared to the default configuration is that the server does not listen on all
addresses, but only on localhost, and not on port 80, but on port 8080).
After this, when you try to connect to your IP address with a regular browser (something that censors
can automatically do when trying to identify a proxy server), Nginx will respond, serving the pages
located in /var/www/html. By default there is a stub there, you can put some pages and videos with
kittens there.
If you are too lazy to bother with raising a fake site, there is a second option - let the web server ask
those connecting for a login and password, and reject all entered options:
location / {
auth_basic "Administrator’s Area";
auth_basic_user_file /etc/htpasswd;
}
The /etc/htpasswd file itself may not even exist at all - we do not need to check the password is correct,
we will reject everything, pretending that the password did not match. Nginx will still start even without
this file.
In the browser it will look like this
The third option is to redirect connections to some other site. XRay does not know how to transfer
connections to external servers, only to local ones, so Nginx will help us here again:
server {
listen 127.0.0.1:8080 default_server;
listen [::1]:8080 default_server;
server_name _;
location / {
proxy_pass http://lib.ru;
}
}
As a result, when you try to open a proxy address in your browser, the lib.ru mirror will be loaded -
replace it with some other site. It’s clearly not worth using any popular or sophisticated sites for this, but
some godforsaken hack of the Web 1.0 era or a nameless webftp file dump is already possible. And to
prevent some stupid bots or search engine spiders from giving you traffic, you can add options for the
ratelimit module in Nginx and limit the data transfer rate from the “redirected” site, for example, to 1
megabit.
Restart xray again:
$ systemctl restart xray
Let's check that everything started correctly:
$ journalctl -u xray
For example, XRay may complain that it cannot parse a JSON file, usually this is due to extra commas
at the end of the {} block, in this case it will indicate which line the error is on. We correct the errors,
restart again, and move on to setting up clients.
I will show Nekoray/Nekobox as an example, but absolutely the same can be done in another client, the
settings will be the same. Download Nekoray , select core Sing-box in the settings (and Nekoray
magically becomes Nekobox).
Go to server -> new profile, and then fill in the fields as follows.
For direct VLESS + XTLS-Vision:
For VLESS-over-Websockets:
For Shadowsocks:
Select the desired connection in the list on the main window, right-click -> Current Select -> URL test,
and see in the log and in the window that the ping is successful:
All. Now just click the System proxy or VPN mode checkbox at the top, and you will be able to access
the Internet through your new proxy.
To set up in other clients or on other devices (for example, on a smartphone, or share the server with
friends), right-click on the server, select Share -> QR code and Link, and get a link that you can send to
someone, for example, via Telegram and QR code that can be scanned with a camera in many clients:
Accordingly, then on a mobile device in Nekobox, or in v2rayNG, or in Wings X, or in any other client,
click something like “Add server” -> “Scan QR” - and that’s it, the new server is in your list, you can
connect.
Important: some clients, when adding a server via a link or QR, lose the uTLS setting, so double-check
that everything is in place after adding a new server.
Lifehack #1: you can also go crazy and add SSH as a connection to Nekobox, an example configuration
is here (first you will need to connect with the native system ssh client, generate client ssh keys and
make ssh-copy-id , in Windows this works too).
Lifehack #2: In order not to forget to set a uTLS fingerprint for each connection separately, you can set it
to the default value in the general settings of Nekobox:
Option two, half- nished
Now let’s imagine that you already have a web server with some website installed on your VPS, TLS
certificates are already configured, and everything else, and you just need to carefully add a proxy,
preferably without breaking the server config.
Option one: have another subdomain and resolve TLS connections at the SNI handshake stage using,
for example, HAProxy or the ssl_preread module in Nginx. Then setting up XRay will be completely
similar to that described in the previous paragraph, except that you will only need to move it from 443 to
another port.
Option two: the TLS session will be terminated by the web server, and if a specific URL is accessed, it
will pass the connection to the proxy. This option is simpler, the only limitation is that no XTLS (neither
Vision nor Reality) will work, and the performance will be slightly lower.
So, let's say you have Nginx (or any other web server with some website) configured. You need to
configure the redirection of requests to a specific URL to a proxy using the web server. There are two
options - use websockets (and you must remember to pass headers specific to them), or use gRPC (if
your server can proxy it). In Nginx it will look something like this for websockets:
location /myverysecretpath {
proxy_pass http://127.0.0.1:8888;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
}
And the XRay config will be like this:
{
"log": {
"loglevel": "info"
},
"routing": {
"rules": [],
"domainStrategy": "AsIs"
},
"inbounds": [
{
"port": 23,
"tag": "ss",
"protocol": "shadowsocks",
"settings": {
"method": "2022-blake3-aes-128-gcm",
"password": "aaaaaaaaaaaaaaaabbbbbbbbbbbbbbbb",
"network": "tcp,udp"
}
},
{
"listen": "localhost",
"port": 8888,
"protocol": "vless",
"tag": "vless_ws",
"settings": {
"clients": [
{
"id": "7957c33c-d9ca-11ed-afa1-0242ac120002",
"email": "user1@myserver"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "ws",
"security": "none",
"wsSettings": {
"path": "/myverysecretpath"
}
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
]
}
As you can see, it is almost the same as in the previous version, only there is no inbound for a “direct”
TLS connection, and there is nothing about TLS at all - the server listens to port 8888 and immediately
processes it as a web socket. /myverysecretpath, of course, must match in the web server config and in
the proxy config.
The client settings for this option will be completely similar to the client settings for Shadowsocks and
VLESS+Websocket from the previous paragraph.
The option with gRPC following the example from the official turnip with examples did not work for me
(my heart knows there is some kind of trick with TLS and redirecting to it) - so if anyone has working
configs for XRay and Nginx with gRPC, share in the comments.
Option three for the laziest (Websockets-only)
$ apt install docker.io docker-compose
$ mkdir /etc/xray/
$ nano /etc/xray/config.json
$ nano /etc/xray/Caddyfile
$ nano docker-compose.yml
/etc/xray/config.json:
/etc/xray/Caddyfile
docker-compose.yml
$ docker-compose up -d
Here Caddy is used as a web server; it itself requests and updates TLS certificates (certbot is not
needed). There will be no IPv6, but everything else works in principle - again, only WS, and no XTLS.
Lazydocker can help you.
Nuances and wisdom
To date, the VLESS+XTLS-Vision combination is the most proven and resistant to blocking. However,
there are a couple more things to keep in mind:
1. Be sure to use uTLS on clients with the correct TLS fingerprint. Clients who do not know how to use
uTLS should not use it;
2. Be sure to set up a fake website or set up a fallback redirect to some fraudulent address;
3. There is an interesting bug associated with uTLS: if for some reason you cannot connect when
using XTLS-Vision, an error like “failed to use xtls-rprx-vision, found outer tls version 771” is visible
in the server logs, try changing the uTLS version. For example, when I select “android” the client
does not connect, but when I select “chrome” everything is fine;
4. It's better with XTLS than without it;
5. When debugging the configuration, in case of problems with TLS, the "allowInsecure" option on the
client can help;
6. It is highly recommended to configure routing rules on clients so that traffic to .ru domains and hosts
with Russian IPs goes directly and not through a proxy (clients come with a GeoIP database for
this).
GeoIP from Nekobox (and other clients) knows Russian bands, but GeoSite no longer knows, alas.
As a result, this setup works for me; GeoIP is activated in the standard way in Nekobox:
Nekobox doesn’t know how to rule for suffixes, but the sing-box at its core can do them, so click
“Custom” and write it down
like this
After this, all traffic to .ru domains and Russian IP addresses will go directly.
If you need to block completely, then in the first window, instead of Direct, insert it into Block, and in
the JSON code, correct direct into block.
You can also have two servers (a low-end server in the Russian Federation can be rented for 60
rubles), and having accepted the connection, transfer it to the next server, specifying in the
outboundTag not freedom or block, but the tag of the corresponding outbound (XRay can work
immediately and both as a server and as a client, don’t forget).
7. When proxying to Nginx or any other server, it is also good practice to proxy HTTP/1.1 and HTTP/2
separately.
In the Nginx config for this you need something like this:
listen 127.0.0.1:8888;
listen 127.0.0.1:8889 http2;
And in the XRay config:
"fallbacks": [
{
"dest": "8888"
},
{
"alpn": "h2",
"dest": "8889"
}
]
What about CDN?
So far, there are two known CDNs that allow you to work with this on free accounts: Cloudflare allows
you to proxy Websocket and gRPC , GCore allows you to proxy Websocket (I don’t know about gRPC, I
haven’t checked). They say about Cloudflare that when proxying very large volumes via websockets,
they may ask you to switch to a paid plan; this is not written about gRPC.
To work via CDN, you will need a full-fledged domain (not DynDNS), which can be delegated to the NS
CDN network and managed there. Next you need to enable proxying for a specific domain:
Life hack : if you have a cheap IPv6-only server, you can specify only an AAAA record (IPv6) for it, and
Cloudflare will still allow you to connect to it over IPv4 through its network. Savvy .
Well, don’t forget to separately enable WS and gRPC proxying in the settings:
Read more: Features of proxying via CDN/Websocket/gRPC to bypass blocking
What about XTLS-Reality?
The technology is promising, it is already supported in many clients, but it must be dealt with separately,
and setting it up is also a separate matter. Those who have already managed and mastered it - write in
the comments, or better yet, another article. Inspiration and example configs with XTLS-Reality can be
found here .
What about Sing-box?
Sing-box is an actively developing and also promising client and server, and it can be used instead of
XRay, since it also supports Shadowsocks-2022, VLESS, Trojan, XTLS-Vision and XTLS-Reality, and
can also work with Hysteria, Naiveproxy, and more other.
Official site
Github
Documentation for setup
The developers are reorganizing the turnip, so following links in the documentation may give a 404 error
- don’t panic, look at the file name, and find the correct path in the git by name, no further problems.
Like XRay, Sing-box can do fallbacks, only here in the “listen” section it is called “detour”, and the value
of this parameter should be the “tag” of another inbound.
Website with auto-installation scripts and configuration examples
Could it be simpler, and do it all at once?
For Xray and its friends, there are many different user-friendly server interfaces with easy installation.
There is Marzban , for example - it can also be installed via Docker, it includes XRay, promises a
beautiful interface for setting up and managing users, and even a built-in Telegram bot.
There is also Libertea , Hiddify (it is said that it can do Reality), and various forks of X-UI, which
promise the same thing.
But I don’t have the time or patience to test and compare them yet :)
That's all. Good luck to you in the difficult task of setting up this whole thing, and may the force be with
you.
Next article in the series:
“ Bleeding-edge bypassing blocking: setting up XRay server and client with XTLS-Reality quickly and
easily ”
Previous articles in the series:
" Modern technologies for bypassing blocking: V2Ray, XRay, XTLS, Hysteria and all, all, all "
" Client programs for protocols for undetected bypass of site blocking: V2Ray/XRay, Clash, Sing-Box,
and others "
If you want to say thank you to the author, make a donation to one of the charitable foundations: “ Give
Life ”, “ House with a Lighthouse ”, “ Anton Is Near Here ”.
Tags: xray, v2ray, sing-box, shadowsocks, vmess, vless, nginx, websocket, CDN
Hubs: Linux setup, Information Security, System administration, Network technologies
20 0 Subscribe
Karma Rating
Deleted user @Deleted-user
It happened that way
Comments 107
Publications
BEST OF THE DAY SIMILAR
Show the best of all time
· ·
· ·
· ·
· ·
· ·
Your account Sections Information Services
To come in Articles Site structure Corporate blog
Registration News For authors Display advertising
Hubs For companies Native projects
Companies Documentation Educational programs
Authors Agreement Startups
Sandbox Confidentiality
© 2006–2024, Habr Technical support Language setting
