Microsoft Store and Clash Verge on Windows: Fix AppContainer Loopback Access

Microsoft Store failed to initialize while browsers and other desktop applications continued to work. The obvious reactions—reinstalling Store, resetting the whole network stack, or replacing Clash—would all have been too destructive.

Nothing was broken in the Store package, the relevant Windows services, or the Clash core. The failure was on the first edge of the data path: Microsoft Store runs inside an AppContainer and lacked permission to reach the Clash proxy through the local loopback interface.

The minimal fix was to grant a loopback exemption to Microsoft Store. Clash Verge kept both TUN mode and the Windows system proxy enabled.

TL;DR

• Symptom: Microsoft Store failed to initialize when Clash Verge used both TUN mode and the Windows system proxy.
• Proxy state: The system proxy was 127.0.0.1:7897, and verge-mihomo was listening on that port.
• Eliminated causes: The Store package and its related Windows services were healthy.
• Root cause: Microsoft Store was missing from the AppContainer loopback exemption list and could not reach the local Clash proxy.
• Fix: Run this command as Administrator:

powershellCopy
CheckNetIsolation.exe LoopbackExempt -a -n=Microsoft.WindowsStore_8wekyb3d8bbwe

Incident context

The failure occurred with both Clash Verge entry points enabled:

• TUN mode: enabled
• Windows system proxy: enabled
• System proxy address: 127.0.0.1:7897
• Clash core: verge-mihomo

Microsoft Store displayed this message:

Sorry about that. Something went wrong and Microsoft Store failed to initialize. Try refreshing or come back later.

The important signal was that regular desktop applications still had network access. A machine-wide outage or a stopped Clash core was therefore unlikely.

Start with the data path

With the system proxy enabled, the expected request path was:

textCopy
Microsoft Store (AppContainer)
        │
        │ connect to 127.0.0.1:7897
        ▼
Clash / verge-mihomo
        │
        ▼
Microsoft services

The broken edge was the first one, not the connection from Clash to the Internet.

Windows isolates AppContainer applications from the local loopback interface by default. A Win32 application reaching 127.0.0.1:7897 does not prove that Microsoft Store can do the same. Pointing the system proxy at a local listener exposes that difference.

Clash Fake-IP records only prove that a request entered Clash's DNS or proxy pipeline. Seeing an address from 198.18.0.0/15 is not enough to blame Fake-IP itself. Changing the DNS mode would have treated a symptom without proving the cause.

Evidence: eliminate corruption before changing anything

1. Verify that Clash is listening

Check port 7897 in PowerShell:

powershellCopy
Get-NetTCPConnection -LocalPort 7897 -State Listen

In this incident, verge-mihomo was listening normally. The proxy process and its local entry point were healthy.

2. Check the Microsoft Store package

powershellCopy
Get-AppxPackage -Name Microsoft.WindowsStore

The package status was Ok. With no evidence of package corruption, uninstalling or re-registering Store would have added risk without addressing the data path.

3. Check related Windows services

powershellCopy
Get-Service AppXSvc, BITS, InstallService, wuauserv

No service failure was found. Package corruption and stopped update services were now low-priority hypotheses.

4. Inspect the loopback exemption list

powershellCopy
CheckNetIsolation.exe LoopbackExempt -s

The list did not contain:

textCopy
microsoft.windowsstore_8wekyb3d8bbwe

The evidence now formed a complete chain: Store had to reach 127.0.0.1:7897, the proxy was listening, but the AppContainer did not have loopback access.

Minimal fix: exempt Microsoft Store only

Open PowerShell or Windows Terminal as Administrator and run:

powershellCopy
CheckNetIsolation.exe LoopbackExempt -a -n=Microsoft.WindowsStore_8wekyb3d8bbwe

Verify the result:

powershellCopy
CheckNetIsolation.exe LoopbackExempt -s

The output should now include:

textCopy
microsoft.windowsstore_8wekyb3d8bbwe

This grants loopback access to Microsoft Store only. It does not require disabling Clash TUN or the Windows system proxy, and it is narrower than relaxing isolation for unrelated applications.

If the local proxy is no longer used, remove the exemption with:

powershellCopy
CheckNetIsolation.exe LoopbackExempt -d -n=Microsoft.WindowsStore_8wekyb3d8bbwe

Clear stale state

After fixing the permission, clear state left behind by the failed requests.

1. Flush the DNS cache

powershellCopy
ipconfig /flushdns

2. Reset the Microsoft Store cache

Close Microsoft Store completely, then run:

powershellCopy
wsreset.exe

wsreset.exe clears Store state and restarts the application. It does not grant loopback access, so running it before fixing the permission may only reproduce the same failure after a clean restart.

Why 0x80073D02 was not the root cause

The event log also contained 0x80073D02. It indicates that Windows could not update Microsoft Store while the application was still using resources required by the update.

That was a separate issue:

• The loopback restriction explained why Store could not reach the local proxy.
• 0x80073D02 explained why a Store update could not finish while Store was running.

The correct response to the error code was to close Store and allow the update to finish. It was not evidence that the Store package was corrupted.

State after the fix

• Microsoft Store package status remained Ok
• Microsoft Store opened and refreshed normally
• The AppContainer loopback exemption was present
• Clash Verge TUN mode remained enabled
• The Windows system proxy remained 127.0.0.1:7897
• verge-mihomo continued running

If the problem returns

Use this order instead of reinstalling Store immediately:

1. Close Microsoft Store completely.
2. Confirm that Clash Verge and verge-mihomo are running.
3. Confirm that 127.0.0.1:7897 is listening.
4. Run CheckNetIsolation.exe LoopbackExempt -s and verify the Store exemption.
5. Run wsreset.exe, then reopen Store.
6. If it still fails, inspect Clash connection logs for Microsoft domain rules and test the selected proxy node.

A major Windows upgrade or system reset is a good reason to check the exemption again. Normal Clash configuration updates should not alter Windows AppContainer loopback permissions.

Takeaway

The misleading shortcut was to equate “Store cannot open” with “Store is broken.” A better troubleshooting sequence is:

1. Draw the request path.
2. Verify every node.
3. Identify the broken edge.
4. Change only that edge.

Here, the broken edge was Microsoft Store → 127.0.0.1:7897. A single-application loopback exemption fixed it. Reinstalling Store, disabling TUN, or changing Clash DNS mode was unnecessary.