https://pastein.ru/t/SJN
Загрузка данных
Да. Но я бы **не делал просто VLESS + REALITY поверх старого TCP-варианта**. Для новой установки я бы взял:
- **сервер:** Xray-core;
- **протокол:** VLESS;
- **transport:** **XHTTP**;
- **security:** **REALITY**;
- **клиент на NixOS:** тоже **Xray-core CLI**, а не sing-box;
- локально: SOCKS5 + HTTP proxy, а при необходимости — TUN.
Причина: актуальный Xray прямо поддерживает связку VLESS + XHTTP + REALITY, причём REALITY сейчас поддерживается с RAW, XHTTP и gRPC. Сам Xray описывает XHTTP как отдельный современный transport, а HTTPUpgrade, например, уже рекомендует заменять на XHTTP. XTLS+1
При этом важно понимать: **«максимально живучей» конфигурации не существует**. Если оператор блокирует конкретные IP/ASN или активно анализирует трафик, любой публичный сервер может перестать работать. Поэтому ниже я также дам архитектуру с резервным вторым транспортом.
## Что именно будем строить
Схема:
```
NixOS
│
│ SOCKS5 / HTTP / TUN
▼
Xray client
│
│ VLESS
│ XHTTP
│ REALITY
▼
Ubuntu VPS :443
│
▼
Xray server
│
▼
Internet
```
На сервере **не нужен настоящий TLS-сертификат для твоего домена**: REALITY использует TLS-подобное рукопожатие и параметры целевого публичного сайта. Клиент проверяет REALITY по публичному ключу сервера, `shortId` и имени сервера. XTLS
---
# 1\. Что понадобится
Предположим:
```
VPS IPv4: 203.0.113.10
VPS OS: Ubuntu 24.04 LTS
SSH user: root
порт: 443/tcp
REALITY target: www.example.com
SNI: www.example.com
```
**`www.example.com` здесь только пример. Не копируй его.**
Target следует выбирать реальный TLS-сайт, который:
- стабильно доступен из сети, где будет клиент;
- работает на TCP/443;
- нормально отвечает на TLS ClientHello;
- имеет предсказуемый сертификат/SAN;
- не является твоим VPS;
- желательно не находится за CDN, который превращает твой VPS в потенциальный открытый TCP-forwarder.
Сам Xray отдельно предупреждает о риске с target за CDN/Cloudflare: неавторизованные REALITY-соединения могут быть перенаправлены на target, поэтому неудачный выбор target может превратить VPS в нежелательный прокси. XTLS
---
# 2\. Подготовка Ubuntu
Подключаемся:
```
ssh root@203.0.113.10
```
Обновляем систему:
```
apt update
apt full-upgrade -y
apt install -y curl unzip ca-certificates jq openssl
```
Проверяем время:
```
timedatectl status
```
Если NTP выключен:
```
timedatectl set-ntp true
```
Это важно: REALITY имеет механизм проверки допустимой разницы времени между клиентом и сервером. XTLS
---
# 3\. Firewall
Я бы оставил наружу только SSH и 443.
Если используешь UFW:
```
apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 443/tcp
ufw enable
```
Проверить:
```
ufw status verbose
```
**Не открывай UDP/443**, если конкретно выбранная конфигурация его не использует.
---
# 4\. Установка Xray
Используем официальный install script проекта Xray, а не случайный one-click installer. Репозиторий Xray указывает его как официально поддерживаемый Linux-способ установки. GitHub+1
Сначала скачиваем скрипт:
```
cd /root
curl -fsSLo install-release.sh \
https://github.com/XTLS/Xray-install/raw/main/install-release.sh
```
Посмотреть его перед запуском:
```
less install-release.sh
```
Запустить:
```
bash install-release.sh
```
После установки:
```
/usr/local/bin/xray version
```
Конфигурация обычно находится здесь:
```
/usr/local/etc/xray/config.json
```
а бинарник:
```
/usr/local/bin/xray
```
Именно такую структуру использует официальный installer. GitHub
---
# 5\. Генерируем UUID
```
xray uuid
```
Получишь что-то вроде:
```
8f5c0f5e-2a9c-4b6e-9c0e-123456789abc
```
Сохрани его.
Например:
```
UUID="8f5c0f5e-2a9c-4b6e-9c0e-123456789abc"
```
UUID должен быть случайным и уникальным; официальная документация Xray прямо рекомендует генерировать его через `xray uuid` или `uuidgen`. XTLS
---
# 6\. Генерируем REALITY keypair
Выполни:
```
xray x25519
```
Получишь примерно:
```
Private key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Public key: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
```
**Private key остаётся только на сервере.**
**Public key понадобится клиенту.**
Это соответствует актуальной схеме REALITY: сервер хранит `privateKey`, клиент — соответствующий ему публичный ключ (`password` в Xray-конфиге; название исторически несколько сбивает с толку). XTLS
---
# 7\. Генерируем shortId
Например:
```
openssl rand -hex 8
```
Получится:
```
4e8a2c91d73f05ab
```
Сохрани его.
REALITY допускает до 16 hex-символов; количество символов должно быть чётным. XTLS
---
# 8\. Проверяем REALITY target
Предположим, ты выбрал:
```
www.example.com
```
На сервере:
```
xray tls ping www.example.com
```
Если target использует 443, этого достаточно.
Если хочешь проверить конкретный порт:
```
xray tls ping www.example.com:443
```
Xray сам рекомендует `xray tls ping` для проверки поведения target. XTLS
Я бы **не переходил дальше**, пока target не выглядит нормально.
---
# 9\. Конфигурация сервера
Открываем:
```
nano /usr/local/etc/xray/config.json
```
Для начала ставим минимальную конфигурацию.
```
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"listen": "0.0.0.0",
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
"id": "YOUR-UUID",
"flow": "xtls-rprx-vision"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "xhttp",
"security": "reality",
"xhttpSettings": {
"path": "/xray"
},
"realitySettings": {
"show": false,
"target": "www.example.com:443",
"serverNames": [
"www.example.com"
],
"privateKey": "YOUR-REALITY-PRIVATE-KEY",
"shortIds": [
"YOUR-SHORT-ID"
]
}
}
}
],
"outbounds": [
{
"protocol": "freedom",
"tag": "direct"
},
{
"protocol": "blackhole",
"tag": "block"
}
]
}
```
Замени:
```
YOUR-UUID
YOUR-REALITY-PRIVATE-KEY
YOUR-SHORT-ID
www.example.com
```
на свои значения.
### Важный момент про XHTTP + Vision
Актуальная документация Xray разрешает REALITY вместе с XHTTP, а VLESS поддерживает `xtls-rprx-vision`. XTLS+1
Если конкретная версия Xray при запуске выдаёт ошибку совместимости параметров, **не начинай экспериментировать с десятком настроек**. Сначала:
```
xray version
```
и:
```
xray run -test -config /usr/local/etc/xray/config.json
```
---
# 10\. Проверяем конфигурацию
Очень важный этап:
```
xray run -test \
-config /usr/local/etc/xray/config.json
```
Если всё хорошо, получишь сообщение об успешной проверке.
Если ошибка — **не перезапускай работающий сервер**, пока её не исправишь.
---
# 11\. Запускаем Xray
```
systemctl enable xray
systemctl restart xray
```
Проверяем:
```
systemctl status xray --no-pager
```
Должно быть:
```
Active: active (running)
```
Проверяем порт:
```
ss -lntp | grep ':443'
```
Должно быть примерно:
```
LISTEN ... 0.0.0.0:443 ...
```
---
# 12\. Если Xray не стартует
Смотри:
```
journalctl -u xray -n 100 --no-pager
```
И отдельно:
```
xray run -test \
-config /usr/local/etc/xray/config.json
```
Чаще всего проблема в:
- неправильном JSON;
- неправильном `privateKey`;
- неправильном `shortId`;
- несовпадающем `serverNames`;
- занятом порте 443;
- неправильном transport;
- несовместимости версии клиента/сервера.
---
# 13\. Клиент NixOS: почему я предлагаю Xray CLI
Для твоего сценария я бы **не ставил GUI-клиент**.
Есть два разумных варианта:
### Вариант A — Xray
Плюсы:
- тот же core, что и сервер;
- актуальная поддержка REALITY/XHTTP;
- CLI;
- удобно держать конфигурацию декларативно в NixOS;
- можно сделать systemd service;
- можно поднять SOCKS/HTTP;
- можно сделать TUN.
### Вариант B — sing-box
sing-box тоже отлично поддерживает VLESS \+ REALITY и является очень хорошим Linux CLI-клиентом. В его документации VLESS имеет `xtls-rprx-vision`, TLS и transport-параметры, а REALITY поддерживается непосредственно. Sing Box+1
Но для **XHTTP + REALITY** я бы сейчас использовал именно Xray, потому что XHTTP — собственный современный transport Xray, тогда как sing-box документирует V2Ray transport отдельно и не предоставляет аналогичного XHTTP transport в этой части конфигурации. Sing Box
---
# 14\. Установка Xray на NixOS
Сначала проверь:
```
nix search nixpkgs xray
```
Xray присутствует в nixpkgs; официальный sing-box сайт также указывает nixpkgs как способ установки sing-box на NixOS. Sing Box
В `configuration.nix`:
```
environment.systemPackages = with pkgs; [
xray
];
```
Затем:
```
sudo nixos-rebuild switch
```
Проверяем:
```
xray version
```
---
# 15\. Клиентская конфигурация Xray
Создай, например:
```
/etc/nixos/xray-client.json
```
```
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"listen": "127.0.0.1",
"port": 1080,
"protocol": "socks",
"settings": {
"udp": true
}
},
{
"listen": "127.0.0.1",
"port": 1081,
"protocol": "http"
}
],
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "203.0.113.10",
"port": 443,
"users": [
{
"id": "YOUR-UUID",
"encryption": "none",
"flow": "xtls-rprx-vision"
}
]
}
]
},
"streamSettings": {
"network": "xhttp",
"security": "reality",
"xhttpSettings": {
"path": "/xray"
},
"realitySettings": {
"serverName": "www.example.com",
"fingerprint": "chrome",
"password": "YOUR-REALITY-PUBLIC-KEY",
"shortId": "YOUR-SHORT-ID",
"spiderX": "/"
}
}
},
{
"tag": "direct",
"protocol": "freedom"
},
{
"tag": "block",
"protocol": "blackhole"
}
],
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "direct"
}
]
}
}
```
Здесь:
```
address
```
— **IP твоего VPS**, а
```
serverName
```
— target/SNI.
То есть это нормально, что:
```
address = 203.0.113.10
serverName = www.example.com
```
REALITY именно так и работает.
---
# 16\. Что такое `fingerprint`
Я бы оставил:
```
"fingerprint": "chrome"
```
REALITY требует TLS fingerprint на клиенте; Xray прямо указывает `chrome` как стандартный пример. XTLS
Не надо каждый раз менять fingerprint «для маскировки». Стабильная, правдоподобная конфигурация лучше, чем хаотическое переключение параметров.
---
# 17\. Проверяем клиентскую конфигурацию
На NixOS:
```
xray run -test \
-config /etc/nixos/xray-client.json
```
Потом вручную запускаем:
```
xray run \
-config /etc/nixos/xray-client.json
```
В другом терминале:
```
curl \
--proxy socks5h://127.0.0.1:1080 \
https://ifconfig.me
```
Если всё работает, внешний IP должен быть IP VPS.
---
# 18\. Делаем systemd service на NixOS
Я бы не запускал Xray вручную.
В `configuration.nix`:
```
systemd.services.xray-client = {
description = "Xray client";
wantedBy = [ "multi-user.target" ];
after = [ "network-online.target" ];
wants = [ "network-online.target" ];
serviceConfig = {
ExecStart =
"${pkgs.xray}/bin/xray run -config /etc/nixos/xray-client.json";
Restart = "on-failure";
RestartSec = "3";
DynamicUser = true;
NoNewPrivileges = true;
PrivateTmp = true;
ProtectSystem = "strict";
ProtectHome = true;
};
};
```
Затем:
```
sudo nixos-rebuild switch
```
Проверка:
```
systemctl status xray-client
```
Логи:
```
journalctl -u xray-client -f
```
---
# 19\. Использование CLI
Теперь приложения можно направлять через SOCKS5:
```
curl --proxy socks5h://127.0.0.1:1080 https://example.com
```
Git:
```
git -c http.proxy=socks5h://127.0.0.1:1080 clone https://github.com/...
```
wget:
```
https_proxy=http://127.0.0.1:1081 \
http_proxy=http://127.0.0.1:1081 \
wget https://example.com
```
SSH:
```
ssh \
-o 'ProxyCommand=nc -x 127.0.0.1:1080 -X 5 %h %p' \
user@example.com
```
---
# 20\. SOCKS5 vs HTTP
Я бы использовал:
```
127.0.0.1:1080 = SOCKS5
127.0.0.1:1081 = HTTP
```
Для CLI в Linux основным сделал бы **SOCKS5**.
Особенно важно использовать:
```
socks5h://
```
а не:
```
socks5://
```
`h` означает, что hostname разрешается через прокси, а не локально.
Например:
```
curl --proxy socks5h://127.0.0.1:1080 https://example.com
```
---
# 21\. Если хочешь проксировать весь NixOS
Тогда SOCKS недостаточно: далеко не каждое приложение умеет SOCKS.
В таком случае я бы сделал второй вариант:
```
NixOS
│
▼
Xray TUN
│
▼
VLESS → XHTTP → REALITY
│
▼
VPS
```
Это существенно удобнее для desktop Linux.
Но TUN требует более сложной маршрутизации, DNS и исключений для самого VPS/Xray. Поэтому я бы **сначала добился стабильной работы через SOCKS**, а уже затем добавлял TUN.
---
# 22\. Что я бы НЕ делал
Не советую следующие популярные конфигурации как основной вариант:
### VLESS + WS + TLS + CDN
Это уже довольно старый шаблон.
### VLESS + HTTPUpgrade
Xray прямо рекомендует переходить на XHTTP вместо HTTPUpgrade из-за характерных признаков HTTPUpgrade. XTLS
### VMess
Для новой установки я бы его не выбирал. Xray позиционирует VLESS как лёгкий stateless-протокол, а современный стек Xray строится вокруг VLESS/XTLS/REALITY/XHTTP. XTLS+1
### WireGuard как единственный публичный endpoint
WireGuard криптографически хороший, но сам Xray отмечает, что его фиксированный UDP-признак относительно легко классифицируется/блокируется, поэтому для прямого обхода фильтрации это плохой вариант. XTLS
---
# 23\. Самое важное: не один сервер
Если тебе действительно нужна **живучесть**, я бы не пытался выжать её из одного VPS.
Архитектура лучше такая:
```
┌── VPS #1
NixOS ── client ───────┤
└── VPS #2
```
Например:
```
Node A:
VLESS + XHTTP + REALITY
Node B:
VLESS + REALITY
другой IP
другой ASN
другой target
```
И клиент имеет два outbound'а:
```
proxy-a
proxy-b
```
с возможностью переключения.
Это намного полезнее, чем бесконечно подкручивать параметры одного узла.
---
# 24\. Ещё одна важная защита сервера
REALITY имеет интересную особенность: неавторизованный трафик может быть отправлен на `target`. Xray отдельно предупреждает, что при неудачном выборе target это может создать проблему с нежелательным использованием твоего сервера. XTLS
Поэтому:
- не ставь первым попавшийся Cloudflare-домен;
- не используй свой VPS как target;
- проверяй target через `xray tls ping`;
- следи за bandwidth;
- держи `show: false`;
- не включай подробный access log без необходимости.
---
# 25\. Обновления
На сервере периодически:
```
cd /root
bash install-release.sh
```
После обновления:
```
xray version
```
Проверка:
```
xray run -test \
-config /usr/local/etc/xray/config.json
```
И только затем:
```
systemctl restart xray
```
Xray-документация отдельно предупреждает, что актуальная документация может описывать поля, которых нет в старой версии, поэтому версии клиента и сервера лучше держать современными. XTLS
---
# 26\. Что в итоге я рекомендую
Для твоего случая я бы начал именно с:
```
Xray
├── VLESS
├── XHTTP
├── REALITY
└── XTLS Vision
```
и на NixOS:
```
Xray CLI
├── SOCKS5 :1080
└── HTTP :1081
```
а затем, если нужен системный proxy:
```
Xray TUN
```
И обязательно иметь **второй VPS**, если под «живучестью» ты подразумеваешь не просто защиту от DPI, а способность продолжать работать после блокировки конкретного IP.
Официальная документация Xray сейчас прямо указывает REALITY как транспортную защиту, совместимую с RAW/XHTTP/gRPC, а Xray поддерживает VLESS, XTLS Vision и XHTTP как собственные современные компоненты. XTLS+1
### Полезные официальные страницы
```
xray version
```
- Xray — официальная документация
- Xray REALITY configuration
- Xray transport configuration
- Xray installer
- sing-box documentation
**Но есть один нюанс:** приведённый выше XHTTP-конфиг я бы не стал слепо копировать на production без сверки с конкретной версией Xray — XHTTP довольно активно развивается. Если скажешь **версию Ubuntu (`24.04/22.04`), архитектуру VPS (`amd64/arm64`) и версию NixOS**, я могу следующим сообщением дать тебе **полностью готовый комплект файлов**: `config.json` сервера + `configuration.nix` \+ клиентский `config.json` \+ systemd + TUN + команды генерации всех секретов, так чтобы осталось только подставить IP и выбранный target.