Allow Chrome to Access the Network? Find the Rule That Blocks It

Updated: October 2026

A user can't open a page, and Chrome's error screen tells them to allow Chrome to access the network in the firewall or antivirus settings. That line is generic advice Chrome prints under a whole family of connection errors. Here's how to read the error, prove whether a firewall or antivirus is the blocker, find the exact rule, and fix it on one PC or a whole fleet.

What the Message Means

The sentence comes from Chrome's error page code. Under a "Try:" list, Chrome suggests checking the proxy, firewall or antivirus (the wording varies by error), and the expanded help reads "Allow Chrome to access the network in your firewall or antivirus settings. If it is already listed as a program allowed to access the network, try removing it from the list and adding it again."

Chrome attaches that suggestion to at least eight error codes, including ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_RESET, ERR_CONNECTION_REFUSED, ERR_CONNECTION_CLOSED and ERR_NAME_NOT_RESOLVED. Those usually mean a slow server, a dead site or a DNS problem. Only one error names the firewall directly: ERR_NETWORK_ACCESS_DENIED, where Chrome says "Firewall or antivirus software may have blocked the connection."

So read the grey error code under the message before you touch any setting.

Check Whether It's the Firewall at All

Five quick checks separate a firewall block from everything else:

1. One site or every site? If only one site fails, the site, its DNS record or a filter category is the problem, not a program rule.
2. Does Edge load it? Edge runs the same engine from a different executable, so a program rule for chrome.exe doesn't touch it. If Edge works and Chrome doesn't, look at Chrome-specific rules, extensions or Chrome policies.
3. Does a guest profile or incognito window load it? If yes, an extension is the likely blocker.
4. Is there a proxy or VPN in the path? Disconnect the VPN and retry before you edit any rule.
5. Does the name resolve? Resolve-DnsName example.com and Test-NetConnection example.com -Port 443 in PowerShell answer the DNS and TCP questions in two lines.

If the name fails to resolve, the fixes for DNS server not responding apply instead. If port 443 answers while Chrome still fails, look at a program rule or an antivirus web shield.

That thread is the usual shape of the ticket: everything else worked, and only one website failed.

Why "Allow an App Through the Firewall" Rarely Fixes It

Windows Firewall blocks incoming traffic unless a rule allows it, and allows outgoing traffic unless a rule blocks it. That's Microsoft's documented default. A browser loading a page makes outgoing connections, so on a default setup there's nothing to allow. The replies get back in because Windows Firewall is a stateful firewall that tracks each connection.

The "Allow an app through Windows Firewall" list manages inbound rules. Chrome only needs inbound for video calls, casting and local device discovery, which is when Windows Security asks "Do you want to allow public and private networks to access this app?"

Cancelling that prompt has a side effect. Microsoft documents that a cancelled or dismissed prompt creates block rules for the app, usually one for TCP and one for UDP. A standard user gets block rules whatever they click.

Block rules win. Microsoft's rule precedence says explicit block rules take precedence over any conflicting allow rule. Ticking Chrome in the allowed list does nothing while a block rule for chrome.exe exists. That's why Chrome's own help says to remove it from the list and add it again: removing clears the block.

List the block rules that name Chrome:

powershell
Get-NetFirewallRule -Action Block -Enabled True |
  Where-Object { ($_ | Get-NetFirewallApplicationFilter).Program -like '*chrome.exe' } |
  Select-Object DisplayName, Direction, Profile, PolicyStoreSourceType

Delete or disable the local ones. If PolicyStoreSourceType says GroupPolicy or MDM, the rule comes from central policy and will return on the next refresh. Fix it there.

Environments that block outbound traffic by default need an explicit allow rule. Rules take the full path, and Microsoft doesn't support wildcards in application rules:

powershell
New-NetFirewallRule -DisplayName "Allow Chrome outbound" -Direction Outbound `
  -Program "C:\Program Files\Google\Chrome\Application\chrome.exe" -Action Allow

Per-user installs live under %LOCALAPPDATA%\Google\Chrome\Application\ instead, so a rule for Program Files misses them. Check chrome://version for the executable path on the affected PC.

Find the Rule That Blocked Chrome

Windows Firewall, antivirus firewalls and VPN clients all plug into the Windows Filtering Platform, and it can tell you which one dropped the connection.

Turn on failure auditing for connections, reproduce the error, then turn it off again, because it's noisy:

code
auditpol /set /subcategory:"Filtering Platform Connection" /failure:enable
auditpol /set /subcategory:"Filtering Platform Connection" /failure:disable

Each blocked connection writes event 5157, "The Windows Filtering Platform has blocked a connection," to the Security log, with the application path, direction, destination and a Filter Run-Time ID. Run netsh wfp show filters, open the filters.xml it writes, and search for that ID. The filter entry names the provider that owns it. Windows Firewall rules show up by rule name, and a third-party antivirus shows up under its own provider.

Antivirus Firewalls and Web Shields

Third-party security suites add their own firewall, a web shield and often HTTPS scanning. Their blocks live in their own console, so the Windows allowed-apps list never shows them.

Web shields and HTTPS scanning cause two recognizable symptoms. ERR_CONNECTION_RESET on specific sites means the shield cut the connection. Certificate errors like NET::ERR_CERT_AUTHORITY_INVALID on every HTTPS site mean the scanner's root certificate isn't trusted by Chrome.

Open the product's blocked-connection log first; it names the URL or process it stopped. Add a scoped exception for that site or executable, and leave the shield on. Microsoft Defender's network protection usually raises a Windows Security notification when it blocks a site, which is quicker to confirm.

Proxies, SSL Inspection and PAC Files

Chrome on Windows uses the system proxy settings. A dead proxy, or a PAC file that's only reachable over VPN, produces timeouts that look like a firewall block. chrome://net-internals/#proxy shows the proxy Chrome is using.

SSL inspection breaks every HTTPS site at once when the inspection certificate isn't on the PC. Push it to the machine's trusted root store before you blame the browser.

Policy blocks look different. A Chrome URLBlocklist policy shows ERR_BLOCKED_BY_ADMINISTRATOR, and chrome://policy lists what's applied.

Local Network Access in Chrome

Since Chrome 142, a website that tries to reach devices on your local network, like a printer or router page opened from a cloud portal, asks permission to "look for and connect to any device on your local network." If a user dismissed it, no firewall rule will help. Reset the permission in that site's settings.

When Not to Add an Exception

An allow rule fixes a signed Chrome caught by a stale rule. Skip it in three cases.

The chrome.exe that got blocked isn't the real one. Check the path in event 5157 and run Get-AuthenticodeSignature on the file. A "chrome.exe" in a temp or AppData folder that isn't Google-signed is malware wearing the name.

The block comes from security policy. If a category of sites is blocked on purpose, the exception is a decision for whoever owns that policy.

The fix involves turning the firewall off. Microsoft advises against disabling Windows Firewall, and stopping its service outright is unsupported and can break the Start menu and app installs.

Fixing It Across a Fleet

On one PC, delete the stray block rule. On fifty, deploy rules centrally through Intune (Endpoint security > Firewall) or Group Policy. With local policy merge disabled, local fixes vanish on the next refresh anyway.

Then hunt for cancelled-prompt block rules before users find them: run the Get-NetFirewallRule query from earlier across your devices and report every hit, alongside the other PowerShell commands in your fleet audits. In OpenFrame, you can run that check as a script across a client's devices and collect the output in one place.

The Short Version

The Chrome message is a generic suggestion. Read the error code, rule out the site, DNS, proxy and VPN, then check for block rules on chrome.exe, because a block rule beats any allow. When you can't tell which product blocked it, event 5157 and the filter ID name the owner. If Chrome is also eating memory while you're in there, see Chrome using too much memory.