UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36

Steps to reproduce the problem:
1. Have Chrome running on a host (chrome.example.com)
2. Try to connect to a remote Chrome devtools url, such as chrome.example.com/json

What is the expected behavior?
Should allow remote connection to debugger and give a valid response to the connection request.

What went wrong?
Request is rejected with message "Host header is specified and is not an IP address or localhost."

Did this work before? Yes Version before  issue 813540  was fixed

Chrome version: 69.0.3497.100  Channel: stable
OS Version: 10.0
Flash Version: 

Due to CVE-2018-6101, reported/fixed in  https://crbug.com/813540 , it is no longer possible to connect to a remote Chrome instance if the request has a Host header whose value is not an IP address or "localhost".

This happened due to the CVE-2018-6101 fix that closed an exploit. However, this also prevents the legit use case of having Chrome running on a remote host that is accessed via its hostname and not the direct IP, causing issues if there is something else in front of Chrome (nginx etc) that needs a host header to route the request to Chrome, and thereby passing the host header along to Chrome.

It was suggested by the reporter of 813540 to add a flag that would let users set accepted hostnames for a request (for example "--remote-debugging-hosts=custom.local,foo.example.com"), but unfortunately this was not included in the fix.

The fix makes sense to prevent publicly exposed Chrome instances from being exploited, but also prevents use cases where the Chrome instance is otherwise secured, and allows no way to bypass this.