По первой ссылке, если я правильно помню, был очень странный перевод на русский
Да, но вроде все понятно. Я не знаю чем или кто его переводил, поэтому на хабре есть более менее внятный пересказ. Но я бы предпочел доверять первой ссылке, а чтобы убедится в правильности перевода я бы со всех 3х языков перевел через переводчик либо chatgpt
Если ещё актуально, вечером скину. Но пока скажу, что у меня стандартный пример с nginx с GitHub запустился без танцев с бубном. Если в кратце, то сертификаты получал через certbot(с плагином для nginx, в security ставил tls, но там указывал только alpn и fingerprint. Насколько я понял, то в таком случае в xray не нужно указывать сертификаты, ТК все равно он скрыт за nginx.
попробовал транспорт h3 и лично у меня на моб инете он неюзабелен, точнее работает точно так же как и hysteria2 c bbr (он там свой, не от линукса) и tuic: скорость не выше 1мбита, любой другой tcp прокси выдает не меньше 10мбит/с
ну и как же много там лишнего… и при этом мультиплекс по дефолту вырублен и даже указание alpn h2/h3 не включает его, нужно указывать MaxConnections=1.
я реально не понимаю чем они там занимаются: в gui клиентах вижу что можно сделать quic с маскировкой под днс, а оказывается в серверной части это тупо вырезали…
в readme в репозитории реклама happ, попробовал ss+xhttp+h3 там - нормально не заработало, какая-то задержка в 5 секунд на каждый запрос, это неюзабельно вообще.
ну и отсутствие нормальной документации до сих пор…
забываю про xray снова и возвращаюсь на амнезиювг и опенвпн
постоянно отлетает туннель к vps с reality+xhttp в ios при большом трафике, в чем может быть проблема? во всех поддерживающих его клиентах так, и именно с xhttp, от сети (вайфай/lte) не зависит. на других системах и протоколах все в порядке. какая-то утечка памяти?
в ios же ограничение 50 мб на впн приложения, вот и отлетает
Себе, ради интереса, настроил xhttp со своим доменом. От 100 мегабит остаётся 40-45
Xhttp h1/h2 работают ничем не хуже остальных tcp протоколов, т.е. потеря скорости не более 5%. Bbr вкл?
На одном VPS у меня xHTTP и Reality настроены, скорости 180/80 Мбит и 350/300 Мбит соответственно. Так что да, xHTTP медленнее, но как резервный вариант сойдёт.
Ни разу не сталкивался. Откуда информация - подробней где-нибудь можно почитать? А главное, зачем такое ограничение?
видел во многих группах в телеге обсуждалось. Типа xhttp притокол вылезает за пределы 50mb озу и у людей соединение рвётся
включен, конфиг выглядит так (собирал по примерам с гитхаба):
xray server config.json
{
"log": {
"loglevel": "warning",
"error": "/var/log/xray/error.log",
"access": "/var/log/xray/access.log"
},
"inbounds": [
{
"listen": "/dev/shm/uds2023.sock,0666",
"protocol": "vless",
"settings": {
"clients": [
{
"id": "UUID #1",
"email": "testclient"
},
{
"id": "UUID #2",
"email": "home"
}
],
"decryption": "none"
},
"streamSettings": {
"network": "xhttp",
"xhttpSettings": {
"host": "",
"path": "/video",
"mode": "auto"
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls"
],
"routeOnly": true
}
}
],
"routing": {
"rules": [
{
"type": "field",
"protocol": [
"bittorrent"
],
"outboundTag": "block"
}
]
},
"outbounds": [
{
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}
nginx config
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
sendfile on;
keepalive_timeout 1h;
keepalive_requests 10000; # Разрешаем много запросов в одном соединении
map $remote_addr $proxy_forwarded_elem {
~^[0-9.]+$ "for=$remote_addr";
~^[0-9A-Fa-f:.]+$ "for=\"[$remote_addr]\"";
default "for=unknown";
}
map $http_forwarded $proxy_add_forwarded {
"~^(,[ \\t]*)*([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?(;([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?)*([ \\t]*,([ \\t]*([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?(;([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?)*)?)*$" "$http_forwarded, $proxy_forwarded_elem";
default "$proxy_forwarded_elem";
}
server {
listen 80;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl default_server; # This configuration is only required for versions 1.25.1 and above; otherwise, it must be removed.
http2 on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_reject_handshake on; #Version must be at least v1.19.4 to be supported.
}
server {
listen 443 ssl; # This configuration is only required for versions 1.25.1 and above; otherwise, it must be removed.
http2 on;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; #If the certificate is an RSA certificate, change all ECDSA certificates to RSA.
ssl_prefer_server_ciphers on; #Use the server-side cipher suite first. (Valid for cipher suites using the TLSv1.2 protocol as described above)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; #Enable HSTS
# Запрещаем доступ к скрытым файлам (кроме .well-known для сертификатов)
location ~ /\.(?!well-known).* {
deny all;
}
# Отпугиваем поисковых ботов, чтобы домен не индексировался как прокси
location = /robots.txt {
default_type text/plain;
return 200 "User-agent: *\nDisallow: /\n";
}
location /video {
grpc_pass grpc://unix:/dev/shm/uds2023.sock; #Forward to local VLESS+XHTTP listening process
grpc_set_header Connection "";
grpc_set_header Forwarded $proxy_add_forwarded;
grpc_set_header X-Forwarded-Port $server_port;
grpc_set_header X-Forwarded-Host $host;
grpc_set_header Host $host;
grpc_set_header X-Real-IP $remote_addr;
grpc_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
grpc_set_header X-Forwarded-Proto $scheme;
# Важно: если данные не идут 1 час, только тогда разрывать.
# Это позволяет параметру hKeepAlivePeriod (30s) в клиенте спокойно работать.
grpc_read_timeout 1h;
grpc_send_timeout 1h;
grpc_socket_keepalive on;
grpc_buffer_size 16k;
}
location / {
root /var/www/html; #Change to your own web file path
index index.html index.htm;
}
}
}
xray client config
{
"log": {
"loglevel": "warning"
},
"dns": {
"hosts": {
"ntc.party": [
"130.255.77.28"
]
},
"servers": [
{
"address": "192.168.2.7",
"domains": ["geosite:category-ru","geosite:yandex","geosite:mailru","geosite:category-gov-ru","regexp:\\.xn--"]
},
"https://dns.google/dns-query"
],
"queryStrategy": "UseIPv4",
"tag": "dns-module"
},
"inbounds": [
{
"tag": "socks",
"port": 2080,
"listen": "127.0.0.1",
"protocol": "mixed",
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls"
],
"routeOnly": false
},
"settings": {
"auth": "noauth",
"udp": true,
"allowTransparent": false
}
}
],
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "example.com",
"port": 443,
"users": [
{
"id": "UUID",
"security": "auto",
"encryption": "none"
}
]
}
]
},
"streamSettings": {
"network": "xhttp",
"security": "tls",
"tlsSettings": {
"allowInsecure": false,
"serverName": "example.com",
"alpn": [
"h2"
],
"fingerprint": "chrome"
},
"xhttpSettings": {
"path": "/video",
"host": "example.com",
"mode": "auto",
"extra": {
"noGRPCHeader": false,
"scMaxEachPostBytes": 1000000,
"scMinPostsIntervalMs": 30,
"xPaddingBytes": "100-1000",
"xmux": {
"maxConcurrency": "16-32",
"maxConnections": 0,
"cMaxReuseTimes": "64-128",
"cMaxLifetimeMs": 0,
"hMaxRequestTimes": "800-900",
"hKeepAlivePeriod": 0
}
}
},
"sockopt": {
"tcpFastOpen": true,
"tcpMptcp": true,
"tcpNoDelay": true
}
}
},
{
"tag": "direct",
"protocol": "freedom",
"settings": {
"domainStrategy": "UseIPv4"
}
},
{
"tag": "block",
"protocol": "blackhole"
}
],
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"port": "443",
"network": "udp",
"outboundTag": "block"
},
{
"type": "field",
"outboundTag": "direct",
"domain": [
"geosite:category-ru",
"geosite:category-gov-ru",
]
},
{
"type": "field",
"outboundTag": "direct",
"ip": [
"geoip:private",
"geoip:ru"
]
},
{
"type": "field",
"port": "0-65535",
"outboundTag": "proxy"
},
{
"type": "field",
"inboundTag": [
"dns-module"
],
"outboundTag": "proxy"
}
]
}
}
ничего по такому конфигу сказать не могу, для диагностики и решения таких проблем нужно начинать с минимального и максимально простого конфига и тестить каждое изменение
согласен, будет свободное время, займусь
Своим можете поделиться, если тоже делали с nginx впереди?
Добрый вечер. Можете дать пример клиентского конфига.
Собрал такую схему, пока ради эксперимента. На eu vps поставил чистый xray c xhttp, без веб-вервера. На ru vps настроил haproxy, который перенаправляет на xray.
Client → ruvps(haproxy) → euvps(xray)
В дампе трафика между клиентом и haproxy все стандартно, как будто подключаюсь к сайту. Но, между ruvps и euvps есть один пакет, по которому можно блокировать такие соединения.
Вот у меня вопрос: на сколько такая схема палевная и есть ли смылс ее использовать?
Нету смысла что-то маскировать, если работает то забей
Ты специально настраивал на 2443 порт?
Схема нормальная, просто обычно вместо реверс прокси на ru vps ставят также xray, чтобы маршрутизировать трафик. Например, случайно попавший от криво настроенных клиентов ru трафик сразу выпускать в директ, а не тащить до eu.
Порт 2443 на стороне euvps, 443 занят уже. На ruvps используется 443. Не вижу смысла прям 443 использовать и прикрываться какой-то страничкой, т.к. у меня доступ по белым спискам.
Маршрутизацией не пользуюсь, мне это не критично. Может, позже подумаю об этом.
Смысл в моей схеме был такой: взять самый дешёвый ruvps, и т.к. ресурсов там мало, поставить туда только haproxy, и проксировать через него различные прокси. Сейчас у меня проксируется через него xhttp, wa-proxy, mtproxy и socks5, которые настроены уже на euvps.
он у вас вообще работает? Вы рискуете баном айпи адреса если curl -k https://ip:port выдает “whatsapp error”
Было бы интересно выяснить, что приводит к бану. Если это результат работы какого-то сканера типо того же сайберока, то проблема решается банальным ACL на сервере. Если это результат анализа трафика клиентов, а там есть куча характерных портов типо 8222 и 587, то тогда конечно вряд ли лечится. Я больше склонен к первому. Еще интересно, что будет, если wa proxy развернут на ru адресе.