net::ERR_UNSAFE_PORT - this site can't be reached (blocked port)

What’s actually happening

You type or click a URL with an explicit port like :6000 or :87 and Chrome immediately shows "This site can't be reached" with ERR_UNSAFE_PORT. It never sends a request — DevTools Network shows nothing, because the browser kills it before the socket opens. Firefox shows its own "This address is restricted" message for the same ports. Drop the port (or move the service to 80/443/3000/8080) and it loads fine.

Common causes

• The site or dev server is bound to a port on Chromium's restricted list — e.g. 21 (ftp), 22 (ssh), 25 (smtp), 110 (pop3), 143 (imap), 6000 (X11), 6666, 87, 540
• Following a link that hard-codes one of those ports, or a redirect that lands on one
• A reverse proxy or container mapping that exposes the app on a blocked host port
• X11/VNC/legacy-service ports (6000, 6665-6669) reused for a web app — these get blocked because browsers treat them as attack vectors for cross-protocol requests
• A typo in the port (e.g. :22 instead of :2222)

How to fix it

1. Move the service off the blocked port — this is the real fixRe-bind the app to 80, 443, or any non-restricted port like 3000, 5000, 8080, or 8443. For a typo, just correct the URL. The blocked-port list exists because protocols like SMTP/FTP tolerate junk input, so a malicious page could smuggle commands through a browser request to them — don't fight that, route around it.
2. If it's a dev box and you can't move it, allow the port explicitly (Chrome)Launch Chrome with --explicitly-allowed-ports=6000 (comma-separate for several: --explicitly-allowed-ports=6000,6666). On macOS: open -a "Google Chrome" --args --explicitly-allowed-ports=6000. This is a local override for your machine only and does nothing for real visitors.
3. Allow the port in Firefox via about:configOpen about:config, create a string pref network.security.ports.banned.override, and set it to the port or range (e.g. 6000 or 6000-6010). Firefox-only and per-profile — again, not a fix you can ship to users.
4. In production, terminate on 443 with a proxyPut Nginx, Caddy, or a load balancer in front, listen on 443, and proxy back to the app's internal port. Users only ever see the safe public port, so ERR_UNSAFE_PORT can't fire for them regardless of what the backend binds to.
5. Check the full Chromium blocked-port list before picking a portThe list includes 1, 7, 9, 11, 13, 15, 17, 19, 20, 21, 22, 23, 25, 37, 42, 43, 53, 69, 77, 79, 87, 95, 101-104, 109-111, 113, 115, 117, 119, 123, 135, 137-139, 143, 161, 179, 389, 427, 465, 512-515, 526, 530-532, 540, 548, 554, 556, 563, 587, 601, 636, 989, 990, 993, 995, 1719, 1720, 1723, 2049, 3659, 4045, 5060, 5061, 6000, 6566, 6665-6669, 6697, and 10080. Avoid all of these for a web service.