mirror of
https://github.com/XTLS/Xray-docs-next.git
synced 2025-01-19 17:21:41 +03:00
translate docs under transport into english (#356)
* translate transpots docs into english * p1
This commit is contained in:
picklefan
GitHub
parent
e1276fdc29
commit
381030ac6e
@ -1,22 +1,22 @@
|
||||
# Domain Socket
|
||||
|
||||
::: danger
|
||||
推荐写到 [inbounds](../inbound.md) 的 `listen` 处，传输方式可选 TCP、WebSocket、HTTP/2.
|
||||
未来这里的 DomainSocket 可能会被弃用。
|
||||
We recommend writing it to the `listen` field in [inbounds](../inbound.md)and the transport mode can be TCP, WebSocket, or HTTP/2.
|
||||
|
||||
Note that the DomainSocket option here may be deprecated in the future.
|
||||
:::
|
||||
|
||||
Domain Socket 使用标准的 Unix domain socket 来传输数据。
|
||||
Domain Socket uses standard Unix domain sockets to transmit data.
|
||||
|
||||
它的优势是使用了操作系统内建的传输通道，而不会占用网络缓存。
|
||||
理论上相比起本地环回网络（local loopback）来说，Domain socket 速度略快一些。
|
||||
The advantage of using DomainSocket is that it uses the built-in transport channel of the operating system and does not occupy the network cache. Theoretically, it is slightly faster than local loopback networks.
|
||||
|
||||
目前仅可用于支持 Unix domain socket 的平台，如 Linux 和 macOS。在 Windows 10 Build 17036 前不可用。
|
||||
Currently, it can only be used on platforms that support Unix domain sockets, such as Linux and macOS. It is not available until Windows 10 Build 17036.
|
||||
|
||||
如果指定了 domain socket 作为传输方式，在入站出站代理中配置的端口和 IP 地址将会失效，所有的传输由 domain socket 取代。
|
||||
If DomainSocket is specified as the transport mode, the ports and IP addresses configured in the inbound and outbound proxies will be invalidated, and all transports will be replaced by DomainSocket.
|
||||
|
||||
## DomainSocketObject
|
||||
|
||||
`DomainSocketObject` 对应传输配置的 `dsSettings` 项。
|
||||
`DomainSocketObject` corresponds to the `dsSettings` item.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -28,16 +28,16 @@ Domain Socket 使用标准的 Unix domain socket 来传输数据。
|
||||
|
||||
> `path`: string
|
||||
|
||||
一个合法的文件路径。
|
||||
A valid file path.
|
||||
|
||||
::: danger
|
||||
在运行 Xray 之前，这个文件必须不存在。
|
||||
This file must not exist before running Xray.
|
||||
:::
|
||||
|
||||
> `abstract`: true | false
|
||||
|
||||
是否为 abstract domain socket，默认值 `false`。
|
||||
Whether it is an abstract domain socket, with a default value of `false`.
|
||||
|
||||
> `padding`: true | false
|
||||
|
||||
abstract domain socket 是否带 padding，默认值 `false`。
|
||||
Whether the abstract domain socket has padding, with a default value of `false`.
|
||||
|
||||
@ -1,37 +1,38 @@
|
||||
# gRPC
|
||||
|
||||
基于 gRPC 的传输方式。
|
||||
An modified transport protocol based on gRPC.
|
||||
|
||||
它基于 HTTP/2 协议，理论上可以通过其它支持 HTTP/2 的服务器（如 Nginx）进行中转。
|
||||
gRPC（HTTP/2）内置多路复用，不建议使用 gRPC 与 HTTP/2 时启用 mux.cool。
|
||||
gRPC is based on the HTTP/2 protocol and can theoretically be relayed by other servers that support HTTP/2, such as Nginx.
|
||||
|
||||
gRPC and HTTP/2 has built-in multiplexing, so it is not recommended to enable `mux.cool` when using gRPC or HTTP/2.
|
||||
|
||||
::: warning ⚠⚠⚠
|
||||
|
||||
- gRPC 不支持指定 Host。请在出站代理地址中填写 **正确的域名** ，或在 `(x)tlsSettings` 中填写 `ServerName`，否则无法连接。
|
||||
- gRPC 不支持回落到其他服务。
|
||||
- gRPC 服务存在被主动探测的风险。建议使用 Caddy 或 Nginx 等反向代理工具，通过 Path 前置分流。
|
||||
- gRPC doesn't support specifying the Host. Please enter the **correct domain name** in the outbound proxy address, or fill in `ServerName` in `(x)tlsSettings`, otherwise connection cannot be established.
|
||||
- gRPC doesn't support fallback to other services.
|
||||
- gRPC services are at risk of being actively probed. It is recommended to use reverse proxy tools such as Caddy or Nginx to perform path-based routing.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
如果您使用 Caddy 或 Nginx 等反向代理，请注意下列事项：
|
||||
If you are using a reverse proxy such as Caddy or Nginx, please note the following:
|
||||
|
||||
- 请确定反向代理服务器开启了 HTTP/2
|
||||
- 请使用 HTTP/2 或 h2c (Caddy)，grpc_pass (Nginx) 连接到 Xray。
|
||||
- 普通模式的 Path 为 `/${serviceName}/Tun`, Multi 模式为 `/${serviceName}/TunMulti`
|
||||
- 如果需要接收客户端 IP，可以通过由 Caddy / Nginx 发送 `X-Real-IP` header 来传递客户端 IP。
|
||||
- Make sure that the reverse proxy server has enabled HTTP/2.
|
||||
- Use HTTP/2 or h2c (Caddy), grpc_pass (Nginx) to connect to Xray.
|
||||
- The path for regular mode is `/${serviceName}/Tun`, and for Multi mode it is `/${serviceName}/TunMulti`.
|
||||
- If you need to receive the client IP address, you can use the `X-Real-IP` header sent by Caddy / Nginx to pass the client IP.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
如果你正在使用回落，请注意下列事项：
|
||||
If you are using fallback, please note the following:
|
||||
|
||||
- 不建议回落到 gRPC，存在被主动探测的风险。
|
||||
- 请确认`h2` 位于 (x)tlsSettings.alpn 中的第一顺位，否则 gRPC（HTTP/2）可能无法完成 TLS 握手。
|
||||
- gRPC 无法通过进行 Path 分流。
|
||||
- Fallback to gRPC is not recommended, as there is a risk of being actively probed.
|
||||
- Please make sure that `h2` is the first priority in `(x)tlsSettings.alpn`, otherwise gRPC (HTTP/2) may not be able to complete TLS handshake.
|
||||
- gRPC cannot perform path-based routing by Xray.
|
||||
:::
|
||||
|
||||
## GRPCObject
|
||||
|
||||
`GRPCObject` 对应传输配置的 `grpcSettings` 项。
|
||||
`GRPCObject` corresponds to the `grpcSettings` item.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -46,61 +47,63 @@ gRPC（HTTP/2）内置多路复用，不建议使用 gRPC 与 HTTP/2 时启用 m
|
||||
|
||||
> `serviceName`: string
|
||||
|
||||
一个字符串，指定服务名称，**类似于** HTTP/2 中的 Path。
|
||||
客户端会使用此名称进行通信，服务端会验证服务名称是否匹配。
|
||||
A string that specifies the service name, similar to the `path` in HTTP/2.
|
||||
|
||||
The client will use this name for communication, and the server will verify whether the service name matches.
|
||||
|
||||
> `multiMode`: true | false <Badge text="BETA" type="warning"/>
|
||||
|
||||
`true` 启用 `multiMode`，默认值为： `false`。
|
||||
`true` enables `multiMode`, with a default value of `false`.
|
||||
|
||||
这是一个 **实验性** 选项，可能不会被长期保留，也不保证跨版本兼容。此模式在 **测试环境中** 能够带来约 20% 的性能提升，实际效果因传输速率不同而不同。
|
||||
This is an **experimental** option that may not be retained for the long term, and cross-version compatibility is not guaranteed. This mode can bring about a performance improvement of around 20% in **test environments**, but actual effects may vary depending on the transmission rate.
|
||||
|
||||
::: tip
|
||||
**只需**在**出站**（**客户端**）配置。
|
||||
**Only need to be configured** in `outbound` **(client)**.
|
||||
:::
|
||||
|
||||
> `idle_timeout`: number
|
||||
|
||||
单位秒，当这段时间内没有数据传输时，将会进行健康检查。如果此值设置为 `10` 以下，将会使用 `10`，即最小值。
|
||||
The health check is performed when no data transmission occurs for a certain period of time, measured in seconds. If this value is set to less than `10`, `10` will be used as the minimum value.
|
||||
|
||||
::: tip
|
||||
如果没有使用 Caddy 或 Nginx 等反向代理工具（**通常不会**），设为 `60` 以下，服务端可能发送意外的 h2 GOAWAY 帧以关闭现有连接。
|
||||
If you are not using reverse proxy tools such as Caddy or Nginx (**which is usually the case**), if this value is set to less than `60`, the server may send "unexpected h2 GOAWAY" frames to close existing connections.
|
||||
:::
|
||||
|
||||
健康检查默认**不启用**。
|
||||
By default, the health check is **not enabled**.
|
||||
|
||||
::: tip
|
||||
**只需**在**出站**（**客户端**）配置。
|
||||
**Only need to be configured** in `outbound` **(client)**.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
可能会解决一些“断流”问题。
|
||||
Enabling health checks may help solve some "connection drop" issues.
|
||||
:::
|
||||
|
||||
> `health_check_timeout`: number
|
||||
|
||||
单位秒，健康检查的超时时间。如果在这段时间内没有完成健康检查，且仍然没有数据传输时，即认为健康检查失败。默认值为 `20`。
|
||||
The timeout for the health check, measured in seconds. If the health check is not completed within this time period, it is considered to have failed.
|
||||
The default value is `20`
|
||||
|
||||
::: tip
|
||||
**只需**在**出站**（**客户端**）配置。
|
||||
**Only need to be configured** in `outbound` **(client)**.
|
||||
:::
|
||||
|
||||
> `permit_without_stream`: true | false
|
||||
|
||||
`true` 允许在没有子连接时进行健康检查。默认值为 `false`。
|
||||
`true` allows health checks to be performed when there are no sub-connections. The default value is `false`.
|
||||
|
||||
::: tip
|
||||
**只需**在**出站**（**客户端**）配置。
|
||||
**Only need to be configured** in `outbound` **(client)**.
|
||||
:::
|
||||
|
||||
> `initial_windows_size`: number
|
||||
|
||||
h2 Stream 初始窗口大小。当值小于等于 `0` 时，此功能不生效。当值大于 `65535` 时，动态窗口机制（Dynamic Window）会被禁用。默认值为 `0`，即不生效。
|
||||
The initial window size of the h2 stream. When the value is less than or equal to `0`, this feature does not take effect. When the value is greater than `65535`, the Dynamic Window mechanism will be disabled. The default value is `0`, which means it is not effective.
|
||||
|
||||
::: tip
|
||||
**只需**在**出站**（**客户端**）配置。
|
||||
**Only need to be configured** in `outbound` **(client)**.
|
||||
:::
|
||||
|
||||
::: tip
|
||||
通过 Cloudflare CDN 时，可将值设为 `35536` 及以上，即禁用动态窗口机制（Dynamic Window）,可防止 Cloudflare CDN 发送意外的 h2 GOAWAY 帧以关闭现有连接。
|
||||
When using Cloudflare CDN, set the value to `35536` or higher to disable the Dynamic Window mechanism and prevent Cloudflare CDN from sending "unexpected h2 GOAWAY" frames to close existing connections.
|
||||
:::
|
||||
|
||||
@ -1,28 +1,27 @@
|
||||
# HTTP/2
|
||||
|
||||
基于 HTTP/2 的传输方式。
|
||||
The transmission mode based on HTTP/2 fully implements the HTTP/2 standard and can be relayed by other HTTP servers (such as Nginx).
|
||||
|
||||
它完整按照 HTTP/2 标准实现，可以通过其它的 HTTP 服务器（如 Nginx）进行中转。
|
||||
Based on the recommendations of HTTP/2, both the client and server must enable TLS to use this transmission mode normally.
|
||||
|
||||
由 HTTP/2 的建议，客户端和服务器必须同时开启 TLS 才可以正常使用这个传输方式。
|
||||
|
||||
HTTP/2 内置多路复用，不建议使用 HTTP/2 时启用 mux.cool。
|
||||
HTTP/2 has built-in multiplexing, so it is not recommended to enable mux.cool when using HTTP/2.
|
||||
|
||||
::: tip
|
||||
当前版本的 HTTP/2 的传输方式并不强制要求**入站**（**服务端**）有 TLS 配置.
|
||||
这使得可以在特殊用途的分流部署环境中，由外部网关组件完成 TLS 层对话，Xray 作为后端应用，网关和 Xray 间使用称为 `h2c` 的明文 http/2 进行通讯。
|
||||
The current version of the transmission mode based on HTTP/2 does not require TLS configuration for inbound (server-side).
|
||||
|
||||
This makes it possible to use a plaintext HTTP/2 protocol called h2c for communication between the gateway and Xray, with external gateway components handling the TLS layer conversation in special-purpose load-balancing deployment environments.
|
||||
:::
|
||||
|
||||
::: warning
|
||||
⚠️ 如果你正在使用回落，请注意下列事项：
|
||||
⚠️ If you are using fallback, please note the following:
|
||||
|
||||
- 请确认 (x)tlsSettings.alpn 中包含 h2，否则 HTTP/2 无法完成 TLS 握手。
|
||||
- HTTP/2 无法通过进行 Path 分流，建议使用 SNI 分流。
|
||||
- Please make sure that `h2` is included in `(x)tlsSettings.alpn`, otherwise HTTP/2 cannot complete TLS handshake.
|
||||
- HTTP/2 cannot perform path-based routing, so it is recommended to use SNI-based routing.
|
||||
:::
|
||||
|
||||
## HttpObject
|
||||
|
||||
`HttpObject` 对应传输配置的 `httpSettings` 项。
|
||||
`HttpObject` corresponds to the `httpSettings` in the [Transport Protocol](../transport.md),
|
||||
|
||||
```json
|
||||
{
|
||||
@ -39,44 +38,45 @@ HTTP/2 内置多路复用，不建议使用 HTTP/2 时启用 mux.cool。
|
||||
|
||||
> `host`: \[string\]
|
||||
|
||||
一个字符串数组，每一个元素是一个域名。
|
||||
A string array, where each element is a domain name.
|
||||
|
||||
客户端会随机从列表中选出一个域名进行通信，服务器会验证域名是否在列表中。
|
||||
The client will randomly select a domain name from the list for communication, and the server will verify whether the domain name is in the list.
|
||||
|
||||
> `path`: string
|
||||
|
||||
HTTP 路径，由 `/` 开头, 客户端和服务器必须一致。
|
||||
The HTTP path starts with `/` and must be the same value between the client and server.
|
||||
|
||||
默认值为 `"/"`。
|
||||
The default value is `/`
|
||||
|
||||
> `read_idle_timeout`: number
|
||||
|
||||
单位秒，当这段时间内没有接收到数据时，将会进行健康检查。
|
||||
The connection health check is performed when no data has been received for a certain period of time, measured in seconds.
|
||||
|
||||
健康检查默认**不启用**。
|
||||
By default, the health check is **disabled**.
|
||||
|
||||
::: tip
|
||||
**只需**在**出站**（**客户端**）配置。
|
||||
**Only need to be configured** in **`outbound`** (**client**).
|
||||
:::
|
||||
|
||||
::: tip
|
||||
可能会解决一些“断流”问题。
|
||||
Enabling health checks may help solve some "connection drop" issues.
|
||||
:::
|
||||
|
||||
> `health_check_timeout`: number
|
||||
|
||||
单位秒，健康检查的超时时间。如果在这段时间内没有完成健康检查，即认为健康检查失败。默认值为 `15`。
|
||||
The timeout for the health check, measured in seconds. If the health check is not completed within this time period, it is considered to have failed.
|
||||
The default value is `15`
|
||||
|
||||
::: tip
|
||||
**只需**在**出站**（**客户端**）配置。
|
||||
**Only need to be configured** in `outbound` **(client)**.
|
||||
:::
|
||||
|
||||
> `method`: string
|
||||
|
||||
HTTP 方法。默认值为 `"PUT"`。
|
||||
HTTP request method. The default value is `PUT`
|
||||
|
||||
设置时应参照[此处](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)列出值。
|
||||
Please refer this [this](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods) when configure.
|
||||
|
||||
> `headers`: map{ string: \[string\] }
|
||||
|
||||
自定义 HTTP 头，一个键值对，每个键表示一个 HTTP 头名称，对应值为一个数组。
|
||||
Custom HTTP headers, defined as key-value pairs. Each key represents an HTTP header name and its corresponding value is an array.
|
||||
|
||||
@ -1,16 +1,16 @@
|
||||
# mKCP
|
||||
|
||||
mKCP 使用 UDP 来模拟 TCP 连接。
|
||||
mKCP uses UDP to emulate TCP connections.
|
||||
|
||||
mKCP 牺牲带宽来降低延迟。传输同样的内容，mKCP 一般比 TCP 消耗更多的流量。
|
||||
mKCP sacrifices bandwidth to reduce latency. To transmit the same content, mKCP generally consumes more data than TCP.
|
||||
|
||||
::: tip
|
||||
请确定主机上的防火墙配置正确
|
||||
Make sure the firewall on the host is configured correctly.
|
||||
:::
|
||||
|
||||
## KcpObject
|
||||
|
||||
`KcpObject` 对应传输配置的 `kcpSettings` 项。
|
||||
`KcpObject` corresponds to the `kcpSettings` in the [Transport Protocol](../transport.md),
|
||||
|
||||
```json
|
||||
{
|
||||
@ -30,77 +30,72 @@ mKCP 牺牲带宽来降低延迟。传输同样的内容，mKCP 一般比 TCP
|
||||
|
||||
> `mtu`: number
|
||||
|
||||
最大传输单元（maximum transmission unit）
|
||||
请选择一个介于 576 - 1460 之间的值。
|
||||
Maximum transmission unit. It indicates the maxium bytes that an UDP packet can carry. Recommended value is between `576` and `1460`
|
||||
|
||||
默认值为 `1350`。
|
||||
The default value is `1350`
|
||||
|
||||
> `tti`: number
|
||||
|
||||
传输时间间隔（transmission time interval），单位毫秒（ms），mKCP 将以这个时间频率发送数据。
|
||||
请选译一个介于 10 - 100 之间的值。
|
||||
Transmission time interval, measured in milliseconds (ms), determines how often mKCP sends data. Please choose a value between `10` and `100`
|
||||
|
||||
默认值为 `50`。
|
||||
The default value is `50`
|
||||
|
||||
> `uplinkCapacity`: number
|
||||
|
||||
上行链路容量，即主机发出数据所用的最大带宽，单位 MB/s，注意是 Byte 而非 bit。
|
||||
可以设置为 0，表示一个非常小的带宽。
|
||||
Uplink capacity refers to the maximum bandwidth used by the host to send data, measured in MB/s (note: Byte, not bit). It can be set to 0, indicating a very small bandwidth.
|
||||
|
||||
默认值 `5`。
|
||||
The default value is `5`
|
||||
|
||||
> `downlinkCapacity`: number
|
||||
|
||||
下行链路容量，即主机接收数据所用的最大带宽，单位 MB/s，注意是 Byte 而非 bit。
|
||||
可以设置为 0，表示一个非常小的带宽。
|
||||
Downlink capacity refers to the maximum bandwidth used by the host to receive data, measured in MB/s (note: Byte, not bit). It can be set to 0, indicating a very small bandwidth.
|
||||
|
||||
默认值 `20`。
|
||||
The default value is `20`
|
||||
|
||||
::: tip
|
||||
`uplinkCapacity` 和 `downlinkCapacity` 决定了 mKCP 的传输速度。
|
||||
以客户端发送数据为例，客户端的 `uplinkCapacity` 指定了发送数据的速度，而服务器端的 `downlinkCapacity` 指定了接收数据的速度。两者的值以较小的一个为准。
|
||||
`uplinkCapacity` and `downlinkCapacity` determine the transmission speed of mKCP. For example, when a client sends data, the client's `uplinkCapacity` specifies the speed of sending data, while the server's `downlinkCapacity` specifies the speed of receiving data. The value used is the smaller of the two.
|
||||
|
||||
推荐把 `downlinkCapacity` 设置为一个较大的值，比如 100，而 `uplinkCapacity` 设为实际的网络速度。当速度不够时，可以逐渐增加 `uplinkCapacity` 的值，直到带宽的两倍左右。
|
||||
It is recommended to set `downlinkCapacity` to a larger value, such as `100`, and set `uplinkCapacity` to the actual network speed. If the speed is insufficient, gradually increase the value of `uplinkCapacity` until it is about twice the bandwidth.
|
||||
:::
|
||||
|
||||
> `congestion`: true | false
|
||||
|
||||
是否启用拥塞控制。
|
||||
Whether or not to enable congestion control.
|
||||
When congestion control is enabled, Xray will detect network quality. It will send less packets when packet loss is severe, or more packets when network is not fully filled.
|
||||
|
||||
开启拥塞控制之后，Xray 会自动监测网络质量，当丢包严重时，会自动降低吞吐量；当网络畅通时，也会适当增加吞吐量。
|
||||
|
||||
默认值为 `false`
|
||||
The default value is `false`
|
||||
|
||||
> `readBufferSize`: number
|
||||
|
||||
单个连接的读取缓冲区大小，单位是 MB。
|
||||
The read buffer size for a single connection, measured in `MB`
|
||||
|
||||
默认值为 `2`。
|
||||
The default value is `2`
|
||||
|
||||
> `writeBufferSize`: number
|
||||
|
||||
单个连接的写入缓冲区大小，单位是 MB。
|
||||
The write buffer size for a single connection, measured in `MB`
|
||||
|
||||
默认值为 `2`。
|
||||
The default value is `2`
|
||||
|
||||
::: tip
|
||||
`readBufferSize` 和 `writeBufferSize` 指定了单个连接所使用的内存大小。
|
||||
在需要高速传输时，指定较大的 `readBufferSize` 和 `writeBufferSize` 会在一定程度上提高速度，但也会使用更多的内存。
|
||||
`readBufferSize` and `writeBufferSize` specify the memory size used by a single connection. When high-speed transmissions are required, specifying larger values for `readBufferSize` and `writeBufferSize` can improve speed to some extent, but it will also consume more memory.
|
||||
|
||||
在网速不超过 20MB/s 时，默认值 1MB 可以满足需求；超过之后，可以适当增加 `readBufferSize` 和 `writeBufferSize` 的值，然后手动平衡速度和内存的关系。
|
||||
When the network speed is no more than `20 MB/s`, the default value of `1MB` is sufficient; after exceeding this limit, you can increase the values of `readBufferSize` and `writeBufferSize` appropriately and then manually balance the relationship between speed and memory.
|
||||
:::
|
||||
|
||||
> `header`: [HeaderObject](#headerobject)
|
||||
|
||||
数据包头部伪装设置
|
||||
Configuration for packet header obfuscation.
|
||||
|
||||
> `seed`: string
|
||||
|
||||
可选的混淆密码，使用 AES-128-GCM 算法混淆流量数据，客户端和服务端需要保持一致。
|
||||
An optional obfuscation seed is used to obfuscate traffic data using the `AES-128-GCM` algorithm. The client and server need to use the same seed.
|
||||
|
||||
本混淆机制不能用于保证通信内容的安全，但可能可以对抗部分封锁。
|
||||
This obfuscation mechanism cannot ensure the security of the content, but it may be able to resist some blocking.
|
||||
|
||||
> 目前测试环境下开启此设置后没有出现原版未混淆版本的封端口现象
|
||||
::: tip NOTE
|
||||
Currently, in the testing environment, enabling this setting has not resulted in the original unobfuscated version being blocked by ports.
|
||||
:::
|
||||
|
||||
### HeaderObject
|
||||
|
||||
@ -112,35 +107,35 @@ mKCP 牺牲带宽来降低延迟。传输同样的内容，mKCP 一般比 TCP
|
||||
|
||||
> `type`: string
|
||||
|
||||
伪装类型，可选的值有：
|
||||
Type of obfuscation. Corresponding inbound and outbound must have the same value. Choices are:
|
||||
|
||||
- `"none"`：默认值，不进行伪装，发送的数据是没有特征的数据包。
|
||||
- `"srtp"`：伪装成 SRTP 数据包，会被识别为视频通话数据（如 FaceTime）。
|
||||
- `"utp"`：伪装成 uTP 数据包，会被识别为 BT 下载数据。
|
||||
- `"wechat-video"`：伪装成微信视频通话的数据包。
|
||||
- `"dtls"`：伪装成 DTLS 1.2 数据包。
|
||||
- `"wireguard"`：伪装成 WireGuard 数据包。（并不是真正的 WireGuard 协议）
|
||||
- `"none"`：Default value. No obfuscation is used.
|
||||
- `"srtp"`：Obfuscated as SRTP traffic. It may be recognized as video calls such as Facetime.
|
||||
- `"utp"`：Obfuscated as uTP traffic. It may be recognized as Bittorrent traffic.
|
||||
- `"wechat-video"`：Obfuscated to WeChat traffic.
|
||||
- `"dtls"`：Obfuscated as DTLS 1.2 packets.
|
||||
- `"wireguard"`：Obfuscated as WireGuard packets. (NOT true WireGuard protocol)
|
||||
|
||||
## 鸣谢
|
||||
## Special Thanks
|
||||
|
||||
- [@skywind3000](https://github.com/skywind3000) 发明并实现了 KCP 协议。
|
||||
- [@xtaci](https://github.com/xtaci) 将 KCP 由 C 语言实现翻译成 Go。
|
||||
- [@xiaokangwang](https://github.com/xiaokangwang) 测试 KCP 与 Xray 的整合并提交了最初的 PR。
|
||||
- [@skywind3000](https://github.com/skywind3000) Credit for inventing and implementing the original KCP protocol in C.
|
||||
- [@xtaci](https://github.com/xtaci) Credit for re-implementing KCP protocol in Go.
|
||||
- [@xiaokangwang](https://github.com/xiaokangwang) Credit for testing the integration of KCP with Xray and submitting the initial PR.
|
||||
|
||||
## 对 KCP 协议的改进
|
||||
## Improvements to the KCP protocol
|
||||
|
||||
### 更小的协议头
|
||||
### smaller protocol header
|
||||
|
||||
原生 KCP 协议使用了 24 字节的固定头部，而 mKCP 修改为数据包 18 字节，确认（ACK）包 16 字节。更小的头部有助于躲避特征检查，并加快传输速度。
|
||||
The original KCP protocol uses a fixed header of 24 bytes, while mKCP modifies it to 18 bytes for data packets and 16 bytes for acknowledgement (ACK) packets. A smaller header helps evade feature detection and speeds up transmission.
|
||||
|
||||
另外，原生 KCP 的单个确认包只能确认一个数据包已收到，也就是说当 KCP 需要确认 100 个数据已收到时，它会发出 24 \* 100 = 2400 字节的数据。其中包含了大量重复的头部数据，造成带宽的浪费。mKCP 会对多个确认包进行压缩，100 个确认包只需要 16 + 2 + 100 \* 4 = 418 字节，相当于原生的六分之一。
|
||||
In addition, the original KCP can only confirm that one packet has been received with a single ACK packet. This means that when KCP needs to confirm that 100 packets have been received, it will send out 2400 bytes of data (24 _ 100), including a large amount of repeated header information that wastes bandwidth. mKCP compresses multiple ACK packets, so 100 ACK packets only require 418 bytes (16 + 2 + 100 _ 4), which is equivalent to one-sixth of the original KCP.
|
||||
|
||||
### 确认包重传
|
||||
### ACK packet retransmission
|
||||
|
||||
原生 KCP 协议的确认（ACK）包只发送一次，如果确认包丢失，则一定会导致数据重传，造成不必要的带宽浪费。而 mKCP 会以一定的频率重发确认包，直到发送方确认为止。单个确认包的大小为 22 字节，相比起数据包的 1000 字节以上，重传确认包的代价要小得多。
|
||||
In the original KCP protocol, an ACK packet is only sent once. If an ACK packet is lost, it will cause unnecessary bandwidth waste due to data retransmission. In contrast, mKCP retransmits ACK packets at a certain frequency until they are confirmed by the sender. The size of a single ACK packet is 22 bytes, much smaller than the data packets which are over 1000 bytes. Therefore, the cost of retransmitting ACK packets is much lower.
|
||||
|
||||
### 连接状态控制
|
||||
### Connection state control
|
||||
|
||||
mKCP 可以有效地开启和关闭连接。当远程主机主动关闭连接时，连接会在两秒钟之内释放；当远程主机断线时，连接会在最多 30 秒内释放。
|
||||
mKCP can effectively initiate and close connections. When the remote host initiates disconnection, the connection will be released within two seconds. When the remote host lost connection, the connection will be released within a maximum of 30 seconds.
|
||||
|
||||
原生 KCP 不支持这个场景。
|
||||
The original KCP does not support this scenario.
|
||||
|
||||
@ -1,24 +1,25 @@
|
||||
# QUIC
|
||||
|
||||
QUIC 全称 Quick UDP Internet Connection，是由 Google 提出的使用 UDP 进行多路并发传输的协议。其主要优势是:
|
||||
QUIC (Quick UDP Internet Connection) is a protocol proposed by Google for multiplexed and concurrent transmission using UDP. Its main advantages are:
|
||||
|
||||
1. 减少了握手的延迟（1-RTT 或 0-RTT）
|
||||
2. 多路复用，并且没有 TCP 的阻塞问题
|
||||
3. 连接迁移，（主要是在客户端）当由 Wifi 转移到 4G 时，连接不会被断开。
|
||||
1. Reduced number of roundtrips in handshake phase. (1-RTT or 0-RTT)
|
||||
2. Multiplexing, and no [Head-of-Line blocking](https://calendar.perfplanet.com/2020/head-of-line-blocking-in-quic-and-http-3-the-details/) problem.
|
||||
3. Connection migration, (mainly on the client side) when switching from Wifi to 4G, the connection will not be interrupted.
|
||||
|
||||
QUIC 目前处于实验期，使用了正在标准化过程中的 IETF 实现，不能保证与最终版本的兼容性。
|
||||
QUIC is currently in the experimental phase and uses IETF implementation that is still being standardized, so compatibility with the final version cannot be guaranteed.
|
||||
|
||||
- 默认设定:
|
||||
- 12 字节的 Connection ID
|
||||
- 30 秒没有数据通过时自动断开连接 (可能会影响一些长连接的使用)
|
||||
- Default settings:
|
||||
- 12-byte Connection ID
|
||||
- Automatically disconnect the connection if no data is transmitted for 30 seconds (which may affect the use of some [persistent connections](https://en.wikipedia.org/wiki/HTTP_persistent_connection)).
|
||||
|
||||
## QuicObject
|
||||
|
||||
`QuicObject` 对应传输配置的 `quicSettings` 项。
|
||||
`QuicObject` corresponds to the `quicSettings` item in the [Transport Protocol](../transport.md).
|
||||
|
||||
::: danger
|
||||
对接的两端的配置必须完全一致，否则连接失败。
|
||||
QUIC 强制要求开启 TLS，在传输配置中没有开启 TLS 时，Xray 会自行签发一个证书进行 TLS 通讯。
|
||||
The configurations of both endpoints must be identical, otherwise the connection will fail.
|
||||
|
||||
QUIC requires TLS to be enabled and if it is not enabled in the [Transport Protocol](../transport.md), Xray will issue a self-signed certificate for TLS communication.
|
||||
:::
|
||||
|
||||
```json
|
||||
@ -33,21 +34,21 @@ QUIC 强制要求开启 TLS，在传输配置中没有开启 TLS 时，Xray 会
|
||||
|
||||
> `security`: "none" | "aes-128-gcm" | "chacha20-poly1305"
|
||||
|
||||
加密方式。
|
||||
Encryption method.
|
||||
|
||||
此加密是对 QUIC 数据包的加密，加密后数据包无法被探测。
|
||||
Extra encryption over entire QUIC packet, include the frame head part. Default value is "none" for no encryption. After being encrypted, QUIC packets will not be detected as QUIC but some other unknow traffic.
|
||||
|
||||
默认值为不加密。
|
||||
The default value is `none`
|
||||
|
||||
> `key`: string
|
||||
|
||||
加密时所用的密钥。
|
||||
Encryption key used for encryption.
|
||||
|
||||
可以是任意字符串。当 `security` 不为 `"none"` 时有效。
|
||||
It can be any string and is effective when "security" is not set to "none".
|
||||
|
||||
> `header`: [HeaderObject](#headerobject)
|
||||
|
||||
数据包头部伪装设置
|
||||
Packet header obfuscation settings.
|
||||
|
||||
### HeaderObject
|
||||
|
||||
@ -59,16 +60,16 @@ QUIC 强制要求开启 TLS，在传输配置中没有开启 TLS 时，Xray 会
|
||||
|
||||
> `type`: string
|
||||
|
||||
伪装类型，可选的值有：
|
||||
Type of obfuscation. Corresponding inbound and outbound proxy must have the same settings. Choices are:
|
||||
|
||||
- `"none"`：默认值，不进行伪装，发送的数据是没有特征的数据包。
|
||||
- `"srtp"`：伪装成 SRTP 数据包，会被识别为视频通话数据（如 FaceTime）。
|
||||
- `"utp"`：伪装成 uTP 数据包，会被识别为 BT 下载数据。
|
||||
- `"wechat-video"`：伪装成微信视频通话的数据包。
|
||||
- `"dtls"`：伪装成 DTLS 1.2 数据包。
|
||||
- `"wireguard"`：伪装成 WireGuard 数据包。（并不是真正的 WireGuard 协议）
|
||||
- `"none"`: Default value. No obfuscation is used.
|
||||
- `"srtp"`: Obfuscated as SRTP traffic. It may be recognized as video calls such as Facetime.
|
||||
- `"utp"`: Obfuscated as uTP traffic. It may be recognized as Bittorrent traffic.
|
||||
- `"wechat-video"`: Obfuscated to WeChat traffic.
|
||||
- `"dtls"`: Obfuscated as DTLS 1.2 packets.
|
||||
- `"wireguard"`: Obfuscated as WireGuard packets. (NOT true WireGuard protocol)
|
||||
|
||||
::: tip
|
||||
当加密和伪装都不启用时，数据包即为原始的 QUIC 数据包，可以与其它的 QUIC 工具对接。
|
||||
为了避免被探测，建议加密或伪装至少开启一项。
|
||||
When neither encryption nor obfuscation is enabled, QUIC transport is compatible with other QUIC tools.
|
||||
However it is recommended to enable either or both for better undetectable communication.
|
||||
:::
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
# TCP
|
||||
|
||||
TCP 传输模式是目前推荐使用的传输模式之一.
|
||||
TCP (Transmission Control Protocol) is currently one of the recommended transport protocols
|
||||
|
||||
可以和各种协议有多种组合模式.
|
||||
It can be combined with various protocols in multiple ways.
|
||||
|
||||
## TcpObject
|
||||
|
||||
`TcpObject` 对应传输配置的 `tcpSettings` 项。
|
||||
`TcpObject` corresponds to the `tcpSettings` item in the Transport Protocol.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -19,27 +19,27 @@ TCP 传输模式是目前推荐使用的传输模式之一.
|
||||
|
||||
> `acceptProxyProtocol`: true | false
|
||||
|
||||
仅用于 inbound，指示是否接收 PROXY protocol。
|
||||
Only used for inbound, indicating whether to accept the PROXY protocol.
|
||||
|
||||
[PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) 专用于传递请求的真实来源 IP 和端口，**若你不了解它，请先忽略该项**。
|
||||
The [PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) is used to transmit the real source IP and port of the request. **If you are not familiar with it, please ignore this item.**
|
||||
|
||||
常见的反代软件（如 HAProxy、Nginx）都可以配置发送它，VLESS fallbacks xver 也可以发送它。
|
||||
Common reverse proxy software (such as HAProxy and Nginx) can be configured to send it, and VLESS fallbacks xver can also send it.
|
||||
|
||||
填写 `true` 时，最底层 TCP 连接建立后，请求方必须先发送 PROXY protocol v1 或 v2，否则连接会被关闭。
|
||||
When filled in as `true`, after the underlying TCP connection is established, the requesting party must first send PROXY protocol v1 or v2, otherwise the connection will be closed.
|
||||
|
||||
默认值为 `false`。
|
||||
The default value is `false`
|
||||
|
||||
> `header`: [NoneHeaderObject](#noneheaderobject) | [HttpHeaderobject](#httpheaderobject)
|
||||
|
||||
数据包头部伪装设置，默认值为 `NoneHeaderObject`。
|
||||
Packet header obfuscation settings, the default value is `NoneHeaderObject`
|
||||
|
||||
::: tip
|
||||
HTTP 伪装无法被其它 HTTP 服务器（如 Nginx）分流，但可以被 VLESS fallbacks path 分流。
|
||||
HTTP obfuscation cannot be proxied by other HTTP servers (such as Nginx), but it can be proxied by VLESS fallbacks path.
|
||||
:::
|
||||
|
||||
### NoneHeaderObject
|
||||
|
||||
不进行伪装
|
||||
No header obfuscation
|
||||
|
||||
```json
|
||||
{
|
||||
@ -49,11 +49,11 @@ HTTP 伪装无法被其它 HTTP 服务器（如 Nginx）分流，但可以被 VL
|
||||
|
||||
> `type`: "none"
|
||||
|
||||
指定不进行伪装
|
||||
Disable header obfuscation.
|
||||
|
||||
### HttpHeaderObject
|
||||
|
||||
HTTP 伪装配置必须在对应的入站出站连接上同时配置，且内容必须一致。
|
||||
HTTP header obfuscation. The configuration must be the same between connecting inbound and outbound.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -65,15 +65,15 @@ HTTP 伪装配置必须在对应的入站出站连接上同时配置，且内容
|
||||
|
||||
> `type`: "http"
|
||||
|
||||
指定进行 HTTP 伪装
|
||||
Enable HTTP header obfuscation.
|
||||
|
||||
> `request`: [HTTPRequestObject](#httprequestobject)
|
||||
|
||||
HTTP 请求
|
||||
HTTP request template.
|
||||
|
||||
> `response`: [HTTPResponseObject](#httpresponseobject)
|
||||
|
||||
HTTP 响应
|
||||
HTTP response template.
|
||||
|
||||
#### HTTPRequestObject
|
||||
|
||||
@ -97,21 +97,21 @@ HTTP 响应
|
||||
|
||||
> `version`: string
|
||||
|
||||
HTTP 版本，默认值为 `"1.1"`。
|
||||
HTTP version, the default value is `"1.1"`
|
||||
|
||||
> `method`: string
|
||||
|
||||
HTTP 方法，默认值为 `"GET"`。
|
||||
The HTTP method, the default value is `"GET"`
|
||||
|
||||
> `path`: \[ string \]
|
||||
|
||||
路径，一个字符串数组。默认值为 `["/"]`。当有多个值时，每次请求随机选择一个值。
|
||||
paths, an array of strings. The default value is `["/"]`. When there are multiple values, a value is chosen randomly for each request.
|
||||
|
||||
> `headers`: map{ string, \[ string \]}
|
||||
|
||||
HTTP 头，一个键值对，每个键表示一个 HTTP 头的名称，对应的值是一个数组。
|
||||
HTTP header, a key-value pair, each key represents the name of an HTTP header, and the corresponding value is an array.
|
||||
|
||||
每次请求会附上所有的键，并随机选择一个对应的值。默认值见上方示例。
|
||||
Each request will include all the keys and randomly select a corresponding value. Please refer to the **default values** shown in the example above.
|
||||
|
||||
#### HTTPResponseObject
|
||||
|
||||
@ -131,18 +131,18 @@ HTTP 头，一个键值对，每个键表示一个 HTTP 头的名称，对应的
|
||||
|
||||
> `version`: string
|
||||
|
||||
HTTP 版本，默认值为 `"1.1"`。
|
||||
HTTP version, default is `"1.1"`
|
||||
|
||||
> `status`: string
|
||||
|
||||
HTTP 状态，默认值为 `"200"`。
|
||||
HTTP status, default is `"200"`
|
||||
|
||||
> `reason`: string
|
||||
|
||||
HTTP 状态说明，默认值为 `"OK"`。
|
||||
HTTP status description, default value is `"OK"`
|
||||
|
||||
> `headers`: map {string, \[ string \]}
|
||||
|
||||
HTTP 头，一个键值对，每个键表示一个 HTTP 头的名称，对应的值是一个数组。
|
||||
HTTP header, a key-value pair, each key represents the name of an HTTP header, and the corresponding value is an array.
|
||||
|
||||
每次请求会附上所有的键，并随机选择一个对应的值。默认值见上方示例。
|
||||
Each request will include all the keys and randomly select a corresponding value. Please refer to the **default values** shown in the example above.
|
||||
|
||||
@ -1,16 +1,16 @@
|
||||
# WebSocket
|
||||
|
||||
使用标准的 WebSocket 来传输数据。
|
||||
Use standard WebSocket to transmit data.
|
||||
|
||||
WebSocket 连接可以被其它 HTTP 服务器（如 Nginx）分流，也可以被 VLESS fallbacks path 分流。
|
||||
WebSocket connections can be peoxied by other HTTP servers (such as Nginx) or by VLESS fallbacks path.
|
||||
|
||||
::: tip
|
||||
Websocket 会识别 HTTP 请求的 X-Forwarded-For 头来覆写流量的源地址，优先级高于 PROXY protocol。
|
||||
Websocket will recognize the X-Forwarded-For header of the HTTP request to override the source address of the traffic, with a higher priority than the PROXY protocol.
|
||||
:::
|
||||
|
||||
## WebSocketObject
|
||||
|
||||
`WebSocketObject` 对应传输配置的 `wsSettings` 项。
|
||||
`WebSocketObject` corresponds to the `wsSettings` item of the transport configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -24,30 +24,38 @@ Websocket 会识别 HTTP 请求的 X-Forwarded-For 头来覆写流量的源地
|
||||
|
||||
> `acceptProxyProtocol`: true | false
|
||||
|
||||
仅用于 inbound，指示是否接收 PROXY protocol。
|
||||
Only used for inbound, indicating whether to accept the PROXY protocol.
|
||||
|
||||
[PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) 专用于传递请求的真实来源 IP 和端口，**若你不了解它，请先忽略该项**。
|
||||
The [PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) is used to transmit the real source IP and port of the request. **If you are not familiar with it, please ignore this item.**
|
||||
|
||||
常见的反代软件（如 HAProxy、Nginx）都可以配置发送它，VLESS fallbacks xver 也可以发送它。
|
||||
Common reverse proxy software (such as HAProxy and Nginx) can be configured to send it, and VLESS fallbacks xver can also send it.
|
||||
|
||||
填写 `true` 时，最底层 TCP 连接建立后，请求方必须先发送 PROXY protocol v1 或 v2，否则连接会被关闭。
|
||||
When filled in as `true`, after the underlying TCP connection is established, the requesting party must first send PROXY protocol v1 or v2, otherwise the connection will be closed.
|
||||
|
||||
> `path` string
|
||||
|
||||
WebSocket 所使用的 HTTP 协议路径，默认值为 `"/"`。
|
||||
The HTTP protocol path used by WebSocket. Default is `"/"`
|
||||
|
||||
如果路径中包含 `ed` 参数，将会启用 `Early Data` 以降低延迟，其值为首包长度阈值。如果首包长度超过此值，就不会启用 `Early Data`。建议的值为 2048。
|
||||
If the path contains the `ed` parameter, `Early Data` will be enabled to reduce latency, and its value is the first packet length threshold. If the length of the first packet exceeds this value, `Early Data` will not be enabled. The recommended value is 2048.
|
||||
|
||||
An example usage of `ed` parameter:
|
||||
|
||||
```
|
||||
"path": "/aabbcc" //original path
|
||||
|
||||
"path": "/aabbcc?ed=2048" //added ed parameter
|
||||
```
|
||||
|
||||
::: warning
|
||||
`Early Data` 使用 `Sec-WebSocket-Protocol` 头承载数据。如果你遇到兼容性问题，可以尝试调低阈值。
|
||||
`Early Data` uses the `Sec-WebSocket-Protocol` header to carry data. If you encounter compatibility issues, try lowering the threshold.
|
||||
:::
|
||||
|
||||
> `headers`: map \{string: string\}
|
||||
|
||||
自定义 HTTP 头，一个键值对，每个键表示一个 HTTP 头的名称，对应的值是字符串。
|
||||
Custom HTTP headers, a key-value pair, where each key represents the name of an HTTP header, and the corresponding value is a string.
|
||||
|
||||
默认值为空。
|
||||
The default value is empty.
|
||||
|
||||
## Browser Dialer
|
||||
|
||||
使用浏览器处理 TLS，详见 [Browser Dialer](../features/browser_dialer.md)
|
||||
Use the browser to handle TLS, see [Browser Dialer](../features/browser_dialer.md)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user