mirror of
https://github.com/XTLS/Xray-docs-next.git
synced 2026-09-28 09:58:06 +03:00
83 lines
4.3 KiB
Markdown
83 lines
4.3 KiB
Markdown
# TUN
|
|
|
|
Creates a TUN interface; traffic sent to this interface will be processed by Xray. Currently, Windows, Linux, macOS, and FreeBSD are supported.
|
|
|
|
On Android and iOS, the TUN FD must be passed in from an external app via the `XRAY_TUN_FD` environment variable, which redirects traffic through the interface designated by the system. It cannot run standalone and only serves as a way for an app to feed traffic into Xray.
|
|
|
|
On Linux, this environment variable can optionally be used to pass in the TUN FD for certain lightweight or unprivileged implementations.
|
|
|
|
## InboundConfigurationObject
|
|
|
|
`InboundConfigurationObject` corresponds to the `settings` item in [`InboundObject`](../inbound.md).
|
|
|
|
```json
|
|
{
|
|
"inbounds": [
|
|
{
|
|
// ...
|
|
"protocol": "tun",
|
|
// [!code focus:9]
|
|
"settings": {
|
|
"name": "xray0",
|
|
"mtu": 1500,
|
|
"gateway": ["10.0.0.1/16", "fc00::1/64"],
|
|
"dns": ["1.1.1.1", "8.8.8.8"],
|
|
"userLevel": 0,
|
|
"autoSystemRoutingTable": ["0.0.0.0/0", "::/0"],
|
|
"autoOutboundsInterface": "auto"
|
|
}
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
> `name`: string
|
|
|
|
The name of the created TUN interface. Default is `"xray0"`.
|
|
|
|
> `mtu`: number
|
|
|
|
The MTU of the interface. The default is `1500`.
|
|
|
|
> `gateway`: [string]
|
|
|
|
The list of address prefixes assigned to the TUN interface, usually one for IPv4 and one for IPv6, such as `"10.0.0.1/16"` and `"fc00::1/64"`.
|
|
|
|
> `dns`: [string]
|
|
|
|
The list of DNS servers assigned to the TUN interface, such as `"1.1.1.1"` and `"8.8.8.8"`.
|
|
|
|
> `userLevel`: number
|
|
|
|
User level. The connection will use the [local policy](../policy.md#levelpolicyobject) corresponding to this user level.
|
|
|
|
The value of `userLevel` corresponds to the `level` value in [policy](../policy.md#policyobject). If not specified, the default is 0.
|
|
|
|
> `autoSystemRoutingTable`: [string]
|
|
|
|
The list of destination prefixes that Xray should add to the system routing table automatically so that the traffic is directed into this TUN interface. Each item is a CIDR. For example, `"0.0.0.0/0"` means all IPv4 traffic, and `"::/0"` means all IPv6 traffic.
|
|
|
|
Currently only supported on Windows. On other systems, the routing table must be configured manually.
|
|
|
|
> `autoOutboundsInterface`: string
|
|
|
|
Automatically binds Xray outbounds to a physical network interface, so that traffic generated by Xray itself is not sent back into the TUN interface and looped.
|
|
|
|
Equivalent to automatically setting [sockopt](../transports/sockopt.md).interface for all outbounds (it also additionally covers some requests that cannot have outbound settings configured, such as the various local modes of the built-in DNS), which can be overridden by manually set sockopt.
|
|
|
|
The default value is `null`, which means not configured. You can specify an interface name explicitly, or use `"auto"` to let Xray choose one automatically. If `autoSystemRoutingTable` is configured but this field is omitted, Xray treats it as `"auto"`.
|
|
|
|
## Usage Tips
|
|
|
|
If `autoSystemRoutingTable` is not configured, you still need to add routes manually to direct traffic to the created TUN interface; otherwise, it remains just an interface.
|
|
|
|
When `gateway`, `dns`, `autoSystemRoutingTable`, and `autoOutboundsInterface` are configured, Xray can perform part of the system-side setup automatically on supported platforms. If your platform does not implement these automatic settings yet, or if you need more fine-grained policy routing, you still need to configure the OS manually.
|
|
|
|
If you only want to proxy specific process(es), the process name routing in the Xray routing system will be very useful.
|
|
|
|
::: warning
|
|
Be aware of potential traffic loop issues. After setting routes, requests initiated by Xray might be sent back to Xray, causing a loop!
|
|
Prefer `autoOutboundsInterface` to avoid this problem. If you need manual control, you can still use `interface` in `sockopt` to bind to the actual physical network interface. `ipconfig` (Windows) or `ip a` (Linux) will help you find the interface name you need.
|
|
Alternatively, use the outbound `sendThrough` setting. It is available directly in `OutboundObject` without the deep nesting level of `sockOpt.interface`. Here you need to use the IP address on the network card, such as 192.168.1.2 (As you can see, its disadvantage is that it cannot automatically support dual-stack; please choose according to the IP actually used for your outbound connection).
|
|
:::
|