Is my server broken if I get ERR_UNSAFE_PORT?

No. This error is generated entirely inside Chrome before any packet leaves your machine. The port can be wide open and the service perfectly healthy — Chrome simply refuses to connect to that port number over HTTP or HTTPS. curl, another tool, or the same site on a different port will all work.

Which ports does Chrome block?

A fixed list of roughly 80 ports tied to non-web protocols — the WHATWG Fetch 'bad ports' list shared across browsers. It includes obvious ones like 22 (SSH), 25 (SMTP), and 21 (FTP), but the ones that surprise developers are 6000 (X11), 6666–6669 and 6697 (IRC), 2049 (NFS), and 10080. Common app ports like 3000, 5000, 8000, and 8080 are not blocked.

Can I just allow the port instead of moving my service?

You can, on your own machine, with the launch flag --explicitly-allowed-ports=PORT (Edge and managed Chrome have an equivalent policy). But that only fixes your browser — every visitor still hits the block. It is a local testing escape hatch, not a fix for a site other people use.

Views: 17

ERR_UNSAFE_PORT: Chrome Blocked the Port

ERR_UNSAFE_PORT means Chrome blocked the port, not the site. Confirm the port is open in 3 checks and move it off the blocklist. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Chrome refuses to load a URL and shows ERR_UNSAFE_PORT (net error -312). The address usually has an explicit port in it, like http://example.com:6000 or http://localhost:6666.

Symptoms

The failure is instant. There’s no loading spinner, no timeout — Chrome rejects the address before making a connection.
The same URL works in curl, Postman, or a plain TCP client. The port is reachable; only the browser won’t touch it.
It only happens on certain port numbers. Move the exact same service to :8080 and it loads fine.
Firefox shows a different but equivalent message (“This address is restricted”), which is the tell that this is a browser policy, not your server.

What ERR_UNSAFE_PORT Actually Means

Chrome ships with a hardcoded blocklist of ports it will not open over HTTP(S), and ERR_UNSAFE_PORT is what you get when you aim it at one. This has nothing to do with whether your service is running. It’s a decision made inside the browser, before a single packet goes out.

The reason is an old attack class called cross-protocol scripting (the HTML Form Protocol Attack, documented back in 2001). Many plaintext protocols — SMTP, FTP, IRC, NFS — parse input leniently, ignoring lines they don’t understand. A malicious web page can submit a form or fetch a resource pointed at, say, port 25, and the browser dutifully sends an HTTP request there. The mail server ignores the HTTP noise but happily executes the SMTP commands the attacker smuggled into the request body. To slam that door, browsers refuse to connect to the ports where those services traditionally live.

The list is the same “bad ports” set defined in the WHATWG Fetch standard, so Chrome, Edge, Firefox, and Safari all block roughly the same ~80 ports. Most are obvious infrastructure ports nobody serves a website on. The trap is the handful that developers do reach for when picking a port out of the air: 6000 (X11), 6666–6669 and 6697 (IRC), 2049 (NFS), and 10080. Spin a dev server up on 6666 because it looked free, and Chrome will refuse to load it while every other tool connects without complaint.

Crucially, the port is not closed. That’s the whole diagnostic: prove the port is open and reachable, and you’ve proven the problem is Chrome’s blocklist, not your network.

Diagnose with DechoNet

Port Check to confirm the port is actually open and accepting connections. If it reports open, the service is fine and the block is 100% browser-side — you’re not chasing a firewall.
HTTP Check to fetch the URL from outside your browser. A normal response (or any HTTP status at all) proves the server answers on that port and the block only exists in Chrome.
DNS Lookup if you’re unsure the hostname even points where you think — rule out a stale record before blaming the port.

Resolution Checklist

Read the port number in the URL and check it against the blocklist. If it’s 6000, 6666, 6697, 10080, or another non-web port, that’s your answer.
Run a Port Check on that host and port. Open + reachable confirms the service is healthy and the block is Chrome’s.
The real fix: move the service to a port outside the list — 8080, 8000, 3000, or put it behind a reverse proxy on 443. This fixes it for every visitor, not just you.
Local testing only: launch Chrome with --explicitly-allowed-ports=6666 (or the Edge/Chrome ExplicitlyAllowedNetworkPorts policy) to bypass the block on your own machine. Don’t ship this as the solution — nobody else has that flag set.
Re-test in a normal browser window after moving the port to confirm the error is gone for a default configuration.

When to Escalate

If the service must live on a blocked port (a legacy internal tool bound to a fixed port you can’t change), front it with a reverse proxy or port-forward on an allowed port rather than telling users to edit browser flags.
If you can’t move the port and can’t proxy it, the port block is expected behavior, not a bug — the escalation is a design decision about where the service should listen, not a browser or network fault to be worked around.