gRPC
An modified transport protocol based on gRPC.
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.
Danger
It is recommended to switch to XHTTP, whose advantages over gRPC are noted in the STREAM-UP/ONE section.
⚠⚠⚠
- 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
If you are using a reverse proxy such as Caddy or Nginx, please note the following:
- 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:
- 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
corresponds to the grpcSettings
item.
{
"serviceName": "name",
"multiMode": false,
"idle_timeout": 60,
"health_check_timeout": 20,
"permit_without_stream": false,
"initial_windows_size": 0
}
serviceName
: string
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 BETA
true
enables multiMode
, with a default value of false
.
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
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
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
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
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
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
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.