Something answered your browser, but what it sent was not an HTTP response the browser could parse. The usual story is a mismatch: the address points at a service that is not a web server at all (a database port, a mail port, a game server), or the scheme and the server disagree, an https:// address aimed at a server that only speaks plain HTTP, or the reverse.
https:// against a plain-HTTP server (or http:// against an HTTPS-only port) is the most common cause. Match them: most dev servers are plain HTTP on their custom ports, so http://localhost:3000, not https.Check that the process behind the port is the web server you think it is (another service may have taken the port), that TLS termination happens where you expect (a proxy passing raw TLS to a plain-HTTP backend produces exactly this), and that the server is not emitting a broken status line or headers. curl -v against the address shows the raw first bytes, which settles what is actually being sent.
If the raw response begins with something that is plainly another protocol's greeting (an SSH or SMTP banner, a database handshake), the address is simply pointed at a non-web service, and no browser setting will ever make it load.
Why does my browser show this for my router or printer admin page? Some embedded admin pages speak odd dialects of HTTP or sit behind redirects to non-standard ports. If the device's page works in one browser and not another, try its exact address including the port from the manual; the device is answering, just not in a dialect Chrome accepts.
Is ERR_INVALID_RESPONSE a security warning? Not as such; it means unparseable, not untrusted. But an intercepting portal or proxy that answers with its own content can produce it, so on an unfamiliar network treat it as one more reason to join the network properly or switch to one you trust.