Chrome DevTools not able to connect to Node inspect since 7.5.0

[owenallenaz]

• Version: 7.5.0, 7.6.0
• Platform: Linux nodeServer 2.6.32-573.el6.x86_64 deps: update openssl to 1.0.1j #1 SMP Thu Jul 23 15:44:03 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux (VM) on Windows 10
• Subsystem: Debugger

When I run a script with --inspect, I am no longer able to connect via Chrome DevTools since Node 7.5.0. When I attempt to connect I get "Debugging connection was closed. Reason: WebSocket disconnected Reconnect when ready by reopening DevTools" Clicking reconnect DevTools does not reconnect."

Simple script:

> node --inspect=8080 -e "setTimeout(function() { console.log('yes'); }, 30000)"
Debugger listening on port 8080.
Warning: This is an experimental feature and could change at any time.
To start debugging, open the following URL in Chrome:
    chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:8080/e7cadd27-e1d6-42d3-8c53-c407dd543ec5

If I perform those steps on Node 7.4.0, it works. If I do the same steps in Node 7.5.0 or 7.6.0, the URL will no longer connect. I have the same results if I utilize Chrome 56.0.2924.87 or Canary 58.0.3025.0 on Windows.

I've recorded a screencast showing the steps to recreate and it functioning on 7.4.0 and failing on 7.6.0: https://www.screencast.com/t/vFyha8YI5

[mscdex]

/cc @nodejs/v8-inspector

[brantw]

I've also seen this. Debugging seems to work locally but not remotely. This also affects --debug as well as --inspect. For example, in node 7.6.0 I can node debug on the host running node, but cannot node debug server_name:5858 from another host. If I downgrade to 7.4.0 I am able to connect to the debugger remotely.

[bnoordhuis]

I suspect #9691 is responsible. It harmonizes option parsing with the old debugger but it presumably changed the default from 0.0.0.0 to 127.0.0.1 (although I'm 80% sure that was the default for --debug already.)

I'd say it's a good thing, security-wise. You can opt-out with --debug=0.0.0.0:5858 or --inspect=0.0.0.0:9229.

[sam-github]

Sounds like the debug port is bound to localhost by default now, since opening it to remote connections allows remote attackers unfettered access, but I don't see signs of this in the changelog.

But there should be a way to change the default if its explicitly wanted.

@ofrobots, do you know anything about this?

[eugeneo]

@sam-github
As @bnoordhuis pointed out, you can specify an IP address to listen on. Inspector is still an "experimental feature" so I did not think that this bugfix needed to be reflected in a change list...

[sam-github]

My comments and Ben's crossed on the wire.

It was an unexpected change in how node behaves, it should have been documented. Experimental doesn't mean "we don't tell you when we changed it, post a github issue if you'd like to know more". I don't think it means "we reserve the right to make breaking changes in minor updates" either. cc: @Trott

I think the change to default to localhost is a good one, but I'm not sure it should have happened before 8.x (though security fixes are allowed to majors even when breaking, the CTC has the power to give them special exemptions).

Btw, something is wrong here: https://github.com/nodejs/node/pull/9691/files shows zero changes in the diff, and no commits, but also says its merged. I haven't seen that before in github, it sure makes it hard to review the PR retroactively to see what was merged.

@eugeneo any idea what is going on with the PR?

[eugeneo]

I am not sure what had happened to the pull request display - the actual commit can be seen here - f9aadfb

But it looks like the change is really this one - #10878

[brantw]

I can confirm --debug=0.0.0.0:5858 does allow for remote debugging again in 7.6.0. I see why the change is beneficial from a security standpoint, but I wish there had been some docs for this change. It would have saved several cycles trying to track down why remote debugging stopped working.

[sam-github]

@eugeneo can you PR some docs for the current state, something saying what address is listened on by default?

[owenallenaz]

While the --debug pathway might work, I'm not sure if there is a way to get the --inspect pathway as it stands on 7.60. I've tested a couple different variants. Looking at the code in the commit, it was altered to use host pretty much everywhere, but if you look at the original code, sometimes it was 0.0.0.0 and othertimes it was 127.0.0.1. Well with the host var it's using the same value everywhere, even though previously it was 2 distinct values. In example the URL that was spit out always contained 127.0.0.1 but then the there was the line for uv_ip4_addr("0.0.0.0", port_, &addr); which had 0.0.0.0 hardcoded.

I've tried variants of passing --inspect=0.0.0.0:8080 and using the URL given back as well as altering the url to contain 127.0.0.1:8080. I've also tried the opposite where I pass --inspect=127.0.0.1:8080 and use the URL or switch the url to be 0.0.0.0:8080. None of the attempts work. Some of them will "connect" but it's a weird state where I'm not able to actually get to any of the sources files, or interact with anything, but it's not giving me the disconnection error.

If someone has figured out a proper set of steps to use --inspect or --debug but connect via Chrome, I'm happy to use it as a work-around. For now we've just reverted back to 7.4.0 in the meantime.

[eugeneo]

I don't think remote debugging was tested enough. I am assigning this over to me - I see issues like json/list returning 0.0.0.0 as a host name (should be detected), I also expect other similar problems.

[oldrich-s]

I also experience issues with --inspect since version v7.5.0. When I install v7.4.0 the inspector works just fine. As soon as I install v7.5.0 or higher the inspector ends with empty sources, i.e. no files are present. Sometimes if I wait long enough the files in sources appear. Still I am not able to set any breakpoint in the files. To me something went really bad between version 7.4.0 and 7.5.0...

[sam-github]

It sounds like an unintended semver-major occurred between 7.4 .and 7.5, should it be reverted? @nodejs/ctc

Change was:

• default listen address for --inspect changed to localhost

Which is particularly problematic because there seems to be a (unrelated?) bug in the inspect option:

• using unspecified/INADDR_ANY listen address does not work

[eugeneo]

@czb what you are seeing sounds like #11589 - fix was merged in last Friday.

[eugeneo]

I performed some tests and the only issues I've seen had been caused by the code returning wrong IP addresses in the JSON responses - that was just fixed.

I believe this can be closed now.

[safizn]

Hi there, fixed. It works with latest versions 7.5+.
Had to change to a specific IP, rather than using 0.0.0.0 as NIM automatically would use it, instead of a fixed IP.

[jpike88]

This is still a rather annoying change. It would have been nice to just another parameter like --inspect-insecure or something... there's already a hash in the URL to protect against hijacking.

[nsisodiya]

I was using node app inside docker. I was unable to dubug it in Chrome dev tools. Later I found that, I have to change syntax.

FROM

nodemon --inspect ./src/server.js --exec babel-node -e js

TO

nodemon --inspect=0.0.0.0:9229 ./src/server.js --exec babel-node -e js

Now debug is working.

[kenny-reyes]

This works for me @nsisodiya.

Thanks

[AlexanderAllen]

Took a while to get this working.
Confirmed that @nsisodiya solution works.

Docker Compose

  node:
    image: node:8.0-alpine
    volumes:
      - ./apps:/opt/apps
    ports:
      - 9229:9229
    expose:
      - 9229

Make sure to publish ports, otherwise connection refused:
docker-compose run --rm --service-ports node bash

Verified using "localhost" instead of 0.0.0.0, but --inspect-brk=0.0.0.0:9229 works as well!

bash-4.3# node --inspect-brk=localhost:9229 index.js
Debugger listening on ws://localhost:9229/33dc4d2a-7a17-47ac-bf64-f66329d60872
For help see https://nodejs.org/en/docs/inspector
Debugger attached.

On Chrome:

chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/14b1c01b-e7f4-40e2-8b59-e914b38209d1

I'm using the Node.js V8 --inspector Manager (NiM) Chrome plugin as well to get to the chrome-devtools address.

[sheetaldubey]

i have node 7.4.0 and i am using mac. As I am starting node server in debug mode

node --debug server.js

The server starts successfully by giving message as Debugger listening on 127.0.0.1:5858

but my chrome not able to load 127.0.0.1:5858.

Any workaround for this.?

[bnoordhuis]

@sheetaldubey --inspect, not --debug. Also, you should probably upgrade to the latest v7.x or v8.x release.

[MohammedEssehemy]

Thanks @nsisodiya

[PopradiArpad]

To debug a node.js service in a docker stack from the Chrome DevTools locally you need to configure
the listening port of the debugger with the long syntax and the inspect parameter as @nsisodiya said :

    command: node --inspect=0.0.0.0:9229 some.js
    ports:
      - target: 9229
        published: 9229
        protocol: tcp
        mode: host

That's all...chrome://inspect will be able to detect the listening debugger as usual.
Remarks:

1. It's possible that the network must be attachable.
2. Current Chrome has problem with a docker network on localhost. Use 127.0.0.1 instead.

[danielo515]

How can I activate remote debugging it on an already running process when I activate the debug protocol by using kill -s SIGUSR1 ?

[dechamp]

@bnoordhuis Dude, you saved me!!! I spent 3 hours trying to figure out why my inspectors wouldn't work. I knew it had mostly to do with me running via docker. But the bind to 0.0.0.0 solved it!!!! You rock!

[wzup]

Can't debug live.
This alert pops up every time I try to save a file. What's that? It's not possible to debug/develop when debugger doesn't reload automatically

I use nodemon to reload my node.js server. My config for it:

{
    "restartable": "r",
    "verbose": true,
    "env": {
        "NODE_ENV": "development",
        "DEBUG": "app:*",
        "DEBUG_COLORS": true
    },
    "ignore": ["routes/___*.js", "routes/___*.html"],
    "debug": true,
    "ext": "js dust html css scss rb json htpasswd",
    "exec": "set DEBUG=express-mysql-session* & node --inspect=0.0.0.0:9229 --debug-brk ./bin/www"
}

Chrome 63.0.3239.108 (Official Build) (64-bit)
Node v6.11.5
Windows 10 64x

[JeffML]

Got this working. In package.json:

"scripts": {
		"debug-remote": "babel-node --inspect=0.0.0.0:9229 ./app.js nocluster",

Then run
npm run debug-remote

and on my local box, go to node-inspector:

chrome://inspect/#devices

add (via configure) the remote device:

172.00.00.00:9229 // replace IP with real remote IP address

Save it, and the remote target list should give you a connection link. Click it and you're good to go.

[MagikLau]

Oh My Lord @bnoordhuis, I try node --inspect-brk xx.js for 4days' debugging without any work.
Finally !!! node --inspect=0.0.0.0:9229 --inspect-brk xx.js works!!!

[softmantk]

I am using puppeteer to launch headless chrome. The problem with me is that I can't use a static port.
The application is being used by multiple users. Each users have to have a chrome browser open to themselves. So I need to expose multiple ports in docker. but it needs to be dynamic.

[creativesoftwaregun]

Current setup is a VM hosted on VMWare using NAT and port 9229 forwarded from VM to host.
NodeJs is v8.10 and Chrome is v71 and the below command works

node --inspect-brk=0.0.0.0:9229 sample_debug.js

thanks to @bnoordhuis @nsisodiya

[fzhange]

use node inspect ./index.js in node 12. it works