XHTTP
XHTTP — транспорт для инбаундов VLESS, VMess и Trojan, который передаёт соединение как обычные HTTP-запросы. Он проходит через CDN и обратные HTTP-прокси, через которые не прошёл бы долгоживущий поток, и работает с TLS, с REALITY или вовсе без TLS. Его читают только приложения на базе Xray, поэтому предлагайте его рядом с инбаундом, которым может пользоваться любое приложение.
Создание
- Входящие → Добавить, тип
vless(илиvmess,trojan). Общая форма описана в Инбаунды. - На вкладке Transport выберите
xhttp. Path — единственное поле, которое нужно большинству инбаундов; остальные находятся среди дополнительных полей. - На вкладке TLS выберите TLS с сертификатом, REALITY или без TLS. Без TLS выбирайте, только когда TLS за вас завершает CDN перед узлом.
- Нажмите Сохранить и добавьте инбаунд в шаблон.
Режимы
Mode определяет, как клиент разбивает отправку и получение на запросы. Пустое значение и auto оставляют выбор клиенту.
| Режим | Как передаётся трафик |
|---|---|
packet-up | отправка идёт серией отдельных запросов. Самый надёжный режим за CDN, потому что каждый кусок — обычный запрос |
stream-up | отправка идёт одним длинным потоковым запросом |
stream-one | оба направления делят один запрос |
Некоторые дополнительные поля работают только в режиме packet-up, а в остальных панель не даёт их сохранить.
Дополнительные поля передаются в ссылке
Каждое дополнительное поле ниже узел применяет и сообщает клиенту в его ссылке, чтобы обе стороны были согласны. Из этого следует одно, что стоит прочитать дважды:
Изменили одно поле — выпускайте все ссылки заново
Клиента со старой ссылкой узел отклоняет. XHTTP отклоняет с периодическими ошибками, а не с явным отказом, поэтому в вашу поддержку приходит «иногда работает». Определитесь с этими полями до того, как клиенты импортируют инбаунд, или будьте готовы к тому, что всем придётся обновить подписку.
Форма помечает каждое из этих полей подсказкой об этом.
| Поле | Что оно делает |
|---|---|
| X-Padding bytes | диапазон размеров заполнения, которое обе стороны добавляют к каждому запросу. Шире диапазон — больше байтов на запрос и менее регулярные размеры. Отключить его нельзя |
| X-Padding obfuscation | если выключено, заполнение передаётся в фиксированном месте, и четыре поля ниже игнорируются. Если включено, место выбираете вы |
| X-Padding placement | где оно передаётся: queryInHeader, header, query или cookie |
| X-Padding key, X-Padding header | имена, под которыми оно передаётся |
| X-Padding method | как создаётся заполнение: repeat-x или tokenish |
| Session placement, Session key | где передаётся идентификатор сессии: в пути (по умолчанию), в параметре запроса, в заголовке или в cookie, и под каким именем |
| Sequence placement, Sequence key | то же для порядкового номера пакета |
| Uplink HTTP method | POST (по умолчанию) или GET. GET принимается только в режиме packet-up |
| Uplink data placement, Uplink data key | куда идут отправляемые данные: в тело (по умолчанию), в заголовок или в cookie. Заголовок и cookie принимаются только в режиме packet-up |
| Max bytes per post | наибольший кусок отправки. Узел отклоняет кусок больше этого, поэтому клиенты получают это значение и не превышают его |
В ссылку попадают только изменённые вами значения. Значение по умолчанию туда никогда не попадает, поэтому последующая смена значения по умолчанию действует и на старые ссылки, и на новые.
Какие приложения его читают
Приложения на базе Xray (v2rayNG, v2rayN, Streisand, Happ) говорят на XHTTP и получают все поля через ссылки и формат Xray JSON. В приложениях sing-box и Clash нет XHTTP, поэтому их файлы подписки не включают этот инбаунд, вместо того чтобы нести его наполовину. Пользователь такого приложения просто не видит этот инбаунд; дайте ему другой.
За CDN
XHTTP — один из транспортов, которые может нести доменный фронт. Настройте фронт на странице Доменный фронтинг и включите его на этом инбаунде.
Заполнение, идентификатор сессии и порядковый номер нормально передаются при любом размещении: это короткие значения в пути, параметре запроса, заголовке или cookie, которые пересылает любой CDN, пересылающий HTTP. Два варианта CDN передать не может: отправляемые данные в header или cookie. Панель отклоняет их при сохранении фронта. У отправки через GET тоже нет тела, которое CDN мог бы переслать.
Настоящий адрес клиента
За CDN каждое соединение приходит на узел с адреса CDN. Чтобы сохранить собственный адрес пользователя (для ограничения адресов и журналов), узел должен читать его из заголовка, в который его записывает CDN.
Укажите этот заголовок в поле фронта Заголовок адреса клиента: CF-Connecting-IP для Cloudflare, а для других CDN поле предлагает обычные варианты. Тогда каждый XHTTP-инбаунд, на котором включён этот фронт, доверяет этому заголовку. Сохранение фронта, меняющее заголовок, перезапускает инбаунд на его узлах, и открытые соединения обрываются.
Адрес надёжен ровно настолько, насколько выполнены три условия:
- CDN сам записывает заголовок. Cloudflare так делает; некоторые CDN передают значение, присланное клиентом, если их не настроить иначе. Проверьте документацию своего CDN.
- Узел принимает соединения только от CDN. Клиент, который подключается к узлу напрямую, тоже может прислать этот заголовок.
- Каждый фронт на инбаунде указывает один и тот же заголовок. CDN передаёт заголовок другого CDN без изменений.
При всех трёх условиях на адрес можно опирать ограничения. Без них считайте его лишь подсказкой.
Инбаунд может также нести собственный список в своём JSON, как trusted_x_forwarded_for внутри transport, и он важнее заголовка фронта. Если нет ни того ни другого (ни списка на инбаунде, ни фронта с заголовком), узел доверяет любому заголовку X-Forwarded-For от кого угодно: клиент, который подключается к инбаунду напрямую, может указать свой адрес сам. Поэтому указывайте заголовок на фронте и не ставьте инбаунд без фронта за какой-либо другой прокси.
Связанные страницы
- VLESS Encryption — сохраняет приватность трафика там, где CDN завершает TLS
- Доменный фронтинг — настройка фронта
- Протоколы — какие транспорты читает каждое приложение