Windows UWP Apps Can't Connect Through a Proxy: Remove Loopback Restrictions and Troubleshoot

What TUN mode changes on Windows

TUN mode allows Clash Verge Rev to capture a broader range of Windows network traffic than the ordinary system proxy. When the system proxy is enabled, applications that understand Windows proxy settings usually send web requests to a local HTTP, SOCKS, or mixed listener exposed by the mihomo core. Applications that ignore system proxy settings, use their own network stack, connect directly by IP address, or send traffic through protocols that do not honor HTTP proxy settings may bypass that listener.

TUN mode works at the virtual network interface layer instead. mihomo creates or uses a virtual adapter, commonly backed by the Wintun driver, and Windows sends selected IP traffic through that adapter. The core can then inspect the destination, apply DNS handling and routing rules, and forward the connection through a proxy node, directly, or to a reject policy. This makes TUN useful for games, command-line tools, launchers, desktop applications, and other programs that do not provide a proxy setting.

TUN mode does not automatically make every connection successful. It only changes how traffic enters the Clash core. The active profile still needs valid proxy nodes, proxy groups, rules, DNS settings, and a suitable operating mode. A node that fails in the Proxies page will also fail when selected for TUN traffic. Likewise, enabling TUN while the wrong profile is active can capture traffic but send it through an unavailable route.

• System proxy: Windows-aware applications connect to the local Clash listener through proxy settings.
• TUN mode: IP traffic is redirected through a virtual network interface so more applications can be handled.
• mihomo core: The core performs DNS processing, rule matching, proxy selection, connection forwarding, and logging.
• Service Mode: A privileged Windows service helps the client create and manage the virtual interface without requiring the main window to run with full administrator rights at every moment.

Prepare Clash Verge Rev and Windows before enabling TUN

Start with a clean baseline rather than turning on every networking option at once. Install a current Clash Verge Rev build that supports the Windows architecture you are using, then open the application and confirm that the mihomo core can start. On a 64-bit Windows installation, the x64 package is normally the appropriate choice; ARM64 devices need an ARM64 build when one is provided. Choosing an incompatible package can cause startup or core-launch failures that look like TUN problems later.

Next, import a working profile from a subscription URL or a local YAML file. Wait for the profile update to finish, activate that profile, and open the Proxies page. Select a usable member in the main proxy group instead of leaving a group in an unknown or unavailable state. If the group uses url-test or fallback, wait for its health checks to complete. Test a normal website with the ordinary system proxy first whenever possible. This confirms that the profile, node, DNS path, and basic mihomo forwarding are functional before the virtual adapter is introduced.

Close other VPN clients, traffic interception tools, and virtual network adapters temporarily if they are not needed. Multiple products may attempt to install drivers, change DNS, or set routing priorities. They can coexist in some configurations, but a first-time setup is easier to diagnose when only one traffic capture layer is active. Also note whether an enterprise security product, endpoint firewall, or device management policy restricts driver installation or Windows service creation.

Check the basic settings first

• Make sure the active configuration contains at least one working proxy node and a usable proxy group.
• Confirm that the mihomo core is running and that the configuration has no YAML parsing error.
• Record the current system proxy state so it can be restored if testing fails.
• Save important work before installing a network driver or changing adapter settings.
• Use an administrator account, or have administrator credentials available when Windows requests permission.
• Keep a direct-access test in mind, such as opening a known local or domestic website, so you can distinguish general network failure from proxy-route failure.

Install and verify Service Mode

On Windows, TUN mode commonly requires elevated operations because the client must create a virtual network interface, adjust routes, and sometimes manage DNS behavior. Clash Verge Rev generally exposes these operations through a Service Mode or service-installation entry in Settings. The exact label and location can vary between releases, but the purpose is the same: install a Windows service that can perform privileged network tasks for the client.

Open Settings and locate the service or system integration area. Choose the option to install, register, or start Service Mode. Windows may display a User Account Control prompt. Approve it only after confirming that the action belongs to Clash Verge Rev and that the application was obtained from a source you trust. A successful installation should change the service status from absent or stopped to installed and running, although the wording depends on the build.

1. Open Clash Verge Rev with the target profile already available.
2. Go to Settings and find the Service Mode section.
3. Select the installation or registration action and approve the Windows elevation prompt.
4. Wait for the status to report that the service is installed or running.
5. Restart Clash Verge Rev if the interface asks you to do so.
6. Return to the TUN settings and confirm that the required privileged component is available.

If the service cannot be installed, do not repeatedly toggle TUN. First check whether the client is already running under a restricted account, whether an older service from a previous installation remains, and whether security software blocked the operation. The Windows Services console can help confirm whether the relevant service exists and is running, but avoid changing unrelated services or startup settings. If a previous Clash-based client installed its own service, disable or remove that component only after confirming that it is no longer needed.

Service Mode is not the same as running the entire graphical client as administrator. The service handles privileged work, while the user interface can usually remain a normal desktop process. Running multiple copies of the client with different permission levels can create confusing state, so close duplicate instances before testing.

Turn on TUN mode and choose safe initial options

After Service Mode is ready, open the TUN section in Clash Verge Rev settings. Enable the TUN switch and apply the change. Some versions expose additional options such as auto-route, strict route, DNS hijacking, stack selection, or interface exclusion. Their names and defaults may differ, so do not copy a setting from another client without checking what the current mihomo version supports.

For a beginner’s first test, keep the configuration conservative. Auto-route is commonly needed so Windows traffic can use the virtual interface without manually adding routes. Strict route can help prevent traffic from escaping outside the intended path, but it can also make local network access, captive portals, printers, or other adapters behave differently. Enable stricter behavior only after ordinary TUN routing works and you understand which local networks must remain reachable.

DNS handling deserves special attention. If TUN captures application traffic but DNS requests still leave through the operating system resolver, domain rules may produce unexpected results or DNS leaks may occur. A profile may use mihomo’s DNS module with fake-ip or redir-host, and the appropriate mode depends on the applications and networks involved. Fake IP can preserve domain information for rule matching, while some games, local services, and applications that expect real addresses may require exclusions. Do not change the DNS mode and TUN routing mode at the same time unless you are prepared to isolate the effect of each change.

A minimal TUN-related configuration can look conceptually like this, although the exact supported fields depend on the mihomo release and the rest of the profile:

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: false

dns:
  enable: true
  enhanced-mode: fake-ip

This example is not a complete profile and does not provide a proxy node. If the graphical client manages these values for you, prefer its supported controls rather than manually adding duplicate YAML keys. Duplicate keys, incorrect indentation, or a profile generator that rewrites the file during updates can prevent the expected settings from taking effect.

After applying the settings, open Windows Network Connections or the adapter list and look for a new virtual adapter associated with the client. The adapter name can vary. It may appear briefly during startup or show a disconnected-looking state while the core is stopped, so judge it together with the Clash status and logs. If the adapter does not appear at all, the likely causes are Service Mode, driver installation, permission, or security software issues rather than a proxy-node failure.

Verify that Windows traffic is actually using TUN

Verification should be performed in stages. First confirm that TUN reports enabled in Clash Verge Rev. Then open the Connections page and generate traffic from an application that normally bypasses the system proxy, such as a command-line tool or a selected desktop application. A new connection should appear in the list with its destination, matched rule, and selected policy. The Logs page can provide additional information about DNS queries, route decisions, connection failures, and adapter startup.

1. Check the core: Confirm that the active profile is loaded and the mihomo core is running without configuration errors.
2. Check the adapter: Verify that a TUN-related virtual interface exists and is not disabled by Windows.
3. Check a direct route: Open a destination that should use DIRECT and confirm that the rule behaves as expected.
4. Check a proxy route: Open a destination assigned to the proxy group and watch for a new connection in the Clash interface.
5. Check the application: Test a program that does not use system proxy settings. If its request appears in Connections, TUN is capturing it.
6. Check the exit: Use a trusted IP or regional test service to confirm the expected egress location, but remember that IP display alone does not prove every application is routed identically.

When a connection appears in the log but fails, investigate the rule, DNS result, selected group, node availability, and upstream error. When no connection appears, investigate traffic capture, adapter status, application exclusions, firewall rules, and whether the application is using a special protocol or another VPN interface. The difference between “no log entry” and “log entry with an error” is one of the most useful clues in TUN troubleshooting.

System proxy and TUN can sometimes be enabled together, but that is not always necessary. System-proxy-aware applications may use the local proxy listener, while other traffic enters through TUN. If you see duplicate connections or unexpected bypass behavior, test with one method at a time. Also remember that established connections may keep their original route after a setting changes. Close and reopen the browser, terminal, game, or launcher before concluding that a new rule did not work.

Troubleshoot permission, adapter, and connectivity failures

If TUN cannot be enabled, begin with permission and service status. Confirm that Service Mode is installed and running, restart the client after installation, and approve any new UAC request. If Windows reports that a driver cannot be installed, check Windows Security, third-party endpoint protection, and device management policies. A blocked Wintun or virtual-adapter component can leave the TUN switch unavailable or cause it to turn off immediately.

If TUN turns on but all websites stop working, temporarily disable TUN and restore the ordinary system proxy test. If system proxy mode also fails, the underlying profile, DNS, node, or rule is probably the real problem. If system proxy works while TUN fails, focus on auto-route, DNS hijacking, virtual-adapter state, route conflicts, and exclusions. Rebooting Windows may clear a stale adapter or route, but record your current settings before making further changes.

• Switch turns off immediately: Inspect Service Mode status, core logs, driver errors, and permission prompts. Do not assume the subscription is invalid.
• No application traffic appears: Check whether the virtual adapter exists, whether TUN is enabled for the active profile, and whether another VPN has a higher-priority route.
• Connections appear but DNS fails: Review the DNS module, upstream resolver reachability, Fake IP filters, and whether the selected profile contains conflicting DNS fields.
• Websites work but games do not: Check UDP support, process behavior, rules for the game’s domains and IP ranges, and whether the game uses a separate launcher or anti-cheat network component.
• Local devices disappear: Test strict-route and local-network exclusions carefully. Printers, NAS devices, routers, and multicast discovery may need direct access or an exclusion.
• Traffic leaks outside the proxy: Check application exclusions, IPv6 behavior, DNS routing, other virtual adapters, and rules that explicitly select DIRECT.
• Only one application fails: Compare its process, protocol, DNS behavior, and firewall permissions with an application that works. A single-app failure does not necessarily indicate a broken TUN installation.

Return to a known-good state

When troubleshooting becomes unclear, disable TUN, stop Service Mode only if necessary, and test the active profile through the normal system proxy. Then change one setting at a time: first TUN, then DNS-related options, then strict routing or exclusions. Keep notes about each change and the exact log symptom. This controlled sequence is faster than replacing the profile, node, DNS servers, and Windows adapter configuration simultaneously.

Finally, update Clash Verge Rev and the mihomo core through trusted release channels when a known compatibility issue affects your Windows build. Before updating, preserve important local profiles and note custom TUN, DNS, and rule settings. A new version may change option names or defaults, so recheck the effective configuration after the update rather than assuming that the previous state was retained.

Use TUN mode safely in everyday Windows sessions

TUN mode is most useful when you need consistent routing across applications, but broad capture also increases the impact of a wrong rule or unavailable node. Keep a reliable DIRECT path for local services and essential Windows connectivity, and avoid sending every private network range through a remote proxy unless that is intentional. If a network requires a captive-portal login, temporarily disable TUN or use an appropriate exclusion so the sign-in page can load normally.

Review the active proxy group before starting bandwidth-sensitive work. Automatic groups can switch members when health checks change, and a newly selected node may have a different region, UDP capability, or access policy. For services that require a stable egress address, a manual or appropriately constrained group may be more predictable than unrestricted automatic selection.

When leaving a trusted network, changing VPN software, or moving between Wi-Fi and Ethernet, check the TUN adapter, DNS status, and the first few connection logs. If Windows resumes from sleep with no connectivity, toggling TUN off and on may refresh the adapter, but persistent failures should be investigated through service and core logs. Avoid deleting adapters or registry entries without a clear reason, because that can create additional driver and route problems.

Once the setup works, record the important values: the active profile, the main policy group, the TUN options, the DNS enhanced mode, and any local-network exclusions. This small record makes future updates and troubleshooting much easier. A successful setup is not merely a switch that says “enabled”; it is a verified path from the Windows application, through the virtual interface and mihomo rules, to the intended direct or proxied destination.