Chrome 156 Blocks Local Network? How to Grant Access (2026)

You open your router’s admin page from a public site and the connection dies without a word. Your 127.0.0.1 dev server, your smart-home dashboard: same. It is Chrome’s Local Network Access restriction, which has put a per-site permission prompt in front of these requests since Chrome 142. Chrome 156, scheduled for stable on October 20, 2026, will remove the last enterprise opt-out, and each site’s grant or denial sticks.

Key takeaways

• Chrome 156 removes the opt-out. The temporary LocalNetworkAccessRestrictionsTemporaryOptOut policy is dropped in Chrome 156 (stable, scheduled October 20, 2026), so managed browsers lose the option to downgrade blocked local network requests to a DevTools warning.
• Granting is per site. The first local network request from a given site triggers a permission prompt. Accepting it lets that one origin reach your LAN, and you can revoke it later.
• Denying is sticky. If you deny, Chrome does not re-prompt that site. The local destination stays down until you flip the permission back on.

What the restriction actually blocks

Chrome 142 turned this on by default and put it behind a permission prompt. A local network request is any request from a public website to a local IP address or to loopback, or from a local (intranet) site to loopback. Google’s stated aim is to blunt cross-site request forgery against devices on your network (the router is the classic target) and to stop sites from using these requests to fingerprint your LAN.

Two details shape what you will feel. The permission only exists in secure contexts, and once you grant it Chrome relaxes mixed-content blocking for requests it already knows are local: a private IP literal, a .local name, or a fetch with targetAddressSpace: "local".

The address spaces that count as local are the private IPv4 ranges (RFC1918), the link-local 169.254.0.0/16, the IPv6 unique-local fc00::/7, the IPv6 link-local fe80::/10, and IPv4-mapped IPv6 addresses that map to a local address. Loopback is 127.0.0.0/8 and ::1. One edge case: carrier-grade NAT uses 100.64.0.0/10, which can still trip the prompt on a public site. The LocalNetworkAccessIpAddressSpaceOverrides policy lets a fleet reclassify it.

Not every connection is covered. As of the May 2026 adoption guide:

• In scope: subresource requests, fetch() calls, and subframe navigations (since 142), plus WebSocket and WebTransport (since 147).
• Out of scope: WebRTC, main-frame navigations, extensions that already hold host permissions, and Android WebView (Android applies its own local network permission there).

How to grant a site local network access

The prompt appears the first time a site makes a local network request, and it is tied to that site’s origin. Two grants sit behind it. local-network covers a public site reaching a device on your LAN, such as a router or an internal server. loopback-network covers a public site reaching an app running on the machine you are using. Chrome 145 split the original single local-network-access permission into these two and kept the old name as an alias.

Accept the prompt and that origin can reach the local network from then on. The decision is persistent and per site, so a site you allow keeps working and a site you deny stays blocked. To change it after the fact, re-grant the local network permission from the site’s permission entry in Chrome’s settings.

For developers, the prompt can be triggered on purpose (Chrome 144 and later). A request to a local or loopback address pre-fires it, and it only fires if a connection would actually be established:

// pre-trigger the local network prompt; fires only if the request would connect
await fetch("http://localhost");
await fetch("https://10.0.0.1");

If the local request lives in an iframe, the embedding page delegates the permission through its Permissions-Policy, and the grant is tied to the embedding origin:

<iframe ... allow="local-network"></iframe>

What a denial does, and the version timeline

A denial has no second chance built in. If you deny a site, Chrome will not show the prompt for that site again, so a denied local destination stays broken until you go back and re-grant it. There is no automatic re-prompt.

The restriction has moved across a handful of releases. As of this article’s September 2026 publication, these are the versions that shaped the behavior:

The managed (enterprise) path

For a single person at home, the prompt is the whole story. For a fleet, the enterprise policies are where the control lives, and Chrome 156 tightens it.

The temporary opt-out policy (LocalNetworkAccessRestrictionsTemporaryOptOut, boolean, off by default since 142) made local network requests only warn in DevTools instead of blocking. That was the escape hatch for teams that were not ready. Chrome 156 is scheduled to remove it, so managed browsers will have no soft warning mode left. The remaining managed levers:

Precedence, from the enterprise policy template, runs in a fixed order: within each pair the block list beats the allow list, and the granular LocalNetwork pair sits above the LocalNetworkAccess pair. Until these policies appear in the main Admin Console UI, you set them through custom configurations.

One footnote on the date. The adoption guide says the opt-out is removed “after M152” and the policy template says “after M163,” but the chromestatus record (the newest source, last updated July 2026) is the one that names 156, so 156 is the number to plan around.

When the built-in restriction is enough

If you rarely reach your router or a dev server from a public site, you may never see the prompt, and that is fine. The restriction does not touch WebRTC, main-frame navigations, or extensions with host permissions.

The decisions that matter:

• If one specific LAN site needs to just work, grant that site’s local network permission. It is per site and you can revoke it, so you are not opening the door to every origin.
• If you are locking down a fleet and want only approved devices reachable, set LocalNetworkAccessAllowedForUrls (and the block lists) as custom configurations. The temporary opt-out you may be relying on today ends with 156.
• If you are still on a pre-156 build and using the temporary opt-out to keep a not-ready fleet functional, migrate now. The policy that softens the block into a DevTools warning is gone in 156, so the allowlist becomes the lever.