feat(tun): user-configurable MTU and outbound interface#27
Conversation
Replace the runtime "detect default outbound interface" probe with explicit user configuration via a new confirmation dialog when enabling TUN mode. Auto mode (the default) lets xray pick the interface itself -- same behavior as before, just without the manual probe. - AppSettings: persist TunMtu (default 1500) and TunOutboundInterface (default "auto"). - XrayConfigConstants: shared TunInterfaceName, MTU bounds, and NormalizeTunMtu so TunService and XrayConfigBuilder agree on the adapter name and value validation. - XrayConfigBuilder: drop tunOutboundInterfaceName parameter; read MTU and interface from settings. "auto" skips sockopt.interface entirely. - TunService: remove DetectDefaultOutboundInterfaceName + helpers. Add ResetTunDnsServers (netsh, single elevated batch) to clear stale DNS on the xray-tun adapter; route-cleanup path bundles the reset into its existing elevated batch so the user still sees one UAC. - TunConfirmationDialog: collapsed "更多选项" panel exposes MTU (NumberBox 68-9000) and an Interface ComboBox seeded with active adapters; a persisted-but-missing interface is surfaced so the user can see what's saved. - ControlPanelViewModel: TUN toggle shows the new dialog and persists the chosen values before relaunching elevated. Also pin Microsoft.WindowsAppSDK.AI / Microsoft.Windows.AI.MachineLearning to 2.0.* (was "*") to avoid an unintended jump to a future major. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9cecf8a807
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| .Where(ni => ni.OperationalStatus == OperationalStatus.Up | ||
| && ni.NetworkInterfaceType != NetworkInterfaceType.Loopback) | ||
| .Select(ni => ni.Name) |
There was a problem hiding this comment.
The advanced interface picker currently includes every OperationalStatus.Up adapter except loopback, which can surface tunnel/virtual NICs (including Xray/Wintun adapters) as selectable outbound targets. If a user picks one of these, TunOutboundInterface is written into sockopt.interface and Xray can bind its own outbound traffic to a non-physical interface, leading to routing loops or broken connectivity in TUN mode. The previous implementation explicitly filtered these adapter types/names, so this is a regression in the new manual-selection flow.
Useful? React with 👍 / 👎.
1 participant
Summary
ResetTunDnsServersso stale DNS entries on the xray-tun adapter get cleared between runs.Why
The previous probe (UDP-to-8.8.8.8 + NIC matching) could fail in multi-NIC / VPN setups and blocked TUN startup. xray-core's
autoOutboundsInterface="auto"already handles the common case — this PR exposes it to the user instead of doing our own detection. As a side benefit, users on unusual network topologies can now override the interface manually.Test plan
xray_config.jsonand persisted across restart.sockopt.interfacefor the proxy/direct/chain outbounds.netsh interface ipv4 show dnsservers).