ERR_UNSAFE_PORT error

Why browsers block ports

ERR_UNSAFE_PORT is a client-side rejection. A subset of TCP ports are reserved or are common homes for dangerous services, and Chrome blocks web requests to those ports from a page as a security measure, refusing to connect at all. When a URL or a page-internal resource points at one of those ports, the browser aborts the connection and shows ERR_UNSAFE_PORT instead of loading it. The blocked list includes ports such as 19, 22, 23, 25, 80 (as a request target), 110, 143, 389 and a few others; the exact set is maintained in the browser's source.

This is unrelated to whether the server works, which is why it belongs alongside the website not loading family: the site can be perfectly reachable from curl, yet the browser will not talk to it because the URL itself is disallowed. Compare with the ERR_CONNECTION_RESET case, where the connection is attempted and then torn down, versus this one, which is refused before connecting.

Find the offending URL

The error is almost always caused by a link or redirect that hard-codes a restricted port. Common scenarios are a plain-HTTP document that references http://site:25/ or http://site:23/, a mail-style service exposed on the web, or a test server started on a port that browser security happens to reserve. Because the block happens before any data travels, the error tells you very little about the server; the diagnosis is a URL audit.

Look for the restricted port in any of three places: the address bar (a manually visited or redirected URL), the page source (an <a> or <img> or script referencing a blocked port), and the server's own redirect targets. A single in-page reference to a blocked port can trip the error for the whole framing document. Search the rendered output and any server-side redirect strings for :port where the port is in the blocked set, then correct the reference to the normal service port, which for web apps is almost always 80 or 443.

Fix for local development

For local development, a project occasionally needs a port the browser blocks by default. Chrome lets you allow specific ports explicitly for that exact purpose, but it is a development-only escape hatch, not something to ship instructions for in production.

# Windows
chrome.exe --explicitly-allowed-ports=11881

# macOS / Linux
google-chrome --explicitly-allowed-ports=11881

Launching the browser with --explicitly-allowed-ports=<port> permits that port so your local server can be reached. This is legitimate only when you control the environment and the port, as you might with a local nginx or a test harness. For anything on the public web, do not instruct visitors to override the block; instead serve the resource on a normal web port, which is the site unreachable article's practical stance on avoiding client-side workarounds. If you discover an external service hard-coded to a restricted port and you cannot change it, treat that as a warning that the service was designed for internal use and should not be exposed on the open web.