3X-UI теперь с Нодами! - Большой гайд 2026

Hi. My name is Bogdan Solovyov. You're on the Let's Talk About IT channel. This is my new guide dedicated to 3XYi technology. I've previously filmed several guides on the 3XYi project on my channel. Now a new version has been released, index 3. That is, our version now starts with the number three. This version has quite a few changes, which I want to talk about in this video. The main thing is that you've updated it.

released, index 3. That is, our version now starts with the number three. This version has quite a few changes, which I want to talk about in this video. The main thing is that you've updated it.

Of course, we have a new version of X-Ray, which supports modern VPN protocols. We'll talk about them today.

Another equally important change is the ability to add nodes to our panel. It looks completely different from the days of Wave or Puzzrgaard, for which I also have guides on my channel, but it can still be used, for example, to

Another equally important change is the ability to add nodes to our panel. It looks completely different from the days of Wave or Puzzrgaard, for which I also have guides on my channel, but it can still be used, for example, to build cascading VPNs or to add different locations within a single subscription. I'll also talk about subscriptions today. This mechanism was already present in 3XY, but in the new version it has been expanded and added new useful functionality. And along the way, we'll, of course, set up several connections. I'll show you the new settings, what it looks like, how to use it, and explain in detail how you can set up a fast, secure VPN server using the modern 3xi. When I'm exploring a new project, like 3Xui, or creating my own, I constantly use neural networks. Modern neural networks can significantly save time on routine tasks and speed up the development or understanding of any application. But there's an important caveat. Neural networks don't replace programming skills or coding experience. They're simply a useful tool that's important to know how to use in today's world.

way, we'll, of course, set up several connections. I'll show you the new settings, what it looks like, how to use it, and explain in detail how you can set up a fast, secure VPN server using the modern 3xi. When I'm

And today, the real value lies in those developers who don't just write a few lines of code, but who can competently use modern neural networks, implement them in their projects, and use them to automate routine tasks. The demand for such specialists is exploding. Analysts predict a 36% increase in demand by 2035. Python is one of the most popular programming languages for entry-level programming. It's used to write programs, develop applications, and develop neural networks, as well as automate and develop all kinds of projects and websites. It currently deservedly holds first place in global rankings and IPL, and the average salary for a Python developer is 225,000 rubles. Skillbox's Python Developer Plus AI course will help you become such a sought-after developer.

networks don't replace programming skills or coding experience. They're simply a useful tool that's important to know how to use in today's world.

This course is for those who want to master programming from scratch, gain insight into Python, and learn how to use neural networks as their work tool.

such specialists is exploding. Analysts predict a 36%increase in demand by 2035. Python is one of the most popular programming languages for entry-level programming. It's used to write programs, develop applications, and develop neural networks, as well as automate and develop all kinds of

You'll gain a solid foundation to get started, learning to write code directly in the simulator, work with databases, create web applications, test your solutions, and use tools to speed up coding, check for errors, search for information, and add new features to your programs. The programs are 100% aligned with market demand. Skillbox studied the job requirements and put together a program tailored to the real-world challenges of a junior specialist. You'll gradually master programming fundamentals, stacks, databases, testing, and team tools—everything you really need to get started in the profession. By the fourth month, you'll have a foundation to use for finding your first projects or landing your first internship to begin to recoup your training costs. By the end, you'll have a portfolio of six major projects. At the end of the training, you won't be left with just one; you'll be taught and shown how to pass interviews and get offers, not rejections. And with the promo code "Pro IT," you get a 65% discount and the course for free. So scan the code on the screen or follow the link in the description, and in a year, this will be the best decision you made today.

This course is for those who want to master programming from scratch, gain insight into Python, and learn how to use neural networks as their work tool.

Let's get started. This video, like all my other guides, will be self-contained. I'll explain from the start why this is necessary, what we're setting up, and I'll show you every step of setting up this project. If you've done this before and already have some familiarity with how things work, the timecodes let you skip straight to the part you're interested in. If you're watching this video for the first time or haven't updated your knowledge on this topic in a while, I recommend watching it in its entirety. First, a quick introduction: I'll explain what 3Xi is and why you need it. Setting up a VPN on a server used to be a rather complicated task. If you've never worked with Linux, don't know how to navigate directories, create text files, edit them, or run commands, this procedure might seem very complex and unfamiliar. To simplify this process, people started creating projects called control panels. A prime example of such a control panel for a VPN is the 3Xi project. Why do I call it a control panel? Because 3xi itself isn't a VPN.

features to your programs. The programs are 100%aligned with market demand. Skillbox studied the job requirements and put together a program tailored to the real-world challenges of a junior specialist. You'll gradually master programming fundamentals, stacks, databases, testing, and team tools—

It simply provides a user-friendly admin panel and other tools for managing a VPN server called X-Ray.

major projects. At the end of the training, you won't be left with just one; you'll be taught and shown how to pass interviews and get offers, not rejections. And with the promo code " Pro IT," you get a 65%discount and the

X-Ray is installed with the 3XY control panel. We don't need to install it manually; everything is included. Just to make things clear, I'll explain that 3XY is just the admin panel and other tools that we'll see as the interface we use. Under the hood, we'll have a powerful X-Ray VPN server running. 3xi isn't the only project like this. There are projects like Remna Wayai, Pauzrgaard, and others, which I also review on my channel. But I've always liked 3XI because it's always been incredibly simple. Extremely easy to install, extremely easy to configure. If you just need your own VPN, so you can easily add it to your router, phone, or any other device, use it without fear of it being blocked tomorrow and, consequently, without fear of someone analyzing your traffic. That's why I prefer to use my own VPNs. And in videos like these, I explain how you can set up a VPN for yourself without any special skills or programming knowledge. We released a new version of 3XUI today, version 3.4. One of the interesting features in this version is more convenient management of our nodes. What are nodes? When you used to install 3XYUi, you installed it on a single server. You also installed X-Ray on that server, and you managed only that server in a specific location. For example, in Germany. But if you wanted a VPN not in Germany, but in the Netherlands, you had to install a second 3XY there, and it would be completely separate. And that meant two different admin panels, two different controls. You had to create two different users, roughly speaking, and then use two different connections in your clients. Nothing has changed fundamentally. You'll still have to install 2-3 XYUI instances on different servers. You need two servers, but now you can manage the second, third, and subsequent 3xi instances from your single master server. And that's very convenient. You don't have to switch between servers. You can manage multiple 3xY instances from a single admin panel. There's some new notification delivery mechanism. There's the ability to manage subscription hosts. So, as I understand it, you can change the host in the config for each user or each subscription. And you can actually hide your node's domain this way. Well, I won't list everything here. There are security fixes. A new version of X-ray. One interesting feature is the addition of fail-to-ban support for filtering by IP address. Well, more precisely, for restricting connections by IP address.

Let's get started. This video, like all my other guides, will be self-contained . I'll explain from the start why this is necessary, what we're setting up, and I'll show you every step of setting up this project. If you've done this

Previously, you had to somehow place fail-to-bans next to each other or come up with some other mechanisms. Now you can limit the number of connections by IP addresses unique to the subscription you've created. And for those in business, let's say they claim 3XY can now handle up to 100,000 clients. That's an impressive number, of course. It requires a very powerful server, but even so, it's pretty cool that it's even capable of this. That concludes the introduction. I'll leave the links, all the useful commands, and everything else in the description of this video, or in my Telegram group if

watching it in its entirety. First, a quick introduction: I'll explain what 3Xi is and why you need it. Setting up a VPN on a server used to be a rather complicated task. If you've never worked with Linux, don't know how to

navigate directories, create text files , edit them, or run commands, this procedure might seem very complex and unfamiliar. To simplify this process, people started creating projects called control panels. A prime example of such a control panel for a VPN is the 3Xi

project. Why do I call it a control panel? Because 3xi itself isn't a VPN.

It simply provides a user-friendly admin panel and other tools for managing a VPN server called X-Ray.

X-Ray is installed with the 3XY control panel. We don't need to install it manually; everything is included. Just to make things clear, I'll explain that 3XY is just the admin panel and other tools that we'll see as the interface

we use. Under the hood, we'll have a powerful X-Ray VPN server running. 3xi isn't the only project like this. There are projects like Remna Wayai, Pauzrgaard, and others, which I also review on my channel. But I've always liked 3XI because it's always been

incredibly simple. Extremely easy to install, extremely easy to configure. If you just need your own VPN, so you can easily add it to your router, phone , or any other device, use it without fear of it being blocked tomorrow and,

consequently, without fear of someone analyzing your traffic. That's why I prefer to use my own VPNs. And in videos like these, I explain how you can set up a VPN for yourself without any special skills or programming knowledge. We released a new version of

3XUI today, version 3.4. One of the interesting features in this version is more convenient management of our nodes . What are nodes? When you used to install 3XYUi, you installed it on a single server. You also installed X-Ray

on that server, and you managed only that server in a specific location. For example, in Germany. But if you wanted a VPN not in Germany, but in the Netherlands, you had to install a second 3XY there, and it would be

completely separate. And that meant two different admin panels, two different controls. You had to create two different users, roughly speaking, and then use two different connections in your clients. Nothing has changed fundamentally. You'll still have to install 2-3 XYUI instances on different

servers. You need two servers, but now you can manage the second, third, and subsequent 3xi instances from your single master server. And that's very convenient. You don't have to switch between servers. You can manage multiple 3xY instances from a single

admin panel. There's some new notification delivery mechanism. There's the ability to manage subscription hosts. So, as I understand it, you can change the host in the config for each user or each subscription. And you can actually hide your node's domain this way. Well, I

won't list everything here. There are security fixes. A new version of X-ray. One interesting feature is the addition of fail-to-ban support for filtering by IP address. Well, more precisely, for restricting connections by IP address.

Previously, you had to somehow place fail-to-bans next to each other or come up with some other mechanisms. Now you can limit the number of connections by IP addresses unique to the subscription you've created. And for those in business, let's say they claim 3XY can

now handle up to 100,000 clients. That's an impressive number, of course. It requires a very powerful server, but even so, it's pretty cool that it's even capable of this. That concludes the introduction. I'll leave the links, all the useful commands, and everything

else in the description of this video, or in my Telegram group if there are a lot of them, because it's simply inconvenient to include a large number of commands and links in the YouTube description. I usually create them in a

separate thread on Telegram. I have a chat there; you can join it and chat with me or other members. So, in this chat, in a separate thread for videos, I'll be adding short comments, or longer ones with configurations, links,

and useful information. Let's begin the section on preparing to install our 3xi panel. To rent a virtual machine, you'll need hosting. Hosting is an online site where you can go and rent a virtual machine of a certain capacity

for a fee. For personal use, the cheapest hosting with the simplest configuration will do. I'll demonstrate this today using a hosting service called hiphosting as an example. I'll also leave links to the hosting services I personally use in the

description. But this isn't necessary. You can use any hosting service. The main thing here is, in principle, simply rent a virtual machine somewhere abroad. It's done the same way everywhere. You go to the hosting service, register, and you can do so

anonymously by simply entering any email address and password. Then you create the virtual machine. And here, it's important to choose the right settings. Well, first of all, you need to choose a location. Not all locations are available right now. Some are

available, while others are not. This is due to high demand. So, sometimes you have to try different hosting providers. And if you need a specific location and a specific hosting provider doesn't have it, they add more periodically, so you can check from

time to time. They'll likely become available sooner or later. When choosing a location, it's best to try to choose one that's geographically close to you, as this will likely reduce ping. Again, this isn't guaranteed, because backbone connections aren't always predictable.

Sometimes a country that seems close on the map may actually be quite far away according to the network plan. But since you can't check this 100%in advance, the only option is to simply choose something geographically close.

For example, I live in Russia, so I wouldn't bother choosing the US unless I specifically need that location, simply because the US is very far away and there would likely be some significant latency. We choose a server , say, in Paris. Next, we choose an

operating system. I'll use Ubuntu as an example because it's one of the most common and easy-to-use operating systems. Choose version 24 or higher.

We're currently releasing 26, but it won't make a difference. It's just too old, like 22 or 20, so there's no need to choose 24 or 26. Choose 24 or 26 if it's available in the selection menu on your hosting provider; you'll be

renting a server somewhere. The standard pricing plan for personal use is suitable for us. If you plan to use a VPS for a large number of clients, say, more than 500 or more than 1,000, it probably makes sense to choose an

HCP build with increased memory or, in general, more resources. And for personal use, you can choose the most basic plan with a gigabyte of RAM and a small flash drive. It will cost us $ 2.40 per month. Again, prices vary from

hosting to hosting. Well, usually the cheapest such plan is around 500 rubles . So, usually it will cost even less than 300 rubles. Top up your balance and click "Create." Once the server is created, you'll see it in the dashboard

in the server list, you can open its details, and in the details, you'll see its IP address. It will be listed, well , somewhere right on this page. For example, with Hiphosting, it will be listed right here. You'll see their

name, username, and password, which you can also copy from here. I recommend choosing a foreign location for your first server, of course, as it will help you bypass most restrictions. If you want to try a cascade connection in

the future, or if you want to easily access both Russian and international resources through a single VPN, as I'll demonstrate today, you'll need another server in Russia, or in the country where you live. Again, it might not be

available right now. For example, right now, hip-hosting doesn't have any locations available for purchase in Russia. Let's see if there's anything available on addmi VPS. It's the same with addmi VPS. Register, log into the admin panel, and find the hosting

section. If you don't have any active services, like me, click "Order." By default, you're redirected to a page with Russian hosting providers, but you can simply remove everything from the address, go to the main page, and see what locations are available. Here we

have Kazakhstan, Poland, Spain, Belarus , Russia, and Germany. Finland and the Netherlands, for some reason, aren't pinging. Apparently, there's no available capacity. Although, maybe there is, because, in principle, it seems like you can rent one. I need a

second server, say, in Russia. Let's look at a monthly rental. It will cost me 300 rubles. This includes 100 Mbps connection speed, backups, a gigabyte of RAM, and 15 GB of flash storage. For personal use, this is more than enough,

because, well, you're unlikely to need more than 100 Mbps for anything. If you have a gigabit plan or want to connect a lot of people to it, then you can even look at more expensive plans. In this case, it's all up to you to decide

based on your resources and budget. I'll order a standard one for 300 rubles. It's perfect for this video.

Here, we're also asked to specify the server name as a domain. You can simply enter something unique here. Some plans include free domains on admin VPS, but they cost about the same here as renting them on a full-fledged hosting

service. However, using them through their admin panel is not very convenient, so we'll rent a domain elsewhere. I'll show you how to do this as conveniently as possible. We also select Utuna 24 as the operating system . Once everything is set up, we

continue with the payment and receive the same credentials for our server. I've topped up my balance and am completing the payment. Okay, ready?

We've rented the servers. Now let's talk a few words about domains. Why do you need them when you can do without them? Now let's talk about a domain.

I'll tell you what it is, whether you need one, and, of course, I'll explain why we use one at all. A domain is the website address that we usually enter in the address bar. For example, for the website github.com, the domain is

github.com. Oh, and you can create the same domain for yourself to conveniently and securely access your future 3Xi admin panel. This is done not only for convenience, but also for security. There's no encryption. All information on the internet is

transmitted in plain text, or a bunch of bytes if they're binary files. And all of this can be easily dumped and read. And since you're working with a VPN server, you'll be transmitting data between the client—say, a browser—

and your 3XY panel, such as logins and passwords, various credentials of your clients, and a lot of other information that you clearly wouldn't want to show to strangers. And the domain allows us to issue certificates and use the SSL

protocol to protect our traffic. Well, most websites on the internet, practically all of them these days, as you can see, use the https scheme at the beginning. And that S at the end of HTTP stands for SSL encryption. I think

using a domain is very convenient, even for personal purposes. Firstly, typing the website address in the address bar is much more convenient than typing the IP address; you don't have to remember it. Secondly, if your server is blocked

, you can easily and painlessly migrate to another server if all your clients use the domain name as the connection host. The server's IP address will change, but the domain won't, and when you migrate, your clients will work

automatically. You won't have to re-distribute the configuration files to them. By the way, regarding migrating the 3xi panel from one server to another, I have a guide on boost. I also have a large number of other guides there, and new ones are

constantly being released. If you want to support me, you can check out the guides I publish by following the link in the description and in the first pinned comment. You can also subscribe if you'd like. In addition to guides,

I've recently been running large giveaways and posting various insider information there that I don't want to make publicly available. Overall, using a domain has a lot of advantages, but it also has one, well, let's say, significant disadvantage. Domains

aren't free either; you have to buy them. The average cost of a domain, for example, in the .COM zone, is around 2,000 rubles per year. Well, that's about 180 rubles per month. It's not much, but if you add in the cost of, uh

, server rental, it adds up to a hefty sum every month, essentially like paying a second fee for your home internet. So, if you can't or don't want to pay for a domain, there's an alternative. In my previous guides, I

showed how to securely route our admin panel through an SSSH tunnel, but that required additional configuration and unnecessary manipulation, and in the new versions of 3XUI, they've come up with a cool alternative. Now we can issue SSL certificates to use the https

scheme directly to an IP address. If you're planning to use 3XY for yourself or a small group of friends, this option is perfectly suitable, and you can basically get by without a domain.

Again, I'll show an example of how to set up both options later. If you do decide to rent a domain, it's very simple. Find a website that provides this service. This could be a hosting service. Some hosting services offer

both virtual servers and domains on a single website. But I usually use different ones because I use several hosting services, where it's more profitable and where I have locations.

And I use the domain with the services that are most convenient for me to manage. When purchasing a domain, you'll need to select a domain extension. A domain extension is a top-level domain, for example, the one after the period at the end of the

website address. This would be .ru, su, US, and so on. The domain extension indicates the country where the domain belongs. In Russia, the cheapest and easiest to buy domains are, respectively, the Russian R.Р.U. and RF. But I don't recommend buying them

because, firstly, they say in the future they will only be available for rent through Gossluzhivaniye (State Services). Well, I don't really like that. And besides, it's not always easy to issue a certificate for them, because Western registrars are also

starting to work less and less with Russian domains. The best option in terms of price and features is a .COM domain. So, you can buy any .COM domain , and it will cost you around 2,000 rubles per year. The main thing here is

not to fall into a trap. If, for example, you click "Register a domain" and see a price for a domain like TokaNet, or maybe not TokaNet, like Dot Store, for 140 rubles, notice that the amount of 4,800 is crossed out. And

4,800 is the price of this domain starting from the second year. If you don't mind changing your domain every year, you can basically rent one for 150 rubles a year. It's a perfectly viable option. I'm too lazy to change

my domain every year, so I use something like .com, which will cost roughly the same amount every year. SWB has a dedicated page called domain prices. You can go to it; it looks like this: Domains index full. Here you can

see how much the first year's rent and renewal costs. So, decide for yourself what you like best. I, of course, recommend simply using TOCOM, because it costs 1,480 rubles, and there won't be any surprises upon registration or renewal. You come up with a name for

your future domain. It's like choosing a nickname in a MM RPG. If the domain is taken, they'll tell you so. So, just like in any game, you change nicknames until one becomes available. Next, you'll need to create a domain persona.

To create a domain persona, you'll need to provide your personal information and go through verification, as per the rules of official Russian hosting services. It's nothing complicated; you don't need to take a photo with your passport, but you will have to provide

someone else's passport information. But if you want to, let's say, officially own a domain and claim it if necessary, without worrying about it disappearing or being transferred, then I recommend official options, of course . If you don't want to give out your

passport under any circumstances, there are alternatives. For example, foreign hosting services, such as Luke Host.

They offer the option to purchase a domain without providing any personal information at all. Simply register via email and register the domain there.

They're currently offering some kind of discount; apparently, the registration fee is $ 18, but next year it will be almost $ 28. Which is, well, about a third more expensive than SpaceWB. But you're paying for anonymity. So at this

point, decide whether you need a domain and whether you'll use it. If you don't want to use it, then just don't rent it and move on. Now that we have a server, and possibly a domain, we can begin

installing the 3xi panel. First, let's figure out how to connect to our server . We won't be connecting via SSH. For this, we'll need its IP address, username, and password. I just created a server, uh, in Russia on an admin VPS

. Well, here everything is the same as with hiphosting. In the server information, we have its IP address, uh , username, and password. Well, more precisely, for some reason we don't have a username here, but the user is

usually root by default unless another one is specified. To connect to the server, you can actually use a regular terminal built into any computer. A modern one could be PowerSell, or a terminal from Linux or MacOS. Just open

it, type SSH, then root, at, and your server's IP address. Press Enter. The first time you connect, it will ask you : "Are you sure you want to connect to an unknown server?" Answer S in English , and then you need to enter the

password. Copy the password, return to the terminal, and paste it here with the right mouse button. Just right-click; it won't appear here.

Press Enter and you're connected to the server. That's it, you're in the remote server's terminal and can now run commands on it. If you don't plan on visiting the server often, you can basically just use it like that. You

don't need to install any additional programs. But that doesn't suit me. I visit servers often, so I use a client called Mobo Xterm. It's shareware for Windows, meaning you can use up to ten saved sessions. You can buy a paid

version, or you can buy a paid version. Yes, I can't give you the details due to YouTube's rules, but you know what I mean. And then the number of these saved sessions will be, well, unlimited . What are these saved sessions? Click

the "Session" button here and select a protocol. There are a whole bunch of protocols besides sсge.tu, so you can use it for anything in the future. Also , enter the IP address in "remote host" here, enter the username "root," and

click "OK." If you're connecting for the first time directly through mob extern, you'll also need to answer "yes " to the question here. Next, enter the password. At this point, it may prompt you to save all passwords securely

locally. I recommend answering "yes" and creating a master password, and then all server passwords will be stored encrypted on your computer. And you won't have to enter the password every time. This means you can rename the connection, for example, for

convenience. So, the next time you want to access the server, you just double-click it and you're right there.

No need to enter any logins or passwords. It's very convenient. Now let's talk a little about the security of our servers. The thing is, by default, the servers are virtual; they're not really configured. That is, they essentially only have the root

user, who is the superadmin, and they have a login and password and that's it . There are no firewalls, nothing enabled. And our SSH is just exposed.

And all sorts of bots are hacking into it, trying to brute-force the login and password and gain access. Of course, if you don't change the password, they're unlikely to brute-force the default password generated by the hosting service because it's quite complex. But

if someone is deliberately hacking you, there's still a chance. So, it makes sense to tweak a few settings on your servers. I won't be making any super-complex settings. Let's create the most basic setup, so to speak.

First, we'll enable the firewall. Now all network connections on our server, both incoming and outgoing, will be managed through the firewall. This is necessary to prevent any random ports from being exposed. In your server's terminal, simply type the command "UFW

enable." Then, two ampersands—these two icons are usually located at the number seven on a PC keyboard. After the two ampersands, type "UFW low open ssh." This enables the firewall. By default, it blocks all incoming connections, and we immediately enable

connections via SSA in one command to prevent us from losing access to the server. We press Enter, and it asks if we're sure. We answer: "Y, it's enabled , and the Open SSH rule has been added.

" What do we do now? First, we don't close this window. We open another connection to the same server and check if we can connect. If we can connect, then everything is fine; we can close them, reopen them, and so on. If we

can't connect, then we carefully check for typos in this part of UFWLO Open SSH. Now all incoming connections are blocked by default. If we need to unblock a port for our admin panel or for our VPN, we'll need to unblock it

separately using the UFWLO command. Let's say we definitely need ports 80 and 443 so we can first obtain an SSL certificate and then, ah, access our admin panel. We enter UFWLO 80 TCP and UFWLO 443 TCP. Well, these are the two

main ports we'll need. Then, to connect , we'll open each port separately. Now, regarding our login, in principle, to the server, when we use a username and password, it's possible, in principle, to log in using the same username and

password. I've been logging into many servers for years using a username and password, and nothing ever happens. The main thing is to keep the password simple so it can't be easily brute-forced. But if you're worried that someone might be deliberately

trying to hack your server to steal your client database, collect logs, information, and so on, then it makes sense to completely prohibit password-based login and use an SSH key . What is an SSH key? It's essentially a password in file form. This file is

quite large, and brute-forcing it is impossible. And without this file, you won't be able to log into the server at all. So, the likelihood of you being able to log in is extremely low.

Perhaps in the future, when quantum computers become a part of our everyday lives, they will learn to crack modern SSH key algorithms. But for now, they can't crack them, and we can be sure that no one will be able to access our

server without this key using the key. First, let's generate the key itself. This can be easily done locally using the same key or path, if you already use it. Or it can be. Go to Tools. Find KGEN here. It's called either pathgen,

if you use paths, or mobile. Basically, you don't need to change anything here. We already have the RSA key type set.

The length is 2048 bits. This is a completely secure key, which will suit us perfectly. Click Generate and move the mouse inside the program window until our bar is full. This way, we generate a completely random key. We've

generated the key, and now we even have short instructions on how to use it.

The key consists of two parts: a public part and a private one. We save the private part additionally. It can also be password-protected. The password can be entered in the K passe field. I usually don't password my keys, because

if your private key is stolen, it's still grounds for reissuing it. And you can password them separately. Only if you have crypto stored there and you're really concerned about the server, then you might want to create a password.

But if you forget the password, you'll lose access to the server. So think about whether you need a password. If you do, enter it here. Once you've entered it here, click the "Save private key" button. It asks if I want

to save it without a password. Yes, I do. But again, if you really want maximum security, save it with a password. Next, come up with a proper directory for storing your keys, because you're not creating them for just one day, and you'll likely have

more than one. And don't just dump them in a pile somewhere in Downloads or Documents; you won't be able to figure them out later. So, let's call it something like "Key." Next, we need to save the public key on the server. The

public key doesn't need to be kept safe ; you can easily transfer it via Telegram, various other websites, or even email. We need to put it on the server. The home directory is on the way. SSH authorized case. Return to the

server terminal. Type the Nano command here, and then type root.ss authorized case. If you're not running as root, but have created a separate user, then save the key in that directory. I won't show you how to create a user here,

because it will be a constant nuisance in the future. If you're a newbie, they won't figure it out. If you know how to use users correctly in Linux, then just create a user and work as that user if

you want. Nan is a text editor that allows you to create and edit text files on the server. We don't have an AtoZ file right now, so a blank file has opened. We need to copy our public key into it. You can get it directly

from the program here. And if for some reason you didn't copy it from here and closed this window, you can upload the private key here using the Low button and enter the password. If you have a password, well, your public key will

appear again at the top. We copy it from here and right-click and paste it here. It should simply read SH RSA, and then the entire key to the end. No extra spaces, no extra characters, nothing extra. And nothing should be

forgotten either. Now press Ctrl and X. We have a little hint here. This up arrow is Ctrl on Windows and Command on Mac. So, press Ctrl X. It asks us if we want to save. Type a capital Y and then

press Enter. Now it's important not to forget this. We need to change the access rights for this file. I have a separate video on YouTube about access rights. If you're interested, you can watch it. But if not, just type the

command "CH mode," then the number 600 and the path to our ru.Stas file. Now, in theory, we should be able to access our server without a password. You can easily check this in Mobo Xter. Our password is already saved. I don't want

to delete it here. Well, there's no need. You can simply use the PowerShell terminal again. Go to the directory with our key. Open a terminal here. In Windows, you can do this by holding down Shift, right-clicking in this

directory, and a menu will appear to open a PowerShell window. Type SSH here . Next, type-I (English in single quotes, I think). Well, we'll check now . Start typing KPPK. Then we finish it with HQ. And now we type root and the

IP address of our server. We get something like this. And press Enter. By the way, my command didn't work for the simple reason that another third-party user, named "codex," has access to this directory. So, in this case, I'll simply delete this user from

this directory. That problem is gone. Now we have the problem that it says the key is in the wrong format. Yes, I sometimes get confused about this because I rarely do this. We have a key format for Windows and a key format for

Linux, and sometimes this happens. It's very easy to fix. We simply return to our Mobo Exterm. Open our key in the generator. And we have a tab called " conversions." And you can click the " Export Open SSHK" button here. You can

basically replace the old key completely. And now our command should work. Yes, the command worked; we logged into the server without a password. This means we can now disable password-based access to the server and only log in with a key. To do this,

we'll need to create a new rule on the server for key-only login. It's quite simple. Again, we use the Nano command to open the file, creating it simultaneously along the paths, etc.

SSH, SSHDconfig.d. Again, you can tab through all these paths to avoid typing them out entirely. I'll try to keep the useful command appropriate. As for you, you enable the useful command; I'll try to remember to leave it all in the

corresponding post on Telegram. Next, we specify the file name. 99 is essentially the priority. By default, our file is created with the number 50.

The higher the number, the higher the priority. We specify 99 to ensure our config will have the highest priority.

This file doesn't exist, but we're creating it now. We'll paste four lines here: Public authentification. Yes.

Password authentification. No, KBD Interactive Authentication, and Permit Root Login Probit password. So, we're disabling password-based logins in general for IT specifically. We check that everything is fine with the SSHD-T command. If there are no errors, then our configuration is valid. We restart

our SSH with the System Catal Reload SSH command. Now, when we try to log in to this server, we should be unable to do so because our server no longer accepts passwords. It no longer accepts passwords from us. To log in, we now

need to specify our key in the connection. We edit our session. Go to Advanced Settings. Click "Use private cache private key." Find it, click " Open," and click "OK." Now we can easily log in to the server using the

key. Thus, by enabling the Firewall and configuring key-based login, we protect our server from hacking, brute-force attacks, and various bots that will try to hack into non-optional settings.

This isn't the only setting. It's for, so to speak, greater security. We can also disable pings on our server, specifically the S&P protocol completely. Then our server will stop responding to the ping protocol. It won't be pingable. What does this give

us? Well, it gives us additional protection from websites and various services that will try to check whether we're using a tunnel or not. If we take our server's IP address and enter the ping command, and then enter it, we'll

see the following picture. We'll see an exchange of packets using the ICMP protocol. And it will say that we're pinging the server, sending so many bytes and receiving so many, and receiving a response after so much time . This is, in principle, the normal,

standard behavior of any server. That is, if you take most websites now and enter the domain or IP address of that site, it will still be pingable. We can turn off this ping. This may, of course , cause some minor alarms in the

hosting admin panel. That is, if a hosting service, for example, monitors its server using the ACMP protocol, it will see that your server is unresponsive, might think you're down, and will try to fix your production server. Well, to be honest, I've never

encountered this. And usually, all the servers where I disable pings are fine with it and work fine. There's a guide on this topic in my Telegram group, called "Also Let's Talk About IT." I don't remember how to do it. Here, I'll

repeat. Our firewall should already be enabled by this point, so we don't re-enable it. Open our config file with the /CUWbe.rules command. Here we find several blocks, namely OK ICMP C for input and ICMP C for forward. Here, we

change everything from "reject" to " drop." Copying works here simply by selecting with the cursor. Pasting works either with the right mouse button, "left," or "Shift-insert." And thus, we replace everything with "drop.

" And in the input block, we add another line, again from my Telegram guide. Or you can just Google it. We also add a new rule with a drop. Save this file, exit it, and run the UFW disable command and two amps of UFW

enable. Well, essentially, we're restarting our firewall. The firewall has been restarted. Let's check that we can access the server, because you can't mess with the firewall. Okay, 41254. Yes, we can access the server without problems. Well, now let's try

pinging our server again. And it stopped pinging. That's it, we've disabled the protocol. Now you can't ping us, and it will be harder to determine that we're using any tunnels.

Now, as for the 3xi installation itself , we can already begin. We're prepared, our servers are renovated, configured, and we've purchased a domain, if needed , but the installation itself may have some nuances. What do I mean? The

installation itself is actually very simple. There's a command in the Quickstart section; it's literally a single line. You copy it and paste it into your server. And if you're using a foreign server, you probably won't have any problems. Basically, you connect to

your foreign server, enter this command , and the interactive installation wizard will launch. Let's go through this installation now so we don't have to jump around, and then I'll talk about some of the nuances of installing 3xy on Russian servers. Our

installation is almost completely automatic. We only need to answer a few questions along the way. By the way, the installation seems to be taking longer now. It used to install really quickly. Now it installs a whole bunch of packages. Yes, it installs a lot of

new dependencies. Fail to b is installed right away. The C ++ compiler is installed. And during the installation, it suddenly didn't ask me a single question. This is some new feature of this version. So, I entered the quick installation command, and it

installed really quickly without any questions at all. Previously, it at least asked about setting up SSL. Well, let's figure out what it did here.

Let's launch the XUI utility. This is our console program that allows you to administer XI without logging into the site. It also allows us to check on the server if the site is down to see what's going on. It says that our panel

is running and everything is working. But it didn't even give us any connection information, but fortunately , you can get it here. We have a tenth option: view current settings. We enter it. We see that our panel has

configured itself. Previously, during installation, it offered to change such settings right away. But to be honest, I don't like how the installation is so silent now; I have to go into the XI utility separately. But maybe this will

be more convenient for someone, and maybe there's now a separate flag for some kind of interactive installation, but I didn't see it here in Quick Start . Well, yes, that's what it says here.

Now we're installing with a random username, password, and everything else . And to change them, you need to go to the XI utility itself, as I did.

Nevertheless, we can already connect. It already received the certificate here, apparently, to our IP address.

Simply copy the connection string into the browser. Our website, our admin panel, opens. From there, we take the login and password. The login and password, which are not here. As far as I know, it can't be displayed, it can

only be set. Yes, it certainly looks strange. Okay, let's run XY again. Select the sixth option for changing the username and password for logging in. Enter Y here and now enter the username. Well, I'll enter mine, the one I usually use. We also enter the

password. I set the password for the user. Now let's log in. We've accessed the dashboard. And, essentially, the 3xi installation is complete. Now it's just a matter of fine-tuning it, setting up the admin panel, setting up the connection, and so on. First, you

can link the domain. It's very easy. We take our site's IP address, go to the hosting service where we rented the domain name, find our domain, click on DNS, and click "Add Record." This looks pretty much the same on all hosting

services. Next, we have the base domain we purchased. For example, mine is drbit.pro, and we need to come up with a subdomain. You don't need to write " VPN" in the subdomain; that's where the admin panel is, 3xui, that's all there

is to it. Write something neutral here, like "CDN" or "CDN 02," as if you have some caches there, files, or something else that can actually be downloaded in large volumes. And in the value, enter the IP address, use the default type A,

and click save. Now our server's IP address is assigned to the cdn.bit.pro domain. Well, you'll have your own domain, of course. You can write it down separately for easy copying later.

You'll need to wait about 15 minutes. Usually, this happens very quickly. The IP address itself is assigned to the domain. Well, in rare cases, it can take half an hour or an hour. While this is happening, you can install 3XY

on a second server, namely, a server in Russia. There are some nuances here. What nuances am I talking about?

Quickstart installation is essentially a single command that does the following. It downloads instructions from the GitHub address usercent.com, and then there's some path to the repository. And this page has recently started getting banned in Russia. Well, you know who they are. They continue to

interfere with our internet use in any way they can. And that's why they started blocking some pages on GitHub.

I don't know if it was targeted intentionally. But if you try to open this page in Russia right now without a VPN, it probably won't open. The same thing happens with many Russian VPSs.

Again, not all of them, but many. You enter a quick installation command, and it might not work. It worked for me right now, so I'll cancel it, but it might not work. You can click it, and it will just hang and eventually time

out. If that happens to you, you can try installing it using an alternative method. As a last resort, if GitHub does get blocked, we'll directly download the archives from 3X to the server and install it from there. We'll

do this completely manually, but for now, you can try a semi-manual approach , so to speak. Follow the link to wki 3xi. There's a manual installation option there. Here we have several commands where we copy an archive directly from the github.com website,

which is not currently blocked. We copy the first block of commands, paste it on our server without changes, and then copy the second block of commands. And after that, our XUI immediately appears . That means we can immediately type XY

on the server; it's already running, and we can look at the current settings again. The only problem here is that it's not configured in any way. That is , we don't have fail-to-ban enabled, and we don't have an SSL certificate

installed or configured, and this only happens when installing via a script. With a manual installation like this, you'll have to do everything manually.

But it's not at all difficult. It immediately offers to generate an IP certificate. We immediately answer: " Yes." Then the semi-interactive mode begins, just like before. It asks if we have an IP6 address. Usually we don't, so we just skip it. At this point, if

we have a firewall enabled, ports 80 and 443 should be open. 443 isn't necessary; we'll just use it for VPN later. Port 80, however, must be open to obtain a certificate. Next, it asks if we want to apply the certificate to

the panel. We answer, "Yes, we do." Now , enter 10 again and check the current settings. Our panel address is now as follows. It's already https-enabled. We can access it. Now, we can configure it further, basically, through the admin

panel. And don't forget to open the port in the firewall. Okay, the port has opened, and the admin panel has appeared. Now let's set a username.

This is the sixth menu item. We've set the username and log in. That's it, we've logged into our panel. We don't have a secret URL for logging into the panel here. It's better to add one. We have a separate panel settings block

here. You can do this directly from here. Let's go to the panel. We have a URI path here. You can either generate a UVRI path or simply enter a random string in it. The main thing is that it's closed with two keys. Incidentally

, we're also advised to replace the port with something less volatile. Click "Save." Basically, the panel will now be unavailable for this path. It will immediately redirect us to a new path. This path will need to be saved.

But if anything happens, you can find it in the terminal in the XY console, or change or reset it. Again, if you can't do anything through the panel, you can do all the operations using the XUI command in the terminal. Let's

check if our domain is bound to KDRIS. Pinging it may be useless if we've disabled ping with Fav, but there's a command line tool called NS Lookup that can help. NS Lookup responds with the IP address 86194. This is the correct

IP address. This means our domain is already bound. We copy it. Then we log into the admin panel of the server we bound it to. The key here is not to confuse things. We open the XUI utility . The nineteenth item is SSL management

. Here we can manage our SL certificates, create them for an IP address, or for a domain. We're currently creating them for a domain.

We select the first option. We have the SOCAT program installed. Now we enter our domain name here. Again, we use the default port, the 1980s. We've successfully obtained a certificate for our domain. Now it asks us if we want

to add the rello flag from cmd to the scripts. We answer yes. Next, we select the first option. This means that our certificate, which has an expiration date, will be reissued. XUI will restart when it's reissued so the new

certificate can be applied. Finally, it asks if we want to use this certificate with our control panel. We answer yes.

Now our control panel's address has changed from an IP address to a domain. And, accordingly, we can now access the domain. You can't access your account by IP address anymore. Ready? We've installed and configured two dashboards . One with a domain, one without, so

that each of you has an example, so to speak, of how to use it with and without a domain. Now it's time to set up a few connections as an example and show you how it's done. Connections are

located in the Incoming tab. Previously , this was the Inbound item. In newer versions of 3XYUI, you may already have a connection created here by default, especially if you set it up with a Quickstart script. It defaults to a

reality connection here. Honestly, I don't understand why it does this, because any self-respecting VPN admin will at least check what's configured there. At worst, it's best to delete it immediately and reconfigure it yourself to understand what's going on. That's

why I deleted it. And if you have it here by default, then it's up to you to figure out what to do with it. I would also delete it and configure it manually. How do we create the first

connection that we can connect to and use? Click "Create Connection." Previously, we had a single window with all the settings on one page. It was very convenient, but for some reason they changed it to tabs like these.

There aren't any particularly new settings, but nevertheless, we have what we have. In the notes, we simply give our connection a name so we can distinguish one connection from another . If you don't have any special ideas for a name, you can just call it "mea."

Regarding the protocol. In addition to the Bessmenu version, X-ray and 3XY support Histeria. This Histeria is specifically the second version, the second version, although it says so in the name. But if you select it, the protocol version will be somewhere

around here. Yes, version 2 is written in the stream. There are also protocols for MT Pro proxies, there are ones for Telegram, and there are various HTTP proxies, Shadow Sock, old Trojans, and everything else. Even VGAR is here.

We'll still select the buss port. You can specify any port. But if we're using buss with TLS encryption and our own domain, I recommend using port 443.

This is the absolute best option because we can create a fullback size placeholder. I'll show you how to do that now. And our site will look as inconspicuous as possible. Further down this page, we have various admin settings: the total traffic we allow

for this connection, the traffic reset after a certain period, and the connection expiration date. You'll only need all this if you decide to temporarily loan this bound to someone.

And to remember to turn it off, you can set a timer here. Let's go to the protocol. We don't have any encryption configured right now, so there's not much to choose from here either.

There's also a hint here that FullBack and everything else will become available after selecting TLS or Reality in the security tab. Why did they make it so inconvenient? Again, it's unclear; perhaps they'll change this by the time you watch the video.

It will be more convenient. Let's move on to security. And here we choose, uh, encryption for our VSA. There are two options: TLS—using your own domain and your own SL certificate—or reality. Reality, when we masquerade as someone else's website. The advantage

of TLS is that you have complete control over everything and aren't dependent on anyone. That is, if your domain works, your website works there —or, more precisely, its XUI works— then your VPN will work too. If you choose the reality option and the

website you're masquerading as becomes blocked or unavailable, or something happens to it, your reality will be down. But for reality, you don't need to create your own domain. Since we have a domain on this server, we choose the TLS option. We don't fill in the SN

in this case. We use it because it's our website's domain, and we'll be connecting as if directly to it. The SNI header is generally used in HTTP to indicate the server's domain when connecting to a website. And many

blocking mechanisms work precisely because SN is transmitted in cleartext. When we type "YouTube" there, for example, DPI detects this and blocks the connection. And programs like YouTube Unblock and Bydpi mask these SNI headers. There's no need to change

anything here. Let's have automatic encryption, the fingerprint will be the same as Chrome's, and leave the LPN unchanged. Click Install Panel Certificate. And basically, there's nothing else you can do regarding security. There are also all sorts of protections against quantum computers

and other things. I don't see the point in using them yet. Quantum computers aren't widespread in our country yet.

Later, if such a future suddenly arrives, we'll deal with them, so to speak. Return to the Back to Stream tab . Again, why they couldn't have done this at least in order, I don't know.

Well, I'm sure they'll rework this in the future, so if they're in a different order, I'll use the name as a guide. In the stream, we need to configure the transport we'll use to transfer our data within the VS

connection. The most recent protocol, recently released, is called XHTP. This protocol simulates work as if we were working directly with an API, for example, of a real website. It adds a little overhead. Your VPN might work a little slower, just a little. Honestly,

I usually don't even notice it, but it's the hardest to detect these days. So we'll select it. We'll leave the host alone. In the path, we'll enter a path similar to the URI of the real website. For example, you could enter

API V2 Uploads. You can select packet App as the mode, as if we were uploading packets to the server; we'll simulate that behavior. The rest of the default settings are generally fine for us here. There's nothing new in the

protocol. And by the way, yes, I forgot to mention, FBK doesn't work with XHTTP transport at first because that's how X-ray works, and that's how this XHTTP transport works, so you can't set up a fullback within X-ray. You can do this

using an external web server. Oh, but we'll talk about that another time. For now, we'll do without fullbacks, because I really don't want to give up this transport. Let's create our connection. Previously, when we created a connection, at least one user was

immediately created in it. That's no longer the case. And now our clients are in a separate tab, where you need to create them separately. Click "Add clients." You can enter anything you want in the "Email" field, for example,

our friend's name, again, admin settings, set limits, different expiration dates, and so on. And now we need to bind one or more incoming, so-called, yes, inbounds, to them. Uh, if we click in this field, we see the created inbound, for example, the

inbound main. You can create several and then add several to a single user at once. In the credentials, we have the user's UID. This is essentially their HISTER subscription ID password.

Basically, these are their cradles, which will be used for all inbounds. They won't be re-created each time, but will be entered here. You can also add third-party links and subscriptions from our other 3x. That is, if you have

another server somewhere and there's an inbound on that server that you want to add to their subscription, you can add it via an external link. But I don't think you need that right now, so we'll basically finish the basic settings and

click "create." Now we have a user who can connect. We can click on the QR code and scan it with any app like Hub or any other app that can work with Westmold over HTTP. We have a subscription QR code here. How is a

subscription different from a direct URL? If we open the subscription on a separate website now, we see a page similar to what you'd see on any modern paid VPN that sells keys for BS. It contains user information, various

limits, and the user's connection configurations. So, let's say they have this main. You can also request their QR code here; you can copy it from here and paste it directly into the client, for example. But I don't recommend

pasting links directly into the client because it's not as convenient as pasting subscriptions. You can copy the subscription link anywhere, open the app on your phone, computer, anywhere.

For example, I'm currently using the app on my computer. We click roughly the same thing everywhere: an "add" button, a "plus" sign, and then "add" a profile from the clipboard. We select " create a new subscription group." And

we get a new subscription linked to our server. Why are subscriptions so much more convenient than direct links? If we'd added a link directly, like, say, by taking it from a clipboard profile and pasting it here, it would certainly

work. Now we launch it, enable the system proxy, and the browser should pick up the default system proxy. So, when I tested it, the initial configuration didn't work because I forgot to configure something. In our incoming connection, for the TLS type,

it's very important to specify a host that matches our certificate in the stream. That is, for security purposes, we have a certificate for the domain.

It needs to be specified in the host. I thought it would be added automatically , but it wasn't. So, we also specify the host. We specified the host. We launch our connection. Let's re-enable the system proxy. Go to 2ip.ru and see

that our IP address has changed to our server's IP address. Our location is Chisinau, Moldova. So, our VPN is working. In principle, in this state, it can already be added to a router, a phone, and so on. And create clients.

Now I'll tell you about the main advantage of a subscription. Let's say we change something in the configuration, our inbound configuration. If we now take our connection, which we added via a link, and create a latency test URL here,

we'll see an unavailable error because the configuration no longer matches what we pasted here. If we use a connection via a link, we'll have to delete it, take a new link, and paste it here. And do this every time. If we

use a subscription, this applies to any app on the phone or computer, we can simply click "renew subscription," the new connection information will download, and everything will work immediately. It's very convenient. You can share these subscriptions with your

friends and acquaintances, and then freely tweak the configuration files, change them, and reconfigure them as you please. If anything happens, they'll simply update their subscription, and everything will work for them. Now, as for FB, our incoming connection port is 443. This is the

standard port for https. If we take our site and try to open it somewhere on the internet, we'll see an error " connection closed" because we have a fullback on local port 8000, but there's no one on that port. For it to

respond on that port, some web server must be listening. Well, the easiest option is probably to install the Enginex web server directly on the system. It doesn't even require any serious configuration. Just a couple of edits. We'll write a UPT update. Opt is

the package manager for our Linux, our Rebellion, which allows us to install applications. We'll now check the update, download the entire current version, and install Engine Xverр through it. Then we type UPT install Engine X. Answer yes to all the

questions. Well, basically, there will only be one question about the 1.6 MB of disk space it takes up. That's it, we've installed it, it's already running by default. Now we need to tweak its configuration a little. Open the configuration at NAN etc. Enginex

sites enabled default. And here we have a default server listening on port 80. We'll change it to 8000 so it doesn't take up port 80. Nothing else needs to be changed here, but for fun, you can look where it tries to look for HTML

templates by default. This is the/ warvwhtml directory. You can copy it right away or remember it. Then we save the config. Exit and type Enginex-T, I think, to check the config. -T is probably small. Yes, it says our config

is fine. And now it seems like a capital S will apply the config, or a capital R. Basically, EngineX can apply the config without rebooting, but I somehow forgot what flag it uses, so I'll just do systemm KTL restart engine

X to restart it. We saw the error protocol error. Oh, yeah, the error is expected; I always forget about it.

Let's go back to incoming editing. If we want to use Engine X without any problems, we need to remove the H2 protocol in Alpn security, because setting it up on Nexexi is quite a pain . And for our stub, for our purpose, we

don't really need it, it doesn't matter . We save the changes and refresh the page. And now we have an MT Response error, which is good. Now we just don't have a suitable template. We know where EngineX expects the template to be, and

we'll create it there now. We type nanow wwwtml and create an index html file here. Well, we can also write hello world here for starters. Now we refresh the page and see our "hello world," which returns our website. Of

course, this won't work for a placeholder, so we'll turn to some neural network. So, I'll go to DeepsK, for example, turn on the mode, and ask it to write me an HTML placeholder.

I'll directly write to it: "Write me a one-page HTML placeholder for the site, as if it were some kind of CDN." And the neural network actually starts doing just that. So, it's finished generating. We click "copy directly," return to the server, open our HTML

index again, delete this line, and paste the content generated by the neural network. We save and refresh the page. And we see a placeholder like this. So, it looks like we now have some kind of CDN running here. If

someone tries to open our connection address without providing special keys, like VPN access, they'll get a basically valid response like this.

Well, it's unlikely that they'll bother to figure out whether the number is real or not during a quick random check . So at this point, you just need to decide what's more important to you: a more secure protocol like XHTT, but

without a stub. And, accordingly, when a person tries to go to the address, they'll simply get an error. And, I don't know, maybe they'll be suspicious that you're going there. Yes, they'll try and see nothing. But then again,

this isn't a clear indicator that your VPN is working. Maybe you have some kind of protection there, like, I don't know, filtering by IP address, and all the IP addresses are fake, you're just blanking without a response. So, I

showed you both methods with XHTTP transport and with a row stub transport , and it's up to you to decide what you prefer: a more modern protocol or a decent protocol that's not old, just simpler, but has the ability to create

a stub like this. Again, I've heard somewhere that the signature of this XHTTP transport is more similar to a real website, or more precisely, to working with a real website. And it's supposedly less noticeable, but to be honest, all protocols are working for

me so far, and none have been blocked yet. This applies to a server with a domain. Now let's consider setting up a server without a domain. We're also creating a connection here, but we're a bit limited in security options. We can

essentially only choose Reality here, because TLS requires some kind of certificate, either a panel certificate or any certificate available on the server. You can even create a Wildcard, a single certificate for a whole bunch of domains. By the way, I have a video

about this on Boost. But if there aren't any certificates, then we use Reality. And in Reality, the main thing is to specify the website we're masquerading as. We'll use its certificate to encrypt our connection.

And this website should be accessible without a VPN. If our client can't connect to the target without a VPN, then their reality scanner won't work.

And if the site itself goes down for some reason, or is blocked by the Cybersecurity Council, or something else happens, then reality scanner won't work either. But the advantage of reality scanners is that you can create as many of them as you want; they have

no dependencies, no certificates required, you can create at least 10 different connections and, accordingly, cram them into your subscription and just use the ones that work. The main thing is to choose the right domain.

I'll show you how to do this now. We have a project called reality scanner.

Well, more precisely, it's called Real Scanner. I don't know why the author suppressed the letter A, but I always call it reallit scanner. I'll also leave a link to it somewhere in the description. We go to releases here,

find the latest release, and look for something for CS. We need AMD64. Copy the link to it. We log into our server, which is running at our IP address. We enter the WGE command and paste the link to our file. Our file has

downloaded. Now we execute the command "chmo + X" to make it executable. We tab through everything manually, so as not to type anything, and run it. We type "dot c/reality scanner." Again, we tab through the double defic ad and

enter our server's IP address. What just happened? The process of polling neighboring IP addresses has begun.

That is, our program takes literally neighboring IP addresses, the same as ours, only at the end it changes 254 to 255, 253, and so on. It goes through all the nearby IP addresses and requests their SNI, that is, it asks if

you have a certificate. If the site has a certificate, it returns a domain associated with that certificate. And now our successful requests start coming in one after another. We're looking at what domains we have. It's best not to use some really dodgy

country domains, because they're likely someone else's VPN, and they could simply stop working tomorrow. That's all. It's good if something well-known gets in. For example, there's some Wildcard certificate hiding under ozon.ru. This, again, doesn't mean Ozon is hosted on a hip hosting service or

anything. It only means that there's a host in our IP network that has the ozone.ru domain. I don't know what that is. It could be some Ozon mirror, or it could be their real website, because hosting companies don't buy out the

entire IP network. You could have an IP address that differs from yours by just a few digits, and it could belong to any company, including Ozon. To be honest, I haven't tried using Wildcard certificates on reality shows. But

let's try it for fun. What's the point of a Wildcard certificate? The wildcard certificate should work with all domains that match the mask. The mask is for zvezdochka.azon.ru, where the asterisk can be anything. So, instead of zvezdochka.ru, there could be an API

domain, a video domain, I don't know, or anything else. So, I'll try writing a specific API. We'll see what happens.

And I'll add the same thing again. Although, let's even try it a little differently. We'll leave the asterisk in the target, and add several options like API and CDN to the SN. How does it work? When we connect to our VPN, our

client will choose a random CP from those we write here and route traffic through it. This way, our connection will have some variability and look more natural. Next, we have the generated certificate. You can regenerate it if you want. This isn't a

real certificate; it's, you could say, self-signed. Well, essentially, it's just two complex passwords. Next comes the protection of quantum computers. We don't need it yet. We'll get to it later, when we have these quantum computers. We can set up streams,

basically the same way as with TCP or, as it's called, TLS. Here, we can use XHTTP for radio, because there's no particular point in creating a stub here. We'll let everyone know that we're actually connecting to Ozon, and

not to this specific server. We'll also write some kind of path. We'll enable packet mode. Well, basically, we don't have to do anything special here. Oh, right, you can also write the host, of course. By the way, here, I don't know

if the host with an asterisk will work, but we'll check that right now. To avoid confusion, I'll call the connection itself "reality protocol to the forest." Our port is like this.

Here, we have favoriteall, I think, enabled, so we need to open it. Well, let's create our connection. Well, after that, we also create a client.

Let's try this. Let's connect. Let's copy the link to our subscription and add it to the client. Okay, our subscription didn't download. Either I did something wrong with the firewall again, or rather, didn't do something.

Let's check now. Yes, our subscription port is different from the panel port, so we need to open it in the firewall too. And let's try updating the subscription. Now everything worked.

Let's run a latency test. It's unavailable for us. Well, that means we did something wrong. Most likely, it's related to xhttp. Let's simply write Ozon.ru as the target, and leave the SNI as is, as if we were trying to use

a Wildcard. We managed to fix the connection. I removed all those tricky settings with the SNI. Everything worked. I must have forgotten something here. I'll try to remember now.

Everything worked. And you need, in general, not to put an asterisk in the target. Just write the domain in the target. And then you can try several options for variety. Or don't bother with it at all, and just enter the same

domain twice, the one you have here and the reality scanner returned. There are also better options for Wildcard certificates. Well, for example, something like, I don't know, 62.ru. I wonder if this is a real site or a stub

? Well, it looks like it is real. There is something here, yes, there is even a phone number and email. So, you can probably disguise it as that. Yes, look , the card even works. And if you don't

want to bother with these certificates or something doesn't work, you can just enter it. Well, that's it, reality is basically up and running. Now let's figure out the transport. In the stream , select x http or v2 upload. Packet up

mode. Save. Update the subscription. Check the activation. The connection works. Now let's figure out the mechanism of the knife, how to connect two or more 3 xya through one central one, so that the rest can be used as

nodes. Um, we select the main server, which will be our primary one. It's probably advisable to make it foreign, so there's less chance of it being blocked. Although, you probably won't guess here. Go to nodes. In nodes, we

click Add new node. And here we need to somehow name our new node. Next, we need to specify its details. Our scheme is https. Enter the IP address here, enter the port here. And enter the path here. Now we need the IPEN of our

remote server. Go to the panel settings . Pitogen is hidden in the panel settings and account. I don't know why here. To be honest, I barely found it the first time. Go to the API tokens tab. Create a new token and name it

something. Well, basically, it's here; they even suggest a name, like "Central panel." Copy it from here and paste it into the first panel. We can only use Direct as an outgoing connection.

Apparently, you can also connect to the panel in some unusual way. Well, we'll use all the inbounds. Okay, let's check the connection. Our connection is fine.

Click save. And our node has successfully connected. Now, first of all, we see clients from our node in the clients. I don't know, by the way, it says here that it came from the node . It appears as if we created it

ourselves, but nevertheless, in theory, it's with us, because on M2, our client is located here and its, uh, unique identifier matches, so it's them. Now we can take our client, any one, for example, the first one, and add reality

from our node as inbounds. If we save this, and then update their subscription, they will have two connections. They can simultaneously use, for example, a Russian server and a foreign server. That's about connecting nodes. You can create as

many as you want this way. I didn't see any restrictions in the documentation. Well, probably if there's a reasonable number, I don't know, less than twenty, then we'll probably connect without a problem. We also have Nbounds from our

node in the Nbounds. And in our "Node" field, it says whether this panel is local or some remote, non-local panel, for example, MSC1. Let's now consider this point. I once filmed guides on cascading VPNs, when we connect through

one VPN to another. This is very useful . For example, if they start blocking foreign VPSs for regular users, we can jump through hosting providers and still connect to them. We used to have attenuation in the X-Ray configuration

in the basic settings. Now there is nothing like that. There is a separate routing option. In the basic connections, we can configure blocked IP addresses and protocols. So, BitРН is blocked here by default, although that doesn't really help. However, we

don't allow downloading rentals through our VPN because it's dangerous, especially in Europe. There are all sorts of DMCA regulations, I think they're called, which can instantly slap you with penalties for copyright and downloading of Tariffs. You can block certain domains entirely. That is

, you can block domains, for example, Russian ones, if you don't want people connecting to Russian websites through your connection. You can set up routing to another VPN, to another node. And here, you can block Russian domains altogether, or any other ones. This

could be useful because, as I understand it, it's currently not recommended to use your VPN, especially foreign ones, to access many Russian government websites, because they could detect your country's IP address and, well, send it for verification or block

it outright. In routing, we can set up rules for our X-Rya, which is located on the server we're currently working on. We can redirect some traffic from it, for example, to another VPN. Let's say this server is located abroad, and

we'd like to connect to it and access a Russian website through our second Russian server, not through the foreign server. How can this be done? First, we need to make an outgoing connection. We go to our Moscow server, or any other

country. Then, we create a system client without any limits or restrictions. From it, we take a link to the specific configuration file, not the subscription. And in the outgoing settings, in the JSON tab, we paste this link and click "import." That's it

, our configuration file is imported. We simply click "create," and we have an outgoing connection called "Reality.

" You can rename it for convenience, for example, "Reality MSK." Click "Save " and return to the routing tab. Here, in the routing tab, we add a new rule.

So, if we have a destination site, and our destination site's domain is in the "category.ru" category, we enter "geost categoria.ru"—this essentially refers to all sites with a Russian domain ending in "rru." And not "tolik.ru," as there are other rules. "Geosite" is "

geobza." All our IP addresses, all our domains, are tied to specific countries . That's why they don't let you into the GPT chat with a Russian IP address, and so on. We also have this GE database locally, installed in place of

3xi. We can use it to specify both individual domains and entire ranges. We can also do this with IP addresses, because we have the same database for IPs, only it's called "Geo IP." And here, I think, the category is simply

called "RU" without a category. But it's better not to mix rules together, because they don't reinforce each other ; they only narrow each other.

Therefore, it's better to create a separate rule for GEOS. Select the outgoing tag "reality MSK." Create and add another rule, this time for the IP address geo ip.ru and also for our outgoing address MSK. Here, the rules work in sequential order, but these

first three rules, in theory, shouldn't interfere with us in any way, because they're linked to some internal trivialization: Geo IP private and bitint. Save. You need to restart the panel for the morphing to apply.

Previously, this could be done directly from here, but now, apparently, you'll have to go to a dashboard or even the panel settings. So, restart the panel.

Now let's test it. Let's connect to our foreign server. After that, open the 2p.ru website. And we see that our IP address is displayed as the Russian one of our server in Moscow. If we open a foreign website, we'll see the Swiss IP

address corresponding to our server, which we initially connect to. This way , the rules can be configured with maximum flexibility. I think it's much more convenient than switching between VPNs. You can simply connect to one VPN , and when you access the same thing,

like the same social network—yes, even a foreign one—you'll access it through Switzerland. But when you access Gosuslugi or Sberg or anywhere else, you'll access it through a Russian server. Again, what I'm showing you now isn't the ultimate truth. There

are a huge number of settings here. I recommend arming yourself with a neural network. If you haven't used neural networks yet, take a look. I recently created a guide on neural networks, including free ones. And with a neural

network, by downloading a local project and studying it, you can eventually figure it out and configure everything the way you want. If you're interested in any specific cases, please leave a comment or message me on Telegram. I read the comments, or at least try to

read them all, though I don't answer them all because I simply don't have the time. I'll try to film a separate video or mini-guide to answer the most frequently asked questions. That's all for today. Thank you very much for

watching. This video was quite challenging, so if you liked it and found it useful, please give it a like, subscribe to the channel, and leave a comment. And also, visit my other social media, like my Boost channel and

Telegram. I not only share interesting news and guides there, but also give away prizes and do a lot of other interesting things. Sharing. Bye, and see you in new videos.