hesoyam/Xray-core
1
0
Fork 0
mirror of https://github.com/XTLS/Xray-core.git synced 2026-10-16 20:44:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

TUN inbound: Handle weak host send and forwarding on the outbound interface on Windows

Browse Source 
Windows ignores the binding of autoOutboundsInterface (IP_UNICAST_IF) when
the outbound interface has weak host send or forwarding on for an IP version
routed to the TUN: Xray's own connections then go into the TUN, from that
interface's address, and stall.

While the TUN runs, weak host send is turned off on that interface for those
IP versions, and turned on again when it stops or another interface takes
over. Forwarding, which Mobile Hotspot and Internet Connection Sharing need,
cannot be turned off without breaking them, so it is reported instead: the
TUN does not start while it is on, and an error is logged when it comes on
later.

Fixes https://github.com/XTLS/Xray-core/issues/6776
Reports the cause of https://github.com/XTLS/Xray-core/issues/6872

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
patterniha
2026-10-05 15:14:52 +03:30
co-authored by Claude Opus 5.5
parent 7da5dae650
commit 6b0f06fb2b
3 changed files with 145 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
proxy/tun/README.md
+2
View File
@@ -213,6 +213,8 @@ If the filters cannot be added, Xray does not start. They are removed when Xray
`autoSystemWfpBlockLeak` (Windows only) is empty by default, as the filters break some setups: with `"dns"`, a local DNS resolver other programs use (e.g. on `127.0.0.1:53`), the DNS of another VPN on its own interface, virtual machines whose NAT resolves names on the host, or signing in to a captive portal; with `"misconfigtun"`, IPv4 or IPv6 on the local network while no route of that version leads to the TUN. Without the filters, DNS may leak as described above. To keep an IP version out of the TUN on purpose while still blocking DNS leaks, use only `["dns"]`.
`autoOutboundsInterface` (the default with `autoSystemRoutingTable`) keeps Xray's own connections out of the TUN by binding them to another interface, which Windows only honors while that interface has weak host send and forwarding off for the IP versions routed to the TUN. Otherwise, Windows sends them into the TUN, from that interface's address, and they stall. While the TUN runs, Xray therefore turns weak host send off on that interface, and on again when it stops or another interface takes over. Forwarding cannot be turned off this way, as Mobile Hotspot and Internet Connection Sharing need it: the TUN does not start while it is on, and an error is logged when it comes on later.
You can give the adapter ip address manually, you can live Windows to give it autogenerated ip address (which take few seconds), it doesn't matter, the traffic going _through_ the interface will be forwarded into the app for proxying. \
Minimal configuration that will work for local machine is routing passing the traffic on-link through the interface.
You will need the interface id for that, unfortunately it is going to change with every Xray start due to implementation ambiguity between Xray and wintun driver.