1. Browser works, Store app doesn't: check for a loopback restriction first

On Windows 10 or Windows 11, the Clash Meta client may have system proxy enabled and your browser can reach the site, while a particular app still reports that there's no network connection. One possible cause is AppContainer network isolation: by default, isolated apps can't connect to services on the local loopback address in the same way as regular desktop programs.

A common proxy address is 127.0.0.1:7890. Here, 127.0.0.1 points to your current PC, and 7890 is an example port—not a fixed value for every client. If an app reads the system proxy settings but can't connect to that local listening port, its request may fail before it reaches the mihomo core.

Check these three things first

  • Does a regular browser work? Try the same destination to confirm that your proxy node, subscription, and basic network connection are working.
  • Is the proxy listening on the right port? Check the HTTP or mixed port in the client settings or active configuration. Don't mistake the external controller port for the proxy port.
  • Are the app's requests reaching the core? Open the client's connections list or logs, then trigger another request from the app. If nothing appears, check how traffic is being captured; that alone doesn't prove a loopback restriction is the cause.

A loopback exemption only grants an app permission to access services on the local machine. It won't fix an expired subscription, a dead proxy node, or a remote server outage, and it won't make a program that ignores the system proxy suddenly use an HTTP proxy.

2. Check the system proxy and mihomo listening port

Go to Windows Settings → Network & internet → Proxy → Manual proxy setup. On Windows 11, you may need to click Edit next to Use a proxy server. Check that the address and port match your current client. With mihomo running locally, a common setup is address 127.0.0.1 and port 7890.

In a Clash Meta configuration, mixed-port accepts both HTTP and SOCKS proxy connections. The snippet below only covers listening settings. Merge it into your existing configuration; don't replace the entire subscription file:

config.yaml · Local listener snippet
mixed-port: 7890
allow-lan: false
mode: rule

The client may generate the final configuration through overrides. Check the values actually in use; editing a YAML file that isn't loaded won't help. You don't need to enable LAN access for a UWP app to use a local proxy, and changing the listen address to all interfaces isn't a safe troubleshooting shortcut.

Check the local port with PowerShell

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://www.microsoft.com/

The first command checks whether a TCP port is listening; the second makes a regular desktop process use the proxy explicitly. Replace the port with your actual value. An HTTP response confirms that the proxy path responded this time, but doesn't prove that an isolated app can access loopback. If the connection is refused, first check whether the core is running and whether another process is using the port. If it times out, check the proxy node, rules, and destination site.

Don't use the output of netsh winhttp show proxy as a substitute for checking the Windows Settings page. WinHTTP proxy settings and the user-level system proxy are separate, and apps may use different networking APIs.

3. Grant a loopback exemption to a specific app with CheckNetIsolation

CheckNetIsolation.exe is a Windows network isolation diagnostic tool. To add or remove a loopback exemption, open Windows Terminal or PowerShell as an administrator. Only change settings for apps that need it: save the current list first, then add one package at a time.

Step 1: Check existing exemptions and find the package name

CheckNetIsolation.exe LoopbackExempt -s

Get-AppxPackage |
  Sort-Object Name |
  Select-Object Name, PackageFamilyName

The second command lists app packages for the current user by default. Find the target app and use its PackageFamilyName, not its display name, install folder, or versioned PackageFullName. If the list is long, filter by a known part of the name. The example below uses the Microsoft Store package; that doesn't mean every network issue requires an exemption for the Store itself.

Get-AppxPackage -Name Microsoft.WindowsStore |
  Select-Object Name, PackageFamilyName

If you're using an administrator terminal under a different account, its package list may not match the account you normally use. Check the package identity in the target user's session first. Don't grant access to every installed app just because you can't find the package.

Step 2: Add an exemption for one package

The PowerShell command below looks up the Microsoft Store package installed for the current user, then passes its actual package family name to the Windows tool. For another app, confirm its exact Name in the list above before changing the query.

$app = Get-AppxPackage -Name Microsoft.WindowsStore

if ($null -eq $app) {
  throw "Microsoft.WindowsStore package not found for the current user. Check the user account and package name."
}

CheckNetIsolation.exe LoopbackExempt -a "-n=$($app.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

Confirm that the output includes the target package, then fully exit and reopen the app. Closing the window may leave background processes running. You can check Task Manager to confirm the app has exited, but don't end critical system processes. Trigger the request again and watch the Clash Meta connections list.

Step 3: Test the result and keep a way to undo it

If the app reconnects and the matching connection appears in the mihomo logs, this traffic path is working. If it still fails, don't keep adding the same exemption. Check whether the app reads the system proxy, whether a separate background component is involved, and whether the proxy rules send the destination domain to the expected policy group.

$app = Get-AppxPackage -Name Microsoft.WindowsStore

if ($null -ne $app) {
  CheckNetIsolation.exe LoopbackExempt -d "-n=$($app.PackageFamilyName)"
}

CheckNetIsolation.exe LoopbackExempt -s

The command above removes this package's exemption. A loopback exemption lets the app access local services—not just the Clash port. Remove the entry if it doesn't help or you no longer need it. Don't clear the entire exemption list instead of removing a single entry; that could disrupt settings used by other tools.

4. Use a GUI tool to grant an AppContainer loopback exemption

If Fiddler Classic is already installed, its WinConfig entry opens the AppContainer Loopback Exemption Utility. This is a Fiddler Classic tool, not a Fiddler Everywhere feature. Button locations may vary between releases.

  1. Open Fiddler Classic, click WinConfig in the toolbar, and grant administrator access when prompted.
  2. Find the target app in the AppContainer list and verify its package identity. Don't rely on a similar-looking display name alone.
  3. Select the target entry, click Save Changes, then fully exit and restart the app.
  4. Return to an administrator terminal and run CheckNetIsolation.exe LoopbackExempt -s to verify the final exemption list.

The GUI tool and the command-line method change the same kind of system exemption. You don't need to use both, and granting access to every app isn't a good shortcut. Untrusted one-click fix scripts may also change firewall, DNS, or proxy settings. When troubleshooting, avoid changing multiple things at once.

5. Loopback exemptions vs. TUN mode: choose based on the traffic path

The system proxy relies on apps choosing to use the proxy API. A loopback exemption lets an isolated app connect to a local proxy port. TUN mode captures traffic through a virtual network interface and routing, so the app usually doesn't need to connect to 127.0.0.1:7890 first. If a program ignores the system proxy, TUN is worth testing—but it isn't a more powerful loopback exemption.

OptionBest forKey limitation
System proxyApps that support and use the user's proxy settingsDoesn't guarantee traffic capture for every app or UDP flow
System proxy + loopback exemptionIsolated apps that need to connect to a local proxyGrants access only; it doesn't force an app to use the proxy
mihomo TUNApps that ignore the system proxy, or traffic that needs IP-level captureRequires the right permissions, routes, and DNS setup; may conflict with other VPNs

TUN configuration and prerequisites

First, enable TUN from your Windows client's TUN settings and follow its prompts to install a service or grant administrator access. Menu names vary between clients. If configuring it manually, the snippet below is a mihomo TUN configuration. Keep your existing proxy nodes, policy groups, rules, and DNS settings.

config.yaml · TUN snippet
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

Use dns-hijack with mihomo's DNS module enabled and working. It isn't a complete DNS configuration and can't intercept all encrypted DNS traffic. auto-route configures routes for traffic capture, while auto-detect-interface identifies the outbound interface. With multiple network adapters, a corporate VPN, or virtual machine networking, automatic selection may not behave as expected; check it separately.

To compare results, you can first turn off the system proxy and test with TUN enabled on its own, so requests don't keep using the old local proxy path. Note the original setting before testing, then restore your preferred setup afterward. Don't run TUN or VPN traffic capture in multiple proxy apps at once, and don't disable the entire firewall to test connectivity.

6. Still not working after the exemption? Troubleshoot using connection logs

No app connection appears in the core

First, make sure you fully restarted the app and granted an exemption to the package that's actually making the network request. Some apps handle sign-in, media, or updates in separate processes; exempting the main app may not cover those components. If the app doesn't use the system proxy at all, test TUN instead of trying different loopback addresses.

The connection reaches the core but matches DIRECT or the wrong proxy group

Check that mode: rule is active and inspect which rule matched the connection. Clash Meta evaluates rules in order, so an earlier rule can take precedence over a later one. Don't switch to global mode permanently just to get one app online. Confirm the destination domain and policy first, then adjust the necessary rules in your subscription overrides to avoid losing local changes on the next subscription update.

Only sign-in, downloads, or video features fail

These features may use different domains, processes, or transport protocols. Traffic handled by the HTTP system proxy follows a different path from UDP sent directly by the app. Note the time of the failure, destination address, and core logs, then check DNS, node capabilities, and routing rules separately. A loopback exemption doesn't change which protocols the upstream proxy node supports.

Change one setting at a time

  1. Record the current proxy port, system proxy setting, TUN setting, and exemption list.
  2. First, confirm that a regular desktop app can reach the destination through the local proxy.
  3. Add an exemption for the target package, restart the app, and check the connection logs.
  4. If that doesn't help, remove any unnecessary exemption and test the TUN path separately.
  5. If the issue persists, keep the error message and matched rule. Before sharing logs, remove subscription URLs, access tokens, and personal information.

To confirm the fix, check that the app works again, its traffic reaches the expected core, and the rules send it through the expected exit. “Exemption added successfully” only means Windows accepted the setting; it doesn't prove the entire proxy path is working.