Repository navigation
[Bug]: #267
Description
Existing issues
- I searched open and closed issues and did not find an existing report of this problem.
OneXray version
v26.10.1-v26.11.2
Xray-core version
No response
Platform
Windows
OS version and device
Windows 10, 22H2 (19045.6456)
Installation source and package
GitHub release (EXE)
Routing mode
Smart Routing
Steps to reproduce
Subject: Windows native TUN: autoSystemWfpBlockLeak: ["dns"] breaks all DNS resolution and HTTPS connectivity
Environment
- OneXray: 26.11.2
- Xray-core: 26.10.31
- OS: Windows 10
- Installation: EXE build from GitHub
- TUN mode: native Windows TUN / Wintun
- Outbound protocol: VLESS + REALITY over gRPC
- Selected physical outbound interface: Ethernet
- IPv6: disabled
- Server endpoint used in the final test: domain name, not a hardcoded IP address
Symptoms
OneXray appears connected, the Core process remains running, and OneXrayTun is present, but websites do not open.
During the failing session:
- System DNS queries time out for both ordinary domains and the VPN server domain.
- Direct DNS queries to several independent resolvers all time out:
8.8.8.81.1.1.1
curlfails during DNS resolution:curl: (28) Resolving timed out- HTTPS by IP address also fails during the TLS handshake:
curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed Test-NetConnection 1.1.1.1 -Port 443returnsTcpTestSucceeded: True, but this only confirms that a TCP connection can be established, not that the full tunnel and HTTPS path works.
Earlier sessions also repeatedly contained:
proxy/vless/outbound: failed to find an available destination
transport/internet/grpc: Cannot dial gRPC
dial tcp: lookup <server-domain>: i/o timeout
Temporarily replacing the server domain with its IP address made the connection work, which showed that the server, VLESS, REALITY and gRPC configuration were functional. However, the later failure affected general DNS resolution as well, so this was not a complete fix.
Configuration generated with the default WFP setting
The generated tunIn inbound contains:
{
"tag": "tunIn",
"settings": {
"name": "OneXrayTun",
"mtu": 1500,
"gateway": [
"198.18.0.1/15"
],
"dns": [
"8.8.8.8"
],
"autoSystemRoutingTable": [
"0.0.0.0/0"
],
"autoOutboundsInterface": "Ethernet",
"autoSystemWfpBlockLeak": [
"dns"
]
}
}Controlled A/B test and workaround
I imported a personal Raw copy of the generated runtime configuration and changed only this setting inside tunIn.settings:
"autoSystemWfpBlockLeak": []I verified that the newly generated runtime configuration actually contained the empty array, so the test was performed with the intended configuration.
Immediately after that single change:
- DNS resolution started working.
- HTTPS started working.
- Websites opened normally.
Verification results:
Resolve-DnsName www.google.com -Type A -DnsOnlyreturned multiple valid IPv4 addresses, and:
curl.exe -I --connect-timeout 5 --max-time 10 https://www.google.comreturned:
HTTP/1.1 200 OK
Conclusion
On this system, enabling:
"autoSystemWfpBlockLeak": ["dns"]correlates directly with complete DNS failure and broken HTTPS connectivity, while changing only this option to [] immediately restores normal operation.
This looks like a regression or interoperability bug in the Windows native TUN / WFP DNS leak-blocking path of OneXray 26.11.2 with Xray-core 26.10.31, rather than a problem with the VPN server or REALITY configuration.
Could you please investigate how the WFP DNS filters interact with Xray’s own DNS traffic, DNS routed through the tunnel, and Windows DNS Client traffic?
In particular, it would be useful to verify that the intended exemption for Xray’s own outbound connections is actually applied to the OneXrayCore.exe process in the EXE/native-TUN deployment, and that the DNS filter does not interfere with the system DNS path before the tunnel is fully operational.
At the moment, the only reliable workaround on this machine is a personal Raw configuration containing:
"autoSystemWfpBlockLeak": []This workaround disables the additional DNS leak-blocking protection and does not automatically follow future subscription updates, so a proper fix or an exposed UI option would be preferable.
Expected behavior
.
Actual behavior
.
Relevant logs
Screenshots, configuration, and additional context
No response
Activity
yiguodev commentedon Nov 8, 2026
Thanks for the detailed report and the controlled A/B test. Please use the Microsoft Store version for now. We will investigate the Windows native TUN/WFP issue and work on a fix as soon as possible.
yiguodev commentedon Nov 8, 2026
Thanks again for the detailed report. We found overlapping process DNS resolver setup between the desktop Core wrapper and Xray's native Windows TUN path.
The change in #269 (currently pending merge) selects resolver behavior by backend:
-set-dns=false, leaving resolver handling to Xray.-set-dns=true.This retains the default WFP DNS leak protection. The Windows x64 build and targeted CLI/App tests pass. We have not reproduced the complete failure on the reported Windows 10 system, so end-to-end confirmation is still needed.
Closing with the fix tracked in #269. Please continue using the Microsoft Store build for now, and let us know if the issue persists after a release containing this change.
jkttim commentedon Nov 9, 2026
The issue is still reproducible on 26.11.3, so #269 did not fully resolve it.
The behavior is intermittent: one run succeeded with working DNS and HTTP/1.1 200 OK, but subsequent runs fail again without any configuration changes.
I have now captured the complete state during a failed run:
OneXrayCore.exe is running.
The actual process command line contains -set-dns=false, so the fix from #269 is active:
Text
OneXrayCore.exe run -set-dns=false -dns 8.8.8.8:53 -interface Ethernet ...
OneXrayTun exists and its status is Up.
Get-DnsClientServerAddress confirms that 8.8.8.8 is assigned to OneXrayTun.
The generated tunIn.settings contains the default:
JSON
"autoSystemWfpBlockLeak": ["dns"]
Despite this, Resolve-DnsName www.google.com -Type A -DnsOnly times out.
Direct nslookup queries to both 8.8.8.8 and 1.1.1.1 also time out.
curl fails with Resolving timed out.
Therefore, this is not caused by a missing TUN adapter, missing TUN DNS assignment, an outdated Core command line, or the server domain. The failure still occurs with -set-dns=false and the default WFP DNS leak protection enabled.
The controlled Raw workaround with only this change still works:
JSON
"autoSystemWfpBlockLeak": []
Could you please reopen the issue and investigate the remaining intermittent Windows native TUN/WFP DNS path? Since the failure does not occur on every launch, a single successful startup test is not sufficient to confirm the fix.
jkttim commentedon Nov 9, 2026
I compared the Microsoft Store and EXE builds on the same Windows 10 computer, using the same server and subscription.
Microsoft Store 26.11.3 — working:
Core command line contains -set-dns=true.
The generated tunIn inbound is actually:
Text
Protocol: socks
Port: 23170
TunName: empty
WfpDns: empty
Windows DNS resolution succeeds.
HTTPS returns HTTP/1.1 200 OK.
EXE 26.11.3 — intermittently failing:
Core command line contains -set-dns=false, confirming that #269 is active.
The generated inbound is native tun.
OneXrayTun is present and has DNS 8.8.8.8 assigned.
The generated configuration contains:
JSON
"autoSystemWfpBlockLeak": ["dns"]
Windows DNS and direct DNS queries time out during failed runs.
Changing only this option to [] in a Raw copy restores connectivity.
Therefore, the reliable Store build does not exercise the failing native Wintun/WFP DNS path. The remaining EXE failure appears specific to that backend rather than to the shared DNS or server configuration.
jkttim commentedon Nov 9, 2026
EXE 26.11.3 generated inbound:
Tag : tunIn
Protocol : tun
TunName : OneXrayTun
WfpDns : dns
jkttim commentedon Nov 9, 2026
The Store build uses a SOCKS inbound and works reliably. The EXE build uses the native TUN inbound with WFP DNS blocking and fails intermittently, even with -set-dns=false. This confirms that the remaining issue is specific to the EXE native TUN/WFP path.