Почему прежняя рекомендация изменилась
Раньше эта статья советовала передавать uplink в теле запроса. Для текущего входа Clearway этот совет устарел: в наших проверках CDN отклоняет GET с телом с HTTP 413. Поэтому в клиентском профиле нужна передача данных в заголовках. Это вывод о проверенном входе Clearway; поведение других CDN нужно проверять отдельно.
Шаг 1. Настройки серверного инбаунда
В существующем XHTTP-инбаунде откройте extra и проверьте:
{"uplinkDataPlacement":"auto","serverMaxHeaderBytes":262144}Добавьте эти поля в существующий объект, сохранив VLESS-пользователей, порт, path, транспорт и остальные настройки. Не заменяйте рабочий профиль пустым примером и не переустанавливайте Xray. Применяйте изменение в панели или службе, которая управляет именно этим инбаундом. Если поля уже имеют эти значения, повторная правка не нужна.
Шаг 2. Настройки клиентского Host
После подготовки сервера обновите клиентский extra:
{"uplinkHTTPMethod":"GET","uplinkDataPlacement":"header","uplinkChunkSize":4096,"scMaxEachPostBytes":4096}Это четыре поля для изменения, а не полная замена вашего extra. Сохраните xmux, служебные параметры и согласованный с сервером uplinkDataKey, если он задан. Не меняйте произвольно имя заголовка. Address, SNI и Host должны указывать ваш CDN-поддомен; порт клиента — 443, TLS включён, path совпадает с инбаундом. Серверный auto в клиенте означает старую передачу в теле; его нельзя копировать в ссылку.
Шаг 3. Обновление подписок
Сохраните Host в вашей панели и попросите абонентов обновить подписку либо импортировать новую ссылку. Уже импортированные профили сами не меняются от изменения настроек в кабинете Clearway. Кабинет формирует клиентский конфиг, но не редактирует Xray на вашем сервере. Подробные шаги для панелей: Remnawave и 3x-ui.
Как проверить результат
Сравните прежний и обновлённый профили в одной сети и в одно время. Проверьте HTTPS-запрос и небольшую загрузку через VPN, затем повторите через Wi-Fi и мобильного оператора. Зафиксируйте приложение, версию Xray, регион, время с часовым поясом и журналы обеих сторон. Ответ 200 от origin и успешный TLS не доказывают, что клиент получил данные.
Что этот переход не исправляет
Header устраняет использование GET с телом в проверенном входе. Он не гарантирует доступность у Билайна, Yota или любого другого оператора. Для HTTP 502, тайм-аутов и unexpected EOF нужны отдельные проверки. Из одного сообщения чекера «туннель есть, сайты не открываются» нельзя установить, что причиной является DPI. WebSocket также нужно проверять отдельно: успешный прямой Upgrade не подтверждает его работу через CDN.
Размер пакетов и число запросов
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.