v6.7.0 V8_inspector link does not work on macOS 10.12 Chrome 53

[JLHwung]

• Version: v6.7.0
• Platform: Darwin jh.local 16.0.0 Darwin Kernel Version 16.0.0: Mon Aug 29 17:56:20 PDT 2016; root:xnu-3789.1.32~3/RELEASE_X86_64 x86_64
• Subsystem: V8_inspector
• Chrome: 53.0.2785.116

Here is a simple forever node daemon

echo "setInterval(() => console.log('Hello world'), 1e3)" > index.js

node --inspect index.js will show

To start debugging, open the following URL in Chrome:
    chrome-devtools://devtools/remote/serve_file/@60cd6e859b9f557d2312f5bf532f6aec5f284980/inspector.html?experiments=true&v8only=true&ws=localhost:9229/node

However, when opening this link on Chrome 53.0.2785.116, the left sidebar is empty. one cannot see any files (index.js) on the panel.

Opening this link on Chrome Canary 55 looks good to me, though.

I use --inspect daily and AFAIK Chrome 53 works good on v6.6.0.

[targos]

/cc @nodejs/v8-inspector

[evanlucas]

hm, I'm unable to reproduce on the same OS and Chrome

[fhinkel]

I can reproduce the problem.

But it works if I run with break on first line:
node --inspect --debug-brk index.js.

Manually opening the file as suggested with Cmd+P also works.

[gibfahn]

Also unable to reproduce.

[JLHwung]

@fhinkel I do a reset settings on Google Chrome and now it works both on --inspect and --inspect --debug-brk. So it's likely due to Chrome configuration issues.

I think this problem can be closed if @fhinkel confirms no reproduction after reset.

[Taivas]

@JLHwung I got the same problem and It works! Thank you man!

[Taivas]

So sad it happened again 10 min later. So reset settings is not a long term solution. Also I can reproduce @JLHwung 's case.

[JLHwung]

I don't realize I can debug v8-inspector front-end until I press command+j accidentally on v8-inspector. It feels like Inception somehow but finally the problem is clear:

It seems that v8-inspector can not establish connection to localhost:9229/node due to a SSL protocol problem.

@fhinkel settings reset solves my problem at first but after couple of hours it happens again. No idea how to trigger this problem.

@Taivas I am more than happy to help you but it seems configuration reset is not a perfect workaround.

[fhinkel]

Have you tried running with with --debug-brk instead of resetting the config?

[JLHwung]

@fhinkel I tried but got no luck. Still SSL Protocol issue. What does your console on v8-inspector complain on --inspect?

[eugeneo]

CC: @ak239 Any thoughts?

[spamguy]

Seeing the same thing, with the same setup. I downgraded to v6.6.0, since @JLHwung mentioned earlier success with it, but no go. Meanwhile, my home computer (also a Mac on 10.12 + Chrome 53 + node 6.7.0) handles --inspect fine. There's an unknown variable in play here.

[JLHwung]

@spamguy I just try downgrading to 6.6.0 and same thing happens. As @fhinkel get work with --debug-brk, have you tried --debug-brk? mine also see the SSL Protocol Error on --debug-brk.

[spamguy]

--debug-brk made no difference. But, the suggestion to use Chrome Canary did work.

[eugeneo]

Looks like this has something to do with Chrome itself - there is no reason for it to try and use SSL for devtools connection.

Canary working might be due to the fact of some fixes on Chrome site or a result of different Chrome profile.
Do you think there might be some Chrome extension installed or some setting enabled that forces SSL?

Note that there is a chance the problem will "fix itself" when Node switches to latest protocol so Chrome will be able to use the latest devtools.

[JLHwung]

@eugeneo

there is no reason for it to try and use SSL for devtools connection.

Thank you for explanation on debug protocol. 🙏

Do you think there might be some Chrome extension installed or some setting enabled that forces SSL?

I just try opening the debugger link (both --inspect and --debug-brk) on Chrome with Private Mode (which means no extension by default), still SSL Protocol error.
Chrome Canary with Private Mode works well.

[ghafran]

I was able to workaround this issue by using the ip address instead of a dns name.

Instead of :
chrome-devtools://devtools/remote/serve_file/@60cd6e859b9f557d2312f5bf532f6aec5f284980/inspector.html?experiments=true&v8only=true&ws=server.com:4000/4f4a5721-1d81-46e6-9197-12d390aa251e

Use:
chrome-devtools://devtools/remote/serve_file/@60cd6e859b9f557d2312f5bf532f6aec5f284980/inspector.html?experiments=true&v8only=true&ws=192.168.99.100:4000/4f4a5721-1d81-46e6-9197-12d390aa251e

[JLHwung]

@ghafran Great appreciation on the workaround. I succeed after replacing localhost by 127.0.0.1, while [::1] does not work.

[JLHwung]

Inspired by @ghafran, I think this issue is likely of HSTS configuration. It should have nothing to do with v8-inspector and Chrome.

For those who have the same issues, please check the following settings

1. go to chrome://net-internals/#hsts
2. On Query Domain panel, input localhost and click Query
3. If there is any result, go to Delete Domain panel, input localhost and click Delete.
4. Now check if v8-inspector works or not.

Final Solution:

For devs who does not deliberately add localhost to HSTS settings, please check if there is any HSTS header configuration on your local dev websites. You have to remove HSTS header configuration on localhost or you will be rendered into the same situation after you visit your localhost website.

HSTS settings explains that it works after Chrome setting reset, but the same issue occurs after couple of hours after you visited your localhost dev website, because Chrome will add localhost to HSTS and use SSL on websocket to localhost:9229

I think it can be safely closed after folks confirmed this solution works.

[Trott]

This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that.