# 3x-ui-with-xhttp: a Russian setup guide for VLESS XHTTP on 3x-ui

> The 3x-ui-with-xhttp repository is a Russian language tutorial, not a software project, showing how to install the 3x-ui panel on a VPS and configure a VLESS inbound with the XHTTP transport, either directly with Reality or behind a CDN such as Cloudflare. It is useful as a deployment walkthrough for people running their own proxy, but the guide is written entirely in Russian, the repository holds only a README and one shell script, and it documents third-party panel software that the repository does not contain.

**ServerTechnologies/3x-ui-with-xhttp** — Настройка прокси vless c xhttp с помощью 3x-ui

- Repository: https://github.com/ServerTechnologies/3x-ui-with-xhttp
- Stars: 756 · Forks: 64
- Language: Shell
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/servertechnologies-3x-ui-with-xhttp

## A tutorial repository with two files in it

The top level of this repository contains exactly two entries: `Readme.md` and `opensslcert`. There is no source code, no build system and no test suite, and the primary language is recorded as Shell because of that one script.

What the repository does have is a complete deployment walkthrough, written in Russian, for a specific configuration: the 3x-ui panel, the VLESS protocol, and the XHTTP transport. The title of the guide says it outright, creating a VPN with the VLESS Reality transport using XHTTP through the 3x-ui panel.

The interesting technical claim is in the second paragraph. XHTTP is described as a modern transport for the VLESS protocol that transfers data using HTTP requests, and the key feature named is the ability to place a CDN server between the client and the server. That single property is what the rest of the guide is built around, because once a CDN can sit in the middle, the origin server's IP address is no longer visible to the client, and the origin no longer has to accept connections directly on a well known port.

Because the whole document is in Russian, the practical audience is narrow. Anyone who does not read Russian gets the panel names, the field names and the commands, which is enough to follow mechanically, but not the reasoning.

There are no GitHub releases and the licence is not classified, so the last push date is the only version marker available.

## The server requirements and the first hour of setup

The guide starts with hardware, which is short enough to state exactly. One CPU, one gigabyte of RAM, ten gigabytes of disk, and Ubuntu 24 x64 as the operating system. The panel is installed on a VPS, and the guide links a hosting provider with more than 36 locations and advises picking one near you if no particular country matters.

The preparation steps are the standard first hour on a fresh server, and the guide is unusually careful about the password. It advises changing the password that arrived in the email, says not to use a password you invent yourself because such passwords are generally unreliable, and suggests generating a random string instead:

```sh
openssl rand -base64 32
```

The guide then makes a point that is easy to misread: this command generates the characters but does not change the password. To actually set it, you run:

```sh
passwd
```

It also asks you to verify the change without closing the current terminal tab, by opening a new tab and reconnecting, so that a mistake in the command does not lock you out of a server you have just paid for.

Then the system is updated and rebooted:

```sh
sudo apt update
sudo apt upgrade -y
```

```sh
sudo reboot
```

The guide notes that the connection will drop during the reboot and that you can reconnect after a couple of minutes, and it mentions that any dialog windows that appear during the package update can be dismissed with Enter. This is the level of detail the whole document sits at, which is why it works as a tutorial rather than as a reference.

## Installing the panel and issuing a self-signed certificate

The panel is installed with a one line script fetched over the network:

```sh
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)
```

Note what that command points at. It is a script from the mhsanaei/3x-ui repository, executed directly from the network, and the guide in this repository does not vendor or pin it. The panel software itself is therefore a third-party dependency that this repository documents but does not contain or control.

The install script asks whether you want to customise the panel port, with the prompt about applying a random port if you do not. The guide's advice is to press Enter and let the port and other settings be assigned randomly, then to save the address and login password the panel gives you somewhere safe.

When you open the panel in a browser, a red banner says the connection is not encrypted and asks you to create a TLS certificate. Two options are described: connect a domain and issue a certificate through the x-ui menu, or create a self-signed certificate. The guide chooses the second, and the commands are:

```sh
mkdir cert
cd cert
wget -qO- https://raw.githubusercontent.com/ServerTechnologies/3x-ui-with-xhttp/refs/heads/main/opensslcert | bash
```

That third line is the `opensslcert` script in this repository, the one shell file in the tree. It prints the paths of the generated certificate files, and you paste those paths into the panel under Settings then Certificates, press Save, and restart the panel. The browser will still complain about the certificate, and the guide is explicit that this is expected, because a self-signed certificate is not trusted by default.

One operational note follows: when you type the panel address in the browser later, change the protocol from `http` to `https`.

The certificate step is framed as being for older panel versions only. The guide notes that newer versions of the 3x-ui panel can issue a Let's Encrypt certificate for an IP address, which removes the self-signed step entirely and is the better path if you are installing today.

## Two inbound setups, one with Reality and one behind a CDN

The guide then splits into two ways of creating the inbound connection, and the difference between them is the whole point of the XHTTP transport.

The simpler route is called XHTTP VLESS Reality. In the 3x-ui panel you create an inbound with the protocol set to Vless, the port to 443, the transport to XHTTP and security to Reality. For the Dest and SNI fields you put any unblocked foreign site, then press Get New Cert and Get New Seed and create the inbound. The panel also creates one client, and you can add more, then pass the connection link to a device or scan the QR code.

The guide is explicit that this configuration works with or without a CDN, roughly like ordinary VLESS Reality with TLS. The Dest and SNI pointing at a real site is the camouflage mechanism, and the certificate and seed are generated per inbound.

The second route puts a CDN in the middle. The guide defines a CDN in the ordinary way, a network of servers distributed across regions that helps deliver content faster and more reliably, then reframes it for this case as simply an intermediate server between the client and the panel server. It says plainly that this slightly reduces speed but hides the server's IP address behind the CDN's IP address. Cloudflare is used in the example because it offers its infrastructure for free, while other services cost money, and you need a domain pointing at the VPN server.

The inbound settings change accordingly. The port must be anything other than 80, 443 or 22, the host is your domain, the path can be anything, security is left empty and sniffing is turned off.

The Cloudflare side is spelled out step by step. Under SSL/TLS you choose Flexible, under SSL/TLS then Edge Certificates you turn off TLS 1.3, under Network you enable gRPC, and under Rules then Overview you create an origin rule. The rule matches on hostname with the equals operator against your domain or subdomain, and the destination port is set with a Rewrite to pointing at the inbound port.

The client configuration is then a small edit to the one you would make otherwise. The address becomes your domain or subdomain, the port is 443, security is TLS and the SNI is your domain or subdomain.

## Client support is still partial, and the guide names what works

One closing note from the guide deserves more attention than it gets, because it is the most likely reason a setup will not work on your device.

The guide states that since this technology is relatively new, not all clients support it yet, and then lists the clients it is sure support the transport. On Windows and Linux that is v2rayN. On Android it is v2rayNG. On iOS and on macOS on arm64 it is Streisand, linked as an App Store application.

So the coverage is: the two v2ray clients cover desktop and Android, and iOS and Apple Silicon macOS have one named option. Anything else is a matter of testing, and the failure mode when a client does not support XHTTP is likely to look like a configuration error rather than a missing feature, which is a poor way to spend an afternoon.

The whole guide is written from the point of view of someone standing up their own proxy on a rented server, and it makes the associated trade-offs along the way rather than hiding them. The CDN route costs a little speed. The self-signed certificate produces browser warnings. The panel port is better left random. The install script is fetched live from another repository.

One thing the guide does not address is how the panel and the inbound configuration are backed up or updated. There is no upgrade step documented, no mention of a backup of the panel settings, and no discussion of what happens to the client configurations when the panel is reinstalled, which is a gap for anyone who plans to run this for a while rather than test it once.

## Conclusion

Use 3x-ui-with-xhttp as a deployment reference if you already read Russian and want a concrete, step by step path from a bare Ubuntu VPS to a working VLESS XHTTP inbound with Reality or a CDN. Do not expect a codebase here, because the repository contains only a README and a single certificate script, and check first that the panel version you install still matches what the guide describes, since newer 3x-ui releases can issue a Let's Encrypt certificate for the IP address and change the panel port handling the tutorial describes.

## FAQ

### What is the 3x-ui-with-xhttp repository?

It is a Russian language deployment tutorial for the 3x-ui panel, showing how to install it on a VPS and configure a VLESS inbound with the XHTTP transport, either with Reality or behind a CDN such as Cloudflare. The repository contains only a README and one shell script called opensslcert.

### What does XHTTP add to the VLESS protocol?

According to the guide, XHTTP is a modern transport for VLESS that transfers data using HTTP requests, and its key feature is the possibility of using a CDN server between the client and the server. That hides the origin server IP address behind the CDN address, at some cost in speed.

### How do I install the 3x-ui panel according to the guide?

The guide runs `bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)`, advises letting the installer pick a random panel port by pressing Enter rather than choosing one, and saving the address and login password the panel prints.

### Do I need a self-signed certificate for 3x-ui?

Only for older panel versions. The guide says newer versions of 3x-ui can issue a Let's Encrypt certificate for an IP address. Otherwise you can create one with the opensslcert script in the repository and paste the printed file paths into the panel's Settings then Certificates page.

### Which clients support the XHTTP transport?

The guide says not all clients support it yet, and names v2rayN for Windows and Linux, v2rayNG for Android, and Streisand for iOS and macOS on arm64.

### Is 3x-ui-with-xhttp still being updated?

The repository is not archived and the last push was on 2026-06-08. There are no GitHub releases, and the licence is not classified, so the push date is the only version marker.

## Sources

- [Issues](https://github.com/ServerTechnologies/3x-ui-with-xhttp/issues)
- [README](https://github.com/ServerTechnologies/3x-ui-with-xhttp/blob/main/README.md)
- [ServerTechnologies/3x-ui-with-xhttp on GitHub](https://github.com/ServerTechnologies/3x-ui-with-xhttp)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/servertechnologies-3x-ui-with-xhttp