patternihaandClaude Opus 5.5 2db099b34b TUN inbound: Block DNS and IPv6 leaks outside the TUN on Windows; Add strictRoute
Windows sends name queries to the DNS servers of all interfaces, and a
resolver on the local network (e.g. 192.168.1.1 from DHCP) is reached
through its more specific LAN route instead of the TUN, so DNS leaks
past it. IPv6 bypasses a TUN that cannot carry it.

With autoSystemRoutingTable set, the Windows TUN now adds Windows
Filtering Platform filters, all in one transaction and in a dynamic
session, so that they are removed when Xray exits, even if it crashes:
- DNS (port 53) only goes through the TUN, in both directions: its local
  address, and the interface it leaves or arrives by, must be the TUN's.
- IPv6 is blocked in both directions when the TUN has no IPv6 address or
  no IPv6 route, except loopback, neighbor and multicast listener
  discovery, and DHCPv6.
- Xray's own traffic is exempt: its connections out with a hard permit,
  which Windows Firewall rules do not override (like sing-box's
  strict_route), connections to its inbounds with an ordinary one.
If the filters cannot be added, the TUN does not start on Windows 10 and
later (only a warning on 7/8). The new `strictRoute` option (true by
default) turns them off.

Also on Windows:
- A warning for `dns` servers outside gateway and autoSystemRoutingTable,
  as queries to them cannot go through the TUN and are blocked.
- While DNS is restricted and autoOutboundsInterface is in use, Xray
  resolves the names it would ask Windows for itself (Go's resolver on
  its own sockets). Those lookups and the `localhost` DNS server skip the
  TUN's DNS servers, unless another interface uses them too, instead of
  looping back into the TUN.
- The DNS cache is flushed when the TUN starts and stops, and DNS
  registration is turned off on the TUN (through netsh before Windows 10
  1809).
- Close no longer panics when registering the route or interface change
  callbacks failed.
The README's Windows section describes all of it.

Tested on Windows 11, elevated, amd64 and 386: the filters, DNS arriving
through a real Wintun adapter and blocked outside it, the IPv6 block,
Windows Firewall rules, and a real Xray run. Windows 7/8 and Windows 10
before 1809 are untested.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 08:15:40 +03:30
2025-08-19 13:58:06 +00:00
2020-11-25 19:01:53 +08:00
2026-01-18 05:11:51 +00:00

Project X

Project X originates from XTLS protocol, providing a set of network tools such as Xray-core and REALITY.

README is open, so feel free to submit your project here.

Sponsors

Remnawave

Happ

BlancVPN

Sponsor Xray-core

Donation & NFTs

Collect a Project X NFT to support the development of Project X!

Project X NFT

License

Mozilla Public License Version 2.0

Documentation

Project X Official Website

Telegram

Project X

Project X Channel

Project VLESS (Русский)

Project XHTTP (Persian)

Installation

Usage

GUI Clients

Others that support VLESS, XTLS, REALITY, XUDP, PLUX...

Contributing

Code of Conduct

Ask DeepWiki

Credits

Bundled Third-Party Components Redistribution

Certain optional features dynamically load third-party components. These optional components are separate works distributed under their own licenses, and are bundled into the ZIP package for ease of use. Users may replace these components under the licenses from these components.

These components include:

Wintun

This distribution contains unmodified official precompiled and pre-signed Wintun binaries.

  • Project: Wintun
  • Copyright: Copyright (C) 2018-2021 WireGuard LLC. All Rights Reserved.
  • Redistribution License: Prebuilt Binaries License (PBL) bundled with official precompiled and pre-signed binaries from wintun.net
  • Component(s): wintun.dll
  • Source: https://www.wintun.net/
  • Included in:
    • Windows x86 (windows-32, win7-32)
    • Windows x86-64 (windows-64, win7-64)
    • Windows AArch64 (windows-arm64)
  • Notes: Wintun is an optional runtime-loaded component only used for TUN inbound functionality on supported Windows platforms.

One-line Compilation

Windows (PowerShell)

$env:CGO_ENABLED=0
go build -o xray.exe -trimpath -buildvcs=false -ldflags="-s -w -buildid=" -v ./main

Linux / macOS

CGO_ENABLED=0 go build -o xray -trimpath -buildvcs=false -ldflags="-s -w -buildid=" -v ./main

Reproducible Releases

Make sure that you are using the same Go version, and remember to set the git commit id (7 bytes):

CGO_ENABLED=0 go build -o xray -trimpath -buildvcs=false -gcflags="all=-l=4" -ldflags="-X github.com/xtls/xray-core/core.build=REPLACE -s -w -buildid=" -v ./main

For Android:

GOOS=android GOARCH=arm64 CGO_ENABLED=1 CC=/path/to/aarch64-linux-android24-clang go build -o xray -trimpath -buildvcs=false -gcflags="all=-l=4" -ldflags="-X github.com/xtls/xray-core/core.build=REPLACE -s -w -buildid= -checklinkname=0" -v ./main
GOOS=android GOARCH=amd64 CGO_ENABLED=1 CC=/path/to/x86_64-linux-android24-clang go build -o xray -trimpath -buildvcs=false -gcflags="all=-l=4" -ldflags="-X github.com/xtls/xray-core/core.build=REPLACE -s -w -buildid= -checklinkname=0" -v ./main

If you are compiling a 32-bit MIPS/MIPSLE target, use this command instead:

CGO_ENABLED=0 go build -o xray -trimpath -buildvcs=false -gcflags="-l=4" -ldflags="-X github.com/xtls/xray-core/core.build=REPLACE -s -w -buildid=" -v ./main

Stargazers over time

Stargazers over time

Languages
Go 99.7%
HTML 0.1%