diff --git a/docs/ru/config/transports/splithttp.md b/docs/ru/config/transports/splithttp.md
new file mode 100644
index 0000000..ed9c995
--- /dev/null
+++ b/docs/ru/config/transports/splithttp.md
@@ -0,0 +1,81 @@
+# SplitHTTP
+
+<Badge text="v1.8.16+" type="warning"/>
+
+Используется для загрузки с помощью HTTP-фрагментированной передачи, загрузка осуществляется с помощью нескольких HTTP POST-запросов.
+
+Может использоваться через CDN, не поддерживающие WebSocket, но есть несколько требований:
+
+- CDN должен поддерживать HTTP-фрагментированную передачу и потоковые ответы без буферизации. Ядро будет отправлять `X-Accel-Buffering: no` и `Content-Type: text/event-stream`, чтобы сообщить CDN об этом, но CDN должен соблюдать этот заголовок. Если промежуточный сервер не поддерживает потоковые ответы и зависает, передача, скорее всего, не будет работать.
+
+Цель та же, что и у V2fly Meek, но благодаря использованию фрагментированной загрузки скорость загрузки выше, а скорость отдачи оптимизирована, но все еще очень ограничена, поэтому к HTTP-прокси предъявляются более высокие требования (см. выше).
+
+`SplitHTTP` также принимает заголовок `X-Forwarded-For`.
+
+## SplitHttpObject
+
+`SplitHttpObject` соответствует элементу `splithttpSettings` в конфигурации транспорта.
+
+```json
+{
+  "path": "/",
+  "host": "xray.com",
+  "headers": {
+    "key": "value"
+  },
+  "maxUploadSize": 1000000,
+  "maxConcurrentUploads": 10 
+}
+```
+
+> `path`: string
+
+Путь HTTP-протокола, используемый SplitHTTP, значение по умолчанию — `"/"`.
+
+> `host`: string
+
+Хост, отправляемый в HTTP-запросе SplitHTTP, по умолчанию пуст. Если значение на стороне сервера пустое, значение хоста, отправленное клиентом, не проверяется.
+
+Если это значение указано на стороне сервера или `host` указан в `headers`, то проверяется соответствие хоста запроса клиента.
+
+Приоритет выбора хоста для отправки клиентом: `host` > `headers` > `address`.
+
+> `headers`: map \{string: string\}
+
+Пользовательские HTTP-заголовки, пары ключ-значение, где каждый ключ представляет имя HTTP-заголовка, а соответствующее значение является строкой.
+
+> `maxUploadSize`: int
+
+Максимальный размер фрагмента загрузки в байтах, по умолчанию 1 МБ.
+
+Это значение должно быть меньше максимального размера тела запроса, разрешенного CDN или другим обратным HTTP-прокси, иначе будет выдаваться ошибка HTTP 413.
+
+Увеличение этого значения может увеличить скорость загрузки.
+
+> `maxConcurrentUploads`: int
+
+Максимальное количество одновременных загрузок, по умолчанию 10, соединения будут использоваться повторно, насколько это возможно.
+
+Если соединение нестабильно или потребление памяти на сервере слишком велико, попробуйте уменьшить это значение.
+
+Значение, установленное клиентом, должно быть меньше, чем на сервере, иначе это может привести к проблемам с подключением.
+
+## Детали протокола
+
+Подробное обсуждение см. [#3412](https://github.com/XTLS/Xray-core/pull/3412) и [#3462](https://github.com/XTLS/Xray-core/pull/3462). Ниже приведено краткое описание и требования к совместимой реализации:
+
+1. Загрузка начинается с `GET /<UUID>`. Сервер немедленно отвечает `200 OK` и `Transfer Encoding:chunked` и немедленно отправляет двухбайтовую полезную нагрузку, чтобы принудительно обновить заголовки HTTP-прокси.
+
+2. Отправка данных начинается с `POST /<UUID>/<seq>`. `seq` действует как порядковый номер TCP, начиная с 0, пакеты данных могут отправляться одновременно, сервер должен пересобрать данные по порядковому номеру. Порядковый номер не следует сбрасывать.
+
+   Клиент может свободно выбирать порядок открытия исходящих и нисходящих запросов, любой из них может инициировать сеанс, но соединение `GET` должно быть открыто в течение 30 секунд, иначе сеанс будет разорван.
+
+4. Запрос `GET` будет оставаться открытым до тех пор, пока соединение не будет разорвано, и сервер, и клиент могут закрыть соединение. Конкретное поведение зависит от версии HTTP.
+
+Рекомендации:
+
+* Не ожидайте, что CDN будет правильно передавать все заголовки, цель этого протокола — обойти CDN, не поддерживающие WS, а поведение этих CDN обычно не очень дружелюбное.
+
+* Следует предполагать, что все HTTP-соединения не поддерживают потоковые запросы, поэтому размер каждого пакета, отправляемого исходящим соединением, должен определяться с учетом задержки, пропускной способности и ограничений самого промежуточного сервера (аналогично MTU TCP и алгоритму Нейгла).
+
+* Что касается версии HTTP, ядро в настоящее время не поддерживает h2c, поэтому Xray будет отправлять только запросы http/1.1 при использовании без HTTPS. Чтобы избежать дополнительных сложностей, связанных с согласованием ALPN, клиент Xray использует h2 при использовании HTTPS (если только alpn не указан вручную как http/1.1 в tlsSettings), а сервер Xray совместим с различными типами входящих подключений (h3 пока нет), поскольку входящие соединения могут быть различных типов из-за промежуточных серверов.