In Windows 11, Universal Windows Platform (UWP) applications, modern packaged desktop apps, and Microsoft Store utilities run inside isolated execution sandboxes known as AppContainers. AppContainers isolate modern software from system-level resources, arbitrary files, and local network subsystems to prevent privilege escalation and malware propagation. As part of this security architecture, Windows enforces network isolation: by default, applications executing within an AppContainer are strictly forbidden from initiating network requests to the local host (127.0.0.1 or localhost).
While this restriction provides crucial defense-in-depth against malicious packaged software attempting to exploit unauthenticated local servers or management services, it presents a substantial challenge during software development, API debugging, and local proxy routing (such as using Charles Proxy, Fiddler, or local Docker API microservices). Fortunately, Windows incorporates a dedicated diagnostic binary, CheckNetIsolation.exe, which allows system administrators and developers to grant targeted loopback exemptions. This detailed guide demonstrates how to inspect, grant, and manage AppContainer loopback exemptions in Windows 11.
Understanding Why Windows Blocks Loopback Connections for Store Apps
Legacy Win32 applications run with broad user privileges, allowing them to freely bind to and query local loopback sockets. In contrast, modern packaged applications operate under AppContainer profiles with granular network capability declarations, such as internetClient or privateNetworkClientServer.
Crucially, even if an application possesses full private and public network permissions, the Windows TCP/IP stack automatically filters loopback packets originating from an AppContainer SID (Security Identifier). Attempting to connect a UWP web client or modern application to a local development server running on http://localhost:8080 will trigger immediate connection aborts or socket refusal errors.
To inspect your wider network configuration and TCP stack parameters, review our comprehensive tutorial on how to configure TCP/IP stack settings and congestion providers in Windows 11 using PowerShell.
Locating the AppContainer SID and Package Family Name
To grant an exemption, you must identify either the Package Family Name (PFN) or the unique AppContainer SID of the target application.
Method 1: Querying Package Family Names with PowerShell
- Press Win + X and choose Terminal (Admin) or launch an elevated PowerShell prompt.
- Execute
Get-AppxPackagefiltered by the application’s common name:Get-AppxPackage -Name *Edge* | Select-Object Name, PackageFamilyName - Copy the returned
PackageFamilyNamestring (for example,Microsoft.MicrosoftEdge_8wekyb3d8bbwe).
Method 2: Inspecting SIDs with CheckNetIsolation
You can also instruct CheckNetIsolation to dump all registered AppContainers and their associated SIDs:
CheckNetIsolation.exe LoopbackExempt -s
This command lists all current loopback exemptions along with their application names and SID strings.
Granting a Loopback Exemption Using CheckNetIsolation
The CheckNetIsolation.exe command-line utility provides dedicated flags to manage loopback permissions without compromising the overall integrity of the operating system.
1. Adding an Exemption by Package Family Name
The most straightforward approach uses the -p flag followed by the target Package Family Name:
CheckNetIsolation.exe LoopbackExempt -a -p=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
Windows will return OK. immediately upon registering the policy change.
2. Adding an Exemption by AppContainer SID
If you are developing a standalone sandboxed binary or working with unpacked test builds where a full PFN is absent, you can exempt the specific SID using the -n flag:
CheckNetIsolation.exe LoopbackExempt -a -n=S-1-15-2-123456789-987654321-1234567890
Auditing and Listing Active Loopback Exemptions
To confirm that your changes have been committed to the Windows network isolation table, execute:
CheckNetIsolation.exe LoopbackExempt -s
The console will output the complete inventory of exempt containers, structured as follows:
List Loopback Exempted AppContainers
[1] -----------------------------------------------------------------
Name: Microsoft.MicrosoftEdge_8wekyb3d8bbwe
SID: S-1-15-2-3624051433-2125758914-1423191267-1740899205-1073925389-3782572162-737981194-4256926729-3178206596-2189128311-222138129
OK.
Revoking Loopback Exemptions
Once local development or proxy diagnostics are complete, you should remove the exemption to restore default security boundaries:
1. Removing an Individual Application
CheckNetIsolation.exe LoopbackExempt -d -p=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
2. Purging All Loopback Exemptions
If multiple experimental exemptions have accumulated and you wish to standardise the environment back to factory defaults:
CheckNetIsolation.exe LoopbackExempt -c
This command clears the exemption registry completely, locking down all AppContainers.
Automating Loopback Permissions with PowerShell
For automated CI/CD pipelines and developer workstation deployment scripts, you can script loopback enablement using PowerShell:
$AppNames = @("Microsoft.WindowsTerminal", "Microsoft.MicrosoftEdge")
foreach ($App in $AppNames) {
$Pkg = Get-AppxPackage -Name "*$App*"
if ($Pkg) {
Write-Host "Enabling loopback for $($Pkg.PackageFamilyName)" -ForegroundColor Cyan
CheckNetIsolation.exe LoopbackExempt -a "-p=$($Pkg.PackageFamilyName)"
}
}
If your enterprise workstations communicate with local storage shares alongside localhost APIs, ensure your transmission channels are secured according to our walkthrough on how to configure SMB signing and encryption in Windows 11 using PowerShell.
Troubleshooting CheckNetIsolation Failures
1. “Access Is Denied” Error
Modifying network isolation rules alters protected system security policies. Ensure that your command prompt or PowerShell instance is running under an elevated administrator context (Run as administrator).
2. Exemption Succeeded but Localhost Still Inaccessible
If CheckNetIsolation reports OK. but the application still cannot establish socket connections to localhost:
- Verify Windows Defender Firewall rules: local listening ports must allow inbound connections from the loopback interface.
- Ensure your local server is binding to
0.0.0.0or explicitly to127.0.0.1rather than only to IPv6::1if the client application is querying via IPv4. - Restart the target modern application so its network sandbox reloads active isolation policies.