Начните бесплатный 3-дневный пробный период
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.
Настройка XHTTP: перенос одного сервера Xray
Marcus Reid
11 октября 2026 г.· 11 мин чтения
Настройка XHTTP создаёт новый транспортный путь, а не переименовывает поле конфигурации. Добавьте отдельный вход, убедитесь, что один клиент отправляет и получает через него данные, и сохраните старый вход для отката. Здесь используются Ubuntu 24.04 LTS x64 с обеих сторон и Xray v26.3.27: прямой TLS, HTTP/2 и явный режим stream-up.［1］［2］
Ключевые выводы
- Выделите испытанию отдельные бинарный файл, службу, конфигурацию, TCP-порт и UUID.
- Сохраните старую серверную службу и клиентский профиль на время приёмки.
- Согласуйте путь, режим, имя TLS и данные доступа на обеих сторонах.
- Отдельно проверяйте получение, отправку, длительные запросы, отказы и откат.
- Не добавляйте в первую миграцию CDN, обратный прокси, REALITY, H3 или разделение направлений.
Версии указаны для воспроизводимости документации; полный сквозной тест не выполнялся. Ниже описаны методы и ожидаемое поведение, а не измеренные результаты. Сначала определите границы приёмки по списку задач и восстановления для самостоятельного размещения.
Что должна сохранить миграция Xray XHTTP?
Сохраните старый слушающий процесс, пользователя службы, выпуск и продление сертификатов, правила межсетевого экрана и клиентский профиль. Зафиксируйте пути программы и конфигурации старого unit, владельцев портов. Сделайте закрытые административные копии старой конфигурации и экспорта клиента. Не публикуйте UUID, ключи, адреса и журналы назначений.
Работайте только с разрешённым сервером, имея консоль восстановления и независимо проверенные ключи SSH. Используйте строгую проверку и отдельный known_hosts; остановитесь при несовпадении, отзыве или непроверенном ключе. Экспериментальный VPN не должен становиться единственным путём управления.
Этот маршрут полезен, если вам нужно эксплуатировать Xray и исследовать его транспорт. Если обслуживание обновлений и сертификатов не помогает задаче, сравните обязанности владельца VPS и пользователя VPN до изменения работающего входа. XHTTP не отменяет различий между протоколом, транспортом и обфускацией.
Закрепите идентичность испытания
Выберите свободный TCP-порт, здесь 8443, и собственный домен, здесь xhttp.example.com. Проверьте sudo ss -lntup и правила провайдера. Выделите новый unit xray-xhttp.service, локальный клиентский вход 127.0.0.1:1081 и новый UUID. Для наблюдения старого пути сохраните отдельный клиентский процесс или приложение.
По возможности разрешите TCP 8443 только нужным клиентам. UDP для этого маршрута не нужен. Сохраните SSH и порты проверки сертификатов. Новый TLS-вход не оправдывает отключение экрана или захват старой службы ACME.
Шаг 1: подготовьте версию и доверенный сертификат
Скачайте архив Linux 64-bit из официального выпуска v26.3.27, изучите примечания и опубликованные проверочные материалы, распакуйте его локально. От root установите программу в /opt/xray-xhttp/v26.3.27/xray с режимом 0755. Сохраните в этом каталоге вспомогательные файлы данных, если они входят в архив. Повторите установку на клиентской Ubuntu.［1］
На обеих сторонах выполните /opt/xray-xhttp/v26.3.27/xray version и сохраните вывод конфиденциально. Не заменяйте выпуск предварительной сборкой и не смешивайте разные ядра незаметно. Создайте новый идентификатор командой /opt/xray-xhttp/v26.3.27/xray uuid; запишите его в защищённую заметку и обе закрытые конфигурации.
Создайте системного пользователя xray-xhttp без входной оболочки. Каталог /etc/xray-xhttp должен принадлежать root:xray-xhttp с режимом 0750. Получите публично доверенный сертификат для xhttp.example.com через существующий разрешённый процесс ACME. Поместите полную цепочку и закрытый ключ в этот каталог как копии root:xray-xhttp, режим 0640. Дайте доступ к этим копиям, не ко всему чужому хранилищу сертификатов.
Существующий механизм продления должен атомарно обновлять копии и после проверки перезапускать только испытательную службу. Зафиксируйте этот hook до переноса повседневного клиента. Если процесса сертификатов пока нет, сначала создайте его отдельно: эта инструкция не запускает второй ACME-демон, конкурирующий за TCP 80 или 443.
Шаг 2: конфигурация XHTTP stream-up на обеих сторонах
Через sudoedit создайте /etc/xray-xhttp/server.json. Замените REPLACE_NEW_UUID сгенерированным значением. В закреплённой версии вход VLESS использует clients, а выход — users. Не переносите входное поле из более поздней редакции документации.［3］
{
"log": {"loglevel": "warning"},
"inbounds": [{
"tag": "xhttp-trial",
"listen": "0.0.0.0",
"port": 8443,
"protocol": "vless",
"settings": {
"clients": [{"id": "REPLACE_NEW_UUID"}],
"decryption": "none"
},
"streamSettings": {
"network": "xhttp",
"security": "tls",
"tlsSettings": {
"alpn": ["h2"],
"certificates": [{
"certificateFile": "/etc/xray-xhttp/fullchain.pem",
"keyFile": "/etc/xray-xhttp/privkey.pem"
}]
},
"xhttpSettings": {
"path": "/migration-stream/",
"mode": "stream-up"
}
}
}],
"outbounds": [{"tag": "direct", "protocol": "freedom"}]
}
Пример слушает IPv4. A-запись домена должна вести на правильный сервер; не объявляйте ещё не настроенный IPv6-вход. Поля VLESS none не шифруют транспорт: эту границу здесь обеспечивает TLS. Поток Vision не настроен.
На клиенте создайте закрытый client.json своего пользователя с режимом 0600 внутри каталога 0700:
{
"log": {"loglevel": "warning"},
"inbounds": [{
"listen": "127.0.0.1",
"port": 1081,
"protocol": "socks",
"settings": {"auth": "noauth", "udp": false}
}],
"outbounds": [{
"tag": "new-entry",
"protocol": "vless",
"settings": {
"vnext": [{
"address": "xhttp.example.com",
"port": 8443,
"users": [{"id": "REPLACE_NEW_UUID", "encryption": "none"}]
}]
},
"streamSettings": {
"network": "xhttp",
"security": "tls",
"tlsSettings": {
"serverName": "xhttp.example.com",
"alpn": ["h2"],
"allowInsecure": false
},
"xhttpSettings": {
"path": "/migration-stream/",
"mode": "stream-up"
}
}
}]
}
Одинаковый путь и явный режим ограничивают испытание. stream-up использует потоковую отправку с отдельным путём получения; реальная конечная точка TLS должна поддерживать H2. Переименование поля gRPC не устанавливает такое поведение.［2］［4］
Шаг 3: проверьте оба файла и запустите отдельную службу
Установите для server.json владельца root:xray-xhttp, режим 0640. Сервер проверяйте от служебного пользователя, клиент — от его владельца:
sudo -u xray-xhttp /opt/xray-xhttp/v26.3.27/xray run -test -config /etc/xray-xhttp/server.json
/opt/xray-xhttp/v26.3.27/xray run -test -config ./client.json
Обе команды должны завершиться успешно. Они выявляют ошибки конфигурации, но не доказывают сетевое доверие сертификату, удалённую аутентификацию или передачу данных. В настоящих файлах не оставляйте шаблон UUID.
Создайте от root /etc/systemd/system/xray-xhttp.service:
[Unit]
Description=Independent Xray XHTTP trial
After=network-online.target
Wants=network-online.target
[Service]
User=xray-xhttp
Group=xray-xhttp
WorkingDirectory=/opt/xray-xhttp/v26.3.27
ExecStart=/opt/xray-xhttp/v26.3.27/xray run -config /etc/xray-xhttp/server.json
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
UMask=0077
[Install]
WantedBy=multi-user.target
Выполните sudo systemctl daemon-reload и sudo systemctl start xray-xhttp. Убедитесь, что PID этого unit владеет TCP 8443, а старая служба сохранила свой порт. При ошибке запуска посмотрите закрытый journal. Для этого этапа автозапуск пока не требуется.
Запустите клиент на переднем плане через xray run -config ./client.json, используя полный путь закреплённой программы. Настройте только испытательное приложение на SOCKS5 127.0.0.1:1081. Убедитесь, что другое приложение или клиент продолжает использовать старый вход. Не останавливайте все процессы Xray как универсальный способ устранения ошибок.
Как настройка XHTTP проверяется в обоих направлениях?
Подготовьте собственную HTTPS-точку с известным файлом для скачивания, подтверждением загрузки и намеренно длительным ответом. Используйте несекретные данные и заранее выбранные ограничения объёма и времени. Не отправляйте файл на сторонний диагностический сайт без разрешения.
curl --fail --show-error --noproxy '' --proxy socks5h://127.0.0.1:1081 https://check.example.net/download -o ./download.bin
curl --fail --show-error --noproxy '' --proxy socks5h://127.0.0.1:1081 --data-binary @./trial.bin https://check.example.net/upload
Замените URL собственными контрольными ресурсами. Сопоставьте скачанное содержимое и подтверждение приёма с исходными файлами. Повторите ту же задачу через реальный локальный порт старого клиента. Запишите завершение, направление, длительность и ошибки: быстрое открытие страницы не подтверждает устойчивую отправку данных.
Для каждого отрицательного случая с копией клиента остановите прежний испытательный процесс на переднем плане, запустите только изменённую копию на том же локальном порту и проверьте владельца слушающего сокета. Меняйте одно условие за раз; перед следующим случаем восстановите правильный файл и повторите положительный запрос.
| Изолированное изменение или проверка | Ожидаемое поведение | Остановка или восстановление |
|---|---|---|
| Верные UUID, имя TLS, путь и режим | Скачивание и отправка завершаются правильно | Найдите ошибку направления до переключения |
| В копии клиента заменить только UUID другим новым UUID | Новый запрос не проходит аутентификацию | При успехе проверьте обход, процесс и список клиентов сервера |
Указать в serverName своё имя, отсутствующее в сертификате | Проверка имени сертификата не проходит | Верните правильное имя; оставьте allowInsecure: false |
Изменить путь клиента на /different-trial/ | Запрос не соответствует транспорту | Восстановите путь: изменение суффикса может всё ещё совпадать с префиксом |
Изменить только клиентский режим на packet-up | Явный stream-up сервер отклоняет packet-up отправку | Верните режим; это не заменяет проверку UUID |
| Длительный запрос через новый вход и отдельное наблюдение старого | Испытание работает; старая служба сохраняет порт и текущую задачу | Остановите испытание при влиянии на старый трафик |
| Перезапуск только испытательной службы | Новые запросы восстанавливаются | Проверьте сохранённые файлы и права сертификата |
Закреплённый сервер проверяет префиксы пути и обработку packet-up/stream-up загрузки. Некоторые другие сочетания могут приниматься, поэтому нельзя обещать отказ при любом различии режимов.［5］ Используйте непересекающийся путь и отрицательный случай packet-up выше, восстанавливая рабочий файл после каждого испытания.
Откройте инструмент проверки IP в настроенном браузере и сравните результат этого запроса с ожидаемым выходом сервера. Это не проверка всего DNS, IPv6, UDP и остальных приложений. Если старый gRPC-путь продолжает сбоить независимо, используйте диагностику тайм-аутов gRPC, не считая его исправленным после миграции. Роли ядер объясняются в статье о Xray и V2Ray.
Когда переключать клиент и как выполнить откат?
Меняйте сохранённую настройку одного клиента только после приёмки обоих направлений, длительной передачи, отрицательных случаев, обработки продления сертификата и перезапуска испытания. Сохраните старый профиль. Установленные соединения не перемещаются автоматически: дайте им закончиться либо переподключите намеренно. После изменения настройки проверьте новый запрос.
Начните откат на клиенте: восстановите старый профиль или локальный SOCKS-вход и проверьте свежее обращение. Остановите испытательный процесс на переднем плане. На сервере sudo systemctl disable --now xray-xhttp выключает только новый вход без редактирования старого unit. Сохранив закрытые доказательства для восстановления, удалите только испытательное правило экрана, UUID, конфигурацию и ненужные копии сертификатов. Убедитесь, что эта служба больше не владеет TCP 8443, а старый вход работает.
Для последующих обновлений подготовьте другой каталог версии и проверьте оба файла до изменения этого unit. Повторите ту же матрицу приёмки. Совместимую копию для отката храните временно, не закрепляя уязвимое ядро навсегда. Успешный перенос одного клиента не позволяет удалить вход, который нужен другим пользователям.
Итоги
Безопасная миграция сохраняет рабочий путь и добавляет независимо наблюдаемое испытание. Условия приёмки — согласованные файлы, передача в обе стороны, целенаправленные отказы и восстановление. Примеры описывают эти проверки, не заявляя об авторском развёртывании, которое их прошло.
Часто задаваемые вопросы (FAQ)
Можно ли просто переименовать настройки gRPC в XHTTP?
Нет. Установите совместимое ядро, создайте согласованный транспорт с обеих сторон, затем отдельно проверьте фактическую отправку и получение данных.
Зачем XHTTP отдельные порт и служба?
Независимое владение позволяет остановить испытание без перезапуска работающего входа. Оно также упрощает обнаружение ошибок порта, выбора конфигурации и отката.
Доказывает ли проверка конфигурации работоспособность UUID?
Нет. Синтаксическая проверка не подтверждает удалённое разрешение. Выполните контрольный запрос с правильным UUID, затем повторите с другим допустимым UUID.
Любое несовпадение режимов XHTTP должно вызывать отказ?
Нет. Результат зависит от закреплённой реализации. Здесь проверяется конкретное несовпадение packet-up клиента с сервером, явно настроенным на stream-up.
Достаточно ли одного успешного скачивания для переноса?
Нет. Проверьте отправку, длительные запросы, отказы, перезапуск и восстановление. Сохраняйте старый вход, пока не выполнены условия приёмки одного клиента.
Переходят ли старые соединения на новый XHTTP-вход?
Установленные соединения сохраняют свой путь. Измените клиентскую настройку намеренно и проверьте новый вход свежими запросами до отключения прежнего.
Можно ли сразу удалить старую серверную конфигурацию?
Сначала проверьте оставшихся пользователей и требования восстановления. Эта процедура одного клиента не разрешает удалять вход, используемый другими клиентами.
Источники:
- Xray-core release v26.3.27 — https://github.com/XTLS/Xray-core/releases/tag/v26.3.27
- Project X: XHTTP mode discussion — https://github.com/XTLS/Xray-core/discussions/4113
- Pinned Xray VLESS configuration implementation — https://github.com/XTLS/Xray-core/blob/v26.3.27/infra/conf/vless.go
- Project X: transport configuration — https://xtls.github.io/en/config/transport.html
- Pinned Xray XHTTP server implementation — https://github.com/XTLS/Xray-core/blob/v26.3.27/transport/internet/splithttp/hub.go
Sources checked 11 октября 2026 г.
Рекомендуемые статьи:
