Chrome maintains a blocklist of ports that belong to other protocols: mail (25), FTP (21), SSH (22), Telnet (23), X11 (6000), IRC (6665 to 6669), and dozens more. Asking a browser to send web traffic at those ports can be used to trick other services into accepting forged commands (a form post to port 25 looks dangerously like email), so Chrome refuses outright and shows this error. It is a safeguard firing, not a failure.
--port 8080 (or your framework's equivalent) is the entire fix in almost every case.:6000 or :25 from a copied address. Correct the port to the one the service actually serves HTTP on.--explicitly-allowed-ports) that can exempt a port for local testing, but it exists for protocol developers, not everyday browsing. Changing the service's port is safer, simpler, and permanent; treat any guide that leads with disabling the block as missing the point of why the block exists.If the port is imposed by a tool you cannot reconfigure, run a tiny local reverse proxy on a safe port that forwards to the blocked one; the browser talks to the safe port and the tool keeps its own. This is a standard workaround in development environments.
Which ports does Chrome block? Ports assigned to well-known non-web services: among them 1, 7, 9, 11, 13, 15, 17, 19, 20, 21 (FTP), 22 (SSH), 23 (Telnet), 25 (SMTP), 37, 42, 43, 53, 69, 77, 79, 87, 95, 101, 102, 103, 104, 109, 110, 111, 113, 115, 117, 119, 123, 135, 137, 139, 143, 161, 179, 389, 427, 465, 512 to 515, 526, 530 to 532, 540, 548, 554, 556, 563, 587, 601, 636, 989, 990, 993, 995, 1719, 1720, 1723, 2049, 3659, 4045, 5060, 5061, 6000 (X11), 6566, 6665 to 6669 (IRC), 6697, and 10080.
Why does my own local service on port 6000 not load? Port 6000 is the X11 window system port, so Chrome blocks it regardless of what you are actually running there. Your service is fine; it is squatting on a reserved number. Restart it on 6001 or any ordinary development port and it will load.