Transports specify how to achieve stable data transmission. Both ends of a connection often need to specify the same transport protocol to successfully establish a connection. Like, if one end uses WebSocket, the other end must also use WebSocket, or else the connection cannot be established.
`StreamSettingsObject` corresponds to the `streamSettings` property in the inbound or outbound config. Each inbound or outbound can be configured with different transports and can use `streamSettings` to specify local configs.
Configures REALITY. REALITY is a piece of advanced encryption technology developed in-house, with higher security than vanilla TLS, but configs of both are largely the same.
REALITY is by far the most secure transport encryption solution, perfectly mimicking normal web browsing when observed. Enabling REALITY with appropriate XTLS Vision flow control schemes has the potential of reaching magnitudes of performance boosts.
When the target is specified by domains, like when the domain is received by SOCKS inbounds or detected via sniffing, the extracted domain will automatically be used as `serverName`, without any need for manual configuration.
You can find the names and descriptions of encryption suites in Go [here](https://golang.org/src/crypto/tls/cipher_suites.go#L500) or [here](https://golang.org/src/crypto/tls/cipher_suites.go#L44).
The above two configs are optional and do not have impact on security under normal circumstances. When not configured, Go will select the parameters automatically on a per-device basis. If you are not familiar with these configs, leave them as is, or you will bear consequences of potential problems caused by your improper configuration.
When `true`, Xray will only use the certificates specified in `certificates` for TLS handshakes. When `false`, Xray will only use the CA certificates provided by the operating system for TLS handshakes.
When `false`, the `session_ticket` extension will not be included in ClientHello. Oftentimes the ClientHello in Go programs does not have this extension enabled, so it is recommended to leave it as-is. Defaults to `false`.
Specifies the fingerprint of the `TLS Client Hello` message. When empty, fingerprint simulation will not be enabled. When enabled, Xray will **simulate** the `TLS` fingerprint through the uTLS library or have it generated randomly. Three types of options are supported:
1. Use uTLS native fingerprint variable names, such as `"HelloRandomizedNoALPN"``"HelloChrome_106_Shuffle"`. See the full list in the [uTLS library](https://github.com/refraction-networking/utls/blob/master/u_common.go#L162).
This feature only **simulates** the fingerprint of `TLS Client Hello` message, leaving other behaviours the same as vanilla Go TLS. If you want to simulate a browser `TLS` more completely, use the [Browser Dialer](./transports/websocket.md#browser-dialer).
When using this feature, some TLS options that affect the TLS fingerprint will be overridden by the utls library and will no longer be effective, such as ALPN.
Specifies the SHA256 hash values of the certificate chain of the remote server, using the standard encoding format. Only when the hash value of the server-side certificate chain matches any of the specified can a TLS connection be successfully established.
It is not recommended to use this method to obtain the hash value of the certificate chain, because in this case, there will be no opportunity to verify whether the certificate provided by the server at this time is a real certificate, and it cannot be guaranteed that the obtained certificate hash value is the expected hash value.
If you need to obtain the hash value of the certificate, run `xray tls certChainHash --cert <cert.pem>` in the command line, where `<cert.pem>` is replaced by the actual certificate file path.
If you want to achieve A/A+ rating in SSLLabs or MySSL tests, visit [here](https://github.com/XTLS/Xray-core/discussions/56#discussioncomment-215600) for further information.
Path to the (Pre-)Master-Secret log file. Can be used by sniffers like WireShark to decrypt TLS connections managed by Xray. Cannot be used with uTLS at the moment, and requires Xray-core v.8.7 or later.
When a new client request comes in, assuming the specified `serverName` is `"xray.com"`, Xray will first look for a certificate that can be used for `"xray.com"` in the certificate list. If not found, it will issue a certificate for `"xray.com"` using any certificate with `usage` set to `"issue"`, with a validity of one hour. The new certificate is then added to the certificate list for later use.
If you already have a domain name, you can use tools to obtain free third-party certificates easily, such as [acme.sh](https://github.com/acmesh-official/acme.sh).
Only valid when `usage` is `issue`. When set to `true`, the CA certificate will be appended to leaf certificate as chain during issuing certificates.
::: tip TIP 1
Root certificates should not be embedded in the certificate chain. This option is only applicable when the signing CA certificate is an intermediate certificate.
When its value is `true` or a positive integer, TFO is enabled; when its value is `false` or a negative integer, TFO is forced to be disabled; when this item does not exist or is `0`, the system default setting is used. It can be used for inbound/outbound connections.
- Linux 3.16: It needs to be set through the kernel parameter `net.ipv4.tcp_fastopen`, which is a bitmap. `0x1` represents the client allows enabling it, and `0x2` represents the server allows enabling it. The default value is `0x1`. If the server wants to enable TFO, set this kernel parameter value to `0x3`.
- FreeBSD 10.3 (Server) / 12.0 (Client): The kernel parameters `net.inet.tcp.fastopen.server_enabled` and `net.inet.tcp.fastopen.client_enabled` need to be set to `1`.
- For inbound, the `positive integer` set here represents the maximum number of TFO connection requests to be processed, **note that not all operating systems support this setting**:
- Linux/FreeBSD: The `positive integer` value set here represents the upper limit, and the maximum acceptable value is 2147483647. If it is set to `true`, it will take `256`. Note that in Linux, `net.core.somaxconn` will limit the upper limit of this value. If it exceeds `somaxconn`, please also increase `somaxconn`.
- Mac OS: When it is `true` or a `positive integer`, it only represents enabling TFO, and the upper limit needs to be set separately through the kernel parameter `net.inet.tcp.fastopen_backlog`.
- Windows: When it is `true` or a `positive integer`, it only represents enabling TFO.
- For outbound, setting it to `true` or a `positive integer` only represents enabling TFO on any operating system.
When `followRedirect` is set to `true` in [Dokodemo-door](./inbounds/dokodemo.md), and `tproxy` in the Sockopt settings is empty, the value of `tproxy` in the Sockopt settings will be set to `"redirect"`.
In previous versions, when Xray attempted to establish a system connection using a domain name, the resolution of the domain name was completed by the system and not controlled by Xray. This led to issues such as the inability to resolve domain names in non-standard Linux environments. To solve this problem, Xray 1.3.1 introduced Freedom's `domainStrategy` into Sockopt.
1. Trigger condition: proxy server (proxy.com). Built-in DNS server, non-local mode.
2. Before Xray attempts to establish a TCP connection to proxy.com, it queries proxy.com using the built-in DNS server.
3. The built-in DNS server establishes a connection to dns.com and sends a query to obtain the IP address of proxy.com.
4. Improper routing rules cause proxy.com to proxy the query sent in step 3.
5. Xray attempts to establish another TCP connection to proxy.com.
6. Before establishing the connection, Xray queries proxy.com using the built-in DNS server.
7. The built-in DNS server reuses the connection established in step 3 to send a query.
8. A problem arises. The establishment of the connection in step 3 requires waiting for the query result in step 7, and the completion of the query in step 7 requires waiting for the connection in step 3 to be fully established.
An identifier for an outbound proxy. When the value is not empty, the specified outbound will be used to establish the connection. This option can be used to support chain forwarding of underlying transport protocols.
[PROXY protocol](https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt) is used to pass the true source IP and port of a request. **If you are not familiar with it, please ignore this option first**.
When set to `true`, after the lowest-level TCP connection is established, the requesting party must first send PROXY protocol v1 or v2, otherwise the connection will be closed.
Default value `false`, fill in `true` to enable [Multipath TCP](https://en.wikipedia.org/wiki/Multipath_TCP), need to be enabled in both server and client configuration.
> `tcpNoDelay`: true | false
Default value `false`, recommended to be enabled with "tcpMptcp": true.
An array for advanced users to specify any sockopt. In theory, all the above connection-related settings can be set equivalently here. Naturally, other options that exist in Linux but have not been added to the core can also be set. The example below is equivalent to `"tcpcongestion": "bbr"` in core.
Please make sure you understand Linux socket programming before using it.
The option name of the operation, using decimal (the example here is that the value of `TCP_CONGESTION` is defined as `0xd` and converted to decimal is 13)
